Tag: vulnerabilities

Proactive Protection for Critical Vulnerabilities in MySQL

Proactive Protection for Critical Vulnerabilities in MySQL

Earlier this month security researcher David Golunski published CVE-2016-6662 for critical vulnerabilities in MySQL “which can allow attackers to (remotely) inject malicious settings into MySQL configuration files (my.cnf).” Oracle has yet to release a security patch for these vulnerabilities but is expected to in October. In the proof-of-concept it is noted that file permissions do NOT matter for the actual exploit to work but poor file permissions are used as an easy example.

For situations where you have critical vulnerabilities and no patches available to resolve them a question may come to mind: “Is there anything out there that could mitigate these vulnerabilities?” Thankfully, the answer is YES!

Working with Symantec Data Center Security Server day in and day out for organizations that are in need of a Patch Mitigation and Server Hardening solution has shown me that there is a great need out there. Providing a solution that not only mitigates risks to the critical system but provides ongoing protection without affecting performance or dealing with definitions is satisfying to say the least.

To help understand how the solution works let’s look at this diagram:

+Symantec DCS Sandbox

When the MySQL daemon is launched it gets routed into a sandbox by the Symantec DCS agent that controls what it can do. What files, network IP’s and ports, and processes running in memory mysqld can access. We’re focused on MySQL in this example, but DCS provides the same protection for any daemon or application.

If you think about most of the exploits out there, malicious actors are instructing a service/daemon/application to do something it should not be allowed to do and does not need to do. With Symantec DCS we are forcing them to only do what they are supposed to. To describe the solution in simple terms, use the analogy of an appliance: Should your microwave ever cook your food longer than what you instructed it to do? No, it’s purpose built. However, OSs are designed to be multipurpose. So DCS takes a database server and says you can only be a database server.

The example given in the proof-of-concept shows how you can update the MySQL configuration file (my.cnf) to load a malicious library once the mysqld is restarted. When it restarts it then opens up a Netcat listener port for the attacker to gain root level shell access remotely.

Since DCS sits in the kernel and intercepts system API calls it can provide Privilege De-escalation and thus prevent from exploit and others like it from succeeding. It does not care what user you are logged in as, root, MySQL, or any other user. In this diagram shows the mysqld process access rules where we’ve specified the files and directories that cannot be accessed and ones that it can read but not write.

 

Symantec DCS Sandbox - Deny/Allow

 

To make the exploit a success we need to execute Netcat to open a listener. With DCS this would not be allowed and it does not matter how its executed and by whom. If it’s not explicitly allowed, then the process will go into a zero access sandbox.

The question now is how would we make exceptions? There is a great feature in DCS called “Auto-tuning” also called “Auto-sandboxing.” When you’re in the initial phase of deploying DCS you’ll have the ability to record the activity and apply exceptions for normal activity.

To summarize:

  • Stay ahead of vulnerabilities with proactive protection for 0-day exploits
  • Services/Daemons/Applications should only have access to what they need
  • Make your servers purpose built
  • Choose a heterogeneous solution that has a proven track record

References:

Contributed by: Shane Mears