ACK Tunneling Trojans

ACK Tunneling Trojans

– Arne Vidstrom, arne.vidstrom@ntsecurity.nu
Summary

Trojans normally use ordinary TCP or UDP communication between their client and server parts. Any firewall between the attacker and the victim that blocks incoming traffic will usually stop all trojans from working. ICMP tunneling has existed for quite some time now, but if you block ICMP in the firewall you’ll be safe from that. This paper describes another concept, that I call ACK Tunneling. ACK Tunneling works through firewalls that don’t apply their rule sets on TCP ACK segments (ordinary packet filters belong to this class of firewalls).

A short description of TCP and the way firewalls handle it

TCP is a protocol that establishes virtual connections on top of IP. A session is established when the client sends a SYN (synchronize) segment, the server responds with a SYN/ACK segment, and the client confirms with a ACK (acknowledge) segment. All traffic in the following session consists of ACK segments.

Ordinary packet filtering firewalls rely on the fact that a session always starts with a SYN segment from the client. Thus, they apply their rule sets on all SYN segments, and simply assume that any ACK segments are part of an established session. More advanced firewalls apply their rule sets on all segments, including ACK segments. Some firewalls are configurable, so you can choose between the two ways to handle ACK segments. The reason to configure a firewall not to apply the rule set on ACK segments is work load. While a session can contain thousands or millions of ACK segments, it only contains one SYN segment. This way you can decrease the work load on the firewall considerably, and save money on expensive hardware. Remember, you cannot establish a TCP session against an ordinary system through any of these two kinds of firewalls if they are set up to block incoming connections.

When ACK Tunneling can be applied

Consider the following case. You have a firewall that doesn’t apply its rule set on ACK segments. The rules are to block UDP and ICMP completely, to block all incoming TCP connections, and to allow all outgoing connections. Also to block any other protocols. The attacker sends a trojan by mail to a user on the inside of the firewall. The user runs the trojan.

Now what? How can the attacker on the outside contact the trojan on the inside? There are at least two ways. Either the trojan makes a connection to some computer on the outside, and accepts commands and sends the results through this connection. There are problems with this solution. First the attacker has to have a static IP. If the attacker doesn’t, he/she might for example upload the dynamic IP each time it changes to a web server that the trojan contacts every now and then to find the attackers IP. Either way the trojan now contains an address that points part of, or all of the way to the attacker. If the trojan is discovered and analyzed it can be used to trace the attacker.

Enter ACK Tunneling. The client part of the trojan uses only ACK segments to communicate with the server part, and vice versa. Now the segments pass straight through the firewall. As long as the attacker knows the IP of the target system, it doesn’t matter if his/her own IP is dynamic. And even if the target IP changes with time the attacker could use a special scanner to scan for the trojan, straight through the firewall. Phear! 😉

The trojan doesn’t have to contain any link to the attacker. And the person connecting to it might not even know who sent the trojan to the user. It would be just like scanning for NetBus over a whole network hoping it’s running on some of the systems. Of course the attacker might be traced through sniffing and tracing the ACK segments. On the other hand there is a great possibility that the firewall won’t log these even if it’s configured to log all outgoing connections, because it probably only logs the starting SYN segment.

A working example trojan

I’ve coded a working example trojan for Windows 2000, called AckCmd. It’s simply a remote Command Prompt, but the concept could be extended to create a new protocol on top of TCP ACK segments that can have the same features as TCP does. One could also extend it to proxy connections through the server component to other systems on the network behind the firewall.

AckCmd sends from port 80 on the client side to port 1054 on the server side. I’ve chosen those ports because even if everything is blocked in the firewall, except the possibility for those on the inside to surf the web, the communication will still work.