Saturday, July 7, 2007

Mobile hacking with the Nokia 770 tablet

I have a bad habit of impulse-purchases when it comes to gadgets, but I'm pretty pleased with how my latest turned out - the Nokia 770 Internet Tablet. It was on Woot a few weeks ago for $135 and you can still buy them on Buy.com for around the same price. This little device is about the size of a Nintendo DS lite, and runs a stripped down version of Debian with a development platform called Maemo. It has a really nice 800x400 touch screen, Bluetooth, and WiFi. There is also a newer version, the N800, with a faster processor and a few better expansion options.

Anyway, because of the 770's Linux OS it's pretty easy for developers to port software over to it. As a result, you can load it up with all sorts of neat stuff - mine currently has an SSH server & client, VNC client, Nmap (with NmapFE working), an X-server, Kismet, Mplayer, and a stripped version of Perl and Python. You just have to add the appropriate repositories to the device's Application Manager, and then you can one-click install them (or use apt-get on the command line). This would be perfect for wireless testing and war-driving due to its size and good battery life. Also, the web browser is based on Opera and can basically render most sites exactly as they appear on desktops - it just chugs a little on JavaScript-heavy pages.

Opera on the BBC web site (RealVideo streams work!)

VNC'd into my Mac

Nmap (after sudo'ing)

Kismet - works great, but you have to reboot to restore WLAN to the tablet's other apps. Might be because it can't get the wireless card back from monitor mode.

Downsides - the device uses RS-MMC for expandable storage, which is getting rare and overpriced. Also, it is a bit unstable so you have to get used to Opera or other apps randomly crashing. I've had it reboot for no apparent reason a few times as well, but it only takes about 20 seconds.

But even with those disadvantages, it's a steal for $140 and a lot of fun to hack around with.

Friday, July 6, 2007

Hacking Oracle Application Servers

A recent post on Darknet turned me on to a new tool for testing Oracle Application Servers called OAPScan. This neat little Perl script is similar to Nikto - it does a "dumb" crawl of web servers based on a scan database and uses pattern matching and server responses to determine whether certain files, paths, and vulnerabilities exist. But unlike Nikto, OAPScan's database has a robust number of checks specific to Oracle Application Servers, which I encounter frequently on both external and internal pen-tests.

Oracle AS has all sorts of default files, scripts, Data Access Descriptors (DADs), and other features that people forget to turn off when deploying these servers. In some cases, they can provide valuable information about the server or even be useful attack vectors for more serious vulnerabilities like SQL injection and file disclosure.

In the past I've always had to manually crawl through these servers, and would perform manual tests based on guidance from two excellent whitepapers:
(Method #6 in the OWASP guide for bypassing PL/SQL exclusion list to perform SQL injection almost always works for me - I don't think it wasn't patched until late last year)

OAPScan will automate a lot of those testing steps for me, albeit as noisily as any other tool that crawls/scans web servers. If nothing else, it's scan database can be a good reference if you want to learn about what things to manually check for, in concert with the whitepapers I mentioned above.

Wednesday, July 4, 2007

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.