Friday, May 9, 2008
Saturday, May 3, 2008
- Impacket - A collection of Python classes developed by the Core Security guys. Includes support for DCE-RPC v4 and v5. I used this to write up a number of scripts for each test case.
- SPIKE - Popular fuzz testing framework based in C - it includes a pre-built msrpc fuzzing tool.
Thursday, November 15, 2007
Earlier this week, I decided to plug my iPod into my hotel TV's A/V input jacks so I could watch a movie on the larger screen. No-brainer, right? They even have the inputs on the front to make it really easy. Then I noticed that I couldn't change video inputs on the stupid thing - no buttons on the remote, no menus, nothing. That's because instead of a normal remote, the TV had a special one programmed for the OnCommand pay-per-view service, and they conveniently left out the input selection function.
The OnCommand unit is a small box that sits in-line between the coax cable running from the wall to the TV. It has a RJ-11 cable that plugs into the television and intercepts the IR signals from the special remote, allowing you to control and purchase "premium content". I did some research and found that a few people have messed with these older hotel PPV systems; in fact, there's an article from 2005 in Wired about how easily they can be hacked. Basically, you can do plenty if you have a USB TV tuner (and/or an expensive, commercial "master remote" that the hotels use to program these things).
I didn't care about free PPV, I don't want to steal anything - I just wanted to enable the damn video jacks. Acting on a stupid impulse, I bought an $8 universal remote and programmed in the codes for the TV's manufacturer. With a press of the "menu" button I had access to all of the TV settings, including adjusting the tuning and channel locks, and most importantly, switching video inputs. It was that easy.
What a stupid design - just let people use the damn inputs, you'll still sell plenty of porn. In the meantime, I guess I'll always pack this universal remote when I travel. Wow, what a nerd I am.
Thursday, August 23, 2007
After a mere ten years, someone has finally modernized this concept into a much more potent attack. Core Security has released Pass-The-Hash Toolkit, which runs on Windows and works with NTLM hashes. It's comprised of two key modules:
- IAM.EXE - This tool "injects" another user's NTLM credentials into your current Windows logon session, given their username, Windows domain, and NTLM hash. You can then use the 'net' tools or any other Windows software that authenticates via NTLM, all under the assumed privileges of the compromised user account.
- WHOSTHERE.EXE - Lists the usernames and NTLM hashes of all users logged on to a system.
Wednesday, August 15, 2007
This was an internal application, so I wasn't surprised to find that it was vulnerable to SQL injection in several areas. However, in-band injection attacks weren't working for the application I was testing - I couldn't use UNION SELECTs, for example, to merge my query results with data rendered in the browser. So I had to leverage an out-of-band technique for retrieving data through SQL injection: Oracle's UTL_HTTP.REQUEST function. David Litchfield mentioned this approach almost two years ago in Data-mining with SQL Injection and Inference, but I never had the need to use it "in the wild" until now.
UTL_HTTP is a built-in Oracle SQL function that issues HTTP requests. The syntax is pretty simple:
For example, consider the following SQL:
The SELECT statement returns the value "SYS" - the first user in the DBA_USERS table. The HTTP request issued by the database is therefore for the URL "http://www.foo.com:80/SYS". In www.foo.com's HTTP access log, the request would look like:
220.127.116.11 - - [08/Aug/2007:10:02:40 +0000] "GET /SYS HTTP/1.1" 404 0 - -
(assuming 18.104.22.168 is our target DB server)
So as an attacker, you simply need to run a web server and point the UTL_HTTP.REQUESTs to your own IP address. You can then view the result of each SQL injection in your server logs. If in Windows, I like to use SHTTPD as it is lightweight and simple to turn on and off.
The biggest limitation to this approach is that you can only query for one row at a time - you'll get an error message if your statement returns multiple rows. (That is due to the UTL_HTTP.RQUEST function itself, not the web server end). But it is still a lot more efficient then using blind SQL injection to brute force one character of a response at a time. Oracle will also throw an error if it can't reach your web server, which may be the case depending on network controls between yourself and the database. Experiment with running on different ports.
There are probably a few things you could do to make the attack more elegant, like setting up a CGI script on your server to better collect and parse the calls from the database. You could also create and inject a PL/SQL function that concatenates results from multiple rows to get around the single-row limitation. I needed a quick and dirty solution to get a few key database records, so I didn't bother venturing beyond the basics for this test.
Outbound HTTP requests originating from a database server should look suspicious, but I think the attack is obscure enough to slip by most admins.