20

Is it possible to execute some code (e.g. PHP code on a PHP-based web application) on the server through SQL injection? If yes, how exactly?

I understand that un-escaped field can lead to SQL injection and an attacker can execute SQL commands of his choice directly on the server. But I think of running only SQL commands, not some arbitrary code. Am I wrong here?

|improve this question
  • 2
    I just want to add that only escaping fields will not fully protect you. Attacks rely on giving malicious content and apostrophes/quotes are only a fraction of what might be used. That is why you should completely sanitize the input, checking for things other than string termination characters. The example used at OWASP illustrates this very well, as the malicious payload used only letters, space (optional), parenthesis and a semi-colon. – DarkLighting Dec 29 '14 at 16:44
  • 2
    Extracted from OWASP SQL Injection CheatSheet:"This third technique is to escape user input before putting it in a query. However, this methodology is frail compared to using parameterized queries and we cannot guarantee it will prevent all SQL Injection in all situations. This technique should only be used, with caution, to retrofit legacy code in a cost effective way." – DarkLighting Dec 29 '14 at 19:48
30

SQL database systems typically have an export mechanism which can write arbitrary files on the server, e. g. SELECT ... INTO OUTFILE in MySQL. If an attacker is able to assemble such a query and isn't stopped by restrictive permissions, they can in fact create PHP scripts. Now they still need to get the server to execute the script. In the easiest case, they have write access to a web directory. If they request the script, the webserver will happily execute it.

|improve this answer
  • If your database was on another machine separate from your web server then this attack wouldn't be possible. You could create the PHP script but without an accessible PHP container to execute it you couldn't get execute it. – chubbsondubs Dec 31 '14 at 14:18
  • The database role of the application shouldn't be able to create files in the first place. – Fleche Dec 31 '14 at 18:00
  • 2
    @chubbsondubs thats a flawed assumption, into out file can still be used in some cases, but second order injections also come to mind. Here is an rce exploit that uses sqli and will work even if the database is on a different host:exploit-db.com/exploits/35578 – wireghoul Jan 2 '15 at 13:08
  • Interesting exploit thanks for sharing, but it's not the same exploit discussed above. Nothing is using the database to write a file to the database server. In your case it's pulling the php from the log file on the web server. Clever indeed. Just to restate what I said WASN'T implying that separating the database from web server keeps you safe as a general rule just that this exploit discussed in the answer wouldn't work if you did that alone. – chubbsondubs Jan 2 '15 at 15:00
  • 1
    Actually @wireghoul's example exploit is exactly what the op was looking for. Better answer than the accepted answer. – chubbsondubs Jan 2 '15 at 15:07
16

It depends on the type of database (MySQL, Postgres, Oracle, etc.) and the privileges of the database user.

If the application connects to the database using an administrator account, code execution is usually possible. It is straightforward on SQL Server, using xp_cmdshell. Other databases require more involved techniques. SQLmap, the most popular SQL exploitation tool, mentions this:

Support to execute arbitrary commands and retrieve their standard output 
on the database server underlying operating system when the database software 
is MySQL, PostgreSQL or Microsoft SQL Server.

For MySQL at least, I think it uses the trick of writing to a PHP file mentioned by Fleche.

From a defence point of view, this is the reason why you should never have your application connect as administrator.

|improve this answer
  • Agreed, it's going to be very database specific and even configuration specific. On SQL Server, the ability to create files combined with ability to enable/load CLR assemblies could allow limited or vast RCE possibilities, but this would require changing default settings(for example CLR is disabled by default, and has limited permissions given the context of the account running the query). – AaronLS Dec 29 '14 at 22:57
  • 1
    @AaronLS worth noting that earlier versions of SQL Server have xp_cmdshell available by default which leads to trivial RCE on apps with SQL Injection. In older tools that's pretty much how it was always done. – Rory McCune Dec 30 '14 at 15:40
4

Many non-trivial applications store objects in the database. An attacker with db access (such as obtained by a SQL injection) could modify them in such way that when they are unserialized, they run the intended code.

This depends on the php application to have a class with a __wakeup() method that can be abused, but the webapp author is not completely in charge of that, as there may be as well third-party classes installed on the server that could be abused.

(The SELECT INTO OUTFILE issue pointed out by Fleche is also worth to note, although *nix mysql servers are usually setup with its own user, and this attack is not possible)

|improve this answer
  • In the serialization case you'd have to modify a pointer to the code, say a class name in the case of Java, to allow for arbitrary code execution. But then you'd have to get your class onto the classpath, and if you could do that then why bother with modifying a serialized object? If you can get something on the classpath you can just execute that code at load time. – chubbsondubs Dec 31 '14 at 14:25
  • 1
    @chubbsondubs, serialization gives you a string like O:8:"DateTime":3:{s:4:"date";s:26:"2014-12-31 23:59:59.000000";s:13:"timezone_type";i:3;s:8:"timezone"... you can freely modify the class name (here "DateTime") and it will be loaded if it either exists in core or a loaded extension, is in the webapp, or the autoloader can find one. The attacker dream would be a class which evals() one of its members, but a class that eg. opened a filename set inside a member variable could also be very valuable. – Ángel Dec 31 '14 at 20:08
  • The first part of your comment was exactly what I said. I could change DateTime to MySpecialAttack, but I have to get MySpecialAttack code into a place where the app would load it (ie classpath), but if I could inject something on the class path why would I bother to modify the serialized object? If a serialized class was eval'ing a member I could see why modifying a serialized class might be helpful. But the real weakness is not serialized objects it's the ability for the attacker to add something to your extensions you load. Cut that off and the attacker can't do anything. – chubbsondubs Dec 31 '14 at 21:19
  • The point of serialization attacks are exactly that you identify a bundled class and divert its logic to the attackers benefit without placing your own code on the server. Look at some serialization exploits against sugarcrm for example. Most of those abuse the applications own theme classes to write php shells on the server. – wireghoul Jan 2 '15 at 13:13
  • Related: Is PHP unserialize() exploitable without any 'interesting' methods? – Ángel Jan 6 '15 at 19:09
3

Besides the things already mentioned, some databases rely on code – for example, the largest part of Oracle itself is written in oracle, i.e. PL/SQL, running inside the database server. If you get an SQL injection, you can very well do things to alter the system state, sometimes beyond what the database user account allows, especially if you have a chance to combine it with a local privilegue escalation.

Oracle, at least, also allows running Java™ code in the database server by default. And maybe a couple more things…

PostgreSQL is extensible, too. You can run things like Perl scripts, not just PL/pgSQL…

|improve this answer
1

Another possible attack vector would be if at any point the contents of the database are executed as code.

A pseudocode example in PHP:

$dbstring = some_db_query('SELECT some_code from some_table ...');
eval( $dbstring );

Thankfully, such a thing would not be common, but if trusted users were permitted to add code to a database, then SQL injection could overwrite it with malicious code.

I believe that the CMS Drupal has such a feature for content created by trusted users (unless they have since removed it).

|improve this answer
1

What your describing would be very possible if the website is running PHP code that is stored in the database and run with eval(). SQL injection would be used to modify the PHP content being stored in the table so that the attackers code is run instead of the original content.

Another possibility would be with a remote file include attack on a file name that is pulled in from the database.

Microsoft SQL server has a stored procedure called xp_cmdshell, that will allow you to run arbitrary command-line applications. This is commonly used by hackers to upload backdoors or web application modifications through FTP.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.