Symantec published a blog post yesterday regarding MySQL and the Trojan.Chikdos.A as can be seen here
The Symantec post gives detail into the behavior of the Trojan and it’s effects on the Windows system registry, yet gives little detail as to how the required first stage (namely a malicious UDF) is injected, citing:
“In the latest Chikdos campaign that we observed, the attackers likely used an automated scanner or possibly a worm to compromise MySQL servers and install the UDF.”
I’m going to give my thoughts on the pre-requisites to infection here.
- The MySQL server has poor network isolation (i.e. is likely accessible from everywhere e.g. shodan.io examples)
- The MySQL user has poor (read: overly permissive) grants e.g. “GRANT ALL”
- The MySQL @@GLOBAL.plugin_dir is writeable (likely poor file ACL & no D.A.C such as SELinux / AppArmor)
This is pretty much the exact same method I discussed at PLUK13 and updated to be discussed again at PLMCE14. There are YouTube videos embedded in each showing the attack aimed at a Linux deployment. The above 3 pre-requisite points, however, should still hold true on Windows.
So what is the real takeaway here?
- Ensure you properly isolate your MySQL service on the network, allowing access from only known hosts which require access.
- There really is no reason at all to have the service accessible from everywhere on the Internet
- Ensure your user grants follow the Principle of Least Privilege; aka, only grant the required access for the user to do the job they are supposed to be doing.
- Never EVER chmod 777 / setenforce 0
I can see that last point raising some arguments; please keep in mind we’re talking about the security of your MySQL data here. Simply turning off security measures “to make it work” is a recipe for disaster.
Good overview – thanks David!
A couple of additional notes:
1. The –secure-file-priv option allows DBAs to set the directory to which users can write output files via SQL commands. Before 5.7.6, the default was empty (no limits on directory). As of 5.7.6, though, there are platform-specific defaults, and these intentionally do not collide with the –plugin-dir default. This exact exploit has long been documented as the reason behind these configuration options, but in 5.7, the default values are improved so no active configuration is required by DBAs. The following are good references:
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_secure_file_priv
https://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_plugin_dir
2. In addition to improved default value, MySQL 5.7.6 allows DBAs to configure MySQL to disallow writing to output files via SQL commands. This is done by setting –secure-file-priv=NULL (new option value). This is a good practice for DBAs who do not know for certain that writing to outfiles is required.
3. The notice references SQL injection as the mechanism to get the UDF installed in the first place. You cover this in part with the recommendation to ensure application account privileges are limited, but a defense-in-depth approach might also involve deploying a database firewall and/or periodic audit log analysis. Multiple solutions for each exist – I’m naturally partial to those produced by Oracle as part of the MySQL Enterprise suite.
Hi David,
Overly permissive users are probably the norm and not the exception – this is because it’s usually easier for database administrator/system administrator to issue a GRANT ALL for a user rather than just selecting which privileges the user should have.
As for MySQL isolation – by default, any platform (including WHM) isolates the MySQL server from the outside world. What we noticed is that developers are the ones that change that (especially for those who travel a lot and don’t want to allow a new IP every time they are in a different place).