Florida Fragments a cc nc sa by image from Merrick Brown's Flickr stream

By Elena Kropochkina and Joffrey Czarny

Slides on the HitB Materials page.

Lots of Webshells used by pentesters to get access to the systems are detected by conventional security products like anti-virus, IPS and WAF. In stead of building a new websheel for each assignment the presenters tried to work towards a framework for webshells, that was modular and added obfuscation as a protection against AV/IPS/WAF.

But if you want to build a webshell framework you need to know what is out there. Most webservers on the internet are dominantly Apache, IIS and Weblogic. Pentesters are most in need of Webshells based on ASP, PHP and Java shells as it is heavily used for intranet applications.

The presenters gave an overview of the webshels out there for webshells for Linux, MySQL, PHP, JSP, ASP. Many of the common shells have high detection rates on the most common anti-virus platforms.

Even tough there are some webshells that are nearly complete in features and others that are not detected by Anti-Virus there isn’t one that is both.

There are a few ways to get around anti-virus encoding, obfuscation and encryption. There are common tools available to obfuscation for different languages like PHP, VBScript and Java. Obfuscation tools make reading the code harder, but are analysis is often still possible.

Using this knowledge the presenters designed a webshell platform. The platform should be language independent, resistant against third party unauthorized access and not be detected by AV/IPS/WAF.

Protection against unauthorized third party access is archived by mean of encryption based on “user provided key”, server IP address and client IP address.

So what are the must have functionalities of the framework:

• System information
• Graphical file maanger
• file upload/download
• command line cmd
• SQL manager

Elena and Joffrey show the design and some code fragments of the platform and demonstrated the proof of concept platform.

The proof of concept is already very feature rich.

Elena Kropochkina begins her professional career in Devoteam Audit Security team. She was graduated by Ecole Polytechnique and Telecom ParisTech with a M.S. in Computer Science. She is specialized in IT Security and Artificial Intelligence.

About Joffrey Czarny

Joffrey Czarny, working for Devoteam Security Business Unit (FR). Since 2001, Joffrey is a pentester, he has released advisories on VoIP Cisco products and spoken at various security-focused conferences (Wireless Conference at Infosec Paris and Wireless Workshop at Hack.lu 2005, VoIP at Hack.lu 2007/2008 and ITunderground 2008/2009). On his site, www.insomnihack.net, he maintains the Elsenot project and posts video tutorials and tools on several security aspects.

Most vendors that refuse to address these issues all use the same argument: “If users do something stupid it their problem.” Well, if they do it in your context it is your problem. This is what the guys from securewebmail.com found out as well.

So where have we found CSRF issues?
McAfee has a site which you van use to scan your own site. With CSRF an attack could use your session to create an extra account and then use that account to scan your sites and get your vulnerabilities.
Wireless routers like the Linksys WRT wireless and others are vulnerable and  can be owned and opened up to outsider attacks.
ESPN, one of the largest coomunity websites in the world is vulnerable to a CSRF attack against itself. It is wormable without any javascript at all. Noscript will not help you…
Dokeos, an e0learning platform which is also used by the Belgian Defense Agency is also vulnerable. Given its installed base, Dokeos has Millions of users
The osCommerce platform used for thousands of online shops with more then 9,300,000+ users. CSRF can be used here to steal credit card data. Interestingly a lot of these sites are branded McAfee secure.
ZenCart is also vulnerable and widely used.
cPanel/WHM is used in over 7,000,000 sites and it is also vulnerable. cPanels responsed that the cannot fix it because “it is a feature.”

But CSRF has other implications as well. It can be used to e.g. forge a persons browser history, which obviously has legel implications. “People have been convicted based on their search history.”

Alternatively it can be used to polute peoples shopping cart history on e.g. Amazon. This might make valuable advertising

Myths in CSRF mitigation.

• Only work via POST requests – This doesn’t always work
• Referrer checking – Referrers get striped in SSL session, also users turn referrer checking of for privacy reasons.
• Multi-step transactions – Multi-step transactions can also be perfored with CSRF

What does work?

• CAPTCHA’s – If they are implemented the right way
• Re authentication – Requesting reauthentication before performing critical actions is a good mitigation action
• Unique request Tokens – make sure session tokens are cryptographically secure.

Their investigation of this specific vulnerability was triggered by an Adobe advisory which discussed the vulnerability without much detail, but mentioned the name the command and control server. Analyzing their malicious PDF samples they found this server in a malicious sample from a bit earlier and they already had the server name in their DNS monitor.

By analyzing the samples they had, they found the vulnerability exploited in them (JBIG2Decode) and started looking for matching samples.

When they informed Adobe, because the was no advisory, Adobe stated that they were aware.

When they found that the attack was not long just used in limited targetted attacks, but in stead the attack count was going up, they decided to do a partial disclosure on shadowserver.org blog. After the partial disclosure, Adobe released an advisory that told people it would be fixed in just over a month.

A few days later a PoC turns up on Milw0rm, which got turned into a weaponized exploit later.

All in all the talk gave quite a bit of insight into lifecycle of mallware.

Steven Adair can be contacte via Steven@schadowserver.com or on twitter as @stevenadair

There is a lot of code involved converting types between various languages.

Interoperability is effected by standard bugs like buffer overflows and memory corruption but also three new vulnerability classes:

• Object retention vulnerabilities
• Type confusion vulnerabilities
• Transitive trust vulnerabilities

Object retention

Since an object does not know which other objects are using it, it does not know when to destroy itself. Most often this is done via a reference counter but this is not perfect, leading to using heap data as pointers, double frees, objects not being freed at all.

Issues arise from reference counters rolling over, objects being freed to often or not at all. Also a shallow copy instead of a deep copy can lead to problems. These are all programmatical errors.

Type confusion

In IE variant data types require careful programming, therefore they present an opportunity to attackers. Often this is not picked up by the compiler. It can lead to memory corruption and can be exploitable. This is what happened in the ATL bug . This can lead to e.g. double frees. These issues are also present in ATL and addressed by Microsoft’s patches.

Demonstration #1: An active X control was loaded and passed a persistent data stream which caused a free call to uninitialized data. This is exploitable so shell code was executed.

Demonstration #2: in windows 7 IE8 an array of object was passed in stead of the actual objects. The browser interpreted the array as an object which leads to exploitable error.

Even tough Firefox’ NPAPI is a lot simpler, it requires the programmer to check the data types himself, which is often forgotten leading to the same types of issues.

Trust

Browsers need to deal with a lot more the just HTML these days.

If a browser uses a trusted object A and object A trusts object B which is not trusted by the browser, it is still executed.

Demonstration #3: An object is first loaded but its killbit set and not executed. Then a trusted object is loaded, but it is passed a killbitted persistent object which it will execute. In its turn this object will actually start up calc.exe

Remediation of the ATL issues

Any ActiveX control compiled in the last 15 may have these vulnerabilities in there. ATL2.0 was released in 1997 and ATL 9.0 in 2008. Any ActiveX control based on a vulnerable ATL need to be checked if it is vulnerable, if may need some reprogramming and will need recompilation.

All in all there might be quite a big check of vulnerable controls out there besides the other interoperability scenarios that this talk did not address.

A paper is available at http://taossa.com or http://hustlelabs.com

Quick word on the Microsoft patches

When I asked the guys if Microsoft patches provide a sufficient solution I got an evasive answer. However, one of the demonstration machines auto updated itself yesterday and the demonstration stopped working.

Slowloris (name after the slow moving primates is a httpd DoS tool written by RSnake of ha.ckers. It works by tying up the httpd worker processes by slowly sending more and more headers of an httpd request.

Nkiller2 is a TCP/IP DoS attack tool which was published in issue 66 of Phrack magazine. It works by tying up httpd worker processes by requesting a file then stalling, mimicking the behavior of a client with full TCP/IP receive buffers.

Cisco CSS is a load balancer produced by Cisco.

In nearly all of the infrastructures built by my employer Schuberg Philis, the web servers are located behind a load balancer. In most cases a Cisco CSS. Because some of our customers were worried, I set out together with my colleague Gert Kremer to see if having a CSS load balancer in front of the web server provides any protection.

Slowloris

First we just had to try and find out what Slowloris did with an unprotected Apache server. The first video shows what happens when you run slowloris against a webserver. The window on the top left shows the number of apache processes, the top right window shows the scoreboard. This shows what the http processes are actually doing. The bottom window shows the slowloris output.

Slowloris vs Apache (No load balancer)

Click here to view the embedded video.

When slowloris is using 100 sockets, you can see 100 httpd workers in state “R”, meaning it is reading requests. The same is the case when running with 200 and 250 sockets. When running with 300 sockets the apache worker processes pool is exhausted and the web server can no longer service requests.

Slowloris vs Apache behind a Cisco CSS load balancer

Click here to view the embedded video.

Slowloris is running against the webserver with 3000 sockets (should be more then enough). As you can see on the top two windows the load balancer does not forward any of the incomplete requests to the webserver. We have stress tested the loadbancer up to 10,000 sockets and it had no effect on the loadbancer.

NKiller

Nkiller vs Apache (No load balancer)

Click here to view the embedded video.

In the video we see for windows. Top left and right show the number of apache processes and the apache dashboard. The middle window displays the NKiller output and the bottom window TCPdump.

When NKiller starts we see the it exhausts the httpd workers processes by putting them in a state where they are hanging while writing their reply back to the client.
Nkiller vs Apache behind a CSS load balancer

Click here to view the embedded video.

When NKiller was used against a server protected by a Cisco CSS load balancer the packets received from the load balancer do not match the expections of the Nkiller tool and the tool crashed producing a segmentation fault.