13.07.2015 Views

Application Layer Covert Channel Analysis and ... - Bill Buchanan

Application Layer Covert Channel Analysis and ... - Bill Buchanan

Application Layer Covert Channel Analysis and ... - Bill Buchanan

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Z. Kwecka, BSc (Hons) Network Computing, 2006 68between all the applications using the new st<strong>and</strong>ard <strong>and</strong> a backward compatibility tothe already existing implementations, which conformed to previous RFCs. Somesecurity concerns were raised, regarding leakage of personal information, attacksbased on path names <strong>and</strong> DNS spoofing, however threats of covert channels’implementation was overlooked. Following interpretation of a RFC 2616, describesoperation of HTTP <strong>and</strong> highlights areas where transfer of data in a covert manner ispossible.General syntaxThe basic units of HTTP communication are messages, made up of a structuredsequence of octets <strong>and</strong> transmitted via a transport layer virtual circuit (connection).There are two types of messages allowed: requests <strong>and</strong> responses. Both use genericmessage format. This consists of a start-line, zero or more header-fields (headers), anempty line <strong>and</strong> optional message body:generic-message = start-line ; a Request-line or a Status-line*(message-header CRLF) ; one or more headerCRLF; compulsory empty line[ message-body ] ; optional application layer dataStart-line is made of either a Request-line in a request message or a Status-line in aresponse message. CRLF is the only end-of-line marker allowed for all HTTPprotocol elements except the entity-body. It st<strong>and</strong>s for carriage return (CR) <strong>and</strong> linefeed (LF). This is a good practice, there is only one st<strong>and</strong>ard allowed, which makesprotocol implementation easier, <strong>and</strong> prevents information hiding. There are fewdifferent types of message-headers: general-header, request-header, response-header<strong>and</strong> entity-header. All of them are built using the same syntax. Each header consists ofa case-insensitive field name followed by a colon <strong>and</strong> an optional field value.message-header = field-name “:” [ field-value ]Case-insensitivity.Field-names are case-insensitive, thus they are ideal carrier for hiding bits (payload).Both clients <strong>and</strong> the servers will interpret a field-name in the same way no matter thecase of the letters. The coincidence is that capital letters in the ASCII code differ fromthe lower case letters only by a value of the 3 rd bit. Thus binary form of letter “R” is01010010 <strong>and</strong> the one of letter “r” is 01110010. Then a mask of 0xDF can beemployed to extract or encode a payload in ASCII characters. Lower case letterswould decode as 1’s, where capital letters would decode as 0’s. An example followsto illustrate how covert payload maybe hidden in a typical HTTP header given below:Connection: keep-aliveThis header can be modified to carry the bit pattern of 0111001011 <strong>and</strong> would look asfollows:ConnECtIon: keep-aliveConsequently above encoding method can be employed to transfer as many bits ofpayload as the total number of letters in field-names in any particular message. Avisual inspection of the HTTP envelope would reveal this covert channel, however asit is unusual for anybody to examine HTTP message header <strong>and</strong> HTTP clients <strong>and</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!