Oracle 9i/10g Views exploit

A quick one for the weekend: Rawlab released a nice little SQL exploit for a recently-patched Oracle 9i/10g vulnerability involving specially crafted Views. This flaw gives database users the ability to update/insert/delete records with SYSTEM privileges. The exploit updates a specified user account in SYS.USER$ with a new password; the code is straightforward enough to be easily modified if you wanted to mess with other records in system tables. I've hit a streak of insecure Oracle databases over the last few pen-tests, so this might be a useful tool to add to my collection.

Dangerous links: Mozilla URI handler exploits

There has been a lot of recent activity among security blogs covering serious new vulnerabilities in Mozilla's URI protocol handling.  This is a significant issue because it is easily exploitable and yields remote command execution on a victim's PC: an attacker only needs to lead the user to a maliciously crafted link.

The root of this flaw lies in how Mozilla handles URIs that are opened by other applications (such as mailto://, aim://, etc.).  These links are designed to pass specific parameters to the external application - for example, a mailto: link typically launches your e-mail client, and composes a new message with a specified "To: address.  Mozilla does not sufficiently parse these URIs; as a result, it is possible to inject characters and change the execution path.  

To make matters worse, the browser does not prompt the user before handling URIs for “mailto”, “news”, “nntp” and “snews”, so this attack can be launched without any interaction.  Yesterday, Billy Rios posted a simple exploit that executes commands through these URIs without any user warning.  However, it only works if the victim has no applications registered to the URIs, which is fairly uncommon (Outlook Express handles them by default, and is installed on most Windows systems).

The latest and most comprehensive vulnerability report was released today by Thor Larholm, and includes several proof-of-concept demos for Firefox, Thunderbird, and the mailto: protocol.  He goes into a lot of detail - it's a great read and a slick hack.

So an important moral to this story is that registering a URI handler really exposes an application to significant risk of attacks originating from the browser.  This is nothing new: for example, there have been numerous buffer overflows affecting AOL Instant Messenger that can be triggered by crafted URIs.  However, when you combine them with widespread cross-site scripting vulnerabilities and something like this URI handling flaw, you can see that a lot of interesting attack vectors are possible.  It is likely that we'll see variations on these theme affecting multiple browser platforms and used in a variety of exploit scenarios.

One last thing - a good post on ush.it details how you can disable unnecessary external protocol handlers to harden your browser. 

Firefox 2.0.0.5 and Thunderbird 2.0.0.4 are vulnerable; this will be patched in the soon-to-be-released Firefox 2.0.0.6.

More on Flash hacking

A quick follow-up to my previous post on testing Flash sites: Stefano Di Paola recently delivered a superbly comprehensive presentation on Flash application security during this year's OWASP conference in Milan. It goes into great detail on the ActionScript security model, how Flash applications are sandboxed, and a variety of client-side attack vectors. The resulting exploits include classic cross-site scripting issues, as well as a variation known as cross-site "flashing". Stefano also covers a few concepts for more advanced hacks, and plans to release testing tools and additional whitepapers soon. You can check out his web-log at Wisec.it.

Threat analysis: Fast-Flux Service Networks

Ever wonder how phishing and malware sites manage to stay online? Through their analysis of botnets and infected hosts, the HoneyNet Project has documented an increasingly widespread technique used by online criminals: "Fast-Flux Service Networks". It's an admittedly clever and approach that makes it much harder to shut down malicious operations.

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.

Decompiling and testing Flash-based web sites

I've recently been evaluating several tools to help our team perform security assessments on Flash-based web applications. We occasionally have to test client sites that are almost entirely written in Flash, and they can be even more annoying to assess than they are to use. I have never really worked with the language from a developer's perspective, so it's been a good learning experience.

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:

Binary AMF response in Paros

Decoded AMF response 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.

JavaScript Web Spider - Powered by Yahoo

pdp has released a proof-of-concept web spider written completely in JavaScript. It is a pure client-side tool, requiring no server support other than the Yahoo Site Explorer service it leverages. The spider is very efficient - it can index the files and directory structure of a web site within a few queries, making it very fast and efficient. The only limitation is that only can fetch pages already indexed by Yahoo.

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.

Backdoor scripts to compromise web servers

I have been putting together a collection of scripts used to gain command execution or reverse-shell access on web servers. We use this type of tool frequently during pen-tests; all you need is the ability to upload files to the web server (and a little luck - remember that you're executing under the context of the server process, which may have limited permissions). These scripts are available for most of the common platforms, including JSP, PHP, ASP, Perl, and even ColdFusion.

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.

Another good collection of web "backdoors", including a variety of ASP and ASPX scripts, is available at Unsec.Net.

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.

How to NOT protect your site against SQL injection

Parameterized queries? Input validation? Pfft. Really secure sites don't need that kind of nonsense to protect against SQL injection attacks.  They just kindly ask that you avoid submitting values like "SELECT FROM" or "DROP".

HTTP proxying through XSS

RSnake's blog just turned me on to the release of XSSTunnel, a very slick project by Ferruh Mavituna. This .NET-based tool lets you leverage a cross-site scripting vulnerability into a full HTTP proxy. By using XSSTunnel in concert with Ferruh's XSS Shell, you can pipe any scanning tool that supports HTTP proxies to run through a victim's "infected" browser. The possibilities are endless: you could run your own web browser, SQL injection tools, Nikto, etc. through the tunnel.

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.

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.

Bypassing anti-virus detection of Netcat

Ever wonder how to modify a hacking tool to evade anti-virus programs? I always understood how signature-based detection worked, but never bothered trying to bypass it during a pen-test. That's typically not something we have time to do on the fly. Besides, the only program we use that gets detected consistently is pwdump - and we got around that problem by modifying the source and recompiling it. But I recently got to use another technique that is interesting enough to share here.

It was an external pen-test: we were able to exploit SQL injection in a web application, and had the ability to run arbitrary commands on the database server through xp_cmdshell. The application was connecting to the MS SQL database with 'sa' privileges - bad move on their part. After running some test commands to verify that everything worked, we stood up a TFTP server on our pen-test build and sent a command for the compromised server to retrieve netcat so we could run a reverse shell.

We saw the file transfer successfully in our TFTP logs, but when we tried to execute netcat to connect to our listener, nothing happened. After spending an hour troubleshooting, we realized that nc.exe was never getting written to the target server's file-system after being uploaded. That's a tell-tale sign that anti-virus was eating the tool. I was a bit surprised - on our test builds neither Norton nor McAfee detect netcat, and I've never had it happen to me during other projects.

Our first instinct was to just recompile the netcat source after applying some changes, as we had done with pwdump, but we were having issues getting a development environment set up on our test system. So I set out to evade anti-virus by directly modifying the executable. First, I just changed some strings in the binary with a hex editor, but that didn't help. So I did some research and found a great writeup that details exactly how to change Netcat v 1.11 to bypass Norton Anti-Virus: Taking Back Netcat. I wasn't sure whether the target server was running Norton, but it was worth a shot. (I guess I could have just ran a 'dir' command to list the contents of "C:\Program Files" - oh well.)

The authors applied a sort of binary-search technique to isolate the code segment in netcat that was being detected by Norton. They then used a debugger (the excellent Olly) to disassemble the code and identify a portion that could be changeable without disrupting the application functionality. Turns out the code segment identified by the AV signature has a sequence of interrupts for software debugging that can be safely modified. By replacing one of those with a NOP, the binary is changed enough to evade detection, yet still works perfectly.

I repeated the steps in the whitepaper, and ended up with a patched version of nc.exe that we were able to successfully upload and run on the target server. It's a time-consuming but simple technique, and I plan on trying it out with some other tools when I get a chance. I'm sure this is nothing new to malware experts, but it was a fun little hack to pull off in the middle of a pen-test.

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.

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:

• OWASP's "Testing for Oracle"
• NGS Software's "Hackproofing Oracle Application Server"
  

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

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.

Why is it still so easy to hack Windows networks?

The other day, a few of us at work were discussing how internal Windows penetration tests have remained ridiculously easy, irrespective of the client, since we first started in this field. Between the four of us, we've done at least twenty or thirty Windows internal pen-tests in the last few years, against both gigantic and small networks. Regardless of the target's size and complexity, we can usually get domain administrator control of the environment within one day, or even a few hours, and it's not through any fancy attack techniques either. The progression is almost always the same:

1. Compromise standalone servers/workstations through a handful of common attacks.
2. Run LSAdump to obtain LSA secrets, run PWdump to crack local account hashes.
   
3. Use recovered credentials to gain access to domain accounts.

Step #1 usually is accomplished by finding SQL servers with blank or weak 'SA' passwords and gaining local admin through xp_cmdshell. Yes, this is still a problem, even in highly sensitive environments where you'd never expect it. We also often find old IIS servers permitting anonymous FrontPage authoring, load up hostile ASP to pass-through commands, and pop the server that way. A third approach is to enumerate users on Windows hosts via anonymous NetBIOS, and test them for blank passwords & password=username. Local accounts are almost always neglected on at least a few hosts. These are the "low-hanging-fruit" for which we'll immediately scan, before attempting more involved attacks. They are incredibly old issues (MS SQL 2005 won't let you give SA a blank password, and anonymous authoring hasn't been enabled by default in FrontPage for years) but in a big environment you'll always find some susceptible systems that were "missed" for some reason or other.

Once we've got Local Admin on a box (one way or another), PWdump gives us the local user password hashes and LSAdump gives us the LSA secrets. It's especially fun to crack the Local Admin account password with PWdump and then realize they're using the same password for Local Admin on every other Windows box. Typical excuse: "It's too hard to manage the Local Admin accounts on so many machines, so we just use the same password on all of them."

But I usually have the best luck with passwords in the LSA secrets - there's almost always some service account running as a domain administrator with the same credentials. It's absolutely ridiculous how liberally some organizations assign AD privileges - "Oh, XXX service didn't run right, so we had to make the account a domain admin." Horrible reasoning. And sometimes you just get a local user account that has the same password for his or her equivalent domain account.

In some cases, we'll get a domain admin account but it won't be allowed to establish Terminal Services connections. That's really not much of a security control when you can still shuttle files on and off the machine with NetBIOS and execute commands with psexec (or schedule commands on the remote host with "at", or remotely start/stop services and edit the registry, etc.).

The bottom line is that although these attack techniques and vulnerabilities are old and easy to fix, they persist year after year, client after client. I think there are a few contributing factors:

• It is difficult to create and maintain an accurate inventory of all systems active in an environment. If you don't know it's there, you can't make sure it's secure.

• Many organizations already know about the vulnerabilities we find, but had assumed them to be acceptable risks. Sometimes it takes a penetration test to really drive home the "real-world" impact of an issue before management will understand and act on it. In other cases, risks are accepted because developers or sys-admins successfully argue that correcting the flaw would "break" key functionality - often because they didn't feel like going through the trouble of making it work.
  
  
• Applying the principle of least-privilege to Windows domains and their user accounts is exponentially more difficult as an environment grows in size and complexity.
  
  
• (potentially controversial point) The barrier to entry for Windows system administrators is lower than that for Unix or networking admins, simply because at a superficial level, it is easier to stand up and maintain a Windows environment. As a result, many are often less technically proficient than they need to be. This is based purely on my anecdotal observations, but other some of my other colleagues agree.
  

I certainly acknowledge that it must be hell to be on the other end of a pen-test, even if you are a diligent administrator - it's much easier to break down one door rather than defend hundreds of them. I just get frustrated when I see really basic security vulnerabilities that are obviously the product of poor controls, organization, and leadership. It shouldn't be That easy for any unprivileged user to own your environment.

Thoughts/comments are welcome.

Introduction

After several years of dormant site content and wasted web hosting fees, I finally decided to revive hideaway.net as a blog. It's been years since I've done any significant writing outside of work, mainly due to laziness and lack of motivation. But I've become increasingly eager to write about security again, and would like to get better involved in the "community" outside of those with whom I work. Of particular inspiration are the blogs of web-app-sec gods like RSnake and Jeremiah Grossman.

A quick about-me: I have been doing IT security consulting for the past five years, and am currently employed with a large company somewhere along the East coast. My passions are penetration testing and web application security, so that's what I plan on writing about the most. In particular, I'd really like to post about war stories and interesting experiences from past assessments and penetration tests - but will always keep things anonymous and change up details to protect my clients (and avoid getting fired). I'll also cover any random hacking/security news, tool releases, or other related things I feel are worth discussing and sharing.

So here's hoping I can keep this up for more than a month, and contribute something meaningful along the way.