cisco-ack-proof-concept.txt rev 1.2 (c) 24/05/2000 codex@bogus.net

THIS IS A PHATE RELEASE. THIS IS COPYRIGHT. KEEP YOUR HANDS CLEAN AND YOUR 
MOUTH DIRTY, YOU WILL GET FAR.

The complimentary code is available at:

        http://www.phate.net/progs/cisco/established-poc.tar.gz


What?
-----

Um, exactly.

This is (probably) not Rocket Science(tm), but since I've been pondering about
it for a long while, and not seen anything about it, I thought I'd spend some
time writing a document and also provide some code (which works).

This document contains details on a proof-of-concept on how to circumvent
Cisco access-lists which rely on only permitting "established" TCP sessions.

This document does not cover access-lists used by the Firewall feature set.

This document is in no way trying to "diss" Cisco in any way shape or form, it
only seeks to highlight a potential security hole in some perimiter defenses.

(Quite a few networks rely on the protection described herein.)

For demonstration purposes, the network overview is defined as seen in fig. 1.

                                (ISP/Internet)
                                      |
                                      |(e0)
                                +-----------+
                                | Cisco-GW  |
                                +-----------+
                                    .1|(e1)
                              --------+--------
                          non-RFC1918 address space


                                   figure 1


Why?
----

I wrote this because a lot of sites are using a Cisco router which doubles as 
a "firewall" by only allowing "established" sessions in from the outside.

Please note that if other routers or "firewalls" use the same technique, they
could be vulnerable to this too. Cisco IOS routers defines what I know about
routers, so you probably want to check what your vendor is up to.


What are "established" sessions?
--------------------------------

An "established" session is only applied to TCP. The idea is that if a session
starts from the inside, the return packets are part of the same session 
(henceforth "established") and are let through. The following list is an 
example of an access-list which relies on "established" protection:

    ip access-list extended INCOMING
    permit tcp any any established               ; allow established sessions
    permit udp ISP.DOMAIN.SERVER.IP domain any   ; allow dns traffic from isp

The access-list INCOMING is placed on interface Ethernet0:

    interface Ethernet0
    ip access-group INCOMING in

Together "no ip directed broadcast", the idea is that this will protect the 
network against a number of attacks, such as

    1) attacks on internal services using UDP, TCP or ICMP, i.e.
       - portscans
       - SYN floods
       - host discovery
       - denial of service (e.g. "ping of death")
       - trojan horse installations (e.g. Back Orifice)
    2) "smurf" amplification
    3) protection against unwanted services on employee workstations, e.g.
       file servers
       
There are probably many more, but hopefully the idea is conveyed. 


How does it work?
-----------------

A packet is marked as "established" if the SYN flag is not set. That is all.
In other words, if a packet has ACK or FIN (or RST) set, it will pass through
the access-list INCOMING, defined above.

(In other words, just because I decided to use the ACK flag, any combination 
of the URG,PSH,ACK,RST and FIN flags can be used.)


Attack!
-------

Well, now that we know what an "established" session really means, we should
start thinking of ways to attack it. Luckily, I am sitting on a train to
London with very little else on my mind, so here are my thoughts on the 
matter.

A little summary first (this is probably for more for my benefit, as I need
to write the code later).

    1) ACK packets are allowed through the access-list
    2) NAT may be in operation

If NAT is in operation, this tool will unfortunately not work. All that gets 
passed through to the other side is a TCP packet with no payload and the RST
flag set.


So how do we do this?
---------------------

We devise two tools. One sends packets (TOOL-A), the other receives them
(TOOL-B). TOOL-B must be installed on the target network. 

In stating that, it must now be clear that our proof of concept WILL NOT WORK
without:

   1) willful installation of TOOL-B
   2) deceptive installation of TOOL-B

A "willful install" covers an employee who doesn't like the strict access-list
policy. He wants access to his desktop files from home, damnit!! (Well, he
could have, if the tools supplied with this document contained any "useful"
features.)

A "deceptive install" covers any means of making sure that TOOL-B is installed
without the receiver knowing it. Much like sending an attachment such as
Back Orifice in an email, showing some dancing pigs when the receiver 
double-clicks on the attachment, while secretly installing the back door. This
relies on stupidity, of which there is plenty.


Notes on the supplied code
--------------------------

Also see separate paper contained in the tar file.

The tools (TOOL-A, TOOL-B) are written with Linux in mind. There is no real
reason why this couldn't be ported to, say, Microsoft Windows(tm). 


Description of packets
----------------------

The following data should be contained in the packets, in some form or
another. This could be encoded, encrypted, or in plaintext. In this proof
of concept code, we use plaintext.

    - TCP datagram, ACK set
    - source address
    - destination address
    - address of TOOL-A
    - address of TOOL-B
    - payload (in this case, just a text message)

We can use the address of TOOL-A and TOOL-B encoded in the packet to 
circumvent other access-restrictions. For example, consider the following 
diagram (fig. 2):

                   +----------+ W.X.Y.Z
                   | Attacker |------(Internet)
                   +----------+           |
                                          |
                                          | A.B.C.D
                                    +-----------+
                                    | Target-GW |
                                    +-----------+
                                          |.1
                               -----------+----------+-----
                                  non-RFC1918/24     | .254
                                                 +--------+
                                                 | Victim |
                                                 +--------+

                                  figure 2
 

Networks configured with non-RFC1918 (public) address space can be attacked 
using a fully  spoofed source address; only the IP destination (dst) address 
needs to be on the inside of the network.

I thought future versions of this code could contain the "real" source and
destination addresses encrypted within the TCP payload (the "TOOL" data).

For example, if the packet is sent to a bogus adress on the inside, it would
still be picked up by the correct TOOL listener if the machine existed on a 
non-switched network. This could be used, perhaps, to obscure which host 
had the listening tool installed.


The TOOLs
---------

While contemplating this, I decided that TOOL-A and TOOL-B should be two small
programs; one "listener" and one "writer" for fixed length messages. 

Other implementation ideas include:

    - password sniffer
    - file grabber
    - DoS attack amplifier (very lame, but the possibility is there)
    - "remote administration tool" (read: trojan horse)

Oh, and you need to be root to run this tool.


More ideas?
-----------

Send us some.


-codex 22/05/2000

Hi to the SPIES gang. Also, Maelstrom and Fake. The dynamic duo and the rest
on #!el8. Oh, and the man with the broken Palm (er, well, when I am around, 
anyway).









