May 17, 2008
GUI access through SQL Injection
|
Alberto Revelli tests web applications and anything else that happens to tickle his passion for breaking things. He is speaking at EUSecWest on the topic of hacking databases. Read on for tips on executing code from SQL statements and for some useful tools you may not have tried yet. |
Sean Comeau: Most web app developers know, or should know, by now that SQL injection attacks allow attackers to do things they shouldn't be allowed to do with data in the database. What else can happen?
Alberto Revelli: Modern DBMS are becoming very complex entities, providing a plethora of functionalities, with powerful features that can impact not only the stored data but also the network and the underlying Operating System. This means that if an attacker is able to interfere with the Database and some preconditions are met, he/she might be able to attack not only the data tables but also the infrastructure on which the Database is deployed. It is important to keep such scenarios into consideration, when assessing the risk of an infrastructure.
Sean Comeau: Does this mean that all SQL injection vulnerabilities are also remote code execution vulnerabilities?
Alberto Revelli: Luckily (or unluckily, depending on which side of the fence you are in), that's not the case. Administrative privileges are usually needed in order to access such privileged features, so either the administrator made a big mistake in configuring the access to the DB (which happens quite a lot, actually) or the attacker was able to escalate his/her privileges, which is not always possible.
If DB administrative privileges are obtained, however, as a general rule, the attacker has the same privileges as the Database process and will be able to perform any OS-level action as that user. So, in general the attacker will be able to run commands, start network connections, bind ports (even privileged ones, if the DB runs with OS administrative rights). At this point, it's almost like sitting in front of the DB server, with the goal of expanding our influence in the target network as deep as possible
Sean Comeau: Can you go into the details of one of the ways you can execute code on the host or make network connections?
Alberto Revelli: The most straightforward example is in MS SQL Server, that provides an extended procedure called xp_cmdshell, which takes as a parameter the command to execute. So, for instance we could inject:
EXEC master..xp_cmdshell 'ping 127.0.0.1';
[Editors note: The extra dot is intentional]
Obtaining administrative rights might be hard, but as you can see as soon as you are an administrator everything becomes easy. Of course this is a trivial example, and is limited to 'DOS prompt'-style. In my speech I will show other techniques to unleash the full power of the underlying OS against its own network ;)
Sean Comeau: Besides SQL Server, are other databases vulnerable?
Alberto Revelli: To the best of my knowledge, all major DB technologies now allow some level of code execution to users that have enough privileges. I can think at least of DB2, Oracle and MySQL. However, in some environments the task can be less straightforward than in others.
On MySQL on Windows, for instance, command execution can be done by injecting a DLL into the target DB file system, and then creating an ad-hoc function that uses that DLL to interface with the OS.
Oracle provides different methods to execute commands. For instance, Oracle 10g provides a feature called 'dbms_scheduler' which can be used exactly for this goal.
Sean Comeau: Is there functionality that can be disabled/enabled/used at the database level to prevent some of these tricks from working in the event that SQL injection is possible?
Alberto Revelli: The principle of least privilege is your best friend here: web applications should only be able to access the data they need, and by no means their queries should run with administrative privileges. Of course, privilege escalation attacks need to be taken into account too here, and administrators can limit the risk by keeping their DB constantly updated and by disabling all unneeded features that could be abused by a malicious user to attain higher privileges. Last but not least, let's not forget the good old principle of "defense in depth": securing the DB is important but the first line of defense should always be a careful (read: paranoid) filtering of user-controlled input.
Sean Comeau: Do you have any easy to cut & paste SQL snippits which DBAs/developers can use to quickly run as their "web" user to determine if it has any dangerous privilages?
Alberto Revelli: Mmh... unfortunately not. Plus, each DB has its own tables and commands to manage the privileges of a particular user. The best way is to check the configuration of the web application, looking at how it connects to the remote DB and with which credentials. Then, on the DB side, check that this user has not privileges that are not strictly needed. Unfortunately, the details vary heavily so it's hard to come up with a useful script that works in all cases.
For more information about SQL Injection, I can recommend the OWASP Site, whereas a nice SQL Injection Cheat Sheet can be found at http://ferruh.mavituna.com. Regarding good free tools to test your applications, I can suggest sqlmap, BobCat, and of course Sqlninja.
Sean Comeau: Very cool. Thank you Alberto.
Alberto Revelli will speak about more attacks against databases at EUSecWest.
