Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


MySQL 0day exploit
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

MySQL 0day exploit

exception0x876exception0x876 Member, Host Rep, LIR

Early on Monday 9/12, Dawid Golunski of http://legalhackers.com/ reported MySQL bug CVE-2016-6662. From seclist.org:

An independent research has revealed multiple severe MySQL vulnerabilities. This advisory focuses on a critical vulnerability with a CVEID of CVE-2016-6662. The vulnerability affects MySQL servers in all version branches (5.7, 5.6, and 5.5) including the latest versions, and could be exploited by both local and remote attackers.

Both the authenticated access to MySQL database (via network connection or web interfaces such as phpMyAdmin) and SQL Injection could be used as exploitation vectors. Successful exploitation could allow attackers to execute arbitrary code with root privileges which would then allow them to fully compromise the server on which an affected version of MySQL is running.

Comments

  • Oh dear... Let's have an eye on this!

    And let me once step in the GIF game:

  • edited September 2016

    http://news.softpedia.com/news/mysql-zero-day-allows-database-takeover-508211.shtml

    "Golunski says he reported the issue to Oracle on July 29. He also mentions that Oracle's security team acknowledged and triaged the report. The next Oracle CPU is scheduled for October 18, 2016."

    So everyone is just gonna be vulnerable for over a month?

    ----------Edit-----------

    https://www.reddit.com/r/netsec/comments/52dgxh/mysql_remote_root_code_execution_privilege/d7jefp0

    Maybe its not as bad as it sounds?

  • Other sources have reported that this is "just" a privilege escalation issue

  • @theblackesthat said:
    So everyone is just gonna be vulnerable for over a month?

    "As temporary mitigations, users should ensure that no mysql config files are
    owned by mysql user, and create root-owned dummy my.cnf files that are not in
    use."

    Thanked by 1exception0x876
  • jarjar Patron Provider, Top Host, Veteran

    @Microlinux said:

    @theblackesthat said:
    So everyone is just gonna be vulnerable for over a month?

    "As temporary mitigations, users should ensure that no mysql config files are
    owned by mysql user, and create root-owned dummy my.cnf files that are not in
    use."

    Aye. It's bad but it looks like there are appropriate measures to take. These days, I'm satisfied with that. I'll take good news on vulnerabilities where I can get it :)

  • JacobJacob Member
    edited September 2016

    @jarland said:
    Aye. It's bad but it looks like there are appropriate measures to take. These days, I'm satisfied with that. I'll take good news on vulnerabilities where I can get it :)

    This is true, though how many people clued up people leave their DB server/s publicly exposed? I imagine not many.

  • jarjar Patron Provider, Top Host, Veteran

    Jacob said: This is true, though how many people clued up people leave their DB server/s publicly exposed? I imagine not many.

    Yeah I expect primarily popcorn time from anyone using a public facing instance of phpMyAdmin. I feel like that defines the characteristics of people who will be compromised.

    Thanked by 2doghouch netomx
  • eva2000eva2000 Veteran
    edited September 2016

    even more reason to switch from Oracle Mysql to MariaDB or Percona MySQL http://news.softpedia.com/news/mysql-zero-day-allows-database-takeover-508211.shtml

    Today the researcher took the extreme measure of publishing proof-of-concept exploit code for CVE-2016-6662 after both MariaDB and PerconaDB fixed the vulnerabilities and Oracle did not.

    "The vulnerabilities were patched by PerconaDB and MariaDB vendors by the end of 30th of August," Golunski explained. "During the course of the patching by these vendors the patches went into public repositories and the fixed security issues were also mentioned in the new releases which could be noticed by malicious attackers."

    MariaDB 10.1.17 was released on August 30, 2016 and https://mariadb.com/kb/en/mariadb/mariadb-10117-changelog/

    MDEV-10465 general_log_file can be abused

    from that JIRA MDEV-10465 ticket

    Fixed Version/s 5.5.51, 10.0.27, 10.1.17

  • deadbeefdeadbeef Member
    edited September 2016

    @jarland said:

    Jacob said: This is true, though how many people clued up people leave their DB server/s publicly exposed? I imagine not many.

    Yeah I expect primarily popcorn time from anyone using a public facing instance of phpMyAdmin. I feel like that defines the characteristics of people who will be compromised.

    It stills requires an SQLi hole to exploit though - or did I misunderstand? Or do you mean in terms of a multi-tenant set up?

  • jarjar Patron Provider, Top Host, Veteran

    deadbeef said: It stills requires an SQLi hole to exploit though - or did I misunderstand? Or do you mean in terms of a multi-tenant set up?

    Oh I'm picturing root owned phpmyadmin with the user who logs in with his root MySQL password. You know, absolute first target for literally any vulnerability kind of person ;)

    Thanked by 1deadbeef
  • @eva2000 said:

    MySQL clones are also affected, including:

    MariaDB
    PerconaDB

    The only good thing is that you have to be vuln to SQL Injection in order for this to effect your server.

  • @MacPac said:

    @eva2000 said:

    MySQL clones

    forks

    Thanked by 1maverickp
  • eva2000eva2000 Veteran
    edited September 2016

    MacPac said: MySQL clones are also affected, including:

    MariaDB PerconaDB

    The only good thing is that you have to be vuln to SQL Injection in order for this to effect your server.

    are you talking about the same issue ? MariaDB already fixed this back on August 30 see https://jira.mariadb.org/browse/MDEV-10465

    from http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html

    The vulnerabilities were patched by PerconaDB and MariaDB vendors by the end of
    30th of August
    .
    During the course of the patching by these vendors the patches went into
    public repositories and the fixed security issues were also mentioned in the
    new releases which could be noticed by malicious attackers.

    Thanked by 1MacPac
  • @eva2000 Does the centos 7 update repo mariadb has this patched?

  • @jarland said:

    Jacob said: This is true, though how many people clued up people leave their DB server/s publicly exposed? I imagine not many.

    Yeah I expect primarily popcorn time from anyone using a public facing instance of phpMyAdmin. I feel like that defines the characteristics of people who will be compromised.

    We need @GCat to scan all colocrossing space for phpmyadmin installations, so we can sell email lists cheap

    jks

    Thanked by 2GCat netomx
  • KuJoeKuJoe Member, Host Rep

    Based on everything I'm reading the only way to exploit this vulnerability is you have to have a local MySQL user on the server and you need specific permissions that most users don't have.

  • FlamesRunnerFlamesRunner Member
    edited September 2016

    What kind of permissions would someone need to exploit this?

    I have a MySQL server with users that can use all privileges on databases named theirusername_% (allows them to create databases with the prefix theirusername_databasename).

    Any elevated access to my MySQL server is accessible only via a VPN.

    (woah, I haven't checked my server in a while and it turns out my users have pushed through 346.5GiB of bandwidth through MySQL alone)

  • @doghouch said:

    @jarland said:

    Jacob said: This is true, though how many people clued up people leave their DB server/s publicly exposed? I imagine not many.

    Yeah I expect primarily popcorn time from anyone using a public facing instance of phpMyAdmin. I feel like that defines the characteristics of people who will be compromised.

    We need @GCat to scan all colocrossing space for phpmyadmin installations, so we can sell email lists cheap

    jks

    Silly you, I've been doing that all week. Surprised I haven't had my scanning servers blocked yet

  • FlamesRunner said: What kind of permissions would someone need to exploit this?

    FILE permissions for starters http://dev.mysql.com/doc/refman/5.7/en/privileges-provided.html#priv_file

  • @eva2000

    I've set up my server to only be able to load from a specific directory.

    Thanks!

  • All you have to do nowadays is to keep an eye on the logs for suspicious activities.

  • smansman Member
    edited September 2016

    @sharp_servers said:
    All you have to do nowadays is to keep an eye on the logs for suspicious activities.

    I have a fail2ban filter that watches the apache logs for any attempt to read phpmyadmin or myadmin directory. Since I don't have that I know it's a scanner and automatically ban it. I also watch for other common scanner activity and update the filter regularly.

    Thanked by 2JustAMacUser mycosys
  • @sman said:

    @sharp_servers said:
    All you have to do nowadays is to keep an eye on the logs for suspicious activities.

    I have a fail2ban filter that watches the apache logs for any attempt to read phpmyadmin or myadmin directory. Since I don't have that I know it's a scanner and automatically ban it. I also watch for other common scanner activity and update the filter regularly.

    I heard about it but I don't trust anyone other than myself in checking mysql logs as that may contain serious information.

  • JustAMacUserJustAMacUser Member
    edited September 2016

    @sharp_servers said:
    I heard about it but I don't trust anyone other than myself in checking mysql logs as that may contain serious information.

    You don't trust fail2ban? It's been out for a long time, I'm sure if it were malicious such details would have surfaced by now. Plus it's by far more likely that locally run, automated processes like fail2ban are going to notice suspect activity before you. It monitors every few minutes, 24 hours a day, all the time; a single person cannot monitor that frequently.

Sign In or Register to comment.