The Channel logo


By | Federico Biancuzzi 27th June 2007 18:34

Worms 2.0!

The Metasploit menace inside your firewall

Interview Wade Alcorn recently published a paper explaining the technical details behind Inter-protocol Exploitation [PDF, 120kb].

In his research he focused on using a web browser as a beachhead to launch Metasploit-style attacks. What this means is that any Javascript enabled web browser might be used to launch an attack against a service, for example a VoIP server, and gain complete control of the box.

Generally exploits are executed inside a development framework such as Metasploit, or run directly from the code. But this time, the code would run inside the browser, using Javascript. And all of this takes palce without exploiting any bugs in the browser itself.

Your browser is now an active menace against the security of your internal network. However, the problem can't be easily fixed, because it is not based on a bug: it simply uses "Web 2.0" technologies against you.

Can you explain how this works, Wade?

Wade Alcorn: It is well known that an attacker can establish a control channel through a firewall/DMZ to a browser. The control channel usually maintains two-way communication through periodic command requests back to the attacker's web server. Using this control channel the attacker can send commands for the web browser to execute. The example most commonly demonstrated is the use of JavaScript code to display an alert dialog box.

My research has shown that the browser can be instructed to launch exploit code, encapsulated in HTTP, at machines on its internal network. Whilst my focus has been on HTTP as the carrier protocol, other protocols can also potentially encapsulate exploits. The examples in the paper employed JavaScript to construct the requests and generate the exploit payload.

Could you cite a real life example?

For successful Inter-protocol Exploitation there needs to be a method to encapsulate the exploit in the carrier protocol. Also, depending on the complexity of the communication flow which is a precursor to exploit delivery, a handshake may also be required. This is the case in the Asterisk manager interface vulnerability; it is exploitable only after authentication.

The Asterisk Inter-protocol Exploit example included in the paper illustrates the multiple requirements. Firstly the HTTP headers are simply interpreted as erroneous commands by the Asterisk server. Next, the encapsulated handshake is sent which, in this instance, is a valid set of authentication details. Now the server is in an exploitable state and the encapsulated exploit is interpreted by the asterisk server. The handshake and exploit use an HTTP multi-part POST request for encapsulation. In this instance the two protocols have communicated sufficiently to send exploit code from the web browser (via HTTP) to the Asterisk manager interface. The example starts a bindshell listening on port 4444.

How does this affect internal networks security?

Organisations commonly use a model that invests the majority of security resources into the external perimeter. This leaves the internal networks as a much softer target. The bug exposes a network's soft underbelly to Inter-protocol Exploitation.

Another danger is that web Inter-protocol Exploitation will be combined with cross-site scripting viruses. The infamous MySpace XSS virus payload was executed one million times. It is safe to presume that a subset of those infected browsers were likely to be connected to internal networks.

Significant damage could have been done if an Inter-protocol Exploit was used as the payload.

In short, an attacker can establish a control channel through a firewall/DMZ to a browser. From this position the browser can then be instructed to launch Metasploit style exploits at internal machines. This combined with non-hardened internal networks increases the risk of penetration by an attacker. In the future, the security of internal networks will need to increase to withstand attacks of this kind.

Is there any workaround that browsers could implement?

An option is to warn the user when a request is performed to ports other than 80 and 443 - like when an invalid HTTPS certificate is detected. This would give users a chance to prevent an Inter-protocol Exploit being launched from the browser.

You gave the example of Asterisk, that required authentication. I am wondering if this means that this could be used to launch password guessing attacks to ssh servers too.

It is unlikely because of the complexity of the SSH handshake. However, brute force attacks can be launched on other protocols eg. IMAP.

Since I don't think we can try to modify HTTP, I guess the best way is to improve the way network daemons handle "strange" garbage at the beginning of a connection. What is your suggestion for programmers of such software?

My suggestion is that network daemons drop the connection immediately after receiving an invalid command. This would reduce the error tolerance significantly and in turn reduce the likelihood of Inter-protocol Exploitation. If error tolerance is required for development or debugging purposes, it could be simply added as a configurable option.

What type of restriction is there in the exploit payload?

The main restriction is the control over the content. Further research is needed in employing different character sets. The method discussed in the paper can create the majority of the 256 bytes. However, there are some important bytes that it doesn't (ie, 0x00). My cursory look at different character sets suggests they can be used in a practical situation to achieve all the possible bytes.

The exploit will come from the machine of the web user, but how will the attacker be able to communicate with the target?

It may be possible to include all the commands in the payload. If it isn't possible or interactive communication is required, there are techniques to employ the browser as a middleman. Commands can be issued to the browser through an attacker control channel which then constructs Interprotocol Communication requests.

Examples of browser communication with a bindshell (behind a firewall) have been done by encapsulating and sending commands in HTTP. These commands echo valid JavaScript and HTML script tags. It literally uses the 'echo' command. The echoed instructions tell the browser to encode the bindshell response and use the response in a new request back to the attacker's web server. This allows the attacker to see the results of the shell commands.

Using the browser as a middleman, the attacker has two way communication. Also, because HTTP is used to send and receive data from the browser it is likely that a Firewall/DMZ will permit the traffic.

Could it work against search engines spiders?

It would depend on the extent to which the spider logic constructs the requests using JavaScript. If it is a fully functioning JavaScript implementation, there is a likelihood that the spider will be capable of Inter-protocol Exploitation just like web browsers.

We talked about web browsers loading the exploit from a website, but could this work with different file formats and software? For example Acrobat Reader comes to my mind for this advisory.

This is a new area of research and there are potentially more inter-protocol issues with web technologies. For one, AJAX can allow more flexibility than the methods discussed in the research. Also, different character sets have the potential to yield more tightly controllable Inter-protocol Exploits.

The recently published acrobat cross-site scripting vulnerability could potentially be used to launch Inter-protocol Exploits. Any issue that has the potential to force an application to make a request with controllable content could be used for attacks, provided it meets the requirements of encapsulation and error tolerance.

The advisory states that the vulnerability does 'allow remote attackers to inject arbitrary JavaScript into a browser session.' Provided there are no other restrictions it will be very similar to using a normal cross-site scripting vulnerability for Inter-protocol Exploitation.

I think it was Nimda that exploited both web servers and browsers to spread... does this approach could be used to install a worm on a webserver, then the browser of every visitor will load some Javascript to exploit a random website that will spread the worm to its visitors, and so on? And this time there is no need to exploit a bug in browsers

It is even simpler. If the attacker used an advanced cross-site scripting virus, the payload would be enough to launch the attack on Internal networks. For example the MySpace virus payload was executed one million times in 20 hours. Inter-protocol Exploitation and advanced cross-site scripting viruses are a dangerous combination.

How do you search for new bugs? How do you develop new attacks?

My work brings me into contact with a wide range of platforms and technologies. In recent times, developing BeEF has supported an interest in the dynamics of component interaction in complex, often eclectic, environments.

Interception proxies are a must when developing web attacks. The Odysseus and Burp proxies allow a lot of control over HTTP communication. Increasingly, I am finding the need for generic network proxies like Echo Mirage that hook into network function calls.

Another tool which I couldn't do without is netcat. It is simple and powerful - a great combination. ®

Wade Alcorn is a security researcher/consultant living in Brisbane, Australia. His permanent role at NGS Consulting is Principal Security Consultant. Further to consultancy engagements he has contributed various security tools and published vulnerabilities and white papers.

alert Send corrections


Frank Jennings

What do you do? Use manual typwriters or live in a Scottish croft? Our man advises
A rusty petrol pump at an abandoned gas station. Pic by Silvia B. Jakiello via shutterstock

Trevor Pott

Among other things, Active Directory needs an overhaul
Baby looks taken aback/shocked/affronted. Photo by Shutterstock

Kat Hall

Plans for 2 million FTTP connections in next four years 'not enough'
Microsoft CEO Satya Nadella


League of gentlemen poster - Tubbs and Edward at the local shop. Copyright BBC
One reselling man tells his tale of woe