Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Network steganography protocols for opening holes in the firewall (20070610)
One of the applications for steganography in protocol design is to hide illegitimate data transfers on a monitored network, by making the illegitimate transfers appear to be normal, legitimate traffic. For example, "Covert Channels in the TCP/IP Protocol Suite" by Craig H. Rowland describes how TCP header fields could be manipulated to carry additional information besides the payload (e.g., giving significance to the choice of sequence number or header flags). One of the likely uses for steganography is in Botnet control, to replace more cleartext and obviously blockable protocols such as IRC.
Network steganography also has legitimate purposes. One particular scenario is:
- An organization with a firewall connected to the Internet may have a TCP-based server behind that firewall. For example, a home network might contain an SSH server, to enable remote administration of system on that network when the owner is travelling.
- The administrator wishes to enable the server to accept incoming connections from clients on the Internet connecting to a specific port (e.g., the SSH port 22) from trusted clients, but the IP addresses of those clients are not known in advance.
- The administrator does not wish the SSH server to be discoverable to someone scanning all IP addresses on the Internet for SSH services.
Ideally, the firewall should not respond to packets containing TCP SYN (connection requests) from port scanners or forward them on to the SSH server; these packets should be dropped. But how does the firewall differentiate between a TCP SYN from a port scanner and from a trusted client? TCP client implementations generally do not enable sending data in the payload along with the SYN, so the client doesn't have a way of including authentication information in that packet.
One approach would be to use a virtual private network based on IPsec, to establish a tunnel from the client to the firewall. The IP packets could be carried in IP-IP encapsulation or within UDP using NAT-T. This requires the client to authenticate and perform key exchange (using IKE) to negotiate an encryption key for encryption of subsequent traffic in the tunnel, which may be overkill if the only protocol being carried within the tunnel, such as SSH or SSL, is also designed to provide the same services. Furthermore, the IPsec services provided by the firewall may be discoverable.
Port knocking and SPA
Alternatively, several approaches have been considered to 'prime' the firewall to be ready for an incoming connection. In these approaches,
- The client first sends a 'pre-request', encoded in one packet or a series of packets, to the firewall.
- The firewall rejects these packets and silently discards them, but a component either located within the firewall, leveraging a network sniffer in front of the firewall, or relying upon a log scanner reading the firewall's log, detects a pattern in these packets.
- This component configures the firewall to permit a subsequent connection from the client's IP address to the client's desired service.
Typically the client has no way of knowing whether the pre-request was successful until it tries its subsequent request, such as sending a TCP SYN to the SSH port.
Some of the approaches for a pre-request that have been defined and published include:
- port knocking, in which the client simulates performing port scan on a selected set of TCP or UDP port numbers, in which the choice and order of port numbers are significant
- hiding information within the text field of a Microsoft Windows messenger spam
- single packet authentication (SPA), in which a nonce, timestamp, username, command, etc., are encrypted by the client, and this encrypted data is sent in a UDP packet to an arbitrary port (62201)
Further design goals of some of these approaches are:
| Port Knocking | Messenger Spam | SPA | |
|---|---|---|---|
| the packet or series of packets of the 'pre-request' should resemble typical 'Internet noise' | yes | yes | no |
| the pre-request should be resilient to typical problems encountered by packets on the Internet (e.g. occasional random packet loss or reordering) | affected by both loss and reordering | not resilient to loss unless retransmitted | not resilient to loss unless retransmitted |
| the approach should follow Kerckhoffs' principle and assume that an attacker will be trying the approach as well | no, unless a secret pattern choice is used | unspecified | yes |
| an attacker with a network sniffer listening to these packets should not be able to replay them and be granted access | not always done | not always possible | yes, packets include nonce |
| the pre-request should contain the identity of a particular user | not typical | unspecified | yes |
| the pre-request should be able to encode a command beyond 'open the SSH port', so that no request need be sent | not typical, however different knock patterns may trigger preset commands in implemented by component | possible | yes |
| the pre-request should not reveal the identity of the requestor to an attacker sniffing the Internet | client IP address revealed | client IP address and command contents revealed | client IP address revealed, but packet contents encrypted with key not known to the attacker |
In order to distinguish between a trusted client and an attacker performing a more advanced kind of port scan incorporating a pre-request, implementation choices include:
- don't distinguish; rely upon the subsequent protocol interaction (e.g. SSH) to authenticate requestors and reject unauthorized attackers
- maintain a shared secret key for encryption or hash authentication between the client sending the pre-request and the component parsing the pre-request in order to authenticate the client
- with the GnuPG option in SPA, the request could be signed with the private key of the client and encrypted with the public key of the server
In particular, there is a tradeoff:
- a small volume of data (a few bits) carried in the pre-request makes the pre-request easier to hide and has a lower risk of being damaged in transit due to loss or reordering, but cannot represent all of the desirable features
- a larger volume of data is more easily noticable, as a series of several hundred port scan requests has a high risk of being damaged in transit, and so it is more resilient to place the data in a single packet with a payload, as is done in SPA.
Hiding in existing protocols
Port knocking and SPA assume that the organization does not wish to expose any public services. If, however, the organization chooses to expose one or more public services through the firewall, the pre-request could alteratively be encoded using existing request-response protocols to access those services.
For example, if the organization supports a SMTP server, the pre-request sent by the client could be a email message. The body of the message would consist of spam keywords with an arrangement which encodes the encrypted pre-request. The message in transit would appear no different than typical spam, and spam filter run by the organization would easily recognize and drop the message.
For example, the client wishing to send a command to the component would
- 1. build PDU incorporating nonce/timestamp, command and other parameters
- 2. sign PDU with client's private key (where component already has the public part)
- 3. encrypt the signed PDU with the component's public key (assuming this is already known by the client)
- 4. rather than base64-encode the encrypted PDU, spam-encode the encrypted PDU with shared dictionary of spam keywords (approved, deal, medicine, oem, petroleum, ...)
- 5. send the content in a RFC 822 message to a plausible address at the organization's domain, with SMTP and message headers that resemble those used by known spam software
The obvious downside of sending the pre-request as spam is that intermediate systems may detect and block the client.
Another approach, if the organization runs a web site, is to have one or more HTTP requests could be used to transfer the pre-request, in which the client simulates a typical user browsing the page, or a web search engine spider. The pre-request could be encoded as the pattern of URIs in GETs of images on the web site home page, fields in the HTTP header, etc.
Similarly, DNS requests could be used, however, the volume of data that could be included in each request is smaller than in HTTP.
Theoretical advantages of the above approaches is that through the use of open mail relays, web proxies and DNS relays, the source IP address of the TCP connections carrying the SMTP or HTTP requests, or the UDP requests, need not be the same as the client itself, and could be different from each request. An attacker with a sniffer next to the organization would not see a pattern that would indicate which client had been granted access.
| Spam/SMTP | HTTP | DNS | |
|---|---|---|---|
| the packet or series of packets of the 'pre-request' should resemble typical 'Internet noise' | yes | yes | yes |
| the pre-request should be resilient to typical problems encountered by packets on the Internet (e.g. occasional random packet loss or reordering) | yes | yes unless sent in parallel | yes unless sent in parallel |
| the approach should follow Kerckhoffs' principle and assume that an attacker will be trying the approach as well | yes | yes | yes |
| an attacker with a network sniffer listening to these packets should not be able to replay them and be granted access | yes | yes | yes (if size permits) |
| the pre-request should contain the identity of a particular user | yes | yes | yes (if size permits) |
| the pre-request should be able to encode a command beyond 'open the SSH port', so that no request need be sent | yes | yes | yes (if size permits) |
| the pre-request should not reveal the identity of the requestor to an attacker sniffing the Internet | yes | yes | yes |