Thoughts on Extended Access Lists

                      v1.00 10/02/2000 (c) codex@bogus.net


Introduction()
--------------

I am assuming the reader is familiar with the term "access list" (ACL). If 
not, I advise you to go to http://www.cisco.com and search for documentation
there.

This document is a collection of thoughts around possible ways of exploiting
this form of packet filtering.

I will also disclaim something straight away. This document is in no way
trying to "bad mouth" Cisco; at worst it may feel like a hoof in the pods
to those people who use Cisco routers this way as a firewall.

If anyone has written about this before, let me know. I don't think I'm unique
in thinking this way, but I have certainly never read it anywhere. If I'm
full of the proverbial crap, be kind.


Main()
------

The "extended access list" is Cisco's way of allowing filtering on protocol
and port level.

A trivial (and not very functional) example;

    Router#conf t 
    Router(config)#access-list 110 permit udp any eq domain any 
    Router(config)#access-list 110 permit 192.168.5.0 0.0.0.255 any
    Router(config)#access-list 110 deny ip any any log
    Router(config)#int serial0
    Router(config-if)#ip access-group 110 in
    Router(config-if)#end
    Router#

The above would allow the following incoming traffic on serial0 of a router;
any UDP packets with source port 53 and any packet with a source address of 
192.168.5.0/24. Everything else is denied and logged.

This may not seem very interesting, but it is just to illustrate the point
that several criteria can be used to permit or deny inbound (or outbound)
traffic.


EstablishedSessions()
---------------------

Cisco has also another configuration option available, namely that of the
"established" sessions. The idea is that only traffic that originates from
the inside may be allowed to open TCP connections.

For example;

    Router#conf t
    Router(config)#access-list 120 permit tcp any any established
    Router(config)#access-list 120 permit udp host 192.168.0.1 eq domain any
    Router(config)#access-list 120 permit udp host 192.168.8.1 eq domain any
    Router(config)#access-list 120 deny ip any any log
    Router(config)#int eth0
    Router(config)#ip access-group 110 out
    Router(config)#end
    Router#

The above example assumes that serial0 is your outside interface, and that
Ethernet0 is the internal interface. It also assumes that Serial0 has no
access-group enabled.

The above example allows the following traffic; UDP with source port 53 from
hosts 192.168.0.1 and 192.168.8.1 (we presume these are "trusted" domain
servers), and it also permits "established" sessions.

IOS regards any inbound packets without the SYN bit set as an "established"
session. In effect, no outside connections may try to establish a TCP 
handshake with a host on the inside.


BadLogic()
----------

So why is it dangerous to trust this configuration? 

The answer is that too many people think that it can be a substitute for a
firewall. It is better than no protection at all, but it is NOT a substitute
for a good firewall. IOS does not keep track of outbound connections like a
firewall does. It does not use a "state table" to control flows.

Below outlines two attacks on access-list 120.


Attack(One)
-----------

First, assume you are able to deploy a new form of BackOrifice[1] on the 
target LAN, which either hacks the target host's TCP/IP stack, or puts the 
NIC in promiscuous mode.

This version of BackOrifice listens for ACK packets with a special signature.
These ACK packets contain the payload to drive the BackOrifice server.

ACK packets are allowed through access-list 120, because the criteria for
"tcp established" packets is that the SYN bit must not be set.

RST or FIN packets could probably be used too, but I am assuming there is a
better chance for bigger payloads in ACK packets.

The ACK packets do not need to be targeted directly at the host backdoored
with BackOrifice, only to the network where it resides (assuming the host
doesn't reside on a switch). Perhaps this is more stealthy?


Attack(Two)
-----------

Right. UDP has been covered before[2], but here we go again; we could forge a
UDP packet containing the source address of one of the trusted domain name
servers, which, for example, contains the real source address and the command
to execute.


Conclusion()
------------

When I have something clever to write here, I will add it.

--
[1] BackOrifice is a product of Cult of the Dead Cow.
[2] http://www.phate.net/docs/security/shared-firewall.txt