My next class:
Web App Penetration Testing and Ethical HackingAmsterdamMar 31st - Apr 5th 2025

When web application security, Microsoft and the AV vendors all fail

Published: 2009-03-13. Last Updated: 2009-03-13 03:07:43 UTC
by Bojan Zdrnja (Version: 1)
6 comment(s)

I just spent some time analyzing yet another incident and I was actually shocked about how the combination of relatively weak defenses led to a system being completely compromised.

The three main actors in this movie were a web application with a security vulnerability, Microsoft’s server class operating systems with an unpatched local privilege escalation vulnerability and the last line of everyone’s defense, the AV vendors.

The story started more or less like hundreds of recently seen incidents.  A web application had a vulnerability that allowed a remote attacker to upload files to the server.  As the files were not validated, the attacker was able to upload a .NET Webshell. This webshell is known as ASPXSpy, it’s an ASPX program that allows easy control over the compromised server. The attacker can now upload files through the browser and execute them.

However, the attacker still does not have total control over the server as the IIS service runs under an unprivileged account. This is where the local privilege escalation vulnerability comes into play.  The attackers uploaded a local exploit called Churrasco2.  This is a PoC created by a well known researcher Cesar Cerrudo and published back in October 2008.  What makes it even worse is that it work on both Windows Server 2008 and Server 2003.  The exploit creates a backdoor shell after it steals the SYSTEM token.  The program’s usage description says it all:

/Churrasco/-->Usage: Churrasco2.exe ipaddress port


After this, it was game over.  The attacker had a backdoor to the server running as SYSTEM.  The next steps were very obvious and included installation of another Trojan as well as a keylogger.

Finally, the last line of defense, the anti-virus program, failed as well.  Although the AV vendors typically include detection for exploits, it’s clear that they missed this one.  I ran it past VirusTotal and the results where … well … horrible is an understatement – 0 AV programs detected this: http://www.virustotal.com/analisis/4f48b73697428888f338bf66fa1eb92a

So, what can we learn from this example? The attacks I described are in the wild and are abused.  The first line of defense, in this case the web application’s security, must be made as secure as possible – secure coding standards, penetration tests and whatever else you can do are justified.  As we saw from this example,  other defenses failed.   And the security of your web application depends only on you.

This doesn’t mean that other two actors should just sit and do nothing.  Microsoft should really fix this vulnerability and pay more attention to local privilege escalation vulnerabilities.  While MS released an advisory with suggested workarounds (available at http://www.microsoft.com/technet/security/advisory/951306.mspx), I don’t think enough people know about this.

Finally, the AV vendors should be more proactive (instead of reactive) and follow exploit research developments so they can add detection for similar exploits early and protect their customers.

--
Bojan
INFIGO IS
 

6 comment(s)
My next class:
Web App Penetration Testing and Ethical HackingAmsterdamMar 31st - Apr 5th 2025

Comments

had the target system not been able to connect directly to the outside world, no such compromise could have happened. firewall, anyone?
Martin, while that is true remember that the attackers were still in position to run any executable on the server with SYSTEM privileges, so this is not a solution, just a way to help a bit.

I agree we should have every layer of defense up, and egress filtering is definitely one that is often ignored.
Let me start my comment by explicitly stating that I stand as one of the accused (I work for an AV vendor, Sophos). My comment is intended to shed some light and provoke discussion and not to irritatingly and pittifully whine about how people don't understand us (grumble grumble etc).

So the components of the attack are as follows:
1. A vulnerability that enable files to be uploaded to a web server
2. An exploit that enable said uploaded code to do privilege escalation
3. Code, now running escalated installs a Trojan (etc)

<rant>
It is important to understand that content analysis of a piece of code is not the only way that malware protection works today (it just wouldn't scale, not with packers, polymorphism, a ton more malware, targetted threats etc). Signature AV has been dead for a while now and the mainstream vendors have moved past this significantly to do much more intelligent analysis of content, but even this is not enough. We have a significant investment in runtime inspection (looking at buffer overflows, looking at vulnerabilities, looking at the behaviour of malware even if we could not deal with it in it's raw content form). In many ways this is similar to the IPS vs . Endpoint security argument. I could pack and alter the content in inumerable different ways (depending on the limitations posed by the vulnerability) making analysis of the content at the transport layer extremely difficult to do reliably. At the endpoint, I can use the content as context (and alot of malware can be stopped with content analysis) but I can combine this with context information about the application, the behaviour, the user and sometimes even the data. Both are useful and both have their place, but there is a clear advantage to inspection of the event in context of execution. There is therefore a significant difference between detection (scanning files) and actual protection offered. Unfortunately, most tests today are focused on detection (because it's fairly easy to scan a file and immensely difficult to measure the actual effective protection in runtime) and whilst this is a useful measure, it's often not very representative.
</rant>

We all need to be realistic that unfortunately in most environments reliable patching does not occur (failure to install, change controls, broken operational process etc) but the chain of attack need only be broken in one place (it’s nice to know you will break it at all points but in your case it was broken at no point!). I'd just like to make it clear that running through virustotal doesn't neccesarily lead to the conclusion that we wouldn't do anything about the attack. We have grown our capabilities significantly, pushing towards proactive protection (Genotype, HIPS, BOPS, Client Firewall etc). I absolutely agree that modern malware protection requires knowledge of exploits and application security and is not just about scanning a file. On that note, I'm off to go and get someone to look at replicating this and seeing what we would do and if we can improve. I’ll post back.

J
and I wish I could use returns in my comments :).
James, thanks for your comments.

Everything you wrote is correct, of course, and I'm aware that AV vendors are moving towards behavior based detection which should help with proactive protection and detection of malware.

I'm also aware that VirusTotal doesn't represent real protection (I wrote that multiple times in my diaries as well).

Still, in this particular incident, I found it very interesting that none of the AV vendors detected this (in pure signature mode) - the exploit has been out for 5 months now (released in October 2008) which means that AV companies are lagging in this.

Anyway, I'm looking forward to other discussions with our readers :)
Bojan, Glad you agree. I think we should look at runtime detection of the exploit (often exploits aren't very effectively detected in their launch files and better identified at runtime). That said, I think the PoC launcher is worth looking at. We're on it.

J

Diary Archives