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

Pass the hash, NTLM style

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.

BlackHat Wrap-Up

I've returned and recovered from a fun week at BlackHat in Las Vegas.  The conference was a great experience and had an excellent selection of speakers.  As with other hacking conventions I've attended in the past, it was humbling to see how smart some of the presenters and attendees are.  I unfortunately couldn't make it to Defcon this year (damn client obligations!), but four days is just about the right length of time to stay in Vegas.  

To share a few random observations and cool things:

• At this point it should be clear that browser vulnerabilities are this "generation's" OS-level vulnerabilities.  Owning the client means you can do just about anything, including full-fledged attacks against internal networks.  David Byrne's anti-DNS pinning really drove this home, particularly when he used Java LiveConnect to proxy a full Nessus scan against an internal host through the browser. 
• Billy Hoffman's talk on "The Little Hybrid Web Worm That Could" was really interesting - he's always a good presenter.  He illustrated several pieces of proof-of-concept JavaScript code that can self-mutate, parse sites like Secunia to "learn" new vulnerabilities, and exploit web application vulnerabilities.  It won't be long before we see these kinds of worms in the wild, as the technology and research are already in place.  
• Errata security demo'd a tool called Ferret that combines WiFi sniffing and gathering sensitive information into somewhat of a point-and-click affair.  It works with a HTTP proxy component that lets you easily use session cookies hijacked from other users' browser sessions.  He used it to hop on to an attendee's GMail account while on stage, which really got the audience going.  There's nothing new here - we all know you can sniff and re-use cookies from non-SSL'd connections - but the tool is still a neat implementation.
• A presentation on extrusion detection systems by Matasano ended up being far more interesting than I expected.  While their research focused on vulnerabilities in agent-based tools designed to prevent information leakage, it conceptually applied to any agent-based product (I'm thinking of SIM tools in particular).  Through reverse engineering, they revealed how trivial it would be to take over agents, execute code at the Windows kernel level, spoof reporting data, and cause other havoc.  It made me really want to grab a copy of PaiMei and learn more about reversing and fuzzing.
• The Metasploit team gave a fantastic two-part presentation (available on their site) on tactical penetration testing.  Their message was one we've always preached to our clients: pen-testing should not just be vulnerability scanning and firing off exploits.  They covered some interesting new resources for footprinting targets and network discovery, such as DomainTools.com and Paterva.com.  
  
  The presentation also included a demo of a new Metasploit component that facilitates NTLM hijacking.  You basically capture the victim's NTLM hash through a man-in-the-middle attack (the WPAD proxy hijack technique works great for this), and can then re-use this hash to authenticate with the user's credentials.  There's no need to crack the NTLM hash!  I plan on testing this one out in our lab - although our rules of engagement unfortunately often forbid us from performing network redirection attacks against clients.   
• SensePost had a presentation on timing-based attacks that I wish I had not missed.   They demonstrated "SensePost-aTime", which leverages timing information to perform SQL injection and extract data.  I couldn't find it on their web-site yet, but will post as soon as a link is available.  Until then, you can check out a recent post on ha.ckers.org that covers a "res://" timing attack that enumerates a user's local files through the browser.
• My "Best Booth Gimmick" award goes to Fortify Software - their Borat-inspired "Discover Hackistan" promotion was pretty damn funny.

Personal goal for next year: to put together a presentation that I can at least attempt to submit for BlackHat or Defcon.

Insecurity through stupidity - FTP servers expose DoD data

The Associated Press is running a story on how they discovered an extensive number of sensitive but unclassified military documents kept on unsecured FTP servers. Both government and contractor systems were found to allow anonymous access to goodies like project schematics, facility security information, building plans, and geological survey data. Some of the responses by the guilty parties are both hilarious and frightening. My favorite quote from the article [emphasis added]:

A spokeswoman for contractor SRA International Inc., where the AP found a document the Defense Department said could let hackers access military computer networks, said the company wasn't concerned because the unclassified file was on an FTP site that's not indexed by Internet search engines. "The only way you could find it is by an awful lot of investigation."

Yeah, it's really no big deal, you never see port scanning or worms checking for anonymous FTP out on the Internet - it's far too much work. If the system isn't indexed on Google, no one will ever find it.

When I first started doing this kind of work, I couldn't believe how many high-profile clients had no grip on their Internet presence or systems therein. I eventually came to realize that it's a widespread problem, made even more problematic when companies have to track both in-house and outsourced systems and hosting. Every external penetration test we perform is preceded by a footprinting phase, where we identify the client's IP ranges and ensure we have approval to test them. Nine times out of ten, they end up shocked at what we discover. Clients often have no clue whether certain address ranges are actually theirs, never-mind what systems are on them or what services they run.

As much as I love tracking the bleeding edge in vulnerabilities and attack techniques, articles like this are a good reminder of how important it is to keep perspective, and recognize that many organizations are still struggling with the most fundamental aspects of IT security.

Oh, and one take-away question...why the hell were these FTP servers discovered by the Associated Press, and not agencies' own vulnerability scans or penetration tests? Either they're not being performed, or the people doing them are incompetent. Neither would surprise me.

Stating the obvious - VNC is insecure

If you need to provide remote desktop access to your organization's Windows machines, and care even a little bit about IT security, do NOT use VNC. The Windows built-in Remote Assistance / Remote Desktop tools are a far better choice. This may seem obvious, but I still find organizations running VNC servers all over the place, usually for the helpdesk to provide users with remote troubleshooting. This can leave an environment ripe for compromise.

VNC has a few fundamental weaknesses:

• Most implementations do not require a username for authentication, and the password is stored in the registry using a trivial hashing mechanism. VNCcrack or Cain will instantly crack these hashes.
• There is typically no client-side confirmation or acknowledgment required for a VNC session to be established between a server and viewer, which can leave a user unaware that their activity is being monitored.
• Most significantly, because there's no simple way to centrally manage VNC servers, administrators will typically use the same VNC password for every host to facilitate configuration and deployment. So if you compromise one Windows box through local vulnerabilities and gain access to its registry, you can obtain a VNC password that will work on every other machine in the environment. Not good.

For a pen-tester's perspective, let's throw a few other variables into the mix. Several Windows tools will scan a set of systems via NetBIOS and tell you which users are logged on to each. And if the domain controllers are configured to allow certain anonymous NetBIOS queries, you can enumerate all the members of key groups like "Domain Administrators". Analyze your scan results and combine the data to produce a list of workstations used by privileged domain accounts. VNC into each system and look for an opportunity to take control of the keyboard and mouse. (Yet another reason to lock your desktop when away from the keyboard!)

It takes less than 15 seconds to open the command shell, execute your "net user /add /domain", and close the window. Bam - you now have a domain account. Not exactly an elegant attack, but it gets the job done.

VNC is an excellent tool that can serve a number of purposes in both home and enterprise environments. However, it is not an ideal solution for remote access across a large number of Windows hosts. It often takes a good penetration test to drive that point home.

Reverse tunneling with Zebedee to compromise trusted networks

During a recent external pen-test, my teammate and I were able to gain root access to a Unix web server through a few serious application vulnerabilities. Once we had a reverse-shell going, we used wget to download Nmap, compiled it, and set off some scans to map out the DMZ and any reachable internal servers. Pretty straightforward so far.

Turned out that there really was no DMZ - everything was in one cloud behind their perimeter firewall. We quickly found a Class C containing lots of Windows hosts, including domain controllers and database servers, with all the expected ports open and exposed - jackpot! But we had a problem: the majority of our pen-testing tools for attacking Windows hosts only run on Windows, especially those related to MS SQL server. We couldn't run them on our compromised Unix server, and we didn't have the time to hunt down and test any equivalent tools that might exist for *nix platforms.

What we needed was a way to securely tunnel a connection from our pen-test system, through the Internet to the compromised Unix web server, and then ultimately to the Windows hosts behind the firewall. Something like stunnel first came to mind, but their firewall would block our inbound connection attempt.

Enter Zebedee...

This wonderful tool, available for both *nix and Windows, lets you set up an encrypted two-way tunnel for TCP or UDP connections. But the real beauty is that you can initialize a "reverse tunnel", much in the same way you'd use netcat to set up a reverse shell and bypass firewalls that strictly filter inbound connections. We configured our pen-test system to be the client and listen for connections from the Zebedee server. We then installed and ran Zebedee's server component on the compromised Unix host, and set up an outgoing reverse tunnel to our listener. The outbound connection got through their firewall, and we were able to directly attack the internal Windows servers from our own machine. You just point your testing tools to localhost as the destination IP, and to the port on which Zebedee client has established the tunnel. (As you might imagine, explaining how this worked to non-technical folks at our client was rather difficult).

Needless to say we were extremely happy to get this working, especially because it took quite a long time to configure and set up properly. Some of the documentation was confusing, and we kept having silly compilation issues because dependencies were in the wrong path. One noteworthy problem we ran into is that we could only get the server to tunnel to one endpoint at a time. In other words, our client listener could stay open, but we had to re-initialize the server with a different tunneling endpoint specified on the command line each time we wanted to test a new Windows host.

Ultimately, that limitation wasn't a huge deal - we still were able to eventually compromise a key Windows server - it just took some extra time to do the testing. The documentation indicates that you can set up a tunnel to any number of endpoints, so we'll have to figure that out for our next pen-test.

Despite these minor quibbles, Zebedee is a great tool that is invaluable for external pen-tests, particularly when your system compromises have spilled over into protected networks.