Operation n

Last year I started working on the Web Backdoor Compilation (WBC). The idea behind the project was the following:

• A tool to aid penetration testers and web developers with security testing document management applications.

Recently I made a pre-v2 release of the tool, which has received even more feedback then the previous version and the project just got even more exciting.

During web applications security audits, I have come across a couple of situations where my uploaded file just vanished off the server - I am sure many reading this have come across this too. The reason behind this was that an Anti-Virus (AV) application had detected the malicious script and removed it. My future plans for this project is to check the effectiveness of AV filters against the scripts in WBC. Dancho Danchev has gone ahead and made a fantastic start to this!

I have gone ahead and added his research into the WBC table for easy viewing and as a centralised location for AV vendors and other interested parties. The results are certainly not a shocker but definately an eye opener. WBC has certainly demonstrated what all security researchers already know, this area needs work!

I can really see AV vendors catching a wake up call in this area or atleast I hope they do. The fun will soon begin to see how we can circumvent their restrictions and help improve some of these products!

A new version of ASP-Auditor has been released, v2.2 (BETA).

Changelog:
# Added additional support for Anti-XSS Validation detection.
# Added ASP Source Directory Leak Check
# Added Apr/07 ASP.NET Validation Bypass Check

This is a BETA version, I would really like to start working on a stable version but require public ASP.NET servers for testing. If anyone has access to these resources and is willing to contribute please email me: david.kierznowski_at_gmail.com.

The latest package is available here.

[Hotlinking] is the placing of a linked object, often an image, from one site into a web page belonging to a second site. The second site is said to have an inline link to the site where the object is located. Inline linking is also known as hotlinking, leeching, direct linking or bandwidth theft - wikipedia

Hotlinking has been around for ages, and the attack vector shown in this paper is not new either; I merely take two known attacks and merge them to create a super dangerous client side attack that is persistent!

I released the Web Hacking 2.0 mindmap at the beginning of this year (2007). Someone from the Phoenix OWASP chapter liked the idea and posted it on owasp.org. I have no problem with this, although an email saying how and where my work was to be used would have been nice. Enough of that, the point here is to demonstrate the concept of exploiting hotlink trust relationships. This is the primary problem with hotlinking. Site 1 is creating bandwidth problems for Site 2, however, Site 2 is now in a position of trust (persistent).

Two possible attacks are as follows:

• Attack 1: We deface the page with a lovely picture of stallowned
• Attack 2: We setup a 302 or 304 redirect on my web server with the image filename used on the site who’s trust we are exploiting. The redirect exploits a CSRF vulnerability. Everytime the page is loaded, the CSRF attack is executed. This is now persistent! Everytime a user loads the Site 1, our CSRF attack is executed.

Lets take this concept a little further. If the site is hotlinking an object or iframe type, it is now possible to turn a reflective XSS attack into a persistent XSS attack. For this attack we require both a reflective XSS vulnerability and a hotlink. What’s really neat and tidy is that an attacker can display the correct object after exploitation, remaining completely invisible to the user.

Our malicious redirects are as follows:

Redirect 302 /a.jpg http://www.owasp.org/index.php?title=Special:Userlogout
&returnto=http://michaeldaw.org
OR
Redirect 302 ^/flashobj.swf$ http://site/trusted.html?<script>alert(1)
</script>

This attack concept is a security catastrophe especially when taking Web 2.0 which is designed around this form of trust.

In summary, don’t hotlink. Rather download the file onto your local server, although with Web 2.0, this will become increasingly difficult.

Web servers can enable hotlinking protection to prevent this; however, since alot of browsers now restrict the referrer field, this security method will not really help.

Thanks to pdp (architect) for allowing me to bounce ideas off him.

References:

• XSS IMG CSRF_2

I have collected some WEB backdoors in the past to exploit vulnerable file upload facilities
and others. I think a library like this may be useful in a variety of situations.

Version 1.2 is still to be released, I am in contact with a few contributers but have decided
to make a series (possibly) of releases as they come in. Enjoy.

Web Backdoor Compilation 1b (Pre 1.2) link.

pdp (architect) encouraged me to tabulate the SQL Injection and Input Validation Cheat Sheets. It took me a good hour, but was well worth it. Check it out and let me know if you have any comments.