Showing posts with label zero-day. Show all posts
Showing posts with label zero-day. Show all posts

Tuesday, November 8, 2016

A nasty pair of MySQL exploits grant attackers system root from any database user

Four days ago I received an email from Dawid Golunski through the list illustrating one of the more brutal pair of security vulnerabilities I have seen recently. Here's how it works.
    The exploit uses a vulnerability within MariaDB, PerconaDB (and/or XtraDB Cluster) and MySQL to, first, gain access to the 'mysql' system user using any mysql user that has CREATE / INSERT / UPDATE permissions. The first part revolves around a race condition when sql generates temporary files as part of the `REPAIR table` command. Then using the mysql system user the second vulnerability grants the attacker root access to the server using a clever hack that takes advantage of mysql_safe's approach to writing to file based error logs. Below I've provided a list of vulnerable server versions. Just about any server using the more recent (unpatched) stable releases of MySQL or MariaDB through CentOS is vulnerable (Percona isn't part of the standard CentOS repositories), with a few of caveats.
    The first caveat is that an unpatched vulnerable server can prevent at least the 2nd exploit by disabling symlinks through /etc/my.cnf using skip-symbolic-links or symbolic-links=0
    The next caveat is that the 2nd exploit also depends on using file-based mysql logging. Using syslog will avoid trouble.
    The third caveat is that for the 1st exploit to work an attacker needs a mysql user and password.
    There is some good news here. The latest stable versions of MariaDB at least disable symbolic links in my.cnf by default (its been a while since I installed MySQL through the repo but I'm fairly sure its disabled here as well). And how would an attacker get a MySQL user anyway?
    Consider that because *any* MySQL user to be used, an un-patched shared server used by a hosting company would depend on the security competency of every one of that c customers to securely handle database authentication. Not only are there a variety of exploits available for obtaining a standard database user, but its depressingly common for web designers to place their connection strings with un-encrypted database username and password into world-readable files. There are a variety of feeds and sites that scan the internet for and compile such files.
    And even without the use of the 2nd exploit, an attacker can still do an enormous amount of damage without server root with only the mysql system user. The attacker will have full access to the MySQL system files. An attacker could easily delete an entire database instance, for example.
    Of course the best part is that this is a vulnerability in MySQL itself. Upgrading MySQL is the scariest, riskiest upgrade there is among standard repo software. A lot of admins compile it from source or install it from a direct RPM (in which cases symlinks are enabled by default). And applications are closely linked with the database version. Even successful upgrades can easily break applications that run on that database as calls used by the application become deprecated. Upgrading applications has substantial costs, whether you develop the application itself or license it. A patch was already in circulation before these exploits were posted, but for all of the reasons listed above, vulnerable databases will be active for years.

Here are the impacted DB versions:


MariaDB 
 < 5.5.52
 < 10.1.18
        < 10.0.28

MySQL  
 <= 5.5.51
 <= 5.6.32
 <= 5.7.14

Percona Server
 < 5.5.51-38.2
 < 5.6.32-78-1
 < 5.7.14-8

Percona XtraDB Cluster
 < 5.6.32-25.17
 < 5.7.14-26.17
 < 5.5.41-37.0

Here the first two links below contain a comprehensive breakdown of both exploits with example scripts that you can run to test.

http://legalhackers.com/advisories/MySQL-Maria-Percona-PrivEscRace-CVE-2016-6663-5616-Exploit.html

https://legalhackers.com/advisories/MySQL-Maria-Percona-RootPrivEsc-CVE-2016-6664-5617-Exploit.html

This link includes a video illustrating how a compromise takes place using the example scripts:
http://legalhackers.com/videos/MySQL-MariaDB-PerconaDB-PrivEsc-Race-CVE-2016-6663-5616-6664-5617-Exploits.html

Tuesday, October 21, 2014

What You Need to Know About the "Sandworm" Exploit

You may have heard about last month's hack of computers belonging to NATO, Ukrainian and European Union representatives. The attack vector was a classic - a loaded email; classic enough that at first I wondered why the attacks were so successful, post-Stuxnet.

Every target opened an email with an infected Microsoft Power Point document. The Power Point was executable. Under ordinary circumstances, users are provided with a security warning that they must over-ride when running and saving executable Power Points. I haven't been able to find confirmation in the news as to whether users read and confirmed these security warnings before running the loaded files; I haven't been able to get my hands on a copy of Sandworm to see for myself, either (please leave a message or email me if you have such a copy).

In some sense, the incompetence entailed in triggering the infection is a bit more forgivable as apparently this infection has been running unabated since its first successful intrusion in 2009. Five years later, presumably world leaders are more savvy about complex attack vectors like downloading attachments from strangers. On the other hand, this infection has been running unabated since its first successful intrusion in 2009. Over the last 15 years I have worked with many companies to resolve security problems. I've seen many best practices ignored, smart security measures over-ridden by lazy employees, critical IT staff replaced incompetents resulting in squandered logs and security infrastructure.

In all of this time I have never seen or in fact heard of a single company, no matter how small, broke or inexperienced, with an ongoing security breach of this magnitude that went completely un-noticed for five years. The length of time involved, the amount of people who had to function with blinders on, the hardware and software changes - all of these things is simply staggering. The only conclusion that can be reached is that for NATO and the European Union, "cyber-security" is another empty buzzword used to drain tax payer money and promote a pack of thieves who know nothing about computers.

With that out of the way, Sandworm is quite a piece of work. The software funnels documents and emails containing intelligence and diplomatic information about Ukraine and Russia and send them back to Sandworm's admins. SSL keys and certificates get ripped off as well. These could be used for a whole host of nasty things, but at the least they would be used to fool email recipients into downloading infected attachments by using email servers with fraudulent certificates. Yet another sign that SSL cannot and should not be trusted for identity-verification purposes.

Sandworm impacts every version of Windows including and after Vista, including Server 2012.

The bug does show its age a bit. For example, it tries to install BlackEnergy, a malware platform that was the absolute sh*t back in 2008 but which is all of useless today. The tool was used to launch DDoS attacks during the great Georgian cyber war - more evidence linking Sandworm to Russian nationals. One can only imagine the consequences should Sandworm had used a newer DDoS platform: what kind of international incident would have resulted from NATO launching a Denial of Service against Ukraine?

The security firm iSight was responsible for catching the mess. You can get a peek at their publicized report by way of the Washington Post.

There are a few simple suggestions that reduce one's susceptibility to Sandworm and bugs like it. First and foremost, despite how the popularity of attachments, email is not a file transfer protocol. Particularly in environments demanding security (like NATO, for gods-sake), email servers should strip attachments from emails. Forwarding the attachments to a DMZ fileserv can allow users to retain the ability to download critical attachments without ensuring infection when users download all of their messages prior to reviewing them using mail client.

PowerPoint has no place in a mission-critical secure environment. There are other options providing the same functionality without being targeted as aggressively for infection. In large organizations, there is no reason why laptops specifically for presentations cannot be assigned. Restrict the ability to install applications on these laptops and limit their access to secure networks. Time and again we hear stories of diplomats and officials taking their office computers to conferences attended by unfriendly governments, only to have those computers compromised. Present at the conferences. Work at the offices. Avoid career-ending embarrassment and international incidents. Its computer science, not rocket science.