ACK
Tunneling Trojans
- Arne Vidstrom,
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.