SQL Post-exploitation: Protections and Mitigations

March 6th, 2013 by

Several questions have come up since giving my presentation in October at ToorCon; a lot of people want to know what they can do to protect themselves from the attacks I’ve outlined and what sort of monitoring solutions are in place to detect these scenarios. The short answer, which won’t give anyone the warm and fuzzy: Not a lot.

Taking a step back from the obvious bad things that these techniques can permit attackers to do in the SQL environment, we have to realize that this is a post-exploitation scenario. To accomplish any of the things I presented, the SQL server is already compromised, the attacker already has elevated access in the database, and the war (at least on that host) is lost.

Several things can be done to prevent the compromise, all of which come with proper SQL server administration:

  • Strict user policies, preventing the creation of extended stored procedures by anyone but an administrator.
  • Log monitoring to watch for the creation of extended stored procedures.
  • Relying on authenticode to permit only signed and trusted binaries from execution in the SQL environment.
  • Code review of applications and services accessing the SQL instances to determine vulnerabilities that can permit access to the server.
  • IDS technologies to monitor SQL communications – with signatures created for the creation of extended stored procedures, anomalies in traffic, and excessive or untrusted connections to and from unknown hosts.
  • Tripwire style file system monitoring.

Because of the nature of database servers, it’s highly unlikely that someone will create a technology to monitor the memory of the database, the overhead in processing would impact the performance of the host; not to mention that everything I’ve demonstrated is facilitated by the SQL architecture. To protect SQL servers from these dangers, the first step is to not get compromised (not always up to you), this is accomplished through solid administrative best practices and due diligence in the environment. If your SQL server comes under fire from these sorts of techniques you already have bigger issues than someone extending the functionality of your database.



Leave a Comment