Sunday, November 4, 2012

Revitalizing the Inter-Protocol Exploitation with BeEF Bind

My last two talks about BeEF were great successes. I presented together with Ty Miller at RuxCon 2012 in the land of the BeEF, Australia. Then I presented the same talk, unfortunately without Ty, at OWASP AppSec USA, in yet another land of the BeEF, Texas (Austin) :D

The first RuxCon talk was on the first day at 9:00AM in the morning, after a drinking night. The room was also much more full at 9:10AM,  and people couldn't get in :D

Ty and Me
Ty and I decided to release the new BeEF Bind research at RuxCon for various reasons:
  •  RuxCon is an old and underground conference, full of proper hackers and friends, not script-kiddies;
  •  many people from the project (Wade, Brendan, Christian, Ben, Scotty, basically everyone except Ryan, Heather, Saafan, Bart, and Quentin and me :-) are from Australia;
  •  I've never been in the land of the kangaroos.

The research is revitalizing Wade's research on IPEC (2007) in the following ways:
  •  We're using XmlHttpRequest instead of HTML forms to send cross-domain POST requests
  •  A new staging shellcode has been developed to be used specifically for this attack technique
  •  Everything has been merged into BeEF, with new exploitation reliability features

The original idea about IPEC is to exploit "tolerant" network protocols which do not close the client connection if non-valid protocol commands are sent. Lets say you have an IMAP server, and instead of sending LOGIN ciccio PASS pasticcio, which are valid commands, you send LOGIN ciccio CAZZ pasticcio. CAZZ is not a valid command for the IMAP protocol, but even if we fuzz the endpoint for thousand times sending the same CAZZ garbage, the connection is never closed unless we close it explicitly from the socket.

This behavior is different across protocol implementations, so you might find an IMAP implementation which does not behave in the following way. Our tests were focused mainly on IMAP, SIP, IRC and a few SMTP implementations. More details about this will be released in the near future.

You can clearly see that this behavior has an obvious flaw. We can exploit it encapsulating the data for this protocol with another one, lets say HTTP, because data which is not valid is just rejected but it is still parsed. This practically means the following HTTP request can be sent:

Wireshark HTTP Request


The HTTP request headers will be parsed as Bad Commands, while the body of the request will be correctly parsed because a001 LIST is a valid pre-authentication command. After that command we're actually sending shellcode, in this case the stager of the new BeEF Bind shellcode, together with an egg-hunter and current/next SEH pointers because the IMAP server (Eudora Mail 3 v6.1.19.0) is vulnerable to SEH based overflow. When the server will parse the LIST command, the shellcode will be loaded into process's memory binding a socket on port 4444. This is not yet a bind shell.

The next step is sending the stage to this port, as another POST request.

While the stage is running in memory, we have port 4444 listening again, waiting for POST requests like:

Wireshark with stager


Note the Access-Control-Allow-Origin, which enables cross-domain communication using CORS.
This means that after the stage is deployed, we can communicate with the shellcode cross-domain from Javascript, reading the HTTP response without violating/bypassing the Same Origin Policy.

The only cross-domain requests where we can't read the response is when we send the stager and the stage of the shellcode. This would have been very helpful, because we could have fingerprinted the service properly.

From a low-level point of view, you can see how the request looks like in the IMAP process memory:

Sending the POST Request

NOP NOP NOP

You can clearly see that the HTTP request headers are in memory, as garbage/NOPs are sent in a normal exploit where we need to fill lets say 800 bytes of memory before reaching the pointers we can overwrite. This adds additional complexity to the exploitation. We cannot know in advance (and we cannot query the XmlHttpRequest object to know it) the exact size of the the HTTP request headers. An error of one byte means the exploit will fail. To calculate the size we send a POST request back to BeEF, on a different socket (to maintain the cross-domain behavior). In this way we can know exactly the size of the headers which will be sent to the target, and we just need to adjust the size considering the Host field which will be clearly different.

Some of you may have been wondering. Wait a sec, how come you can send cross-domain POST requests to port 143? True, there is no magic here.

A pre-requisite is to disable PortBanning for selected ports, and we do that by delivering a malicious Firefox extension. As you know, Firefox extensions have no limitations on which configuration objects to override. So, basically, everything accessible from about:config can be overwritten or modified.

So it's enough to send a malicious (or backdoored) Firefox extension which contains in prefs.js the following line:


pref("network.security.ports.banned.override", "20,21,22,25,110,143");


to disable PortBanning for those selected ports.

Our research has been focused, and currently works perfectly, on latest Firefox. It works also in WebKit (Chrome/Safari) based browsers if you target not-banned ports. I still need to find a way to disable PortBanning on WebKit based browsers. Opera is still not tested, and Internet Explorer too. For IE there is an additional limitation: it looks like cross-domain POST requests cannot be sent.

The impact of this research is "Rooting your internals" (i.e. internal network services) from a browser which sits in your internal network, using only the browser as a pivot for internal network attacks. The communication with the shellcode is entirely in-browser via BeEF, there are no additional reverse sockets open. From a forensics point of view, this should be much more difficult to understand what's happening, or what happened. The attack is much more stealthy.

Slides from our RuxCon talk here:
http://www.slideshare.net/micheleorru2/rooting-your-internals-exploiting-internal-network-vulns-via-the-browser-using-beef-bind

I've also uploaded the screencast of the demo we shown at RuxCon on my Vimeo channel:
https://vimeo.com/52801406
The demo covers a phishing scenario using the BeEF Social Engineering extension, and shows all the steps required to use the BeEF Bind shellcode: from the malicious Firefox extension delivery, to internal live systems identification and port scanning, finishing with exploitation using IPEC.

Expect more goodness on this topic in the near future.

If you want to help debugging/analyzing known/new exploits and see if they can be ported to this technique, let us know. Your help will be greatly appreciated.

4 comments:

  1. This is really nice and interesting blog.I'm glad to know. I admire the time and effort you put into your blog and detailed information you offer.

    AimIT Software - SEO Company

    ReplyDelete
  2. hey dude..!! thnx for the discussion i really appreciate it but not only our support and comments made this efforts, your also own efforts helps you.. see you on boards dude..!

    RPJ Technologies - Call Center Services transcription services

    ReplyDelete
  3. Thanks for the informative post. It helped me a lot. May the Force be with you.
    Call Centers Republica Dominicana

    ReplyDelete