COVERT TIMING CHANNELS USING

HTTP CACHE HEADERS

Denis Kolegov, Oleg Broslavsky, Nikita Oleksov Tomsk State University Information Security and Cryptography Department

Introduction

A covert channel is a mechanism for sending and receiving information

between hosts without alerting any firewalls and IDSs

HTTP is one of the most used Internet protocol so detections of the

covert channels over the HTTP is an important research area

Example – HTTP Headers

Using steganography methods in header values

Suppose that

Then

“en” 0 “fr” 1

Accept-Language: en,fr 01 Accept-Language: fr,en 10 Accept-Language: en,fr,en,fr,en,en,en,en 0x50

Covert Channels’ Usage

• Botnet C&C channel

• In-band key exchange

• Transfer illegal content

• Stealing information from

“secure” environments

Types Of Covert Channels

TIME DEPENDENCE

• Storage channels – a storage location is written to and read from

• Timing channels – transmitting information through time values

DIRECTION

• Client – server

• Server – client

Client-Server Covert Channels

Client-server covert channels are easier to implement, e.g. covert

storage channel via If-Range request header

GET / HTTP/1.1 Host: 162.71.12.43 If-Range: 120c7bL-32bL-4f86d4105ac62L …

Hex-encoded data

Server-Client Covert Channels

Server-client channels are more complicated and most of them are

timing channels so it is more interesting to research

Basic HTTP Cache Headers

RESPONSE (SERVER) HEADERS

• Last-Modified

• ETag

REQUEST (CLIENT) HEADERS

• If-Modified-Since

• If-Unmodified-Since

• If-Match

• If-Non-Match

Request

Response

Last-Modified Response Header

Last-Modified HTTP header stores a date of the last web entity’s modification

HTTP/1.1 200 OK Server: nginx/1.1.19 Date: Wed, 02 Apr 2014 14:33:39 GMT Content-Type: text/html Content-Length: 124 Last-Modified: Wed, 02 Apr 2014 14:33:39 GMT Connection: keep-alive (data)

Page request

Response

GET / HTTP/1.1 Host: 162.71.12.43 (other headers)

ETag Response Header

The ETag value is formed from the hex values of

120c7bL-32bL-4f86d4105ac62L file's inode size last-modified time (mtime)

GET / HTTP/1.1 …. HTTP/1.1 200 OK Server: Apache/2.2.22 (Ubuntu) Date: Wed, 02 Apr 2014 14:33:39 GMT Content-Length: 124 ETag: 120c7bL-32bL-4f86d4105ac62L (data)

Page request

Response

Common Usage of Cache Request Headers

HTTP cache headers allows web-client not to download a page if it

hasn’t been changed since the certain time

Page request

Page has been changed

HTTP/1.1 200 OK (page data)

Page has not been changed

HTTP/1.1 304 OK (only headers)

GET / HTTP/1.1 Host: 162.71.12.43 If-Modified-Since: Wed, 02 Apr 2014 14:33:39 GMT (other headers)

GET / HTTP/1.1 Host: 162.71.12.43 If-None-Match: 120c7bL-32bL-4f86d4105ac62L (other headers)

Common Usage of Cache Request Headers

Second pair of headers does the same as previous but with logically inverse condition

Page request

Page has been changed

HTTP/1.1 412 OK (page data)

Page has not been changed

HTTP/1.1 200 OK (only headers)

GET / HTTP/1.1 Host: 162.71.12.43 If-Unmodified-Since: Wed, 02 Apr 2014 14:33:39 GMT (other headers)

GET / HTTP/1.1 Host: 162.71.12.43 If-Match: 120c7bL-32bL-4f86d4105ac62L (other headers)

General Covert Channels Idea – Client Side

HTTP request

Get new header value

Received ‘1’

If page changed

Store header value

Received ‘0’

Wait n seconds

then else

General Covert Channels Idea – Server Side

On the server side we can use two different models:

First context Minimum privileges on server: • SECRET.FILE – read only • Covert channel web page –

write only

Second context Web server is fully controlled by an attacker

Covert Channels Using HTTP Cache Headers

• Last-Modified header value

• Using If-Modified-Since header

• Using If-Unmodified-Since header

• ETag header value

• Using If-Match header

• Using If-None-Match header

Last-Modified based

ETag based

Ways to Implement

In tons of possible ways we focus on

• Python – Socket library

• C++ – Boost ASIO library

• С – simple C socket library

We choose C due to its highest performance (among these ways) and

decent stability. Also we choose server model in first context for its

least requirements.

Issues in first context

Some problems we solved during implementation

Issue Solution

Server-client synchronization Special synchronizing function

Different time of requests Dynamic sleep time

Lateness after sleep “Active” sleep

High CPU load with “active sleep” “Dynamic” and “active” sleep combination

Issue 1

Necessity of synchronization

“read” (web client) and “write”

(host) services

Solution:

Synchronizing function that does

requests at a maximum speed

(without sleep)

Send HTTP request

Get host response

If page has been

changed

then else

Issue 2

Different time of requests can

break services synchronization

Solution:

Dynamic sleep time equals to

(sleep_time – time took for

request)

Calculate time took for request

diff_time

Sleep (sleep_time – diff_time) µs

Issue 3

Inaccurate sleep - after sleep

(usleep() is used) the program

can awake with 10-200μs

lateness

Solution:

Use “active sleep” - calculation

time difference between last

request and current moment

while it is less than sleep_time

Calc diff_time

then else If diff_time <

sleep_time

Issue 4

High CPU load with “active sleep” Solution: Combine “active” and “dynamic” sleep

Calculate diff_time

If diff_time < CONST

then else

Sleep (sleep_time – CONST –

request_time)

Advantages Of Covert Timing Channels

• Does not modify common HTTP request structure

• Does not require web-server modifications

• Any read-only activity on web page that is used by the channel do

not break its work

• If-* specified channels can work even if main header (Last-Modified

and ETag) is disabled

Specification

Header Sleep time

Min start sequence

Avg sequence Max

sequence Speed Accuracy

Last-Modified

2s 3400 bits 10145 bits 22143 bits 0.5 bit/s 99,87%

1s 3200 bits 8848 bits 19712 bits 1bit/s 99,82%

ETag 1s 3200 bits 8848 bits 19712 bits 1bit/s 99,82%

0.5s 2400 bits 8142 bits 18123 bits 2 bit/s 99,5%

Client in C, server in first context model

Second server context model

In the second context we can avoid necessity of client-server synchronization by waiting for the request and responding directly:

Send new header value

Send old header value

If current message bit

is ‘1’

Store header value

then else

WAIT for HTTP request

Specification

Second context model. Client in C, controlled web server on PHP

+

Header Network Average HTTP

ping Speed

ETag

Local host 0.55 ms 986 bit/s

Data center local network 1.63 ms 845.65 bit/s

Local network 6.9 ms 295.69 bit/s

Internet 383.2 ms 4.89 bit/s

Covert Channels in Browsers

Kenton Born. «Browser-based covert data exfiltration»

W. Alcorn, C. Frichot, M. Orru. «The Browser Hacker’s Handbook»

DOMAIN NAME SYSTEM (DNS)

Query: “Where is some.domain.example.com?”

Response: “It is at 88.0.13.37!”

some.domain.example.com

Subdomain Domain

bigbrother.watchingme.evil.com

Information Domain IT’S CLIENT-SERVER CHANNEL

Browser Context

Purpose:

To implement covert timing channels using browser-side technologies

as JavaScript, AJAX and different HTML features

Timing Channels in Browsers

Problems:

• Lack of any “sleep” function

• Low accuracy of existing time management functions

• Difficulties with synchronization of covert channel’s server and client

So implementation of the used model is pointless, but it is possible to

implement covert channels in these restrictions using controlled web

server

Issues

Issue Solution

Server-client synchronization Client does special request to begin conversation

End of message determination Client receive some special HTTP code in response, e.g. 404 – Not Found or 403 - Forbidden

Single client communication only Open a session that stores transferring bit number for each client

The Browser Exploitation Framework

“BeEF allows the professional penetration tester to assess the actual

security posture of a target environment by using client-side attack

vectors.”

BeEF ETag Server-to-Client Tunnel

ETag Tunnel in BeEF consist of 2parts: extension in Ruby, that

implements server side logic via couple of web pages mounted to

BeEF webserver, and module in JS, that is responsible for receiving

information from C&C at zombie client

ETag

Covert Channel

BeEF extension

BeEF module

BeEF Etag Specification

BeEF ETag server-to-client tunnel testing results

Network Average

ping

Average HTTP ping

256 bit 1024 bit

Local host 0.045 ms 0.6 ms 10.11 bit/s 9.9 bit/s

Local network 18 ms 19.8 ms 10.3 bit/s 9.78 bit/s

Internet 176 ms 360.9 ms 5.09 bit/s 4.97 bit/s

Proof Of Concept

http://youtu.be/W2qWA7XUzGQ https://github.com/beefproject/beef

Oleg Broslavsky

ovbroslavsky@gmail.com

@yalegko

Denis Kolegov

dnkolegov@gmail.com

@dnkolegov

Nikita Oleksov neoleksov@gmail.com

@neoleksov