ACK Tunneling Trojans


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.


Stoneheart
stoneheart@1lsn.com
ICQ: 68585330
AIM: ArchMageWM