SQL Injection Penetration Testing

Fun with SQL Injection Penetration Testing in CORE IMPACT Pro

As some of you readers may already know, I’ve made the decision to leave Core and join SpiderLabs. Some life changes (notably, a child!) have occurred and while I’ll miss Core greatly, I’m excited about my new life. I’ve been with Core for a while now, but before I even interviewed at Core, I was doing Web pen testing. Naturally, I’ve been getting a bit nostalgic, and I figured I should do one more blog post before I go.
On the topic of nostalgia, I thought my blog post should be about one of the first things in CORE IMPACT Pro that really impressed me when I first got a chance to play with it. The feature I’m referring to is part of IMPACT’s ability to blend attack vectors together. With this post, I’m going to focus specifically on seizing control of a database server through an SQL injection flaw where the privileges gained allow for the execution of system commands!
There are a few ways to do this through IMPACT, but first we need to find an SQL Injection flaw. Let’s assume that we’ve already got one, either by letting IMPACT fuzz it out for us, or by telling IMPACT where it is and letting the tool figure out how to exploit it. Once it successfully confirms that exploitation is possible, we’ll see a SQL Agent, as pictured below.
If we look at the SQL Agent itself and check out the Quick Information pane, we can see the privileges the SQLi flaw gives us, as well as information about where the flaw lies, what kind of query we’ve injected into and a bunch of other data.
Score! We’re not only admin, but we’re totally unrestricted. Since this is an MSSQL database (we can see this if we scroll down), it’s one of the databases that supports running system commands through SQL queries. If the xp_cmdshell procedure has been removed, we can recreate it through an IMPACT module called “Enable xp_cmdshell stored procedure.” Right-clicking the Agent will immediately allow us to pop either a command shell or an SQL shell on the database.
Let’s pop a command shell. This is all performed through SQL injection, so even if the database cannot communicate with us directly, we can still run system commands through the vulnerable Web application.
Naughty, naughty! Looks like we’re running as SYSTEM…
A shell is nice, but what if I want to be able to use all of the features of IMPACT from this machine? We’ll need an OS Agent on there so we can pivot off of it and use the post-exploitation modules written to be used with OS Agents. IMPACT has a module that will write an Agent Trojan to the host and execute it, all through our nice little SQLi flaw. Let’s look at the “Install OS Agent using SQL Agent” module.
Here we have three options. The first option defines the SQL Agent to use. The second allows us to choose a directory in which to drop the OS Agent executable. It defaults to the working directory and that’s fine by me. The third allows us to choose a name for the file to be dropped. Here you can see I’ve defined a very convincing and subtle name for the Agent!
Once the module finishes running, we’ll have a new Agent deployed and visible in the Network tab. From here, we have a foothold on the network and complete control over the host. Now we can set the database server as the source of our attacks and continue our test as if our Impact console was installed on the database server.
One final note: The above example was using traditional, vanilla SQL injection. IMPACT also offers the same capabilities via Blind SQL Injection, which just takes a little longer to run (understandably).
If you’re anything like I was years ago when I first saw this in action, this is pretty exciting stuff!
Well, it looks like that’s it for me.
A fond farewell from yours truly,

SQL Injection Penetration Testing Rating: 4.5 Diposkan Oleh: Miftah Budi

0 komentar:

Post a Comment