Database Security 3.0

Team SHATTER Database Vulnerability 9 of 10 – Unpatched Databases

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has researched the Top 10 Database Vulnerabilities in order to provide you with the most up-to-date vulnerabilities, risk and remediation information.

Organizations house sensitive data – typically in databases. In response to the ever-changing vulnerabilities that are being exploited by attackers, database vendors release patches to ensure sensitive information in databases is protected from threats.

The good news.  Most vendors provide patch updates on a fairly regular basis. For instance, Oracle provides a critical patch update (CPU) every quarter. The most recent Oracle CPU was just released last Tuesday that provided patches to 13 database specific vulnerabilities. Team SHATTER was credited in the release for identifying 3 vulnerabilities. Once a vulnerability is publicly disclosed, whether a vendor has released a patch or not, Team SHATTER updates its vulnerability knowledgebase with workaround details to ensure databases are as secure as possible.

Now for the bad news. Once these patches are released they should be patched – at least the most critical vulnerabilities. If left unpatched, hackers can reverse engineer the patch, or can often find information online on how-to exploit the unpatched vulnerabilities, leaving a DBMS even more vulnerable that before the patch was released.

In our last post we discussed the SQL Slammer worm – this is a great example of what can happen when organizations don’t patch database vulnerabilities. 

Many organizations don’t implement patches right away – some even wait a year or more. The most common excuses are the downtime involved with implementing patches and the time involved with testing these patches to make sure they don’t affect the production software. Whatever the excuse may be, organizations should use database activity monitoring to manage the gap between patches on its databases containing critical information PII data.

The Team SHATTER Vulnerability of the Day series on Twitter provides you with what to check for and how to mitigate these common risks. Stay informed. Follow @TeamSHATTER on Twitter.

Team SHATTER Database Vulnerability 7 of 10 – Privilege Escalation

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has researched the Top 10 Database Vulnerabilities in order to provide you with the most up-to-date vulnerabilities, risk and remediation information.

Today’s topic is Privilege Escalation.

In any well configured Database Management System (DBMS), accounts are restricted to only perform the actions and access the data that they require to perform their job functions. For anybody with malicious intent, this is like being at a candy store, but you’re stuck in the room that only has oatmeal cookies. There could be a whole database with millions of credit card numbers, but you only have access to the organizations marketing folder.

Of course, too often, the locks to the candy store are easy to pick.

A privilege escalation attack is when the attacker is using a known vulnerability in a DBMS that allows a user account with restricted privileges to execute instructions or query data that that typically requires higher privileges. Thus unlocking the locks in the candy store. 

There are different common vulnerabilities that allow for privilege escalation. Sometimes misusing a function that runs under a sysdba, sa or similar security context. In other cases it is done by exploiting vulnerabilities that allow a low-privileged account to grant itself more rights.

To protect against these types of attacks, it is important to always keep your DBMS updated with the latest security patches available from the vendor, as well as continuously monitor for known attack signatures.

The Team SHATTER Vulnerability of the Day series on Twitter provides you with what to check for and how to mitigate these common risks. Stay informed. Follow @TeamSHATTER on Twitter.

Team SHATTER Database Vulnerability 6 of 10 – Buffer Overflows

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has researched the Top 10 Database Vulnerabilities in order to provide you with the most up-to-date vulnerabilities, risk and remediation information.

The first five installments of this series have been mostly about configurations and best practices, finally, we are making it to the good stuff.

Buffer Overflows. Now what exactly are they?

A buffer overflow is when the input to a function contains more data than the input buffer can hold. If the size of the input is not checked during the copy to that buffer, adjacent memory that is used for other purposes might get overwritten. In most cases, this will be more or less random and can lead to unpredictable behavior, like crashing the server. However, if an attacker is able to also change the code execution pointer to the location of the overwritten memory, it is possible to execute any kind of malicious code using the context of the DBMS process. This could lead to a potential total compromise of the system, resulting in loss of sensitive information and overall security.

To protect against these types of attacks, it is important to always keep your DBMS updated with the latest security patches available from the vendor, as well as monitoring for known attack signatures.

The Team SHATTER Vulnerability of the Day series on Twitter provides you with what to check for and how to mitigate these common risks. Stay informed. Follow @TeamSHATTER on Twitter.

How Do You Protect 27% of the World’s Wealth?

An interesting story broke today that is flying under the radar. It’s being reported that Swiss Banks are in conversations with the government on sharing sensitive data. Switzerland has been called out by France for the lack of a cohesive policy around how they share highly confidential customer information.

The bulk of this discussion centers around taxes, and how foreign tax authorities are requiring information – basically because Switzerland had to make some deals with the UK, US and France to stave off a blacklisting by the OECG as being a tax haven for evasion.

What’s interesting are the data security challenges associated with whatever mandate the Swiss government enacts. Why? Because 27% of the world’s privately vested offshore wealth resides in Swiss bank accounts. Not a small chunk of change. And likely a LOT of data.

Guess where the data at most of those Swiss banks probably lives? Oh yes, multiple databases. And guess where the most coveted information exists? You guessed it, in those databases.

But the million-dollar question is do all those banks have the right database controls and protection deployed so that they can ensure that confidential information remains confidential? And will the Swiss government require the right levels of protection to comply? And once they roll out the requirements (and its announced publicly) will the hacker community pounce on it, knowing some of the banks won’t implement what they need to during this equivalent of a patch gap? Probably.

This all speaks to the issue of continuous compliance in the database and the need for a methodology that should enable an organization to know what the audit result will be before that database is audited. And it speaks to the need for the right combination of scanning and monitoring functionality to avoid that ‘gap’ which can leave systems extremely vulnerable to attack.

Is it possible we have hit the crisis point?

Our annual study with Enterprise Strategy Group usually generates a lot of buzz around what firms aren't doing to protect their most critical applications that house sensitive information - you guessed it, the database.

But what we've seen in our survey that we launched today isn't just a bunch of statistics – it’s a grim reminder that we are facing perhaps the worst of threats to our confidential data, and there are things we are either overlooking, don't understand...or, simply doing nothing about.

We polled 175 IT Security execs at large organizations, and based on some of the staggering numbers, it’s possible we may have a crisis on our hands...

The study reveals that 60% of organizations don’t feel their existing database controls adequately protect their organization’s confidential data. Coming from security executives, this doesn't inspire a lot of confidence.

In addition, the data reports that nearly 70% of organizations do not feel that their existing database controls are well-defined. Again, considering the source, if controls aren't spelled out and communicated appropriately, how can IT Security even do its job?

The survey reveals that despite the fact that over two-thirds of organizations are spending moderate to significant amounts of time writing custom scripts, remediating compliance issues, and engaging in associated tasks - which means costly manual processes are the norm. 

38% of organizations still failed database security audits, which tells us that while companies may be better this year in identifying database audits as important, they aren't taking a continuous approach to compliance. Therefore they may be passing one audit, but what happens in the next one a month or even a week later? 

The study further reveals the troubling statistic that less than 4% of IT budgets are spent protecting the data where it lives – in the database. Why is it troubling? Well, if companies looked at their overall IT Security spend and re-prioritized their misplaced spending, they'd be able to ground both their compliance initiatives and protections in the database.

 

Authorized Database Roles - Where do they go when someone leaves?

By now you know the drill - another data breach, more identity theft, more records potentially compromised. MassMutual experienced a database breach of employee information over the weekend through a contracted vendor database.

There's some information that's come to the surface already, and it appears they've been able to curb the damages and take the proactive steps to protect employees.

What this breach underscores is the fact that organizations are still not taking the right steps to protect sensitive, confidential information in a comprehensive way. What also persists to be a major issue is the lack of segregation of duties in the database.

As the unemployment rate hovers around 10% and organizations are still slashing headcount, roles and privileges to data still exist, possibly even if that employee has been let go, has moved on or has been reassigned. When those access controls still exist, organizations are at risk.

Databases contain sensitive information are large, enterprise organizations. 99% of enterprise data exists in some form inside a database. Yet with breach numbers up to 340,102,273 you'd think there would be a massive call to action for organizations who have are facing a radically scaled-up threat environment.

Beanbags and Database Security. A discussion at CSI 08.

By Josh Shaul.

The week before Thanksgiving I led a session at the CSI 08 conference in Washington, DC. It was setup as a group discussion in a small room with bean bags instead of chairs. It was a relaxed atmosphere designed to foster a philosophical discussion. In reality, there was one row of chairs at the back of the room. Everyone except one or two folks sat on chairs. The bean bags were a little intimidating. Once you sit in one of those things, there is no telling if you’re ever getting up. 

Decision Making - The Stakeholders

Our discussion was an exploration of who the stakeholders and responsible parties are in a typical corporation’s database security program. We started by reviewing a few recent data breaches, discussing how they happened and could have been prevented. With an understanding of the mechanics of a data breach, we began on discussion on responsibilities. 

It quickly became clear that not everyone in the audience knew of a database security program at their office. Some even came clean, admitting that they have no such program or effort. Those who did have a plan in place discussed radically different approaches and experiences.  

Group Authority?

A security manager at a large retailer described how his team was responsible for ensuring that databases and other applications are configured securely; in accordance with the requirements of internally developed standards. That was the good news. The bad news was that his group was not responsible for making sure databases had security patches applied. That was someone else’s responsibility. His group was also not responsible for auditing access to databases or monitoring for attacks. Those activities would also fall into other groups….if they were in place at all…he wasn’t sure.

Split up Responsibilities

Another member of the audience described that they have a policy that mandates some basic database security requirements such as strong passwords and access controls. The policy is fairly solid, but there is no one responsible for ensuring that the policy is implemented. Some systems are likely in compliance, others are not. The only people who have a chance of knowing are the system owners, and the scope of their knowledge is very narrow, they only know about the systems they personally own and manage. 

Clear ownership, No ownership

We also heard from a utilities company where there is clear ownership of policy development, and database assessment and auditing, but nobody responsible for remediation or risk reduction. This group made an investment in technology and processes to measure their security posture, but gain very little return from that investment because they rarely fix the problems they find. 

Does anyone own database security? 

According to the group I met with, no one person ultimately does. It boils down to a shared responsibility between operations teams (database admins), IT security teams, and often audit / compliance teams. The group agreed that picking a vocal leader for each of the major functions of a database security program (policy development, assessment, auditing, monitoring, and remediation) is a critical step.

Ensuring that the leaders communicate and cooperate, and are held accountable when their functions don’t deliver is the ultimate key to a successful program, but is often the biggest hurdle to overcome.

It's the Privileged Activity You're After....Not Just the Privileged Users

By Josh Shaul

It’s a problem that I see organizations struggling with every day. An audit finding has come down requiring the monitoring of privileged users in databases containing sensitive or regulated data. From the outside, this seems simple. Get a list of privileged users and log whatever they are doing. However, as folks dig into this, the first question they have to ask is who are the privileged users? And that’s where the trouble starts.

What exactly is a privileged database user? It’s probably not anyone and everyone with access to the system. Maybe it’s only the database administrators, but what exactly does that mean? Membership in a DBA or SysAdmin role? That can be very misleading, since DBA level privileges can be granted directly to a user without any role membership, or new roles with names like Not-A-DBA can be created with DBA equivalent privileges.

Maybe a privileged user is anyone with write access to the database? But that tends to include everyone, since it’s been pointed out by database security researchers many times in the past that creating a read-only database user is essentially impossible, due to all the write privileges that are typically (and often irrevocably) granted to PUBLIC (that’s everyone in the database).

Even with a firm definition of what makes a user a privileged user, the problems don’t go away. Just because a user is not privileged today, does not mean they won’t be privileged tomorrow. Actually creating and maintaining an accurate list of privileged users in an enterprise full of databases can be an impossible task.

There is another way forward though. One that is simple to define, implement, and maintain. One that meets the letter of regulations and audit findings, and one that ensures that no matter how or when a user obtained their privileges, that their activities in the database are tracked. The answer is to pay attention to the activity first, and who did it second.

While it’s hard to define what a privileged user is, it is easy to define what privileged activity is. Changes to the structure of the database (DDL) and changes to the privileges in the database (DCL) are both clear areas of privileged access that must be tracked. Changes to data (DML), particularly changes to sensitive or regulated data is another clear area of privileged access. Perhaps direct connections to a database via an ad-hoc query tool, or via MS Access or MS Excel are considered privileged access. Check out the latest Insider Threat White paper in the Application Security resource center.

In the end the exact definition of what is and is not considered privileged access is going to be dependent on the organization, the auditors involved, and the regulations that govern protection of the stored data. However, in every case, these definitions are fairly straightforward to establish, and once they are have been laid out, it’s easy to implement monitoring based on the activity type, instead of based on the user running queries.

There are a number of ways to actually implement this monitoring. All DBMS vendors provide some native auditing functionality. For the major database vendors, these audit systems allow configuration based on the commands being issued, not just the user issuing them. Native database auditing systems have a poor reputation though as a performance nightmare, so DBAs often fight hard against enabling them. There is another equally important reason not to rely on native database auditing. Those systems are under the complete control of the DBA, the exact people that we’re being asked to monitor. It is hard to prove the integrity of an audit trail when the persons being audited can enable, disable, and reconfigure the audit system at will.

A much better approach is to use a 3rd party database activity monitoring (DAM) tool. These products tend to have little to no impact on database performance, and the good ones on the market are setup such that they are not under the control of the administrators being monitored. I fully expect that in the not too distant future, IT auditors will require the use of trusted 3rd party systems to implement privileged activity monitoring, purely for the segregation of duties benefits that they bring.

If you’re facing a situation where you’ve been required to monitor your privileged users, make things simple for yourself by turning the problem on its head and monitoring the privileged access.

For more information on Database Activity Monitoring, visit the Application Security, Inc. website at www.appsecinc.com.

If you are serious about monitoring priviledged users and activity, I definately recommend checking out the Arrest the Threat white paper.

Black Hat 2008

Last week I took part in  the yearly security pilgrimage called Black Hat in Las Vegas. This years briefings were at Cesars Palace, with 8 parallel tracks ranging from App Sec and 0-Day to Reverse Engineering and Over The Air.

Day 1

I started the day out with a great refresher on everything Application Security by Jared DeMott. Anybody interested in a great general purpose intro on all the different App Sec jargon, and techniques should take a look at this once it shows up in the Black Hat archives.

Next I wanted to see Dan Kaminsky’s ‘DNS is broken’ presentation. Unfortunately clouds of people were already outside the doors and I could not get in the room. But then this got covered by the press and on various blogs in enough detail by now. So in the end, it won the ‘coveted’ most overhyped talk award at the end of day one.

After lunch I sat in the talk by Petko Petkov aka PDP. He had a great presentation mostly talking about x-site/application authentication issues. The core of his message was that we can’t take systems out of context for security testing. An application that is quite secure standalone or in a particular environment, can be used quite maliciously when integrated with another app, or ported to a new platform. For example Apple’s Quicktime™ which runs quite secure in the Mac™ environment has had a flew of issues in the recent past on Windows™.

Bruce Potter of SchmooCon fame, had probably the funniest of all presentation and should really consider a second career path as a comedian. While he did quite extensively promote his newest venture, he had some really good thoughts on presenting vast amounts of audit data. Presentation of data can make or break a security product and I’m really exited about our continued reporting enhancements in DbProtect.

Day 2

I started the day out with Arian Evans presentation about double/triple-encoding as well as transcoding attacks. This February’s highly successful SQL Worm and its more recent derivatives are using this class of attacks. Basically an attacker can circumvent all web app firewalls by properly encoding SQL code, and hide its malicious payload until the database interprets the mumbo jumbo passed through from the web sites POST command. Our security team jumped on this earlier this year, and we were able to create DbProtect activity monitoring filters and rules for these attacks.

I see this as proof, that a comprehensive security posture requires more then just perimeter protection, but that the bad guys will always find their way around these protections, and make their way to where the data is, which is where DAM really comes to shine.

Incidentally, my next stop were some short ‘turbo talks’ of which one was by Justin Clarke, who looked at the same class of attacks from a slightly different angle, and who had a really nice working attack demo.

Later this day Microsoft™ introduced 3 new security initiatives. As a security vendor I was really exited about MAPP, the Microsoft Active Protections Program. In a nutshell, Microsoft will give pre-release announcements to select 3rd party vendors for upcoming security patches, including some pretty detailed vulnerability information. This will give active protection vendors like AppSec a leg up on the hackers, allowing for release of application protection content at the same time new patches are released. Allowing IT departments to thoroughly test these new patches, while still being protected from new attacks exploiting the new vulnerabilities.

I really hope for this to be successful, and for IBM™, Oracle™, etc. to come up with similar initiatives.

Finally I was all set to go to David Litchfields talk. I had never had the chance to see him before and was really looking forward to it. Turns out he lost his passport, and by the time he got a replacement, the airfare would have been not worth it for him, to go for one day.

I can’t help it, but to be disappointed. While I don’t know how much his airfare would have been, I wish he would have thought about his audience, too.