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 perimeter 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).