My last few posts about SQL have been about how to exploit a SQL box within the confines of a company network. I wrote about xp_cmdshell and how it can be combined with a poorly-configured SQL box to produce some very unpleasant results. This week, someone at work (an apps developer, of course), wanted me to publish a SQL box to the internet. My answer was an emphatic NO, given this particular app person's history for writing crap code. This person wanted our network guys to poke a hole through the firewall, sending TCP 1433 to the SQL box. Talk about a disaster waiting to happen.
Long-time followers of my blog know that I have a Masters degree in Networking and Systems Administration. One of the subjects of that degree was supposedly about Linux, but actually turned out to be more about security. At the time I was running an e-commerce site, so I had an interest in securing that site. Learning about my own site, the server it ran on, the applications that ran on it etc was very enlightening. I was able to see through the web server logs that my server was being hit 24/7 by automated attack scripts.
The scripts weren't really all that interesting; mostly they were remote file inclusion probes. Some contained URLs to files on servers that had already been exploited. I downloaded these files and most of them were pretty stock-standard footprinting scripts. The sort of thing that details what OS the compromised system is running, what version of its components (eg SSH, which at the time had a pretty nasty vulnerability) etc. One file contained a huge script that created an IRC bot network. It was actually fascinating.
But that's not what this post is about. All of this study and research got me onto SQL injection vulnerabilities. At the time, there was a poorly-coded osCommerce module called something like Customer Testimonials. It did not sanitise its inputs, so a properly-crafted URL could reveal information contained within osCommerce's tables…. including credit card details, if the site operator was silly enough to save them (BTW, this is a fundamental breach of PCI standards, which I'll not go into, but is worth learning about if you're interested in e-commerce). I set up a test VM running osCommerce plus the vulnerable version of the testimonials plugin, and sure enough, I was able to exploit it to view data from osC's tables.
Remote File Inclusion attacks are pretty easy to defend against. Tell the web server (or relevant module eg PHP) not to run content from URLs or remote file systems. Defending against SQL Injection attacks can be more complicated. At its worst, it means checking hundreds of lines of code for silly things like (pseudo-code):
$query = content of web form or specially-crafted URL execute $query
There are server-level defences to filter out SQL injection attacks, which I won't go into here, but the reality is that bad code will always be bad code. And bad coders often don't know their code is bad until long after it's in the wild. With that in mind, and bearing in mind some of the xp_cmdshell exploits I demonstrated in my previous posts, have a wander over to this page. What I really like about some of the stuff demonstrated here is that one of the examples (example 8) leverages bad SQL security to inject a file, which in turn can be run to perform some malicious task.. or even better, run as part of an IRC botnet. The possibilities really are endless. Click some of the links at the bottom of that page to read some very interesting articles on SQL injection attacks.
Bad configuration within a corporate network is one thing. Sure, it sucks, but it can usually be contained (perhaps by design of other systems such as firewalls, content filters etc). An internet-facing server, once compromised, can be used to do some pretty bad stuff. Anyone who thinks publishing a SQL box to the internet consists of only poking a firewall hole on port 1433 needs to rethink their approach to system security. Actually, anyone who thinks whacking a firewall in front of an internet-facing server will magically protect it.. think again.
What I find really interesting about SQL injection attacks is that they are a multi-layered thing. They rely on poorly-configured web servers, crappy code, badly-configured SQL boxes etc. But what's really cool is that the SQL boxes themselves don't need to be presented to the internet. The only requirement is that a the web server (or more generically, the application server) have connectivity to the SQL box. Hiding those SQL boxes on a private subnet won't help. Hiding them behind an internal firewall won't help. Hiding them on protected VLANs won't help. It won't matter. Because once the web server manages to talk to the SQL box, once the web-server-generated query traverses the wire from web box to SQL box, the scope for damage is already present.
What I'm saying, folks, is that security is a multi-layered thing. I don't claim to have all the answers. I'm not a security expert. But I am security-aware. All good sysadmins ask questions about the code that's running on their boxes. What does this code do? Why does it do it that way? Can it be done in a more secure fashion? What does it really need access to? Can the code be run isolated? Do we have sufficient logging to keep track of breaches? If this box is compromised, what else can it access? If there is a breach, what is the scope of information disclosure? There's so many questions to ask. Don't be afraid to ask them. If your apps people can't tell you this stuff off the top of their heads, stamp a great big red DENIED across the request.