• 
  

• Archives

  • May 2014
  • May 2013
  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • January 2012
  • December 2011
  • October 2011
  • May 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • August 2010
  • July 2010
  • May 2010
  • February 2010
  • December 2009
  • November 2009
  • October 2009
  • August 2009
  • July 2009
  • May 2009
  • April 2009
  • March 2009
  • January 2009
  • September 2008
  • August 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • April 2007
  • February 2007
  • January 2007
  • December 2006
  • September 2006
  • June 2006

• Categories

  • Authentication (2)
  • Code Review (8)
  • Debugging (6)
  • Development (25)
  • Malware (6)
  • Nebulous (2)
  • News (33)
  • Privacy (3)
  • Reverse Engineering (5)
  • SDL (9)
  • Security Testing (40)
  • Tools (22)
  • Unicode (12)

Subscribe

• RSS Feed

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.

-rob

Tags: SQL

This entry was posted on Wednesday, March 6th, 2013 at 2:00 am and is filed under Security Testing, Tools. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.