Researchers have identified a serious vulnerability in some versions of Oracle’s MySQL database product that allows an attacker to strip SSL/TLS connections of their security wrapping transparently.
The vulnerability is the result of the way that an option in MySQL handles requests for secure connections. Researchers at Duo Security discovered the bug after noticing some odd behavior in MySQL a few weeks ago. They realized that even when they set the correct option to initiate an SSL connection with the MySQL server, they could not make the client enforce a secure connection. In other words, if the server tells the client that it doesn’t support SSL–even if it does support the protocol–the client will send information over plaintext TCP.
This means that an attacker with a man-in-the-middle position could force an unencrypted connection and passively sniff all of the unencrypted queries from the client to the MySQL database. The flaw is very similar to the SSLstrip attack developed by Moxie Marlinspike several years ago. Oracle implemented a fix for the flaw more than a year ago, but it was only fixed in a branch of the product that isn’t generally available yet.
“Now, if you’re an avid MySQL user, you might be thinking ‘but wait – I can just use the REQUIRE SSL option on my server…’ Nope! That’s the beauty of ssl-stripping attacks: Mallory can initiate a bona-fide TLS session with the server, while continuing to speak plaintext with the client,” researcher Adam Goodman said in a blog post explaining the bug.
“Actually, the good news is that the MySQL team has already realized this was a problem, and implemented a fix. Like, over a year ago. The bad news? The fix was only applied to MySQL 5.7.3 and later; 5.7.x is not yet even a GA release! (Also, the fix was applied to version 6.1.3 of the standalone libmysqlclient distribution). The worse news? In many cases, the “fix” is not enabled by default! So, while we haven’t collected any real data on the subject, we’re pretty confident that the vast majority of libmysqlclient users are affected by this issue.”
The vulnerability is nicknamed BACKRONYM (Bad Authentication Causes Kritical Risk Over Networks Yikes MySQL) by the Duo researchers, who also put up a site that riffs on the recent trend of researchers putting up sites for major vulnerabilities.
“The most serious risk is posed by adversaries with passive monitoring capabilities like the NSA, intelligence agencies, or other capable attackers who may have a foothold on your network. Many MySQL clients will use a DNS hostname (eg. db1.app.company.com) to connect to the database server, triggering a DNS query that may traverse monitored links on the Internet. A global passive adversary like the NSA can spoof a reply to this DNS request in order to hijack the MySQL connection, perform the downgrade, and steal/manipulate database contents,” the Duo researchers said in an FAQ on the site.
The vulnerability affects MySQL 5.7.2 and earlier versions, along with MySQL Connector versions 6.1.2 and earlier, all versions of Percona Server and all versions of MariaDB. The Duo researchers said that while the bug could be a problem, it may not be a huge risk.
“Now, for most MySQL users, this vulnerability probably isn’t panic-worthy: as mentioned earlier, Mallory has to be in a position to perform a Man-In-The-Middle attack between the database and its client(s). It’s pretty typical for a database server to be adjacent to (or even on the same box as) its client – e.g. a web application server – so MITM attacks might not be a serious concern. We also expect that many MySQL users don’t bother to enable SSL at all,” Goodman said.
The oCERT open source security team has posted an advisory about the vulnerability, too.
