As shown, injections are still one of the worse problems. If you're not familiar with SQL injection check out some basic ways to exploit it on vulnerable site. The examples are often about trying to select some sensitive data and getting the data to be rendered on the vulnerable site.
I'm not a black hat hacker so I've always thought about SQL injection as something primarily putting the site and it's data into danger. But tag along to see that SQL injection can be the entry point of pwning the complete server and getting inside the firewall and the internal network.
Now, I was reading up on SQL the other day for a project at work and stumbled upon some SQL syntax I didn't know about. Combining this with an SQL injection vulnerability could be dynamite.
So first, assume you found a weakness on a site. There are tools for that, but basically try to append code to request parameters like ' or 'foo'='1 or similar to look for server crashes giving you a hint of SQL injection problems like Unknown column 'foo' in 'where clause'. Now you would "normally" start the tiresome work of finding something valuable in the database.
But, with the SQL syntax INTO FILE you can write files. Nice. So depending on what technology the server is based on you could write files that can be accessed via the web interface. If the file names in the URI don't give away what technology used look at the HTTP header value of Server. If for example the header talks about JBoss you can guess that the site is Java based and we could try to create JSP files. Similarly you could aim for creating PHP script files etc if that's whats dished out by the server.
So, by using something like this in the injection exploit (the red is what is supplied by the hacker via the request parameter injection)
SELECT a, b FROM someunknowntable WHERE someunknowncolumn = '' UNION SELECT '<?php system($_GET["cmd"]); ?>' INTO OUTFILE '/var/www/htdocs/pwn.php'; --
or similar for other scripting technologies like JSP, ASP etc you have created a public backdoor.
Catastrophe!
Point you're browser to http://thesite.com/pwn.php?cmd=pwd
to print out the currect working directory of the web server process.
Now only imagination stops you. cmd=cat /etc/passwd /etc/shadow to dump all user credentials. If the web server is running as root it's too easy to start creating misery like keylogging the other users or dumping all databases.
The lesson from this is that if you have five web servers and databases hosting different sites on your server it is the weakest link of them that defines the total security. So by hacking the not so important server with an SQL injection weakness you can get to the data of the highly secured applications with no SQL injection weaknesses via a backdoor.
Some thought on avoiding this kind of problems
- Always use frameworks and libraries that removes the possibility of SQL injection. Java has prepared statements or some of the ORM technologies. The other languages has their own ways.
- Run the database process as a user with low file access priviligies so that it can't write files anywhere it shouldn't be able to. Or even better, run it on a separate machine.
- Same for the web server, don't run it as root. There are other ways of hacking web or application servers to gain shell access.
- A general good thought is not to reveal to much information about what technology serves the site if possible to make it harder to exploit knowledge about how it behaves. For example, don't show server versions in HTTP headers, don't show crash stacktraces in server responses in production mode and so on.
