Application Security // Database Security
6/13/2012
10:10 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Expect A Surge In Breaches Following MySQL Vulnerability

Vulnerability is so easily attacked and so prevalent that we're bound for a bump in database exposures

An unusual password vulnerability that makes hundreds of thousands of MySQL and MariaDB databases vulnerable to simple brute-force attacks is likely to soon start a ripple effect of increased data breach activity online, security experts predict.

According to researchers, databases within host service provider and cloud infrastructures are the likeliest targets, but all administrators are advised to keep on the lookout for patches from their open source distribution and adhere to basic best practices to mitigate risk in the interim.

[ What weaknesses do bad guys look for in your databases? See How Attackers Find And Exploit Database Vulnerabilities. ]

Initially, the vulnerability was discovered over the weekend by a developer in the MariaDB community and who reported it as a quirky but trivial bug. Subsequently, though, research into the vulnerability was crowd-sourced to the security community at large via social media, which found the problem to be a lot bigger than initially thought.

"This was one of the cases where it looked like a minor bug, but the folks didn't do enough coordination and they ended up leaving everyone out there kind of hanging in the wind," says HD Moore, chief security officer at Rapid7 and creator of Metasploit. "From their perspective, it didn't affect their shipping build, but it's all the other vendors who compile packages slightly differently who may be affected more than they realized."

The vulnerability itself is in the way MySQL accepts passwords -- the bug makes it such that there's a one in 256 chance that the wrong password will still grant the user access to an account. So an endless loop of attempts will eventually grant an attacker access. It was a bug so unique that Moore says some MySQL developers ran into it, couldn't reproduce it ,and eventually chalked it up as a fluke.

"I've never really seen a vulnerability like this where the thing just randomly doesn't verify your password and lets you in. I hadn't seen a vulnerability like that before," says Josh Shaul, CTO of Application Security, Inc.

According to Moore, who happened to be doing research online across a number of IP spaces on the Internet already, he was able to use some existing data feeds to find that there are about 1.74 million vulnerable MySQL databases facing the Internet at the moment, half of which he found employed no kind of host-based access control to mitigate risk of an attack. That tallies to approximately 870,000 databases online and vulnerable to an attack that needs very little technical expertise to carry out.

With such a large number of vulnerable systems and such an easy path to attack them, the community should expect a surge in breaches, he warns.

"We're going to see a lot of exposure to this," Moore says. "I wouldn't be surprised if we see a whole lot of data breaches coming out because it is so easy to exploit. You don't have to be a hacker to do it, you can just type in one line and you're guaranteed to get into a vulnerable server.

In fact, some security pundits have already thrown out wild theories that maybe we've already seen the surge start.

"Crazy theory: Could this be related to the LinkedIn, last.fm, eHarmony and other recent breaches? Did any of them have MySQL exposed? Even worse, was this really a bug or a very clever backdoor?" wrote security blogger David Dede in the Sucuri Research Blog earlier this week.

However, Shaul thinks that's not likely at all.

"I think it's unlikely because I'd be shocked to see eHarmony and LinkedIn exposing their database to the public Internet so that people could exploit it from login," he says. "I think you're much more likely looking at significantly less sophisticated IT shops that are vulnerable to this."

Nevertheless, this vulnerability still has the potential to affect databases hooked up to everything from ecommerce systems to online forums, Rapid7's Moore says. He says that even before patches are available, organizations can protect themselves with best practices.

"The good thing is that it is best practice not to expose the database to the network in the first place. We do see a lot of them out there, but those are folks who are doing something wrong to start with," he says. "And folks who don't have host access control, that's another strike against them saying 'You aren't dong the even minimum level of security.'"

However, there are cases where host access control isn't possible, which is why he believes host service providers and cloud providers are squarely in the crosshairs for this. "There are cases where service providers have got a huge arm of shared servers and they may expose a MySQL server to some customers or their IP ... such that they can't just firewall it off," he says. "Also, you see that with a lot of cloud providers, where they give you a dynamic IP address every time your server comes up so you can't use host access control a lot of times."

This latest MySQL exposure is the second big security black eye for the database software in the past year. In September 2001, the MySQL.com website was breached and redirected to a website serving up malware controlled by the BlackHole crimeware kit. The site had been hit by a SQL injection attack in that instance.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
PierluigiStella
50%
50%
PierluigiStella,
User Rank: Apprentice
6/21/2012 | 4:46:10 PM
re: Expect A Surge In Breaches Following MySQL Vulnerability
This story reminds me of the SQL Slammer of January 2003.- -

For those who do not remember it, this was the first example of an incredibly small piece of code (less than 400 bytes total) which intruded networks as a network worm and caused havoc to many large databases exposed to the internet.- For instance, Continental Airlines reservations system went down and caused serious issues at HoustonGs International airport; Bank of AmericaGs ATM network was affected; and a number of other large corporations suffered from that attack as well.- In that case, the worm was simply exploiting the fact that some people keep these databases completely exposed (read: vulnerable) to the internet.
-
Apparently, 10 years later, we have not learned our lesson.--

This article reports the possible number of databases exposed to the internet to be under 900,000 G that is absolutely staggering.- The assumption is that these would be small companies who do not follow best practices, who do not understand security issues, and who are more likely to be at risk.-- While that, in my opinion, is a rather na+ve and GhopefulG assumption, it still concern me.- Even IF this is true, the data exposed on those small databases owned by those small companies who are not following such best practices could be my credit card number or my social security number.- For all I know, they might very well be a small online retailer from which I purchased something last year.-

On top of all this, the internet makes everyone look GǣequalGǥ.- The smallest mom and pop shop can look like a large chain on the internet; you have no way of knowing who you are giving your information to; and before you know, it ends up on the net.

And what about PCI, you may ask?- True, PCI is trying to address the issue but this is so big an issue that it would be virtually impossible to address it in its entirety.- It just makes me wonder G should I stop shopping online?- Should I just stick with Amazon.com? (assuming, no, hoping they follow best practices, of course).- No law or regulation can ever ensure that everybody follows best practices; even within the banking industry, with yearly audits, strict regulations and clearly assigned responsibilities, issues remain possible.
-
And if those at risk are indeed small companies not following best practices, will they update their systems once a patch becomes available?- Or will they leave their systems vulnerable and expose their data for a long time?
-
I wish I had a more hopeful answer to all these concerns but the unfortunate truth is that, at the moment, I do not see a solution in the horizon at all.-

Databases are exposed, and they will be exploited, and data will be stolen.- It should be obvious that this should not happen; it should go without saying that you do NOT expose a database to the world.- But, then again, not everyone follows the GǣobviousGǥ logic.- Unfortunately.
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-3154
Published: 2014-04-17
DistUpgrade/DistUpgradeViewKDE.py in Update Manager before 1:0.87.31.1, 1:0.134.x before 1:0.134.11.1, 1:0.142.x before 1:0.142.23.1, 1:0.150.x before 1:0.150.5.1, and 1:0.152.x before 1:0.152.25.5 does not properly create temporary files, which allows local users to obtain the XAUTHORITY file conte...

CVE-2013-2143
Published: 2014-04-17
The users controller in Katello 1.5.0-14 and earlier, and Red Hat Satellite, does not check authorization for the update_roles action, which allows remote authenticated users to gain privileges by setting a user account to an administrator account.

CVE-2014-0036
Published: 2014-04-17
The rbovirt gem before 0.0.24 for Ruby uses the rest-client gem with SSL verification disabled, which allows remote attackers to conduct man-in-the-middle attacks via unspecified vectors.

CVE-2014-0054
Published: 2014-04-17
The Jaxb2RootElementHttpMessageConverter in Spring MVC in Spring Framework before 3.2.8 and 4.0.0 before 4.0.2 does not disable external entity resolution, which allows remote attackers to read arbitrary files, cause a denial of service, and conduct CSRF attacks via crafted XML, aka an XML External ...

CVE-2014-0071
Published: 2014-04-17
PackStack in Red Hat OpenStack 4.0 does not enforce the default security groups when deployed to Neutron, which allows remote attackers to bypass intended access restrictions and make unauthorized connections.

Best of the Web