Bonfire - Multi-Protocol Covert Channel

Bust through network barriers

When the network won't let you reach out, there are sometimes other means of communicating with the outside world.

Whether it's a sensitive corporate network with strict firewall rules and monitored internet proxies, or just a public Wi-Fi with a generic paywall, some specific protocols are often left allowed through the gates.

In many cases, DNS lookups are forwarded to the public Internet without much consideration. Sometimes, even ICMP exchanges are allowed with normally segregated networks.

Bonfire exploits such cases to encapsulate TCP communications within other protocols and in turn bypass network restrictions and monitoring.

Take the pain out of exfiltration

Bonfire sets up a link between a "server" instance (running in 'srv' mode) and a "client" instance (running in 'cli' mode). The "client" instance listens for incoming TCP connections and forwards every socket through the Bonfire link, so that it comes out of the "server" instance.

This also means Bonfire allows multiple simultaneous connections, including to different final targets, even from different clients.

The link is setup for a given DOMAIN, which can be different things depending on the PROTOCOL. Bonfire currently supports the following protocols:

  • dns - DOMAIN is an actual domain name for which the server should be the authority
  • icmp - DOMAIN is any name or IP address at which the server can be reached

When run in client mode, Bonfire listens for TCP connections on CLI_LSTN_ADDR:CLI_LSTN_PORT. Any connection that comes in will cause a channel to be opened with the server via the defined PROTOCOL. At the other end, the server will open a client TCP socket and connect to whatever the channel's client has defined as TARGET_ADDR:TARGET_PORT. All communications from the server's 'client' socket are then transported over the channel to the client's 'listener' socket, effectively bridging the two.

Multiple clients can use the same server, allowing for different target destinations. Care must be taken however, as each client must use a different transaction ID (TX_ID). This should be automatic in most cases, as the TX_ID is random by default. However if collisions do occur, unique TX_ID values can be manually set via command-line arguments.

Run anywhere

Built using cross-platform C, Bonfire runs equally well on Windows and Linux systems. In most cases, no admin privileges are required.

Indeed, using the DNS protocol requires no extra privileges for running either the client or the server (though running the server on port 53 obviously will require admin privileges).

For ICMP, admin privileges are only required on Linux. However, the ICMP server mode is not supported on Windows, due to its network stack being a bit more finicky. With ICMP the general scenario is to run a Linux server (as root) and then run a client on either Linux (as root) or Windows (as normal user).

Built-in security

If the server is exposed to untrusted networks such as the public Internet, care should be taken to avoid unauthorized access and abuse.

For this purpose, all communications can be encrypted using AES by providing a matching 256-bit security key on the server and client(s) via the -k argument. Additionally, a custom initialization vector (IV) can be set using -i.

Free & open source

Bonfire is entirely free and open source.

Binaries for the current stable version are available for download here:

The full source code can be obtained here: bonfire-1.1.0.tgz

Usage

Below is the complete help, which can be obtained by running the tool without any arguments:

Usage: bonfire [options] MODE PROTOCOL DOMAIN
Bonfire - Multi-Protocol Covert Channel

Bonfire encapsulates TCP communications within various other protocols to bypass network restrictions and monitoring.

A Bonfire link is setup by running one instance in 'srv' mode (typically on a server) and another in 'cli' mode (usually your client / workstation).

The link is setup for a given DOMAIN, which can be different things depending on the PROTOCOL. Bonfire currently supports the following protocols:

 * dns - DOMAIN is an actual domain name for which the server should be the authority
 * icmp - DOMAIN is any name or IP address at which the server can be reached

When run in client mode, Bonfire listens for TCP connections on CLI_LSTN_ADDR:CLI_LSTN_PORT. Any connection that comes in will cause a channel to be opened with the server via the defined PROTOCOL. At the other end, the server will open a client TCP socket and connect to whatever the channel's client has defined as TARGET_ADDR:TARGET_PORT. All communications from the server's 'client' socket are then transported over the channel to the client's 'listener' socket, effectively bridging the two.

Multiple clients can use the same server, allowing for different target destinations. Care must be taken however, as each client must use a different transaction ID (TX_ID). This should be automatic in most cases, as the TX_ID is random by default. However if collisions do occur, unique TX_ID values can be manually set via command-line arguments.

If the server is exposed to untrusted networks such as the public Internet, care should be taken to avoid unauthorized access and abuse. For this purpose, all communications can be encrypted using AES by providing a matching 256-bit security key on the server and client(s) via the -k argument. Additionally, a custom initialization vector (IV) can be set using -i.

When using the DNS protocol, the actual server to which requests are sent is picked up from the system configuration by default. UDP port 53 is also used by default. These can be configured via command-line arguments (-n / -P).

Options:

 -a CLI_LSTN_ADDR When in client mode, listen on address CLI_LSTN_ADDR for connections (default: any)
 -p CLI_LSTN_PORT When in client mode, listen on port CLI_LSTN_PORT for connections (default: 8333)
 -d TARGET_ADDR When in client mode, use TARGET_ADDR as final destination address (default: 127.0.0.1)
 -D TARGET_PORT When in client mode, use TARGET_PORT as final destination port (default: 22)
 -n DNS_SRV_ADDR When using the DNS protocol, use DNS_SRV_ADDR for lookups (default: whatever system is using)
 -P DNS_PORT When using the DNS protocol, use DNS_PORT for requests / responses (default: 53)
 -q DNS_QTYPE When using the DNS protocol, use DNS_QTYPE as query type (allowed: TXT, MX, NULL - default: TXT)
 -x TXID When in client mode, use TXID as transaction ID (default: random)
 -w TIMEOUT When in client mode, set message wait timeout to TIMEOUT ms (default: 1000)
 -r RETRY_COUNT When in client mode, set message retry count to RETRY_COUNT (default: 10)
 -c CNCT_TIMEOUT When in server mode, abort connection attempts after CNCT_TIMEOUT seconds (default: 3)
 -C CHAN_TIMEOUT Drop channels after CHAN_TIMEOUT seconds of protocol inactivity (default: 30)
 -k SEC_KEY Secure communications using AES with SEC_KEY (default: no security)
 -i SKEY_IV When using AES, use SKEY_IV as initialization vector (default: b0nf1r3_s3cur1ty)

Report bugs to <eresse@dooba.io>.

IMPORTANT NOTE: THIS IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED.

NO HELP OR SUPPORT WILL BE PROVIDED OTHER THAN THIS PAGE.

IF YOU ARE DOWNLOADING THIS, IT IS ASSUMED YOU KNOW HOW TO USE IT AND WHAT YOU ARE DOING.

THAT BEING SAID, YOU ARE REQUIRED TO OBEY THE LAW AND ARE PROHIBITED FROM USING RINGTAIL PRODUCTS FOR ANYTHING OTHER THAN LEGITIMATE PURPOSES.

RINGTAIL WILL NOT BE HELD RESPONSIBLE FOR ANY DAMAGE CAUSED AS A RESULT OF USING OUR PRODUCTS.