In case anyone is keeping score at home, SharePoint strips alternate data streams off of files. SharePoint (usually) stores its documents in a SQL database, so my guess is that’s what does it.

Error handling is one of the most often overlooked areas of application security. If you have a public-facing application, you don’t want the public to know too much about how the application works, even if you’re convinced they should never see errors. Case in point is demonstrated in the image presented here. I was just surfing the web, reading about one of my other innocuous hobbies (in this case baseball) when I came across the following page. As a user, I shouldn’t be able to see any of that. As an attacker, I just found a goldmine if information which I can use to try and exploit the site.

Well that was a long and unexpected blogging break. It started because I wanted to write a long and detailed post about the last BGP exploit when I realized how little most security people knew about BGP. Unfortunately I never had time, a bunch of other things demanded my attention, (like real life), and then once I got out of the habit of blogging, it was too easy to just ignore it. I’m back though, and I’ll try to blog regularly, albeit perhaps at a slower rate if real life persists in being as time consuming as its been lately.

Since this blog is coming back from a long hiatus, I think perhaps it’s appropriate to do so by bringing back an old vulnerability from a long hiatus as well. Format String Vulnerabilities have been around since around 1999. The short explanation is that when a C program doesn’t use format specifiers (you know, all those %s things you learned about way back when), but rather just prints a buffer directly, an attacker could put in format specifiers (like %x and %n). %x will just print the next hex number on the stack, so an attacker can view the stack. %n is more insidious – it is used to count the number of characters printed so far and copy that number into an arbitrary memory array. An attacker can use this to overwrite a given memory location (like, say, a return pointer) and execute arbitrary code.

In August of 2004 it was revealed that Windows’ sort.exe had a format string vulnerability. Like most people, I assumed that since the fix for this is trivial (just use a format specifier instead of printing the buffer directly), Microsoft would have fixed it in the next patch release or service pack. Lo and behold, they haven’t. This is a copy and paste from the command shell of my Windows XP machine.

 Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\>ver

Microsoft Windows XP [Version 5.1.2600]

C:\>sort %x
7c812f39The system cannot find the file specified.

C:\>sort %x%x
7c812f390The system cannot find the file specified.

C:\>sort %x%x%x
7c812f3900The system cannot find the file specified.

C:\>sort %x%x%x%x
7c812f390078257825The system cannot find the file specified.

C:\>sort %x%x%x%x%x
7c812f39007825782578257825The system cannot find the file specified.

C:\>sort %x%n

(sort.exe crashes as I’ve tried to write data to some random place in memory)

Everyone knows that Microsoft has a reputation for not fixing vulnerabilities unless forced to, but this is bad even by their standards. 4+ years and they haven’t fixed a know format string vulnerability.

It was of course inevitable that once Dan Geer found a vulnerability in DNS, someone else would find it too, even if Dan asked people not to publicize it. It was also inevitable that someone would quickly write a metasploit plugin for it. What amazes me is the fact that despite all the fuss over this, everyone who was security conscious should have had this problem fixed years ago. Yes, I know it was only “discovered” recently, but what people are failing to highlight is that to exploit this against a DNS server, you have to allow recursive queries from third parties. I’ve been telling my clients for years to turn that off (the ones that had it on that is). This falls under the old security rule of “if you don’t need it, turn it off”, which is perhaps the single most important, and yet often ignored, security rule there is.

Since cache poisoning became a worry it has been well known that leaving recursive queries on was allowing an attacker an avenue to force your DNS server to make specific and known queries. This is a necessary step in almost any poisoning attack. In 2007, a study found that about half the DNS servers on the net still allowed recursive queries. Even after repeated warnings and previous DNS vulnerabilities, you would think that most people would have disabled recursive queries, but it doesn’t look like that’s the case. (Furthermore, the response has universally been to patch, rather than to turn off recursive queries). The solution to this and almost all other cache poisoning attacks is very simple:

If you don’t use it, TURN IT OFF!

Jeremiah Grossman has an article in CSOonline wherein he calls the current web application security methods (review code, find flaws, fix) insane and proposes web application firewalls as the better alternative.

It is unreasonable to expect publishers, enterprises and other site owners to restart and reprogram every website securely from scratch. Nor can we fix the hundreds of thousands (maybe millions) of custom Web application vulnerabilities one line at time. The very thought sounds insane to me. It would take too long (probably never finish), cost far too much (billions per year), and the bad guys are already ahead of us.

…..

We have to be able to detect flaws, react faster, and adapt better on an Internet-wide scale. Web application vulnerability assessment solutions like those provided by WhiteHat Security are able to do this and then inform businesses of where the problem spots are. To address identified issues quickly Web application firewall (WAF) technology is getting a serious look. Recent technology advancements enable vulnerability assessment results to pipe straight into a WAF as virtual patches.

Honestly it sounds good (really it does), and I know many entities which have been forced to dos omething similar (most didn’t call it a WAF at the time) when faced witht his problem. (That being too many applications and too little time).

My general feeling on WAFs is that the centralization and tremndous time savings can be a boon to many enterprises, but that signature systems will always have flaws, and need to be constantly maintained and updated. To use a metaphor, think of traditional port filtering firewalls and IDS/IPS. Imagine an admin who has only an IPS, and must constantly be on the lookout for new attacks so that he can write new signatures and block them. Then there is thefirewall with a default deny. That admin knows that only specific ports are allowed through because only those services are needed and on which machines they reside. His life is a lot easier (although admittedly he still has to worry about application vulnerabilities). Once again however, Jeremiah has beaten my thought process to the punch.

To implement default-deny Web Application Firewalls (WAF) must know everything about a website at all times, even when they change.

What we need to do for web applications is do what we did for networks in the past – learn everything. We need to know which applications do what, and what inputs and outputs they should have. Hard? yes. But ultimately it will be better than the alternative.

_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]

There’s a new paper out on SQL injection DoS attacks. Given the severity of the claims, I don’t see why this isn’t getting more coverage. The authors purport that almost any server with a SQL back-end and a search form is vulnerable. Essentially, they craft SQL queries that take an exorbitantly long amount of time to execute. When launching a small handful of them, you can actually make a database completely unresponsive. Although perhaps not as damaging as traditional SQL injection (most people would rather have their data unavailable rather than in the hands of an attacker), it appears to be much easier to execute, so it probably won’t be long before people start seeing this show up everywhere.

Why am I only finding out about this now (also reported by wired)?

Oleksandr Dorozhko hacked a system containing information on IMS health that would negatively affect their stock price. (Or, possibly, someone else hacked the system and gave him the information). He invested in puts and netted himself about $300,000 in one day. The SEC noticed and tried to block it, but the court has ruled that a hacker is not an insider, and therefore insider trading does not apply. Mr. Dorozhko gets to keep every cent of his admittedly ill-gotten gains.

I remember back in “the good old days” people would laugh at web defacements. It might be a way for a hacker to prove themselves or gain their fifteen minutes of fame on 2600, but it was not a gateway to sensitive or important information. The web was, after all, nothing more than an advertisement – a billboard on the information superhighway. Organizations had important information on computers, but none of it was on web servers. Web page defacements were akin to graffiti, not corporate espionage.

Fast forward to today, and it’s remarkable how everything has changed. The web has begun supplanting the other 65535 ports on the internet. Although e-commerce was the first thing to change the web from a static billboard to a method of transmitting sensitive data, it is web applications which have done the most recently. Now everything occurs over the web – companies use SOAP to transmit sensitive information between them, and back-end databases frequently hold incredibly important data. Even services which were originally designed to function over other protocols, such as remote administration, email, and file transfer, have now begun to migrate to the web. The bottom line is that the web matters. There are still the electronic graffiti artists who want nothing more than their 15 minutes of fame on zone-h.org, but serious hackers are eying the web too.

I remember some time ago I got into a long discussion with someone at work that at its essence revolved around the question of whether or not the web mattered. I essentially argues my old position, more out of habit than anything else, while he argues that the web was of paramount importance (although admittedly he had other ulterior motives for taking that position). I was ultimately proven right only because the case we were dealing with turned out to be nothing more than a simple electronic graffiti artist. Despite being right in that single instance, I am being forced to change my overall position.

In terms of practical application, it means people can no longer blithely allow in traffic to their web servers on ports 80 and 443. Traffic must be examined, either by an intermediate network device or the web server itself to ensure safety. Web applications need to be coded securely, and web servers should in general not be trusted. (Don’t run the process as root, perform system calls in a sandbox, etc.)