But the logo says I'm secure!

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.

Fun with DCE-RPC Fuzzing

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 within their environment.  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.  The client, naturally concerned about how common RPC exploits are in Windows environments, wanted to see if this functionality worked as advertised.

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.

Our team's results were mixed.  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.  It certainly was a nice change of pace from our traditional Windows penetration tests.

Hotel TVs and stupid security controls

A quickie while I'm still logged on:

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.

Still alive

So much for keeping a regular blog. A few weeks of boring documentation work gave me no inspiration to write, and then I was on vacation for another two weeks. Since then, I've been slammed with back-to-back web app assessments and pen-tests. Which is great, because that's when I'm actually learning and exploring new techniques...except it also means that I'm too busy to post here. I have a fun little SQL injection write-up that I'll get online soon; I've also received a few e-mails asking about how to get started in this field, so I'll eventually cover that too.

My First Physical

After years of trying, I finally got onto a security project that included physical penetration testing. I'll readily admit that I romanticized the whole idea of it - how can you not get excited about being allowed to break into a company's offices and hack their network like a real intruder? I was going to do some real social engineering, maybe even some James Bond-esque stuff to get in. That or I was going to get caught on the spot, spoil our testing, and be the well-deserved subject of ridicule among my coworkers.

So it seems perversely appropriate that after days of nervous, meticulous planning, executing the whole test took a mere few minutes and was absurdly simple:

Walked into the lobby and loitered around for a while, pretending to be on the phone...

Tailgated behind someone through a badge-access door...

Wandered around the office floor, walking with "purpose" until an open cubicle was found...

Plugged into the network, hit our target servers, collected evidence. Done and out in no time.

All that build-up for nothing - but at least it was a success! Then we got in the same way three more times, at different offices altogether, to really prove our point and demonstrate that our first compromise had not been a fluke. It was really no challenge at all - no one ever questioned me or my teammate, even when we spent half an hour stealing a printer's network connection while pretending to repair it in a copy-room.

Easy or not, it was still a huge rush to pull off the attack without a hitch. The human element of security fails yet again. But in all fairness, who wants to be the jerk who says "Hey, I'm closing the door on you, you need to badge in!"

It's a good thing we didn't have to attempt one of our more absurd cover stories. One idea was to pretend we were air quality inspectors working for the office building's management company, and needed to walk the halls with our "equipment" to test some Carbon Monoxide levels. It seemed like a good idea at the time - hell, maybe it would have worked.

I guess I should also mention how the two of us spent a half hour in a locked, private men's bathroom at one of the client's offices, trying to crack a wireless access point's encryption key. It was the only publicly accessible, inconspicuous place where we could get a usable signal worth a damn. Needless to say, we exited the bathroom ten minutes apart, and very carefully. Definitely wouldn't have wanted to talk my way out of getting caught in that situation.