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:
188.8.131.52 - - [08/Aug/2007:10:02:40 +0000] "GET /SYS HTTP/1.1" 404 0 - -
(assuming 184.108.40.206 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.
Monday, August 13, 2007
Saturday, August 4, 2007
- 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.
- 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.
Sunday, July 29, 2007
Wednesday, July 25, 2007
Tuesday, July 24, 2007
Wednesday, July 18, 2007
The premise behind fast-flux service networks is simple: attackers register a fully qualified domain name, and then rotate hundreds or thousands of IP addresses that are assigned to it. A DNS name may only be mapped to a particular IP for a few minutes. Each IP is an infected member of a botnet - but they are not the source of content, such as a virus or a scam web-site. Instead, they simply act as proxies, redirecting to one or more "mothership" servers that actually host the content. A more complex variation, "double-flux" service networks, implement additional misdirection by also rotating the authoritative name servers.
Like most of the HoneyNet Project's work, the whitepaper is very well-written and includes a case study with real-world examples. Definitely worth checking out if you're interested in how the more sinister side of the Internet underground operates.
Tuesday, July 17, 2007
I was first interested in decompilers, thinking that certain poorly-coded applications might have hard-coded host information, credentials, or other potentially sensitive information. I found that Flare is an effective (and free) tool for extracting ActionScript from SWF files. However, after using it on a number of projects I've come to realize that there's rarely much of interest in the ActionScript. (There are a few horribly coded Flash login portals that store passwords in the source code, but I've never seen them used in a "professional" client application. Google for "login.swf", and decompile a few of the results to see what I mean.)
Ordinary proxy tools like Paros or Burp will catch any inbound or outbound HTTP requests issued by a Flash application. However, some applications talk to the server using a SOAP-like messaging protocol known as Flash Remoting, in which messages are binary encoded in "Action Message Format" (AMF). Neither Paros nor Burp will decode AMF, making it difficult to analyze the transactions. However, there are a few applications that can: ServiceCapture and Charles Debugging Proxy are two of the more popular and well-regarded tools. Below are a few screenshots of a binary AMF response as seen in Paros, versus the same response decoded in ServiceCapture:
As you can see, deserializing Flash Remoting traffic can provide a lot of information about an application, and even identify targets for parameter manipulation or SQL injection attacks.
Unfortunately, I haven't been able to find any free tools with this capability. ServiceCapture and Charles offer downloadable trials, but require a reasonable license fee for continued use. The Burp Proxy team is soliciting requested features for their next update, so I will be sure to submit this as a recommendation.
Monday, July 16, 2007
As pdp points out in his writeup, it would be simple to modify this code to identify vulnerabilities in spidered sites and exploit them in real-time. We will almost certainly see XSS/AJAX worms leveraging this sort of technique to target and compromise other web applications, and they will be very difficult to block.
Sunday, July 15, 2007
Here is what I've got so far:
- Perl Reverse-Shell - Once executed on the web server, this Perl script throws a shell to a Netcat listener running on your machine.
- PHP Reverse-Shell - Same idea as the Perl script above, by the same author.
- JSP Reverse-Shell - Designed to run on any server supporting Java Server Pages. The provided example is designed for Windows as it invokes cmd.exe.
- PHP-Shell - Not a true interactive shell, but lets you execute commands and view their output via a web-based form.
- PHPTerm - Another PHP web-based command shell.
- Open-Labs Hacker WebKit - Collection of scripts for ASP, CFM, EXE, JSP, PHP, PL, SERVLET and SH. Provides command execution, file browsing, and file uploading.
Thursday, July 12, 2007
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.
Wednesday, July 11, 2007
Tuesday, July 10, 2007
The logistics of the attack are fairly simple. You need to host the XSS Shell components on an IIS server under your control, and configure XSSTunnel (which runs locally on your machine) with its location. Your cross-site scripting attack will load the code from the XSS Shell server into the victim's browser, either through a reflected or persistent vector. (It's worth noting that XSS Shell has some nasty attacks on its own, including key-logging, stealing cookies and clipboard contents, etc). Once everything is set up you can launch the tunnel, wait for your XSS attack to reach a victim, and then proxy to your heart's content.
Ferruh's Bugtraq post includes links to a video and whitepaper; the tool is also available at Portcullis-Security.
Monday, July 9, 2007
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.
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.
Saturday, July 7, 2007
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.
But even with those disadvantages, it's a steal for $140 and a lot of fun to hack around with.
Friday, July 6, 2007
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:
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
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.
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.