"Centralized firewall" problems by Codex (codex@bogus.net) 11-Oct-1999 version 1.05 (28-Oct-1999) [Document home: http://www.phate.net/docs/security/shared-firewall.txt] DISCLAIMER: This document contains untested ideas, please verify or debunk me. Perhaps this is already old information? In any case, I would like some (constructive) feedback. Introduction ------------ Many Internet Service Providers (ISPs) provide so-called "centralized firewall" services to leased line customers. This document is an attempt to highlight problems which may be associated with such a service. Bear in mind that the ideas have not been tested (yet). So, what is a centralized firewall service? And what is the idea behind such a service? Well, let's talk about the idea first. The "easy" way to add security to a network is to place a firewall between the network to be protected and the open one (the Internet). The problem with this solution is that someone has to spend time watching logs, maintaining rules, apply any patches, and keep the firewall software up-to-date. This costs a lot of time, and in most cases, a lot of money (security professionals are usually not cheap these days). ISPs know this. They also know that it is unlikely that small and medium- sized businesses (SMBs) have the time, money or expertise to invest in such a position. The solution they sell to SMBs is the centralized firewall. The centralized firewall leaves all the log-watching and maintenance to the ISP, and the ISP provides some sort of report if there is an attack, and usually some sort of weekly or monthly summary (SMB executives like to know how "visible" they are on the 'net). Service types ------------- I know of three types of ISP "firewall" services. One of them is not centralized, so will not be covered here (remote maintenance, where there's a physical firewall at the customer's site, owned and maintained by the ISP). The two other types are based on a "real" firewall (such as Firewall-1) or by using access-control lists (ACLs). The two figures below outline the (usual) configuration for both solutions. Figure 1 describes the solution using a true firewall, and figure 2 a solution using access-lists. The two solutions usually reflect the price of the service. Leased-line customers usually have the benefit of a "true" firewall, while dial-up customers are given the ACL option. {Internet} (5) {Internet} (3) | | +-------------+ +---------------+ | Core router | (4) | Access Router | (2) +-------------+ | w/ ACL | | +---------------+ +-------+ | | | ISDN lines | Fire- | (3) | | | | wall | +------+ | +------+ +-------+ | Cust | | | Cust | ... | +------+ | +------+ +--------+ | | Access | (2) +------+ | Router | | Cust | (1) +--------+ +------+ / | \ Leased Lines / | \ +------+ +------+ +------+ | Cust | | Cust | | Cust | ... (1) | Rtr | | Rtr | | Rtr | +------+ +------+ +------+ Figure 1 Figure 2 As you can see, there is a great deal more hardware involved when involving a firewall than just relying on ACL's on the access router (hence the difference in price). Both setups, however, have the same basic functions. In figure 1, the traffic is only allowed to travel in the following manner: (1) -> (2) -> (3) -> (4) Policy routing ensures that traffic going from the customer _has_ to pass through the firewall, thus prohibiting inter-customer traffic at level 2. In figure 2, one uses "reflexive access-lists" (RACL, introduced in Cisco IOS 11.3) to make sure that traffic cannot pass from one customer to another without passing through the ACL. TACACS+ or RADIUS determines which customer should have this ACL installed (the ACL is defined in the router configuration, not in the TACACS+ or RADIUS configuration file). Depending on the ISP's setup, either a separate RACL will be installed for each customer, or every customer uses the same RACL. This document assumes the latter. It may be possible to use standard (extended) ACLs, but the idea behind RACL is that timeouts are introduced in a kind of "state table". A standard ACL doesn't have this; it validates packets using static rules. For more on RACLs, check out http://www.cisco.com/univercd/cc/td/doc/product/ software/ios113ed/113ed_cr/secur_c/scprt3/screflex.htm (no spaces in this URL). Where is the problem? --------------------- Both the firewall and the router containing the RACL uses some form of "state table". This table defines what packets have left the inside, and usually contains the following information (at least): Source IP Source port Destination IP Destination port The router or firewall determines what packets are allowed through from the outside depending on this table. TCP packets destined for the inside cannot have the SYN flag set (unless specified in the filter rule), and are discarded. UDP packets are not allowed through unless: a) specified in the RACL b) a UDP packet has been initiated from the inside first AND c) the UDP reply has been received within a predefined time limit Timers are used to invalidate UDP "sessions", since there is no way of knowing when a UDP session ends (without looking at the overlying protocol). This sounds innocuous enough if you are the only user of the firewall (this is what happens when you have your own). However, in the above context, several networks share the same firewall, and indeed, the same state table. If we assume that all the customers are Nice(tm), then there shouldn't be a problem. We should be paranoid, though, and consider the following scenario. What if Customer-2 really dislikes Customer-1? In fact, how about Customer-2 (mean.com) dislikes Customer-1 (nice.com) so much that Customer-2 gets in touch with Mr. Evil (evil.org) on the Internet? See figure 3 for a quick situation overview. +----------+ {Internet}----| Mr. Evil | evil.org | +----------+ | +----------+ | RACL/ | | Firewall | +----------+ / | \ / | \ +--------+ +--------+ +--------+ | Cust-1 | | Cust-2 | | Cust-3 | ... +--------+ +--------+ +--------+ nice.com mean.com Figure 3 Staging the attack ------------------ Since they all share the same state table, Cust-2 could inject fake UDP packets containing Cust-1's source IP and Mr. Evil's destination IP. Let's place ourselves in Mr. Mean's shoes and make a coordinated attack on nice.com. First, we call up Mr. Evil, or indeed, we just log into an account at evil.org, that way we don't have to pay anyone to do our dirty deed. Then there are a few ways we can do the next stage. If we know that nice.com is comprised of UNIX machines, we could try exploiting the possibility of poorly configured tftpd(8) servers. Gaining unauthorized files using tftp(1) is a very old attack, as we well know. However, tftpd(8) servers are surprisingly often present on networks that rely on firewalls to protect them. I am quite sure there are some other remote exploits we could use; rpc.statd or rpc.mountd perhaps. tftp(1) is used as an example as it is an easy thing to describe. Anyway. Back to our dirty deed. We send the following spoofed packets from mean.com: src_ip:src_port dst_ip:dst_port 1.nice.com:69 evil.org:31337 2.nice.com:69 evil.org:31337 3.nice.com:69 evil.org:31337 .. .. 254.nice.com:69 evil.org:31337 From evil.org we fire up nmap[1] as root, and tell it to scan for machines 1-254.nice.com using source port 31337 and destination port 69. We (hopefully) get a few results back. It is probably a good idea to start the nmap scan fairly soon after we inject the spoofed packets through the firewall/RACL as the state table won't keep the UDP traffic valid for very long. When we have a list of usable tftpd(8) servers, we fire up our patched version of tftp(1) which will let us issue requests with predefined source ports (in this case 31337). That's about it. The firewall will (if all goes to plan[2]) let the traffic through, and if there are any ill-configured tftpd(8) servers there, we might be able to grab /etc/passwd (or perhaps their gateway-conf[3] files). Another attack -------------- We could also stage an attack against a Windows network, but the attack outlined below doesn't implicitly need mean.com. An attacker from evil.org could do the same attack without having help from the "inside", i.e. there would no need for a port forwarder on evil.org; one could just fire up the BO2K administration software there. (I ran out of ideas here, ok? Perhaps one could stage a NetBIOS attack or something.) Set up a port forwarder on evil.org, which points UDP port 1138 to salesguy.nice.com port 53. Netcat (hobbit@avian.org) can be used for this. 1) Send an email to some of his employees (phone up nice.com's switchboard for the email of a sales person). 2) Send "Dancing Pigs" + BO2K attachment to sales guy. Configure BO2K to use UDP on port 53 (perhaps using this port will not seem too suspicious in any firewall logs, as it could be confused with a regular DNS request). 3) Wait for BO2K to install itself (SpeakEasy or ButtTrumpet will tell us when this has been happened). Send the following fake UDP packet from mean.com: src_ip:src_port dst_ip:dst_port salesguy.nice.com:53 evil.org:1138 Start our BO2K administration software, and connect to evil.org:1138. We should[2] now have control over salesguy.nice.com. Conclusion ---------- Historically, it has been well documented in security papers that UDP is a very difficult protocol to handle securely. Despite this well known fact, more and more applications have been built on this weak foundation. The reasons vary, but the truth is that UDP is a very simple (and fast) protocol to base higher level protocols on. Customers should not rely solely on the protection offered by the ISP when purchasing this type of service. This paper has discussed two attacks against a poorly implemented "centralized firewall", with a few hints towards other attacks. It should be clear that this is a very real threat. Failure to recognize this fact could lead to a very embarrassing compromise. It is imperative that there's some form of spoofing protection in place on the company's border perimeter. In figure 1, this can easily be achieved by using regular ACLs on the Access Router (2). Without having delved too deep into the matter, it is possible that CEF[4] could be used too. CEF, however, does not work on all Cisco IOS routers; consult your manual. If RACLs (figure 2) are used, the ISP can prevent spoofing by using separate RACLs for each customer. This, however, can become a huge configuration issue, depending on how many dial-up customers the ISP has. Addendum -------- It should also be noted that some ISPs also provide a hosting service with "firewall protection". Figure 4 shows a general overview. {Internet} | +--------+ | Router | +--------+ | +----------+ | Firewall | +----------+ | +------+ +--------+ +------+ | Cust |---| Switch |---| Cust | +------+ +--------+ +------+ | +------+ | Cust | +------+ Figure 4 The "Cust" machines are customer servers, with perhaps one or more of the following scenarios: - owned by ISP, customer has no root access - owned by ISP, multihomed, customers have no root access - owned by customer, customer has root access When the machine is owned by the ISP, there is a distict possibility that the ISP will try to confine the customer to a "safe"[5] environment. Usually the customers are separated from each other on a switch with VLANs to prevent them from attacking each other. However, if the theory described above works, there is no reason the tricks described in the attack section shouldn't apply here. -- [1] Infamous scanner written by Fyodor (found at http://www.insecure.org). [2] Of course, as I disclaimed in the beginning, only if this theory works!! [3] "-conf" is the usual extension used by Cisco router configurations. [4] Cisco Express Forwarding (http://www.cisco.com/univercd/cc/td/doc/ product/software/ios112/ios112p/gsr/cef.htm#xtocid262640). A layer 3 switching mechanism. [5] Probably exploitable. Kudos to: Mael, Ob1 Hello to: The SPIES gang (you know who you are), Sluggo, and PHATE.NET. [Writer home: http://www.bogus.net/~codex]