Articles
On Cinco de Mayo in 1997, which happened to be the first Monday in May that year, the Hacker Publication First Monday included an article entitled, “Covert Channels in the TCP Protocol Suite,” by Craig Rowland.
“The TCP/IP protocol suite has a number of weaknesses that allow an attacker to leverage techniques in the form of covert channels to surreptitiously pass data in otherwise benign packets. This paper attempts to illustrate these weaknesses in both theoretical and practical examples.”1
The methods employed in this paper exposed data hiding vulnerabilities in the Transmission Control Protocol (TCP) and demonstrated a very simple and straight-forward method for hiding data in the TCP initial handshake sequence. In some ways, this served as a warning that hiding information within a data stream was not only plausible but was also simple and practical. As with most cyber security related warnings of this type, there was an initial outcry to develop more secure protocols that could mitigate such threats. Once the voices died down, we moved on to the next threat of the day and many forgot about the vulnerability. I wonder if a viable solution will exist by Monday, May 5, 2014 when Cinco de Mayo falls once again on the first Monday in May? As of today, not only is the TCP protocol still vulnerable to Craig’s initial warning, but hundreds of new protocols have arrived on the scene, most containing a plethora of opportunities to hide information in innocuous ways.
Turning to the Present Day
One of the new areas of interest is Voice over Internet Protocol (VoIP) solutions. The reasons are quite obvious: VoIP is ubiquitously deployed and utilized; VoIP solutions generate a large number of small packets which would be ideally suited for hiding small pieces of a larger message; and finally, the wide variety of packet types, codecs, and encoding methods for VoIP abound, providing cover for the needle in a haystack.
VoIP utilizes network transport mechanisms that are inherently unreliable. The underlying Real-Time Transfer Protocol (RTP) and the User Datagram Protocol (UDP) do not retransmit lost or delayed packets. At first glance this would appear to be a huge drawback for data hiding activities, since losing packets that contain portions of the secret message—especially if they were encrypted—would be problematic. Actually, one of the methods we will discuss leverages this weakness into a strength.
To begin, I’m going to focus on a simple RTP protocol running on top of UDP in a point to point arrangement to explain the core elements of the data hiding method. Of course, to execute this within a true VoIP setting, you would need to work with session initiation protocol (SIP), Real-Time Transfer Control Protocol (RTCP), and others. The diagram below depicts this simplified structure.
Figure 1: VoIP RTP Simplified Packet Overview
Figure 1 depicts a simplified version of the VoIP RTP packet structure. As you can see, the RTP packet is a payload of the UDP packet which carries out the unreliable transport. In turn, the UDP packet is the payload of the IP packet, which provides the Internet Routing needed. In Figure 2 we turn our attention to the RTP packet exchange between the infamous Alice and Bob.
Figure 2: RTP Packet Exchange between Alice and Bob
As you can see in Figure 2, Alice and Bob exchange a sequence of RTP packets in a continuous stream. As you recall from above, packets can be missing, dropped, out of sequence, or delayed, but since the protocol is not meant to be completely reliable, data continues to stream. As mentioned, control packets and other protocol elements that can assist in re-establishing connections if things go wrong have been omitted from this 30,000 ft view.
Figure 3: RTP Payload Insertion
The simplest method of data hiding available is to insert content directly into the payload section of each packet. The secret message is broken up into small chunks and embedded directly into the payload. The current methods we have evaluated use one of two basic schemes.
- The small chunks of the overall secret message are inserted into the header of the payload section. Since most RTP payload types have a built-in header that provides information to the receiver about the configuration of the payload, it is possible to insert a small number of bytes into this payload header.
- The small chunks of the secret message are broken into a bit stream and each bit is used to overwrite the least significant bit of encoded data within the payload.
The problem with both methods, of course, is that if data loss occurs, (lost or delayed packets) some of the hidden data will also be lost. This can be overcome by transmitting redundant packets (secret message chunks). The applications we have reviewed that perform this function allow the setting of the redundancy frequency.
Figure 4: RTP Delayed Packet Modification
The final method I reviewed is actually the most interesting, and is depicted in Figure 4. This method actually takes advantage of the fact that RTP packets are sometimes delayed, delivered out of order, or lost in transmission as a core element of the method. This approach systematically extracts specific packets from the data stream before they are released by the sender. This causes certain packets to purposely not be delivered in a timely fashion to the receiver. The receiving application, whether VoIP or an audio player, automatically compensates for the delayed packet and fills in the blanks, if you will. Since most RTP packets only contain a few milliseconds of audio, the compensation is hardly ever noticed when listening to a conversation or even a streamed audio track.
Here is the best part! Once the packet has been extracted from the stream, the data hiding application can utilize the full payload section to insert slices of the hidden message content. The application then reinserts the packet back into the stream (after a few seconds of delay, of course). Once the packet arrives at the destination, (now significantly delayed), the receiving application discards the packet, (it is never used) since it has already compensated for it earlier. However, a listening application recognizes the delayed packet and extracts it to rebuild the original message.
Investigating Protocol Data Hiding
From an investigative perspective, analyzing the protocol requires a network protocol analyzer or sniffer. Wireshark2 is a great tool for examining the details of such protocols. Once you suspect this type of behavior is occurring, you can utilize Wireshark to capture the RTP packets flowing between two entities. At that point, detailed analysis of the headers of the payload section of each RTP packet is performed to detect inserted values. This may sound completely impossible or impractical. Actually, since Wireshark has powerful search and filtering capabilities, and the headers of the packets are quite regular, detecting the rogue packets is possible with some effort.
When attempting to detect the delayed packet hiding method, you are specifically looking for packet sequence numbers that are delayed. Sorting by the packet timestamps and writing a simple python script that will identify packets delayed more than a couple seconds is possible. Those of you that are more affluent with SNORT3 or other intrusion detection sensors, can come up with other rules and triggers that could constantly monitor for such aberrant behaviors.
Next month I will be taking a look at one of the newest Linux data hiding methods. Until then—keep discovering the hidden.
Discovering the Hidden is a monthly column examining steganography and data hiding.
References
- “Covert Channels in the TCP/IP protocol suite”, First Monday, Volume 2, Number 5 - 5 May 1997. http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/5...
- WIRESHARK Network Protocol Analyzer Information, http://www.wireshark.org/
- Open source network intrusion prevention and detection system (IDS/IPS), http://www.snort.org
Chet Hosmer has been researching and developing technology and training surrounding data hiding, steganography, and watermarking for over a decade. He has made numerous appearances to discuss the threat steganography poses including National Public Radio's Kojo Nnamdi show, ABC's Primetime Thursday, NHK Japan, Cyber Crime TechTV, and ABC News Australia. He has also been a frequent contributor to technical and news stories relating to steganography and has been interviewed and quoted by IEEE, The New York Times, The Washington Post, Government Computer News, Salon.com, and Wired Magazine. Chet also delivers keynote and plenary talks on various cyber security related topics around the world every year.
