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,
0 komentar:
Post a Comment