hiding traffic from network administrators
So far all the techniques we were using deployed hiding network connections, but anyone can reveal “wrong” traffic on physical level with sniffers and similar defense mechanisms. Hackers made their effort and invented covert passive channels which transfer useful information without generating any traffic. Source code is released, and now we have to realize how to screw it into our keyloggers or remote shells. This is what we are going to do now, but first we have to RTFM
It isn’t enough to put shellcode into remote machine and stake out backdoor there. It’s only half of process. Do we realize what our next step shall be? We have to hide our IP address and bypass any firewall we have to, without leaving a single trace in logs. They can be analyzed either by IT stuff or automatic IDS’s, and there are too many IDS’s by now.
There are also many traffic-hiding utilities, although it is easy for firewall systems to detect and block any kind of “hackerish” traffic. No attacker should let it happen. This would be such a bummer. That’s not healthy either.
Ideally, we have to create a secret communication tunnel, and it must not create any excessive connections or produce any traffic. So we can be sure no traffic dumps taken by tcpdump can reveal something suspicious.
At first, this idea had only theoretical lab implementation(Andrew Hintz, Craig Rowland). It couldn’t be used in practice. After that, Joanna Rutkowska developed NUSHU protocol, and released source code for quite deployable Linux 2.4 modules. She promised to port it for xBSD and NT systems. It has been 5 years since her promise, and nothing yet happened.
But there’s little reason to get sad. Anyone willing to port code can do it on his own. The only important thing is Joanna gave us a powerful weapon for remote shell control that has no adequate defense against.
Now we should only take care to learn how to use that weapon. Some users already made their statement ‘we push every button but the damn thing doesn’t even boot’.
Passive Covert Channels: conception
Very recently hackers added Passive Covert Channels(PCC, in short) term to their vocabulary. It is derived from Covert Channels(CC, in short). They are different only in the way they work: the former neither set up “their” connections nor generate any traffic at all! Information transmission is performed via modification of traffic passing by an attacked node.
The point is those packets never go directly to the hacker, but roam around the Internet till their destination, www.google.com for example. It helps achieve strong anonimity. How can a hacker receive packets bypassing his machine? For this he must hack any router on the traffic’s way(usually those are controlled by victim’s ISP) and install the special TCP/IP header parsing module. Its purpose is watching for, and injection of encoded information inside the traffic.
With this method, a hacker can establish duplex passive covert communication channel with victim relay. He achieves both hiding “wrong” information transmission, and anonymizing his IP address. The only person who can see his IP is the hacked router’s owner, while the victim endpoint cannot!
The hacker X introduces his own way we shouldn’t discuss here, to take over the target computer A with his shellcode. It takes control over target computer and embeds backdoor in it, it also contains our PCC protocol’s implementation module. Now all TCP/IP packets sent out by victim are changed a bit to contain information a hacker wants to retrieve, i.e. passwords and other confidentional information.
These packets are routed via router B, which was preliminary taken over by hacker who also injected his PCC module for TCP/IP header analysis. The module is watching for “hidden content”; if there is any, it decodes it and sends to the hacker via an open channel.
The way the hacker’s commands are transferred to his victim is similar to what we discussed above. PCC router module looks for packets with the target IP address and modifies their headers according to the preferred encoding method.
Thus, we developed the protected channels of A-B and B-X. Note that hacker can always connect to B node via anonymous proxy server. He can even build his own chain of servers. Also, he is free to choose any router on the victim traffic’s way as B node, as long as the preferred node is situated between A node and C node.
our cab - IP protocol
Let’s take IP protocol and try to make IP-based PCC. Among a variety of useful and not-so-much useful IP header fields, we turn our attention to the 16-bit “Identification” field. It is filled by operating system with random value, and is used for datagram identification when it is fragmented. The receiving node groups together fragments with the same IP source/destination pair, protocol type, and identificatior field, of course.
RFC doesn’t define standard for the identification field generation. Some operating systems use timer for this, others set ID field as it is in corresponding TCP segment. The latter gives slightly better performance results when OS starts TCP segment retransmission because IP packet uses the same ID as TCP segment.
PCC module can modify ID field as it wishes to transmit useful data of 16-bit length. This is the theory. In practice we have to devote several bits to check if IP packet is “ours”. 12 lower bits can contain useful data, 4 higher bits should contain useful payload checksum. PCC receiver can calculate CRC for 12 lower bits and compare the result with 4 remaining bits. If the values are equal, then it is our data, otherwise we can let it go.
We have to also care about numeral ordering of packets because normally IP packets don’t have the same sequential order numbering as they did upon their transfer. For this we need spare bits of data, so the real informational payload of IP header is equal to 1 byte. This is not so bad. It is enough for sending small data amounts. Don’t forget that IP ID has to be both unique and random-looking. For this we have to apply pseudorandom data sequence(key) with XOR operator over plaintext. The key is known to PCC sender and PCC receiver.
We can also change TTL, TOS and protocol fields. Caveat emptor: it is easy to notice for tcpdump and other sniffers when analyzing dumps.
our cab - TCP protocol
During TCP connection establishment, the endpoint who wishes to set up connection, node A, toggles SYN flag and chooses random 32-bit sequence number, or SEQ. If the other endpoint, node B, is willing to make connection with node A, it sends TCP segment with ACK flag and acknowledgment number of SEQ+1. The second node generates its own random SEQ. After receiving acknowledgement, node A does the same thing. The following scheme shows the overall algorithm:
node "A" ------ SYN(ISN) -----------> node "B" node "A" <----- SYN(ISN+1)/ACK ------ node "B" node "A" ------ ACK ----------------> node "B"
TCP connection establishment order
ISN is the Initial Sequence Number unique for any TCP connection session. After connection establishing, sequence numbers increase for value of sent/received bytes. That’s enough of theory now.
The 32-bit ISN field can be changed with XORing by hidden data and… no one will notice it! Obviously, connection bandwidth loses 4 bytes for every TCP session created by the victim computer, supposing we won’t see a lot of TCP connections(especially if we hacked workstation and not the server).
Anyway, so little bandwidth is enough to transmit passwords for terminal sessions.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP header layout
Joanna Rutkowska decided to work on practical implementation rather than experimenting in lab. She developed the NUSHU protocol that creates PCC via ISN modification with DES encryption. The algorithm encrypts ISN based on IP packet’s ID, TCP source port, and the destination endpoint’s ID address.
practical magic session
We can see “tools” section on Joanna Rutkowska’s site, find “NUSHU — passive covert channel engine for Linux 2.4 kernels” and download source code archive http://invisiblethings.org/tools/nushu/nushu.tar.gz, with README file - http://invisiblethings.org/tools/nushu/readme.txt.
Unpack and build it. We have to use “make” utility. After that we get three kernel modules: nushu_receiver.o, nushu_sender.o and nushu_hider.o(if compilation fails, that means there’s something wrong; before spamming Rutkowska with ranting, it’s worth to take some time and read good FAQ on kernel module building, and to RTFM hacking xBSD kernel)
The receiver should be set inside hacked router, the sender is set up on victim computer. To conduct duplex communication, it’s necessary to set up both receiver and sender for both nodes. The module of nushu_hider.o doesn’t take part in PCC communication, its purpose is hiding the fact ISN was changed from tcpdump-like sniffers.
As you can see in README, the sender module can process the following command flags:
- dev =
, network device, i.e. eth0, ppp0, etc;
- cipher = [0|1], 0 - disable encryption, 1 - use DES;
- key = “string”, used only with encryption mode turned off;
- src_ip=<ip_where_nushu_sender_is_placed> - the IP address of the computer with the sender module installed;
The receiver module takes the same parameters as above except src_ip, instead there is exclude_ip. It specifies the list of “untouched” IP addresses, with NUSHU protocol disabled when receiver starts transmission back to them, so ISN doesn’t change.
The nushu_hider.o module doesn’t provide command-line arguments.
OK! All modules are loaded, the kernel is still working, and it doesn’t seem to panic. What’s next? Nothing!!! This was just an engine for PCC functionality. We can screw in keylogger or remote shell, but we have to do it on our own. How?! No readme’s or presentation slides can answer this question, so we have to dig in the source code and tear it apart into bytes.
Let’s start with sender in sender.c. In init_module() function we can see the following code lines:
struct proc_dir_entry *proc_de = proc_mkdir ("nushu", NULL); create_proc_read_entry ("info", 0, proc_de, cc_read_proc_info, NULL); struct proc_dir_entry * wpde = create_proc_entry ("message_to_send", 0, proc_de);
Listing 1, the crucial fragment of init_module() in sender.c
The module uses /proc filesystem to create “nushu” directory with two files in it: “info” and “message_to_send”. The OS interacts with them as if they were normal devices(actually, pseudodevices; this is not important for now).
The same goes for receiver:
struct proc_dir_entry *proc_de = proc_mkdir ("nushu", NULL); create_proc_read_entry ("message_received", 0, proc_de, cc_read_proc_message, NULL); create_proc_read_entry ("info", 0, proc_de, cc_read_proc_info, NULL);
Listing 2, the crucial fragment of init_module() in receiver.c
There is “message_received” instead of “message_to_send”, we can read new messages from here with standard I/O functions.
Joanna’s site also has some dumps demonstrating NUSHU functionality: invisiblethings.org/tools/nushu/nushu_dumps_10k.tar.bz2 and invisiblethings.org/tools/nushu/nushu_dumps_100k.tar.bz2.
There are also other ways to do traffic hiding like changing TCP header time stamp. HTTP protocol provides with even greater opportunities for this due to presence of the fields anyone can change without harm for oneself. Changes are easy to detect, though, anyway NUSHU stays the most detection-proof protocol.
Can a computer administrator under attack reveal PCCs at least theoretically? Very scrupulous traffic analysis in fact can lead to discovery of strange ISN distribution anomaly, but there must be thousands of “hacked” packets analyzed to make it happen. They must also be compared to the original unchanged packets. So it is way easier to find out there’s alien kernel module responsible for PCC functionality. Administrator should use common system integrity verification methods, this is another topic we will talk about later.
Comparison table of different transport fields for PCC
|Transport||Bandwidth||Detection difficulty||Noise resistance||Implementation difficulty|
|IP ID||2 bytes||nearly impossible to detect||high||easy|
|TCP ISN||4 bytes for TCP connection||nearly impossible to detect||high||medium|
|TCP Timestamp||1 byte for TCP segment||nearly impossible to detect, except low-bandwidth channels||low||high|
|Reserved fields in TCP header||6 bits for TCP segment||low||low||easy|
|IP TOS||1 byte||low||low||easy|
the sacred meaning of Nü Shu
Nu Shu is a Chinese word that translates literally to “women’s writing”.
Nu Shu was developed approximately in the 15th century in Jiangyong County of Hunan province located in Southeast China. Women of the County developed their own secret language as decorative ornament of twirls for their clothing. This secret was told by mothers to their daughters for generations and centuries, and it was revealed to the masculine public in 1983! This is an amazing conspiracy act!!! While women talk no men can see it!
There is obvious correlation between “women writings” and the NUSHU protocol developed by Joanna Rutkowska to transmit hidden information inside TCP headers, so no admins and other males can see it.