Friday, May 20, 2016

Separate Servers for your Website and DB?

Let's say you have a website and a database. Should you have 1 server or 2. Does it matter? Here's just 1 example of why it matters. Let's pretend your website has a single SQL Injection vulnerability on it. When that attacker injects a SQL statement, it will execute against your database. Did you realize there are SQL commands that can interact with the server's filesystem? As an example

SELECT * from orders INTO OUTFILE '/tmp/orders.txt';

The above statement could be used to dump the output of a select query of all orders into a text file. Hey, as a DBA or developer that might be useful. But guess what, as an attacker, that is useful too! First I'll give a simple example.

SELECT '<? echo 'hello world' ?>' INTO OUTFILE '/var/www/helloworld.php';

Now the above statement seems a bit strange at first, but essentially I'm dumping PHP code for a hello world program into a php file. So now I could navigate to hxxp:// and there would be a file that says 'hello world'. Interesting right? Maybe not harmful yet, but it has potential. Now try something a bit more evil.

SELECT '<? system($_GET[\'p\']); ?>' INTO OUTFILE '/var/www/backdoor.php';

The above statement may be daunting at first, but all it's doing is writing php code that executing At the server's command line what is passed via parameter 'p' . Why is that bad? Well, the attacker could now visit your site again perhaps with this url hxxp:// and guess what, the page would execute the 'ls' command and list out all files in the web root directory. Now you could get way more creative than that and create a file or run an command that perhaps uploads a web shell, malware, or something more persistent to the server and control is on a more permanent basis.

Now back to the original topic at hand. In a scenario like above, what is one thing that would've made this type of attack a bit harder? One answer would be if the Web Server and Database server were on separate servers. Why would that make it harder for the attacker? Well, they likely can no longer run a single SQL injection command that dumps a php file and creates a backdoor. Instead the SQL command they run will be on a SQL server that doesn't necessarily have access to the web server or web root folders on the web server. Thus the attacker is going to have a lot more work to do, such as establishing persistence on the SQL server, then finding a way to either communicate outbound from the sql server back to the attackers device (likely harder if it's an internal machine with additional security hardening), or finding a way to pivot to and attack the web server to take control of it. Either way it's definitely a more daunting task than simply being handed a nice little server with the web and database mashed together. Consider that the next time you architect your solution. Tiered environments have many security benefits.

More about neonprimetime

Top Blogs of all-time
  1. pagerank botnet sql injection walk-thru
  2. DOM XSS 101 Walk-Through
  3. php injection ali.txt walk-thru

Top Github Contributions
  1. Qualys Scantronitor 2.0

Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

No comments:

Post a Comment