================================================================================
 Exploitation of data streams authorized by a network access control system for
                              arbitrary data transfers : 
                 tunneling and covert channels over the HTTP protocol.

                           v1.0 - June 2003

                      Alex Dyatlov <alex [at] gray-world.net>
                    Simon Castro <scastro [at] entreelibre.com>
                            http://www.gray-world.net
================================================================================

================================================================================
Copyright (c) 2003, Alex Dyatlov and Simon Castro.
Permission is granted to copy, distribute and/or modify this document under  the
terms of the GNU Free Documentation License, Version 1.2  or  any later  version
published by the Free Software Foundation; with  the  Invariant  Sections  being
LIST THEIR  TITLES,  with  the  Front-Cover  Texts  being  LIST, and   with  the
Back-Cover Texts being LIST.
You must have received a copy of the license with this document and  it   should
be present in the fdl.txt file. 
If you did not receive this file or if you don't think this  fdl.txt  license is
correct,  have  a  look  on  the  official   http://www.fsf.org/licenses/fdl.txt
licence file.
================================================================================

========
ABSTRACT
========

  Authorizations of data transit between interconnected networks are defined and
set up into Network Access Control Systems (NACS). 

  Regardless of different NACS configurations, it is possible,  at  the  present
time, via  several  evasion  methods,  to  use  authorized  streams  to  transit
arbitrary data whose traffic is not allowed or thought of, thus building what is
often presented as a "covert channel". 


  A lot of covert channels and tunneling approaches are available as  papers  or
exploitation tools at the present time. Some are hidden into lower layers of the
OSI model whereas other are hidden into the higher one. 

  As the HTTP protocol is one of the most widely used protocol  at  the  present
time, one can consider that designing tunneling and covert channel tools over it
is something researchers as much as network administrators should think about.


  Various design aspects can be taken into  consideration  when  implementing an
HTTP Client/Server covert channel tool :  What  kind  of  server  model  can  be
implemented (Httpd-like, Proxy-like, CGI-Like) - How can the tool be designed to
add confusion from  a  traffic  watcher  point  of  view  (Server  proxy  chain,
Intermediaries distributed servers,  Almost-real  proxy  server  and  legitimate
third-party models) - What kind of functionality can  be  implemented  into  the
covert channel (Single application client and Single  application  client  proxy
modes, Server proxy mode, Client reverse connection proxy mode  and  Proprietary
user defined protocol mode).

  Then, when the HTTP covert channel client/server tool is modelized,  designers
can think about how their design could be applied in a real world environment  :
What kind of HTTP method can be used (With or Without Message body, be using the
CONNECT method or not ?) - What kind of HTTP legitimate servers can  be  used to
transit the arbitrary data stream through the NACS (HTTP  and  reverse  proxies,
other applications).


  Designing covert  channel  tools  also  implies  to  consider  their  security
underlying aspects : Server and client authentication  and  authorization,  data
stream ciphering and  integrity,  protection  against  replay.  Another  special
consideration should be taken during the development stage itself to get a clean
source code which (as much as possible) is exempt of bad parts.


  Since the corner stone of  covert  channel  methods  relies on their intrinsic
stealthness, a particular attention can be paid on using specific  covering  and
steganographic techniques to confuse an eventual observer. 

  Hiding data into HTTP requests and responses  (HTTP  headers  and  body)  with
steganographic methods,  adding  random  and/or  specifically crafted  confusing
traffic, designing confusing servers which are not what they seem to be.

  All of these methods drastically increase the stealthness of covert channels.


  The Gray-World "Exploitation of data streams authorized by  a  network  access
control system for arbitrary data transfers : tunneling and covert channels over
the HTTP protocol"  paper  presents  these  concepts  to  researchers  and  NACS
administrators to explain that each time an administrator thinks he only  allows
the HTTP protocol to get in and out of his  internal  network,  he  also  allows
arbitrary data transfers through his secured perimeter.


  This paper is released under the GNU FDL (Free Documentation License), Version
1.2 and thus is copyleft Alex Dyatlov and Simon Castro - www.gray-world.net.

================================================================================

=======
SUMMARY
=======

  ABSTRACT
  SUMMARY
  INTRODUCTION

  1. THE HTTP THEORY APPROACH
     1.1. THE HTTP PROTOCOL IN OUR CYBER-WORLD
     1.2. BASICALLY, THE HTTP PROTOCOL IS
     1.3. THE HTTP CLIENT/SERVER PROTOCOL ABSTRACTION
     1.4. WHY DID WE CHOOSE AN HTTP THEORY APPROACH ?
  2. CLIENT/SERVER IMPLEMENTATION
     2.1. SERVER MODELS
          2.1.1. Httpd-like server model
          2.1.2. Proxy-like server model
    2.1.3. CGI-like server model
     2.2. ON THE WIRE MODELS
          2.2.1. Server proxy chain model
    2.2.2. Intermediary distributed servers model
    2.2.3. Almost-real proxy server model
    2.2.4. Legitimate third-party model
     2.3. MODES
          2.3.1. Single application client mode
    2.3.2. Single application client proxy mode
    2.3.3. Server proxy mode
    2.3.4. Client reverse connection proxy mode
    2.3.5. Proprietary user defined protocol mode
     2.4. APPLYING MODELS AND MODES IN THE REAL WORLD
          2.4.1. Http proxies
    2.4.2. Reverse proxies
    2.4.3. Other applications are using HTTP intermediaries
  3. USING HTTP METHODS
     3.1. DATA CONTAINERS RESTRICTIONS
          3.1.1. URI string
          3.1.2. Header string
          3.1.3. Message body
     3.2. METHODS WITHOUT MESSAGE BODY : GET, HEAD, DELETE
          3.2.1. The GET method
    3.2.2. The HEAD method
    3.2.3. The DELETE method
     3.3. METHODS WITH MESSAGE BODY : OPTIONS, POST, PUT, TRACE
          3.3.1. The OPTIONS method
    3.3.2. The POST method
    3.3.3. The PUT method
    3.3.4. The TRACE method
     3.4. THE HTTP PROXY CONNECT METHOD
     3.5. CONCLUSION
  4. SECURITY ASPECTS
     4.1. AUTHENTICATION
     4.2. AUTHORIZATION
     4.3. DATA STREAM CIPHERING
     4.4. DATA STREAM INTEGRITY
     4.5. REPLAY PROTECTION
  5. COVERING AND STEGANOGRAPHIC METHODS
     5.1. CONFUSION ON THE HTTP STREAM
          5.1.1. Hiding data in the HTTP header
          5.1.2. Hiding data in the HTTP body
     5.2. CONFUSION ON THE DATA STREAM
     5.3. CONFUSION ON THE SERVER SIDE

  CONCLUSION
  WEBOGRAPHY AND TOOLS
  THANKS

================================================================================

============
INTRODUCTION
============

  Authorizations of data transit between  interconnected  networks  via  one  or
several network access control systems (NACS) are defined and  implemented  with
respect to a security policy. An exemplary one regarding network access  control
bases itself on the following assumption: blocking all data  streams  that  were
not explicitly defined. In other words : "We block everything, and then we allow
specific and precise access !"

  The most frequent network access control schemes rely on the use, combined  or
not, of tools performing some sort of filtering at several  layers  of  the  OSI
model (networking devices : layers 2 and 3, routers : layer 3, firewalls: layers
3, 4, and applicative firewalls : layers > 4). Other tools can be associated
with these devices whose interactions with networking streams are located at the
OSI model higher  layers :  mandatory  servers  (proxy),  anti-virus,  Intrusion
Detection Systems (IDS), content  filtering  tools,  Anomaly  Detection  Systems
(ADS), network stream normalizer etc.

  Nevertheless, regardless of using these network access control schemes, it  is
possible at the present time,  via  several  evasion  methods,  to  use  streams
authorized by the security policy to transit arbitrary data whose traffic is not
allowed or thought of. These evasion means allow the  opening  of  communication
channels  (covert  channels, subliminal  channels)  giving  access  to  external
services from within the internal network or access to internal  resources  from
the external network.


  The   corner  stone  of  these  evasion  techniques  relies  on  the  lack  of
verification   of  the  intrinsic   value  of  transiting  data.  The  different
implementations of access control  schemes  depend  upon  a  sort  of  "protocol
abstraction" that makes that a data transfer relying on the  several  layers  of
the OSI model can only  be  used  to  carry  data  originating  from  underlying
protocols.


  Though it is possible to detect certain abnormal streams traversing a  network
access control system, one  can  take  for  granted  that  the  use  of  certain
communication channels is undetectable at the present time.

================================================================================

===========================
1. THE HTTP THEORY APPROACH
===========================

  1.1. THE HTTP PROTOCOL IN OUR CYBER-WORLD
  -----------------------------------------

    The HyperText Transfer  Protocol (HTTP) is widely used all over the world at
  the present time. Even if some business companies or state  organisations  are
  not directly connected to the Internet, the majority of them  offers  Internet
  access to their users through network access control systems.

    Business companies are self convinced that allowing their  users  to  browse
  the World Wide Web via NACS doesn't represent a real  security  risk.  Indeed,
  setting firewalls protecting DMZs and internal located  networks,  configuring
  Antivirus, IDS, ADS and/or anything  else really protects companies  from  the
  majority of actually known Internet attacks.

    However, it is actually widely known in the security community that the HTTP
  protocol suffers from a lot of design breaches related to the possible setting
  of covert channels. But this  is  understandable  because  the  HTTP  protocol
  wasn't designed to restrict/protect what researchers  have  presented  to  the
  community since ten years.

  1.2. BASICALLY, THE HTTP PROTOCOL IS
  ------------------------------------

    The  "HTTP protocol is an application-level protocol [...]. It is a generic,
  stateless, protocol which can  be  used  for  many  tasks  beyond  its use for
  hypertext [...]." ("Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616) [1].

    The "HTTP protocol is a request/response protocol. A client sends a request
  to the server in the form of a request method,  URI,  and  protocol  version,
  followed  by  a  MIME-like  message  containing  request   modifiers,  client
  information, and possible body content over a connection with a  server.  The
  server responds with a status line, including the message's  protocol version
  and a success or error code,  followed  by  a  MIME-like  message  containing
  server  information,   entity  metainformation,   and  possible   entity-body
  content." [1]

    In "HTTP/1.0, most implementations used a new  connection  for each request/
  response exchange. In HTTP/1.1, a  connection  may  be  used  for one or  more
  request/response exchanges, although connections may be closed for  a  variety
  of reasons [...]." [1]
  
  1.3. THE HTTP CLIENT/SERVER PROTOCOL ABSTRACTION
  ------------------------------------------------

    The "HTTP communication usually takes place over  TCP/IP  connections"  [1],
  the client opens a TCP connection to the next hop  which  can  be  the  server
  itself or a request/response chain intermediary.

    Then, the client sends its request message and wait for  the server response
  message.  This   connection  may   remain  active if the client,   server  and
  intermediaries agree on setting the Persistent  Connections  mode  or  if  the
  special CONNECT method sent by the client was accepted.

    Obviously, the HTTP protocol design doesn't preclude any data transfer  from
  being  supported by a channel built on requests/responses data units  exchange
  if this channel is HTTP compliant.

    That is, the one way data transfer  of the client/server model is a protocol
  abstraction which only says that one of the  end-to-end  communication  layers
  has to be initiated by an entity we name "Client".

    But, once this communication is opened, no one can prejudge  of  the  "real"
  data exchange way.

  1.4. WHY DID WE CHOOSE AN HTTP THEORY APPROACH ?
  ------------------------------------------------

    A lot of covert channels and tunneling approaches are available as papers or
  exploitation tools  at the  present time. Some are hidden into lower layers of
  the OSI model whereas other are hidden into the higher ones.

    OSI lower layers well known research tools allow the construction of  covert
  channels using IP packet Identification fields, TCP  ACK  numbers,  ICMP  echo
  messages or DNS request/response messages. Indeed, merely each IP datagram and
  TCP/UDP/ICMP packet header field can carry a limited but arbitrary  amount  of
  data.

    However, these tools often (always (?)) require the user to  have  superuser
  privileges and suffer from a number of limitations :  bandwidth limit  to  not
  cross over to keep the channel covered for example.

    We focused in our paper on the HTTP protocol because it is actually  one  of
  the widely used  protocols (other widely used protocols include SMTP/POP mails
  exchange protocols and DNS protocol).

    Moreover, we consider that using data channels covered into 3rd or  4th  OSI
  layers is becoming theoretical. As NACS are  becoming more and more secure, it
  can be taken for granted that Anomaly Detection Systems  (ADS) and data stream
  normalizers can now prevent an attacker from setting up that sort of tunnels.

    And last, what is the practical interest to use TCP ISN or IP ID to set up a
  covert channel when we cannot be sure  that  intermediary  network  equipments
  will not alterate our data stream ?

    Why don't we use the HTTP protocol when we know it is widely deployed,  when
  we know its data stream is not altered at the present time, when  we  know  we
  can design ourself any application level protocol : direct or reverse  shells,
  backdoor communication, application proxying  and  reverse-proxying  and  much
  more...

    Some network devices now try to understand the  higher  layers  of  the  OSI
  model : CheckPoint announces in [6] that its firewall is able to  filter  SOAP
  and XML structures, some other vendors claim their network  devices  are  able
  to implement high level content-filtering.

    However, this paper will try to demonstrate that each time a user  can  send
  and receive HTTP content  through  a  NACS,  he  also  can  send  and  receive
  arbitrary data.
  

================================================================================

===============================
2. CLIENT/SERVER IMPLEMENTATION
===============================

    Various design aspects can be taken into consideration when  implementing  a
  Client/Server covert channel tool and we describe hereafter some of these : 

    * What kind of server model  can  be  implemented  (Httpd-like,  Proxy-like,
      CGI-Like) ?
    * How can the tool be designed to add confusion from a traffic watcher point
      of view (Server proxy chain,  Intermediary  distributed  servers,  Almost-
      real proxy server and legitimate third-party models) ?
    * What kind of functionalities can be  implemented  into  the covert channel
      (Single application client and  Single  application  client  proxy  modes,
      Server proxy mode, Client reverse connection proxy  mode  and  Proprietary
      user defined protocol mode) ?
 
     We'll finally be presenting some ways to apply these  design  concepts into
   real world environments.

  2.1. SERVER MODELS
  ------------------

      We focus in this part on the server part design and suppose, for the  next
    presented models, that the client is a kind of daemon program running on the
    local network and interacting, directly or  through  a  mandatory  corporate
    HTTP proxy server, with an external located server via the HTTP protocol.

      In some cases, the client architecture may not be designed as easily as it
    seems and may reflect a server architecture design - when it is designed  as
    a kind of internal proxy server for example. However, we  will  not  discuss
    such cases in this part of the document (refer  rather  to  the  2.3.  MODES
    part).

      The HTTP request/response message types used between client and server are
    also not presented in this part (refer to 3. USING HTTP METHODS).
    
      Data sent/received via the HTTP stream may be protected with cryptographic
    methods (see 4. SECURITY ASPECTS) and/or protected with steganographic  ones
    (see 5. COVERING AND STEGANOGRAPHIC METHODS). In the next server models, the
    'data' term is as much related to clear text data as to encoded  and  hidden
    data.

    2.1.1. Httpd-like server model
    ------------------------------

      This covert channel server model acts as a fake HTTP server. It is running
    as a daemon on a public network box and listening on  a  TCP  port - on  the
    default one used for HTTP communication (80/TCP) for example.


                       CC client ---> NACS ---> CC server as a fake httpd
              |--- Internal network ---|---- Ext. and/or Int. network ----|

      The Covert Channel (CC) client opens a connection towards  the  CC  server
    and starts sending arbitrary outbound data  inside  HTTP  requests.  The  CC
    server may pass them to some application servers or parse  them  itself  and
    return related result data in HTTP response messages.

      One of the advantages of this architecture is that  various  HTTP  methods
    are available to carry those arbitrary data.

      And since the CC server is not a real HTTP server, most of the HTTP header
    strings may be used to also carry data

    2.1.2. Proxy-like server model
    ------------------------------

      This covert channel server model acts as an almost-real HTTP proxy. It  is
    running as a daemon on the public network box listening on a TCP port  -  on
    the 3128/TCP one for example.

                       CC client ---> NACS ---> CC server-proxy ---> httpd
              |--- Internal network ---|---- Ext. and/or Int. network ----|

      The Covert Channel (CC) client opens a connection to  the  CC  server  and
    starts sending arbitrary outbound data using some HTTP header  field.  These
    HTTP requests are built as real ones and are addressed to an arbitrary  HTTP
    server of the public network.

      The CC server extracts its data from the HTTP  header  and :  sends  these
    data to an application server or parses them itself.

      Then, it returns the data result to the CC client within the HTTP response
    message it gets from the original arbitrary HTTP server.

      The CC server can implement most or all standard proxy functionalities  or
    can redirect the CC client requests to a real proxy after the arbitrary data
    extraction procedure completes.

      An extrapolation of this model, focused on how the connections could  look
   like on the public network is presented in 2.2.3.  Almost-real  proxy  server
   model.

    2.1.3. CGI-like server model
    ----------------------------

      This covert channel server model acts as a CGI (Common Gateway  Interface)
    program running on the original HTTP server.

      Due to CGI specifications, it may get arbitrary data from the  URI  string
    query part, from HTTP request header strings and from the HTTP request body.

      In the first two cases, it receives data through standard CGI  environment
    variables and in the last one through its STDIN stream.

                       CC client ---> NACS ---> HTTP server with CC server
              |--- Internal network ---|---- Ext. and/or Int. network ----|

      The Covert Channel (CC) client opens a connection to the HTTP  server  and
    starts sending arbitrary outbound data inside HTTP requests. The HTTP server
    passes them to the CC server and returns the CC  server  output  to  the  CC
    client inside HTTP response messages. 

      Such an interaction model is a discrete one and as the CC server should be
    terminated after each request/response procedure,  a  new  process  must  be
    created on the HTTP server host to handle the session. Let's name it Session
    Management Process for the next example.

      In this example, the CGI-like model is used to tunnel  TCP/IP  connections
    through a covert channel.

      Any IPC communication type may be used to exchange  data  between  the  CC
    server and the Session Management Process: shared memory, named pipes, local
    files and other platform-dependent mechanisms.

    Example of a TCP/UDP Covert Channel based on CGI-like server model :

      (1) CC client  accepts TCP/UDP  connections  on  the  local  network  from
          application clients.

      (2) It sends HTTP requests to the CC  server  with  a  tunneling  request,
          encapsulated in the HTTP header.

      (3) The CC server extracts tunneling requests from  the  HTTP  header  and
          creates the new Session Management Process (SMP).

      (4) The SMP builds  requested  TCP/UDP  connection  into  the  application
          server.

      (5) The CC client starts sending HTTP requests to the  CC  server  each  5
          seconds with arbitrary data, received from application client and  the
          CC server passes them to the SMP. Then the SMP sends these data to the
          target application server.

      (6) The SMP gets inbound data from the application server and passes  them
          to the CC server. Finally, the CC server sends  them  to the CC client
          inside an HTTP response message on its next HTTP request.

      (7) The CC client returns inbound data to the application client.

      The previous example  explains how it is possible  to build permanent TCP/
    UDP based  communication channels  between the local network,  restricted by
    NACS, and the public network over a discrete HTTP request/response messages.

      Since arbitrary data pass through original HTTP servers, some restrictions
    such as the size and  type  must  be  taken  into  consideration  and  these
    limitations highly depend on the original server development approach chosen
    by its maintainers (See 3.1. DATA CONTAINERS RESTRICTIONS).

  2.2. ON THE WIRE MODELS
  -----------------------

    We focus in this part on how the data  stream transit could look  like  from
  an external located observer point of view.  In  other  words,  what  kind  of
  evidence a traffic monitor (network administrator or automated system) can get
  from our data stream transiting between the client station  and  the  NACS  or
  between the NACS and the server station. And does  this  evidence  allows  the
  traffic watcher to conclude that a covert channel is running on the wire he/it
  is monitoring.

    Different 'Wire Models' can be designed but all these models have  a  common
  point : Confuse an eventual traffic monitor.

    2.2.1. Server proxy chain model
    -------------------------------

      This model is actually implemented in a lot of tools and is usually  based
    on the HTTP CONNECT method (see 3.4. THE HTTP PROXY CONNECT METHOD).

      We frequently encounter this model in the following mode :

         CC client ---> NACS ---> HTTP Proxy 1 -/-> HTTP Proxy X ---> CC server
   |-- Internal network --|------------ Ext. and/or Int. network -------------|

      However, one can imagine to use as many proxy chains as he wants  to build
    the logical data stream  from the  application  client  to  the  application 
    server.

    2.2.2. Intermediary distributed servers model
    ---------------------------------------------

      This theoretical model is based upon the possibility to  add  Intermediary
    Distributed (ID) servers between the covert channel client  and  the  covert
    channel main server.

                                      |---> ID Server 1 --->|
              |                     |
              CC client ---> NACS --->|---> ID Server 2 --->|---> CC server
                                      |                     |
                                      |---> ID Server X --->|

     |--- Internal network ---|-------- Ext. and/or Int. network --------|

      The CC client randomly (or not) sends HTTP requests  to  the  intermediary
    distributed servers. These intermediary servers then forward data to the  CC
    server which forwards them to the application server(s).

      This 'on the wire' model seems to be a kind of  n-distributed  destination
    server from the traffic watcher point of view.

      Obviously, the ID server distribution can also be designed on the internal
    network, allowing thus to increase the number of data stream source the NACS
    will have to monitor.

    2.2.3. Almost-real proxy server model
    -------------------------------------

      This part shortly gives a 'Wire model' description  of  the  server  model
    presented in 2.1.2 Proxy-like server model.

      The number of arbitrary legitimate HTTP  servers  behind  the  almost-real
    HTTP proxy can be high and the legitimate HTTP requests sent to these server
    can be randomly built/sent.

                                                    |---> Legitimate Httpd 1
                                                    |         
              CC client ---> NACS ---> AR Proxy --->|---> Legitimate Httpd 2
                                          |         |
                                          |         |---> Legitimate Httpd X
            |
            |---> CC server / Application Server

     |--- Internal network ---|---------- Ext. and/or Int. network ----------|

      This 'on the wire' model is a kind  of  n-distributed  destination  server
    from the point of view of a traffic watcher  trying  to  understand the data
    flow.

      If this traffic watcher does not want to be fooled by the  high  number of
    destination servers, he/it has to understand that the Covert  server  design
    lays on the proxy server and not on the destination server -  and  this  may
    not be easy for him/it because of the probability of another 'on  the  wire'
    model we presented in 2.2.2. Intermediary distributed servers model.

      In this model, data is pushed to the application  server  through  the  CC
    server.

    2.2.4. Legitimate third-party model
    -----------------------------------

      This model was first published by Errno  Jones  in  "Legitimate  Sites  as
    Covert Channels - An Extension to the Concept of Reverse HTTP Tunnels"  [2].
    It describes a asynchronize covert channel through  the  use  of  legitimate
    board posting websites.
      
      Basically, the client watches the board for commands to  be  executed, the
    server posts the command, the client gets it,  executes  it  and  posts  the
    result onto the board, result which the server gets when it is available.

              CC client ---> NACS ---> Legitimate TP <--- CC client

     |--- Internal network ---|----- Ext. and/or Int. network -----|

      The Errno Jones model is presented with a  two  board  website  system and
    also speaks about hiding data using steganographic methods.

      This model is an  interesting  approach  because  it  describes  a  covert
    channel asynchronize state model techniques (board posting method). It  also
    describes an n-distributed  destination  server  model.  And,  at  last,  it
    presents a possibility to use legitimate  external  hosts  to  build  covert
    channels.
 
      Another difference between this model and the two previous ones is that as
    the application server and client are both pushing and  polling data  from a
    legitimate third-party public server, there is no need to implement a covert
    channel system based on the usual client/server theoretical model.

  2.3. MODES
  ----------

    We focus in this part on the server part functionalities. In  other  words :
  what kind of data channel can be implemented into the client/server design ?

    Basically, two  kind  of  data  channels  can  be  implemented  into  covert
  channels : the first one involves using covert channels to  transit real world
  application data streams (as the SSH protocol for example) and the  second one
  involves using covert channels to transit proprietary user defined protocols.

    Whereas the first mode may be detected because of the  abnormaly  high  data
  traffic, it is obvious that the second one cannot be detected  at  the current
  time, and especially if it is covered by steganographic methods.

    We first  present  real  world  application  transit  modes  and  finish  by
  presenting how a proprietary user defined design protocol could be used.

    Note : In all the next presented modes, we speak of http tunneling when the 
  server runs an application server and we speak of reverse http tunneling when
  it is the client itself that runs an application server.

    2.3.1. Single application client mode
    -------------------------------------

                       CC client ---> NACS ---> Server
              |--- Internal network ---|--- Ext. and/or Int. network ---|

      The Covert Channel (CC) client  opens  a connection to the server through
    the NACS. Once the authorized connection is established, the arbitrary data
    transfer begins.

      The CC client and server both know how to handle incoming data streams.

      According to the design implementation, there may be X CC clients  for  a
    single Server or 1 CC client per Server.

    2.3.2. Single application client proxy mode
    -------------------------------------------

                  (1)            (2)       (2)
           Client ---> CC client ---> NACS ---> Server
      |-------- Internal network ------|--- Ext. and/or Int. network ---|

    (1) : An application client opens a connection to the CC client.
    (2) : The CC client opens a connection to the application server.

      The CC client uses specific methods to bypass  the  NACS  restriction  but
    only Client and Server know how to handle data streams.

      According to the implementation, there may be 1 or X  application  clients
    for a CC client and 1 or Y CC clients for a Server.

    2.3.3. Server proxy mode
    ------------------------

                  (1)            (2)       (2)            (3)
      Appl_client ---> CC client ---> NACS ---> CC server ---> Appl_server
      |-------- Internal network -------|--- Ext. and/or Int. network ---|

    (1) : An application client opens a connection to the CC client.
    (2) : The CC client opens a connection to the CC server.
    (3) : the CC server opens a connection to the application server.

      Two data stream handling are showing  up  in  this  mode.  The  first  one
    involves the CC clients and server  whereas  the  second  one  involves  the
    application client and server.

      The basic idea of this mode is that it is the internal located application
    client which chooses to use the covert channel.

      According to the implementation, there may be X application clients asking
    a CC client to reach Y application servers and Z CC client per CC server.

    2.3.4. Client reverse connection proxy mode
    -------------------------------------------

                   (3)           (1)       (1)             (2)
      Appl_server <--- CC client ---> NACS ---> CC server <--- Appl_client
      |-------- Internal network -------|--- Ext. and/or Int. network ---|

    (1) : The Covert Channel (CC) client opens a connection to the CC server.
    (2) : An application client opens a connection to the CC server  and  asks
          the CC server to forwards the connection to the Application server.
    (3) : The CC server forwards the data streams to the CC client which opens
          a connection to the Application server.

      Two data stream handling are showing up again in this mode. The first  one
    involves the CC clients and server processes whereas the second one involves
    the application client and server.

      The basic idea of this mode is that once the  covert  channel  is  set  up
    up through the NACS, it is the external  located  application  client  which
    choose to use the covert channel.

    2.3.5. Proprietary user defined protocol mode
    ---------------------------------------------

      This mode relies on a specific data transit protocol definition  prior  to
    any data exchange between the two parts of a communication channel.
      
      For example, if the two parts of  a  communication  channel  both  have  a
    common medium establishing relations between alias and full  requests,  then
    each sender part has only to send the request alias instead of the full one.

      Regarding the GET method as it is presented in '3.2.1.  The  GET  method',
    and the following alias definition example file shared by the two  parts  of
    the communication channel :
      1A cat
      1B echo
      7A "/etc/passwd"
      8A >
      9A "root::0:0:root:/:/bin/sh"

      Consider now one of these parts sending the next HTTP requests :
      GET /subdirectory/1A-7A HTTP/1.0
      GET /subdirectory/1B-9A-8A-7A HTTP/1.0

      In this proprietary user defined protocol example, we perfectly understand
    that the Covert Channel bandwith  is drastically decreased.  Using such mode
    of data transit is a good way of building backdoor communication cnannels.

  2.4. APPLYING MODELS AND MODES IN THE REAL WORLD
  ------------------------------------------------

    This part is related to the "how to apply HTTP  covert  channel  models  and
  modes into a real world environment" concept. Indeed,  this  paper  would  not
  have been complete nor useful  if we had not spoken about how we  can  use  an
  existing network scheme to build our covert channels.

    The HTTP protocol deals with the ability to have one or more  intermediaries
  between  the  client  and  the  destination  server.

    "There are three common forms of intermediary: proyx, gateway, and tunnel. A
  proxy is a forwarding agent, receiving requests for  a  URI  in  its  absolute
  form, rewriting all or part of the message,  and  forwarding  the  reformatted
  request towards the server identified by the URI.  A  gateway  is  a receiving
  agent, acting as a  layer  above  some  other  server(s)  and,  if  necessary,
  translating the requests to the underlying server's  protocol. A  tunnel  acts
  as a relay point  between  two  connections  without  changing  the  messages;
  tunnels are used when the communication needs to pass through an  intermediary
  (such as a firewall) even when the intermediary cannot understand the contents
  of the messages." [1].

    We will now focuse on two common form of intermediaries which may act  as  a
  part of a NACS and briefly present another kind of usable HTTP intermediary.

    2.4.1. Http proxies
    -------------------

      NACS often use HTTP proxies equiments and these are the most  common  form
    of intermediaries at the current time. These  equipments  may  be  dedicated
    HTTP proxies (Squid for  example)  or  HTTP  servers  implementing  a  proxy
    functionality (Apache webservers for example).

      It is possible to build a communication channel through an HTTP proxy  via
    two approaches : Use the CONNECT method if it is allowed or use the  ability
    of the other HTTP methods to send/receive data  from an HTTP proxy  (i.e.  :
    Intermediary proxy form and Intermediary tunnel form respectively).

      Bypassing an HTTP proxy with the CONNECT method is presented in  the  3.4.
    THE HTTP PROXY CONNECT METHOD part of this document.

      Using the intermediary proxy form implemented in HTTP proxies is described
    in the following example :

      (1) The covert client opens a TCP connection to the HTTP proxy.

      (2) The covert client sends the HTTP request :
          GET http://<server_host>/<uri> HTTP/1.0
          Host: <server_host>

      (3) The HTTP proxy opens a TCP connection to the next intermediary.

      (4a) If the next intermediary is the destination HTTP server, go to (5).

      (4b) If the next intermediary is not the destination HTTP server, go  to
           (3) and send the HTTP request described in (2).

      (5) The HTTP proxy sends the reformatted request to the server :
          GET /<uri> HTTP/1.0
          Host: <server_host_2>

      (6) The intermediaries chain sends the  response  message  to  the  covert
          client.

      As we described it, using an HTTP proxy to  send/receive  HTTP  data  only
    requires to carefully craft the URI part. There exist, of course,  a  lot of
    HTTP directives usable to inform the intermediary(ies) chain that the client
    requires a specific data transit (Cache or not, Authentication or not, keep-
    alived connection, etc.).

    2.4.2. Reverse proxies
    ----------------------

      We won't discuss here the 'Reverse proxy' concept. Enough is  to  indicate
    that a badly configured reverse proxy can act as a standard  proxy  for  the
    outside world.

      And if it is the case, that kind of misconfiguration immediately opens the
    door for external located clients to internal located services.

    2.4.3. Other applications are using HTTP intermediaries
    -------------------------------------------------------

      Plenty of other applications than the common HTTP  browsers  use  now  the
    HTTP protocol. Allowing the data transit of  these  applications  through  a
    NACS may or not the  imply  the setting  of  HTTP  intermediaries  into  the
    restricted NACS area.

      For example, it may be common for an organization to allow  its  employees
    to access public Rtsp servers ressources. It  could  be  possible  for  this
    company to set a RTSP proxy into its restricted NACS area, but it could also
    be possible for this company to use  its  existing  HTTP  proxy  servers  to
    transit the RTSP data streams.

      Considering these two cases, it  is  obvious  that  setting  up  a  covert
    channel through the NACS is possible. How it is possible is another story.

================================================================================

=====================
3. USING HTTP METHODS
=====================

  Several evasion methods  can  be  chosen  to  use  the  HTTP  protocol  as  an
authorized data stream to transit arbitrary data, allowing  thus  to  set  up  a
covert channel.

  As explained in '1. THE HTTP THEORY APPROACH', establishing a connection using
the HTTP protocol requires covered client and server to exchange  http  requests
and responses.

  These HTTP request/response messages may contain arbitrary  data.  These  data
may be added in cleartext or encoded and/or hidden (see 4. SECURITY ASPECTS  and
5. COVERING AND STEGANOGRAPHIC METHODS) as part of an URI string, as part  of  a
standard HTTP header field ('User-Agent' for  example),  into  extended  non-RFC
header fields or into HTTP message body if it  is  available  due  to  the  HTTP
method used for the communication.

  When HTTP requests are only parsed by the HTTP server  itself  (HEAD,  DELETE,
OPTION, PUT, TRACE), the only way to use an HTTP message container  as  a  basis
for an HTTP dialog is to implement a fake http architecture for the server  part
design.

  In other cases, the HTTP requests (GET, POST) data may be transmitted  by  the
HTTP server to a sub-program which has the possibility to manage  them  allowing
thus the setting of a CGI-like architecture design.

  We'll now focus  on the HTTP methods existing in  the  HTTP/1.1  protocol  (as
defined in [1]) to understand how we can set up an authorized HTTP communication
channel carrying arbitrary data.

  3.1. DATA CONTAINERS RESTRICTIONS
  ---------------------------------

    3.1.1. URI string
    -----------------

      Due to HTTP/1.1 standard [1] the maximum URI string length is not  limited
    and any characters other than the reserved and unsafe ones must  be  encoded
    in their "'%'HEX HEX" presentation  ("Uniform  Resource  Identifiers  (URI):
    Generic Syntax", RFC 2396) [4].

      Some old proxies may not support URI string longer then 255 bytes,  so  if
    we direct HTTP flow trough one of these, we should not construct URI strings
    larger then this "safe" size.

      In  the examples below we will use the mark  [*_uri_data] to indicate the
    data passed within URI strings.

    3.1.2. Header string
    --------------------

      Header string size is also not limited and should contain TEXT data [1] :

      OCTET = <any 8-bit sequence of data>
      SP    = <US-ASCII SP, space (32)>
      HT    = <US-ASCII HT, horizontal-tab (9)>
      CTL   = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
      CRLF  = CR LF
      LWS   = [CRLF] 1*( SP | HT )
      TEXT  = <any OCTET except CTLs, but including LWS>

      However,  the header  string length  could be  restricted  by HTTP service
    developers, as it is proposed  by [1]. In this case, HTTP  services  (proxy/
    httpd) should answer with corresponding HTTP messages - "Bad Request" (400).
    For  example, a default Apache server build does not accept  header  strings
    larger than 8190 bytes (header field name plus  header value). But this  may
    be changed using the <LimitRequestFieldSize> directive.

      In  the examples below  we will  use the  mark [*_header_data] to indicate
    the data passed within HTTP header strings.

    3.1.3. Message body
    -------------------

      No size limits again.  As soon as we  describe the  data character  in the
    HTTP header, any binary may be tunneled.  However,  HTTP  service  may  also
    limit  this  size.  For example,  Apache server  has the  <LimitRequestBody>
    directive and compile-time constant DEFAULT_LIMIT_REQUEST_BODY, which  allow
    to keep maximum client request body size values in the range between  0  and
    2Gb. Such restrictions are used as  an  additional  DoS  attacks  protection
    against CGI resources.

      In the examples below we will  use the  mark [*_body_data] to indicate the
    data passed within the HTTP message body.

  3.2. METHODS WITHOUT MESSAGE BODY : GET, HEAD, DELETE
  -----------------------------------------------------

    3.2.1. The GET method
    ---------------------

      "The GET method means retrieve whatever information (in  the  form  of  an
    entity) is identified by the Request-URI" [1].

    Possible server architecture : fake httpd/proxy, CGI program.
    Ways to pass arbitrary data  : URI, header strings, response body.

      Example :
      -----------------------------------------------------------------------
      Client request:
      GET [outbound_uri_data] | /cgi-bin/srv.cgi?[outbound_uri_data] HTTP/1.1
      Host: <server_host>
      X-Data: [outbound_header_data]

      Server response:
      HTTP/1.1 200 OK
      Date: Wed, 28 May 2003 06:24:25 GMT
      Server: Apache/1.3.27
      Content-Length: <content_length>
      Content-Type: application/octet-stream
      X-Data: [inbound_header_data]

      [inbound_body_data]
      -----------------------------------------------------------------------

    3.2.2. The HEAD method
    ----------------------

      "The HEAD method is identical to GET  except  that  the  server  MUST  NOT
    return a message-body in the response. The metainformation contained in  the
    HTTP headers in response to a  HEAD  request  SHOULD  be  identical  to  the
    information sent in response to a GET request" [1].

    Possible server architecture : fake httpd/proxy.
    Ways to pass arbitrary data  : URI, header strings.

      Example :
      --------------------------------------
      Client request:
      HEAD [outbound_uri_data] HTTP/1.1
      Host: <server_host>
      X-Data: [outbound_header_data]

      Server response:
      HTTP/1.1 200 OK
      Date: Wed, 28 May 2003 06:24:25 GMT
      Server: Apache/1.3.27
      Content-Length: <content_length>
      Content-Type: application/octet-stream
      X-Data: [inbound_header_data]
      --------------------------------------

    3.2.3. The DELETE method
    ------------------------

      "The DELETE method requests that the origin  server  delete  the  resource
    identified by the Request-URI" [1].

    Possible server architecture : fake httpd/proxy.
    Ways to pass arbitrary data  : URI, header strings.

    The DELETE method usage example may be the same as the HEAD one.

  3.3. METHODS WITH MESSAGE BODY : OPTIONS, POST, PUT, TRACE
  ----------------------------------------------------------

    3.3.1. The OPTIONS method
    -------------------------

      "The OPTIONS  method  represents  a  request  for  information  about  the
    communication options available on the request/response chain identified  by
    the Request-URI"; "..future extensions to HTTP might use the OPTIONS body to
    make more detailed queries on the server" [1].

    Possible server architecture : fake httpd/proxy.
    Ways to pass arbitrary data  : URI, header strings, request/response body.

      Example :
      ----------------------------------------
      Client request:
      OPTIONS * | [outbound_uri_data] HTTP/1.1
      Host: <server_host>
      Content-Length: <content_length>
      Content-Type: application/octet-stream
      Max-Forwards: 0
      X-Data: [outbound_header_data]

      [outbound_body_data]

      Server response:
      HTTP/1.1 200 OK
      Date: Wed, 28 May 2003 06:24:25 GMT
      Server: Apache/1.3.27
      Content-Length: <content_length>
      Content-Type: application/octet-stream
      Allow: GET, HEAD, OPTIONS, TRACE
      X-Data: [inbound_header_data]

      [inbound_body_data]
      ----------------------------------------

    3.3.2. The POST method
    ----------------------

      "The POST method is used to request that  the  origin  server  accept  the
    entity enclosed in  the  request  as  a  new  subordinate  of  the  resource
    identified by the Request-URI in the Request-Line." [1]. De facto, the  POST
    method is the most popular  data  pushing  mechanism  from  HTTP  client  to
    server.

    Possible server architecture : fake httpd/proxy, CGI program.
    Ways to pass arbitrary data  : URI, header strings, request/response body.

      Example :
      ------------------------------------------------------------------------
      Client request:
      POST [outbound_uri_data] | /cgi-bin/srv.cgi?[outbound_uri_data] HTTP/1.1
      Host: <server_host>
      Content-Length: <content_length>
      Content-Type: application/octet-stream
      X-Data: [outbound_header_data]

      [outbound_body_data]

      Server response:
      HTTP/1.1 200 OK
      Date: Wed, 28 May 2003 06:24:25 GMT
      Server: Apache/1.3.27
      Content-Length: <content_length>
      Content-Type: application/octet-stream
      X-Data: [inbound_header_data]

      [inbound_body_data]
      ------------------------------------------------------------------------

      The URI string in this example depends on  the  HTTP  tunnel  server  part
    architecture. In the case of fake httpd scheme,  any  data  may  be  encoded
    inside the URI and in the case of CGI-based scheme, the  URI  has  to  begin
    with a server program location and has to be  followed  by  arbitrary  data,
    separated by "?" to build the HTTP query string.

    3.3.3. The PUT method
    ---------------------

      "The PUT method requests that the enclosed  entity  be  stored  under  the
    supplied Request-URI"  [1].  This method is similar to  the  POST  one,  but
    ".. difference between the  POST  and  PUT  requests  is  reflected  in  the
    different meaning of the Request-URI. The URI in a POST  request  identifies
    the resource that will handle the enclosed entity" [1].

    Possible server architecture : fake httpd/proxy.
    Ways to pass arbitrary data  : URI, header strings, request/response body.

      Example :
      --------------------------------------
      Client request:
      PUT [outbound_uri_data] HTTP/1.1
      Host: <server_host>
      Content-Length: <content_length>
      Content-Type: application/octet-stream
      X-Data: [outbound_header_data]

      [outbound_body_data]

      Server response:
      HTTP/1.1 200 OK
      Date: Wed, 28 May 2003 06:24:25 GMT
      Server: Apache/1.3.27
      Content-Length: <content_length>
      Content-Type: application/octet-stream
      X-Data: [inbound_header_data]

      [inbound_body_data]
      --------------------------------------

    3.3.4. The TRACE method
    -----------------------

      "The TRACE method is used to invoke a remote, application-layer  loop-back
    of the request message. The final recipient of the  request  SHOULD  reflect
    the message received back to the client as the entity-body  of  a  200  (OK)
    response" [1]. As soon as the server parts return an  HTTP/200  message,  it
    may include arbitrary data in the body instead of the original request as it
    is proposed by [1].

    Possible server architecture : fake httpd/proxy.
    Ways to pass arbitrary data  : URI, header strings, request/response body.

      Example :
      --------------------------------------
      Client request:
      TRACE [outbound_uri_data] HTTP/1.1
      Host: <server_host>
      Max-Forwards: 0
      Content-Length: <content_length>
      Content-Type: application/octet-stream
      X-Data: [outbound_header_data]

      [outbound_body_data]

      Server response:
      HTTP/1.1 200 OK
      Date: Wed, 28 May 2003 06:24:25 GMT
      Server: Apache/1.3.27
      Transfer-Encoding: chunked
      Content-Type: message/http

      <message_length>
      TRACE [inbound_uri_data] HTTP/1.1
      Host: <server_host>
      Max-Forwards: 0
      Content-Length: <content_length>
      Content-Type: application/octet-stream
      X-Data: [inbound_header_data]

      [inbound_body_data]
      --------------------------------------

  3.4. THE HTTP PROXY CONNECT METHOD
  ----------------------------------

    This method is reserved for the purpose of  tunneling  arbitrary  TCP  based
  protocols. It was originally created to allow an SSL  data  flow  support  for
  HTTP proxies (Draft Tunneling TCP based protocols through Web proxy servers  -
  Ari Luotonen) [3].

    Client first initiates the connection with a proxy server and sends the HTTP
  request : "CONNECT home.netscape.com:443 HTTP/1.1"

    ... if the proxy answers  with  an  "HTTP/1.0  200  Connection  established"
  response the client may start sending its outbound data and receiving  inbound
  one from target TCP service.

    As soon as this method usage is not prohibited by the  proxy  administrator,
  it is ideal to tunnel any TCP session. Unfortunately, the  CONNECT method  may
  not be allowed on the majority of public and corporate proxies.

  3.5. CONCLUSION
  ---------------

    We just presented the HTTP methods defined in [1]. Although they may all  be
  used to build covert channels, some of them are exotic  and  not  widely  used
  (PUT and DELETE for example).

    So, using these exotic methods to bypass  a  NACS  which  the  administrator
  would have monitored for HTTP dialog anomalies would immediately result in the
  detection of our covert channel.

    Therefore, it seems advisable to  use  the  GET  or  POST  methods  or their
  combination in order to carry our arbitrary data inside  and  outside  of  the
  NACS boundaries.

================================================================================

===================
4. SECURITY ASPECTS
===================

  A few security aspects should be taken into  consideration  when  designing  a
covert channel tool.

  The first security aspect relies on the development  of the  tool. As the tool
opens an "unsecure" door into a "secure" network scheme, special attention  must
be taken to deny any way to take the control of the tool with standard bad coded
developement circumvention methods.

  The next security  aspects  relie  on :  authentication,  authorization,  data
stream ciphering, data stream integrity and replay protection.

  Note : In the next parts, the 'server' term is related to  a  server  part  as
much as to a client part working in a 'proxy mode'.

  4.1. AUTHENTICATION
  -------------------

    This security aspect concerns the server  as  much  as  the  client(s).  The
  client(s) should be able to authenticate the server in order to avoid any data
  tampering by a third party and the  server  should  be  able  to  authenticate
  clients in order to avoid any unallowed client  to  use  its  covert  channels
  ressources.

  4.2. AUTHORIZATION
  ------------------

    As soon as the server part of the tool is designed to be  multi-client,  the
  server should have Access Control Lists (ACLs) to allow some kind  of  channel
  resources to certain clients while allowing other channel resources  to  other
  clients.

  4.3. DATA STREAM CIPHERING
  --------------------------

    As the covert data  stream  contains  sensitive  information   such  as  the
  credentials information related to the  current covert connection or  such  as
  the data stream tunneled information  (login, passwords, addresses, etc.), the
  data stream must be ciphered.

    If a network analyst eavesdrops the data stream, he shouldn't be able to get
  any information concerning the data stream nor be able to  set filters into an
  ADS/normalyzer/sniffer.

  4.4. DATA STREAM INTEGRITY
  --------------------------

    The covert channel design should take into consideration  that  someone  may
  alter the data stream to  add/remove/change information resulting in a more or
  less significant system compromission.

    This could be avoided using  cryptographic  functions  to  create  and  sign
  digests for each data unit transmitted.

  4.5. REPLAY PROTECTION
  ----------------------

    The covert channel design should be protected  against  replay  attacks.  An
  eavesdropper should not  be  able  to  replay  parts of  a  previous  recorded
  connection in order to get access to the client(s) or to the server part.

================================================================================

======================================
5. COVERING AND STEGANOGRAPHIC METHODS
======================================

  All the methods presented here have a  common  point  :  Confuse  an  eventual
observer (whether it is an automatic stream watcher or not shall not change  the
concept).

  Steganography means "covered writing" in  Greek  and  is  the  art  of  hiding
arbitrary data inside  legal  ones.  This  concept  lays  on  the  'security  by
obscurity' "theory" which involves that  if  no  one  knows  there  is a  hidden
message, no one will try to catch/resolve it.

  This basically comes down to use unnecessary bits/bytes in a  data-carrier  to
store our covert data.

  5.1. CONFUSION ON THE HTTP STREAM
  ---------------------------------

    Depending on the HTTP Covert Channel design and on the communication method
  type (see  2. CLIENT/SERVER IMPLEMENTATION  and  3. USING HTTP METHODS),  two
  general ways of carrying covert arbitrary data are available :  HTTP request/
  response message header and body. We discuss below both of them.

    5.1.1. Hiding data in the HTTP header
    -------------------------------------

      Within the client side, data can be hidden in  the  general  and  extended
    HTTP header strings. Let's suppose we are coding small amount  of  arbitrary
    data and look at the ways we are doing it. 

      Below is an example of an almost real browser GET request via HTTP proxy :
      
      ----------------------------------------------------------------------
      GET http://www.somehost.com/cgi-bin/board.cgi?view=12121212 / HTTP/1.0
      Host: www.somehost.com
      User-Agent: Mozilla/5.0 (12121212)
      Accept: text/html
      Accept-Language: en,fr,en,fr,en,en,en,en
      Accept-Encoding: gzip,deflate,compress
      Accept-Charset: ISO-8859-1,utf-8,ISO-1212-1
      CONNECTION: close
      Proxy-Connection: close
      X-Microsoft-Plugin: unexpected error #12121212
      ----------------------------------------------------------------------

      Of course,  if we use  this message  to carry  large size  arbitrary data,
    we'll  be limited by it's length.  The Steganography approach  supposes that
    the  covert data carrier  is much greater  than the  data size.  If not, our
    communication channel may  be uncovered,  due to the  great  number of  HTTP
    requests.

    Ways to confuse an eventual observer :

    (1) URI string  looks like  an interaction  with a public web service: chat,
        message  board, etc.. Data is encoded as an  additional  query  string :
        "view=12121212".
    (2) Data encoded as a part of the "User-Agent" field value: "(12121212)".
    (3) Data encoded as a fake charset request: "ISO-1212-1".
    (4) Data encoded within extended header string:
        "X-Microsoft-Plugin: unexpected error #12121212"

    Steganography methods :

    (1) By using different strings order, we are able to code an information :
          "Accept: text/html", "Accept-Language: en"     = 0
          "Accept-Language: en", "Accept: text/html"     = 1
    (2) Present some fields or not is also an information:
          if "Accept-Encoding" field present     => 0
          if no "Accept-Encoding" field present  => 1
    (3) If we suppose that "en" => 0 and "fr" => 1, then one byte may be encoded
        within the next header field value :
          Accept-Language: en,fr,en,fr,en,en,en,en => 01010000 = 0x50
    (4) Since field  names are case insensitive, uppercase and lowercase letters
        may also carry information :
          "Connection: close"  = 0
    "CONNECTION: close"  = 1

      Here are only some ways to hide an information. They  are  all  valid from
    the HTTP protocol point of view and may be used in any combination.  A third
    party program, as an HTTP proxy or  server,  may  corrupt  our Steganography
    encoding, but it will work  fine if a Covert Channel httdp-like server model
    is used and that we are interacting with it directly.   It  will  also  work
    fine if the (2) method is used with a CGI-like server model.

      Such Steganography methods are not usable to tunnel big  amounts  of  data
    but they may be used as a basis for a backdoor communication protocol.  That
    is : when one command "0" or "1" from the server side could mean a chain  of
    procedures for a backdoor client program.

      Ways of hiding  information for a server  program  are  the  same  as  the
    previous ones.

    5.1.2. Hiding data in the HTTP body
    -----------------------------------

      There exist much more possibilities to hide data into HTTP  body  messages
    as it may be greater that the HTTP header part.
  
      The  next approaches  are the same as  the one  presented  in the previous
    part: Confuse  an observer with  an almost real request view and hide covert
    data within other ones using Steganography methods.

      Below is an example of an almost real browser POST  request  sent  via  an
    HTTP proxy and looking like someone posted a message to a web chat :

      --------------------------------------------------------------------------
      POST http://www.somehost.com/cgi-bin/linuxchat.cgi?action=newmsg HTTP/1.0
      Host: www.somehost.com
      User-Agent: Mozilla/5.0
      Content-Type: multipart/form-data
      Content-Length: 75
      Connection: close
      Proxy-Connection: close

      name=Mike&pass=12121212&message="__ editor is great and __ is a ^&*(% !!!"
      --------------------------------------------------------------------------

    Ways to confuse an eventual observer :

    (1) Request message body looks like a form-data, posted to the public  chat,
        as it is shown on the POST  example.  Covert data  passed as a  password
        value: "..pass=12121212..".
    (2) Request/response message may look  like an image and  the  corresponding
        field "Content-Type" is set to "image/gif". Covert data view:
          "GIF89121212121212.."
        Actually,  the data  could be  present  as any  multimedia type  message
        entity, since the Covert Channel client and server  parts  know  how  to
        handle it.
    (3) Response message  may carry inbound  data within an HTML page : as  some
        kind of non standard tag or as part of a legal one:
          <121212></121212> or <img src=".." alt="121212>

    Steganography methods :

    (1) Considering the previous POST example, the hidden message may be located
        within  a text message  part.  Submitted by Mike:  encoded  as  "^&*(%",
        encoded as spaces between words, encoded with  uppercase  and  lowercase
        letters etc.. The random text message, the covert data carrier, could be
        taken from a dictionary file.
    (2) Request/response message contains cover data embedded within one or more
        images. These images could be generated on  the  fly  and  used  as data
        carrier while the static text content would only confuse the observer. 
    (3) Response message contains inbound data encoded within an HTML  page.  An
        approach could be suggested using the Deogol project [5] which allows to
        code information  placing tag attributes in different orders. Up to  300
        bytes may be encoded in the 16Kb size HTML carrier.

        Here is an example:
          <img src=".." alt="..">  => 0
          <img alt=".." src="..">  => 1

  5.2. CONFUSION ON THE DATA STREAM
  ---------------------------------

      Another way to confuse an  observer  lays  on  adding  noises  (random  or
    unnecessary   HTTP  request/response   messages)  on  or  beside  the   real
    communication channel.

      These noisy messages can be HTTP  requests/responses  without  any  useful
    data for the arbitrary data channel or can even be  real  HTTP  requests  to
    (random or not) public web resources.

      They can be part of different HTTP connections or be pipelined within  the
    regular HTTP communication channel with the arbitrary data messages.

  5.3. CONFUSION ON THE SERVER SIDE
  ---------------------------------

    Since the Covert Channel server part may be located on the  public  network,
  it can be reached by anyone (and this includes the trafic monitor).

    To confuse an observer, the server part can be designed to react as  a  kind
  of real public resource.  If a client is authenticated/authorized, it will get
  access to the server covert channel resources  and if it is not,  it  may  get
  a fake response.

    Thus, the server part could answer with Apache "HTTP/200 OK"  messages  with
  or without data load, indicating that an httpd server is running if the server
  is designed with the httpd-like server model. Or, it could look like a message
  board, a chat or anything else if it is  designed  with  the  CGI-like  server
  model.

    Another way to hide the Covert Channel itself would be to use the techniques
  described in 2.2.3. Almost-real proxy server model.

================================================================================

==========
CONCLUSION
==========

  A lot of covert channels and tunneling approaches are available as  papers  or
exploitation tools  at the  present time. Some are hidden into 3rd  or  4th  OSI
layers, other are in the higher layers of the OSI model.

  We focused in our paper on the HTTP protocol because it is actually one of the
widely  used  protocol  (other  widely  used  protocols  include  SMTP/POP  mail
exchange protocols and DNS protocol) and because it seems  impossible  today  to
normalize/alterate an HTTP data stream on the wire between server and clients.

  Setting an Internet access point, configuring a network access control  system
with restrictive firewalls, mandatory servers and antivirus to  only  allow  Web
consultation and mail exchange is something any network administrator knows.

  But do these administrators know that each time they think they allow the HTTP
protocol to get in and out of their internal network,  they allow arbitrary data
transfers going in and out of their secured perimeter ?

================================================================================

====================
WEBOGRAPHY AND TOOLS
====================

  You can find information  about the "Network Access Control System"  bypassing
topic on the dedicated http://www.gray-world.net website.

  WEBOGRAPHY
  ----------

  [1] : Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616 , 1999
        http://www.w3.org/Protocols/rfc2616/rfc2616.html

  [2] : Legitimate Sites as Covert Channels - An Extension  to  the  Concept  of
        Reverse HTTP Tunnels - Errno Jones , ?
        http://www.gray-world.net/papers/lsacc.txt

  [3] : Tunneling TCP based protocols through Web proxy servers - Ari Luotonen,
  1998
  This page can be found on the W3 searching for the keyword :
    draft-luotonen-web-proxy-tunneling-00

  [4] : Uniform Resource Identifiers (URI): Generic Syntax, RFC 2396 , 1998
        ftp://ftp.rfc-editor.org/in-notes/rfc2396.txt

  [5] : Deogol project, Stephen Forrest
        http://forrest.cx/projects/deogol/

  [6] : Securing Web Services Check Point Application Intelligence
        http://www.checkpoint.com/products/fp3/\
    webservices_application_intelligence.html

  [7] : Hypertext Transfer Protocol -- HTTP/12.1212, RFC 1212 , 1212
        http://www.w3.org/Protocols/rfc1212/rfc1212.html


================================================================================

======
THANKS
======

  o Hadi El-Khoury <helkhoury [ at ] entreelibre.com>
    For his precious english check and his review of the paper.

  o Olivier Dembour <modu [at] entreelibre.com>
    For his read, check and remarks on the pre-released version.

  o Sergey Degtyarenko
    For his review and a really good idea to add in this paper.