Application Security // Database Security
10:10 PM

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,, 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 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
Newest First  |  Oldest First  |  Threaded View
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 (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
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-07-05
EMC Secure Remote Services Virtual Edition (ESRS VE) 3.x before 3.06 does not properly verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

Published: 2015-07-05
EMC Secure Remote Services Virtual Edition (ESRS VE) 3.x before 3.06 does not properly generate random values for session cookies, which makes it easier for remote attackers to hijack sessions by predicting a value.

Published: 2015-07-05
Mozilla Network Security Services (NSS) before 3.19, as used in Mozilla Firefox before 39.0, Firefox ESR 31.x before 31.8 and 38.x before 38.1, Thunderbird before 38.1, and other products, does not properly determine state transitions for the TLS state machine, which allows man-in-the-middle attacke...

Published: 2015-07-05
Use-after-free vulnerability in the CanonicalizeXPCOMParticipant function in Mozilla Firefox before 39.0 and Firefox ESR 31.x before 31.8 and 38.x before 38.1 allows remote attackers to execute arbitrary code via vectors involving attachment of an XMLHttpRequest object to a shared worker.

Published: 2015-07-05
Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 39.0, Firefox ESR 31.x before 31.8 and 38.x before 38.1, and Thunderbird before 38.1 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code v...

Dark Reading Radio
Archived Dark Reading Radio
Marc Spitler, co-author of the Verizon DBIR will share some of the lesser-known but most intriguing tidbits from the massive report