hideaway [dot] net

Wednesday, July 23, 2008

I still remember the first time I bought an issue of 2600. I was probably 13 or 14 and had discovered the magazine through some posts on a BBS. Finding a copy at the local bookstore was a huge nerdy rush, and I'm embarrassed to admit that I felt like some sort of rebellious bad-ass with contraband when I took it to the register. Even if I was too chicken to try anything remotely illegal, I still wanted to soak up every last article no matter what the topic: phreaking, computer hacking, lock picking, or simply defying the man.

My quarterly copies of 2600, combined with text files gathered from BBSs and early web sites, engendered the passion I still have for hacking and security. I kept a binder, organized by subject, where I would collect articles and printouts. I discovered "Off the Hook" on WBAI and would tune in every week. And I even penned a few letters and articles that were published - you can imagine what a thrill that was for the ego of this young geek (thinking about them now makes me cringe).

I stopped keeping up with 2600 many years ago, mostly because the Internet became a far better source of information. So it was with an enormous dose of fond nostalgia that I purchased "The Best of 2600: A Hacker Odyssey" from Amazon this week. I'm happy to say that it's an exceptionally well-done collection spanning 800 pages and 20 years of history and hacker lore. Articles have been nicely arranged by era and general subject matter, with plenty of interspersed new material written by Goldstein. Content spans everything from phone phreaking during the Ma Bell days to hacking during the modern Internet era.

Of course, nostalgia doesn't change the fact that some of 2600's articles suffered from awkward writing and somewhat juvenile anti-establishment overtones - especially when you read them as a staid "grown-up" instead of an over-eager hacker-wannabe teenager. But you have to consider the context in which they were written. Many of the older articles truly capture the hacker spirit, developed by pioneers who had far fewer resources at their disposal for obtaining and sharing knowledge.

If you have even a passing interest in the history and evolution of the hacking "scene" over the last few decades, I highly recommend this book. For me, reading it has been both informative and a fun trip down memory lane. You can pick up a copy at Amazon.

Friday, May 9, 2008

Russ McRee at HolisticInfoSec.org posted a fun little video to demonstrate just how effective McAfee's "Hacker Safe" ScanAlert really is. These sites have some really basic XSS vulnerabilities, so either the scans aren't working, the companies aren't bothering to fix known weaknesses, or it's a little bit of both. If all they care about is sticking a logo on their site, they might as well invest in Scanless PCI.

Saturday, May 3, 2008

I recently finished working on an interesting project that was a mix of architecture assessment and penetration testing. One of our key tasks was to analyze the effectiveness of a firewall that they had configured to perform layer 7 inspection of Windows DCE-RPC traffic. The firewall was designed to enforce a white-list of allowed RPC services (based on UUID) and deny all others. It also did some fancy dynamic port management, automatically opening/closing high-number ports for permitted RPC connections.

Our pen-tests usually don't entail a significant amount of packet crafting and manipulation, since we're more typically working at the OS or application level. So testing this firewall's RPC filtering mechanism was a fun challenge. We ended up relying on two tools to perform fuzzing attacks, primarily manipulating the UUID and function call fields in the RPC packets:

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.

I initially wanted to use Scapy, but it unfortunately doesn't have native support for DCE-RPC and I didn't have the time (or skill) to build out the protocol. Of course, we also heavily relied upon Wireshark since it decodes DCE-RPC v5 very nicely, and Metasploit to launch a few known RPC exploits.

After extensive brainstorming and failed attempts with my colleague, we were able to trick the firewall into opening RPC ports by spoofing valid RPC sessions - but only for white-listed UUIDs. I was more interested in getting the firewall to choke on malformed endpoint mapper requests or other RPC packets, and possibly create denial of service conditions (or get packets with disallowed UUIDs past the filtering mechanism). No luck there, mostly due to how the RPC endpoint mapper and firewall work together to dynamically open ports. The specific port opened for an RPC service is dictated by the endpoint mapper response and cannot be defined by the initial request - which makes sense, the client shouldn't have any say in what port the server chooses for the service.

Despite failing to completely own the firewall, designing and implementing our testing approach was a great experience - especially coding the Python test scripts with Impacket.

Thursday, November 15, 2007

Ever come across a web application that only performs input validation via JavaScript? It'll pop up and stop you from submitting a form with illegal characters, but it's obviously just a client-side control, and therefore trivial to bypass using a proxy tool like Paros or Burp. Stupid, but I guess it stops the dumbest of script kiddies.

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).

The basic premise is that the PPV movies are broadcast in the clear over regular channels, but until you pay for them the OnCommand box prevents your remote and TV from tuning to them. In other words, if you can bypass the IR control you can tune to whatever you want. It's "fake" security, just like the JavaScript input validation. (That was a hell of a long way to go for a bad analogy).

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

Way back in 1997, a Windows exploit named "NT Pass the Hash" was posted on Bugtraq. This Unix-based tool was a modified SMB client that lets you use captured LanMan hashes, without having to decrypt them first.

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.

No password cracking required! So if you own other systems on the network, you can just run whosthere.exe on them until you snag a domain admin's hashes. Or you could use a man-in-the middle attack, like the WPAD proxy exploit. As I discussed a few posts ago, the Metasploit guys covered several methods for grabbing NTLM hashes in their Tactical Exploitation presentation at BlackHat.