Entries tagged with “breach”.


Just published a blog entry on my McAfee official blog. It talks about some of the trends of database security as we see them from the global McAfee Threat Report.

Just today I reviewed Verizon’s Intellectual Property Theft and it has a large section about databases, privileged users and compromised assets.

The one figure that caught my eye is this:

Compromised assets by percent of breaches involving Intellectual Property theft

McAfee just posted a threat brief we created regarding the LizaMoon attack spreading through vulnerable web sites. Thanks to Vadim and our red team for providing the material and Andy for doing the proofing and adding his words of wisdom. As always, the simple way to solve SQL injection is to use bind variables.

On another topic, I’m presenting another “Hacking Exposed” session with McAfee tomorrow (4/14/2011) at 11am PDT. This session is going to demonstrate many techniques used by hackers to exploit SQL injection (with focus on Oracle) including some new blind time-based SQL injection options. Please register, it’s free!

I guess this is somewhat ironical. At least it was nothing simple as in-band SQL Injection via errors or directly. It just goes to show you that any site can be vulnerable to attacks, even guys that write DB engines for a living. On the other hand, I’m sure that the sites were not created by the same guys who work on the database.

The answer to SQL Injection is very simple – use BIND VARIABLES, for Pete’s sake. It will cover 99% of your use-cases and for the other 1%, consider the security implications!

This is just too funny – the site owner is accusing the guys that reported the vulnerability of extortion. More details can be found here and here.

And it all started with a simple SQL Injection that can be exploited through the site error messages. I talked about this multiple times in the past.

Of course, the passwords were in clear text and multiple messages from site members to use hashing and not email passwords to users were deleted from the site’s forum.

OK, it looks like this was a test site but nevertheless it makes you wonder.

Leaving web application vulnerable to SQL injection and entire databases out there without protection is a sure way to get yourself hacked. It doesn’t even matter if the site was a test site (I hope it was) but we’ve seen many cases where access to a machine on the company DMZ was followed by getting control of the machine and getting further inside into the company (remember Heartland?).

About a month ago I posted about breaches at educational institutions, and suggested that rectifying the problem could start by simply not hoarding PII (personally identifiable information) unnecessarily.

Today I read about this breach at Northwestern University (not the first data breach for them) where social security numbers of 4,000 individuals may have been compromised, including all those who attended a certain program from 1991 to 2007.

Why oh why would the university need to keep SSNs of people who went there in 1991?! Surely there are some other ways of identifying those individuals. Why take such unnecessary risk?

Like a Greek tragedy unfolding, you know that the SSN appearing in the first scene will be breached in the end. Tragic, but in this case entirely avoidable.

While it’s not headline news yet (and may never achieve such lofty status), a recent database breach at UWF was exposed and later reported in local news. What exactly happened and how many records were compromised is, as usual in such cases, unknown.

This made me think: We hear of breaches at universities all too frequently. Privacy Rights Clearinghouse, a website that documents data breaches, lists over 140 breaches in universities since January 2005. That’s more than one per week on average. Ouch.

Why is that?

The crucial factor here is that universities have very large populations of “insiders”. Students are like employees: They are authorized users. They have logins and passwords. They are also young and rebellious, and many are tech savvy – e.g., computer science students, to state the painfully obvious. Some are “hackers”, looking to prove they can hack, or influenced by some anarchist/Marxist/New Age book they browsed in the library, and others may be more traditionally motivated by money, criminal intent or a deep desire to change their grades…

This is also a transient population, and very hard to control. Every 3-4 years the population changes almost completely. Unlike employees, they do not stay long enough to develop any kind of loyalty, plus of course the don’t get paid – quite to the contrary, they’re the ones paying.

What about the data itself? Naturally grades are very important to students, but they are of little value to anyone else. Other student data is a lot more interesting, including Social Security numbers, bank account details and other personally identifiable information – the bread and butter of identity thieves. At least gone are the days when SSNs were used as student numbers – although many of those still lurk in alumni databases around the US, which highlights another point: Although the population is transient, the data is not. It stays. A large-ish university will have hundreds of thousands of former student records. Quite the honeypot.

Universities mostly lack the IT resources that Fortune 500 companies have, but the challenge they face in securing their data is no less daunting. I think that one simple, non-technical solution would be not to collect unnecessary data in the first place, and if it must be collected for current students, dispose of it once the student graduates. As an alumnus, why would I possibly need my alma mater to retain my Social Security number?

Technically there are many things the universities can do, but I don’t want to already sound tedious on my second post (hint: If you don’t monitor database activity, you won’t know if the DB was breached, when, how, by whom and how badly – but enough of the hard sell)

What better way to start a blog about database security than to discuss what is possibly the biggest data breach ever?

It now seems that several banks are suing TJX over claimed losses of tens of millions of dollars – so negligence in data protection carries a cash penalty, not just nebulous damage to reputation. Gross negligence, in fact – this is not some one-off lapse in judgment such as a laptop with sensitive information forgotten on a bus, or a CD lost in the post.

The details recently published about the ongoing investigation provide insight into what possibly happened:

  1. The breach lasted 17 months: For 17 months someone (or more than one person) was systematically stealing data. I can only infer from this that security measures and procedures at TJX were grossly inadequate. It also means the breach was not accidental – it may have been opportunistic at first, but certainly malicious after that. More likely it was malicious from the start.
  2. Insider(s) were involved: It seems that some encrypted credit card data was decrypted using keys, which only an insider with privileged access would have. Whether such an insider was knowingly complicit or duped into divulging such information is unknown, but it shows us all what the sophisticated criminals already know – why bother sweating and hacking your way through firewalls and IDS when it’s so much simpler to use an insider?
  3. Utter lack of visibility: Most astonishing of all, more than 50 experts TJX put on the case have reached no conclusions. Besides not knowing how many thieves were involved, TJX isn’t sure whether there was one continuing intrusion or multiple separate break-ins, according to a March 28 regulatory filing.”
    In other words, the thieves either did a great job of covering their tracks (and they certainly had ample time to do that!), or worse, they didn’t have to do it because their actions were invisible to begin with…

It is clear that even a rudimentary audit could have prevented the breach from going undiscovered for so long. It is also evident that encryption alone wasn’t enough to protect the data, and that perimeter defenses such as firewalls are useless against inside jobs like this one.

But ultimately, the entire thing could have been prevented with real-time monitoring and intrusion prevention at the database level.