February 19, 2004

MSDN Webcast Review: Application Hacking Techniques

Well well well. An actual presentation on attacking a target that wasn't scripted from a "Hacking Exposed" book. (I have low tolerance for people who have no real knowledge on attacking targets past reading "Hacking Exposed" once and pass themselves off as 'leet h4X0rs).

To be honest I enjoyed watching the SQL injection demos the most. I even learned a neat new command through general extended procedures:

EXEC master.dbo.xp_cmdshell 'dir C:\'

Well, ok I already knew that one... but I DIDN'T know you could manipulate registry keys:

EXEC master.dbo.xp_regread 'HKEY_LOCAL_MACHINE', 

      'SOFTWARE\Microsoft\Windows NT\CurrentVersion', 

      'CurrentVersion', 

      @ver OUT

Thats right, you can read/write/delete registry keys in SQL. There is a tonne more commands you can execute which I stumbled upon while looking into this during the demo like checking media types and even checking if files exist on a system!

Overall this was a pretty good presentation. There were a couple of slow parts, but I was able to use that time to figure out how to install EmbPerl (thanks Wim and Alan!) into Apache and get it running cleanly over SSL.

As always, in the next few days the presentation will be online on-demand which you can check out here, which will let you check it out for yourself. In the meantime, I kept a copy of the power point slides of the presentation, which you can get here.

Posted by SilverStr at February 19, 2004 12:55 PM | TrackBack
Comments

What would be a legitimate use for modifying the registry, running commands, and such through SQL Server? I'm at a total loss here.

Posted by: Darren at February 19, 2004 03:03 PM

If you are connecting to SQL Server through a high-privileged user such that you can use xp_cmdshell, you can do anything. I mentioned in my last security talk, when giving similar demos on SQL Injection, someone could create a user, place the user into the local Administrators group, and then set login access for that user to be allowed from any computer. Imagine that! Scary.

Posted by: Robert Hurlbut at February 19, 2004 04:04 PM

I've used xp_cmdshell in SQL Server before.

Mostly I use it from a scheduled job. On Unix/Linux systems crontab is the standard. However, on Windows I find that the SQL Server Agent has a much nicer scheduling system then using 'Scheduled Tasks'. For example, one of my jobs might have a step that does a quick check for certain things in the database, then conditionally runs a system maintance script written in Perl or some thing like that.

Transact-SQL can do a lot, but on many occasions I've push those limits :-)

I think that as long as you don't send variable arguments to them, or sanitize them if you do, and think through some of the possible threats then it should be ok.

It is indeed scary to see how many SQL installations don't use SSL, use empty or default passwords, give too much access to users, have everyone sharing the same database account, and so on. On the flip side, if the application in question is only accessible to a small handful of trusted people, isn't accessible from the Internet, server access is restricted, and so on and so forth etc, then the risk is pretty low I guess. Of course, that's the kind of thinking that helped SQL Slammer spread, no?

Posted by: Wim at February 19, 2004 06:59 PM

You can create and manipulate OLE Automation objects, as well.

Posted by: Peter Torr at February 22, 2004 11:04 AM