Previous: 1 Introduction
Up: Securing 'Classical IP over ATM Networks'
Next: 3 Solutions
The model for the following security analysis of a ``Classical IP over ATM'' (CLIP) LAN consists of two logical IP subnets (LIS) connected to each other by a firewall. The firewall is used to divide the LAN into a critical subnet containing valuable data called the ``internal network'' (192.168.15.0) and a public subnet connected to the world called the ``external network'' (192.168.16.0). The TCP/IP traffic between the networks is examined by the firewall. The type of services provided and the access control policy enforced by the firewall will not be discussed here. Currently no ``native ATM'' applications need to be supported, but the concept must not prohibit extensibility.
One possible setup for the above requirements is shown in figure 1. This configuration has two major drawbacks. Firstly, it does not allow for the possibility of running a ``native ATM'' application using both of the networks, as the firewall only provides TCP/IP services. Secondly, as this configuration requires the use of two ATM switches, expensive equipment is wasted.
Figure 1:
Gateway-Firewall in an ATM Network
As ATM allows for multiple virtual networks on the same physical network (i.e. on the same ATM switch) a similar setup can be built with just one ATM switch (see fig. 2).
Figure 2:
Gateway-Firewall with one ATM Switch
The configuration of multiple virtual networks using one ATM switch is a simple task, but configuring this setup in a secure mode requires a deep analysis of the associated risks. The configuration with one ATM switch allows ``native ATM'' traffic to bypass the TCP/IP firewall. Unfortunately, ``native ATM'' connections can also be used to send IP datagrams. By circumventing the local Classical IP stack an attacker can send IP datagrams to systems in the other virtual network without traversing the firewall. The associated security risks and possible solutions are discussed in the following sections.
IP spoofing attacks have been well understood for many years [2]. Essentially, IP spoofing means sending IP packets with faked IP source addresses. Services that use IP source addresses for authentication can be easily exploited by this attack.
IP spoofing is possible in `Classical IP over ATM' (CLIP) networks. Whenever the ATM address of a server is known, an attacker can establish a direct ATM connection to that host. The attacker can now register with the IP address of a trusted host by sending a carefully crafted `InATMARP-Reply' message over this connection. After successful registration, spoofed IP packets can be sent over this connection. Moreover, due to the ``ATMARP-Cache poisoning'', the attacked server will send reply packets back to the attacker on the same ATM connection.
This kind of attack is possible, because the peers do not authenticate each other in a reliable manner. Moreover section 6.4 ATMARP Client Operational Requirements of RFC 1577 [10] explicitly requires, that CLIP clients process 'InATMARP-Requests' and 'InATMARP-Replies' in order to update their local address resolution tables.
In contrast to legacy LANs (e.g. Ethernets) there is no need to attack the host whose address has been used. Because the server sends its segments over the virtual connection to the attacker, the trusted host will not notice that its address has been used by another system.
Furthermore there is no need for the attacker to guess the TCP sequence number of the server. The server will use the established virtual connection to send its segments to the attacker. So all other packets destined to the trusted host will also be sent to the attacker (see also section 2.3).
In summary, IP spoofing is easier to accomplish in ATM based networks and harder to detect. It can also be considered more dangerous, as simple countermeasures, for example requiring an IDENT [9] query before access is granted, can be spoofed more easily than in ``legacy networks''.
The figure 3 shows the time-sequence diagram of a successful simulated attack in a test environment. The attacker (A) pretends to be the host (192.168.15.A) and registers itself by sending an `InATMARP-Reply' to host (B). In order to verify that the spoofing is successful, an `ICMP-ECHO-Request' is used to test the established connection.
Figure 3:
ATM based Spoofing Attack
It should be noticed that the attack is not detectable unless the host (B) verifies the 'InATMARP-Reply' by contacting a trusted ATMARP server (see section 3.1 for a discussion on securing the ATMARP server).
This attack is not restricted to hosts in the same LIS. Any host to which a direct ATM connection can be opened can be attacked. Routers that connect different LISs can be bypassed if the underlying ATM network allows for a direct ATM connection between hosts in different LISs. It is therefore important to point out that filters in these routers cannot be used to protect against this type of IP spoofing attacks. Neither a firewall nor an inter LIS router will have access to the datagrams because all hosts of the same LIS always use direct (non routed) connections. Moreover if the attacked host subsequentially wants to open TCP connections to the host (e.g. an IDENT query [9]), the address of which has been used for spoofing, a typical implementation will use the established virtual connection to the attacker. This would also enable the attacker to perpetrate `Man in the Middle' attacks.
The attacker may now register itself with any unused IP address of the LIS. As every IP address can only be registered once, this will prevent hosts that were temporarily offline from registering themselves, if the attacker succeeds in allocating their IP address. The LIS member will be unable to use CLIP services as long as its IP address is registered with the attacker. Moreover the attacker may wait for clients to go offline by periodically verifying if a learned binding is still in the ATMARP servers cache.
Instead of reserving a random IP address in the subnet, the attacker only reserves the addresses of those LIS clients which are known to be temporarily offline. This puts the attacker in the position of being able to perpetrate very efficient attacks. Some additional aspects of ATMARP server based denial of service attacks are discussed in [1].
This kind of attack is possible, because any host that is able to establish an ATM connection to the ATMARP server, may register various <IP address,ATM address> bindings without authentication. An attacker only needs the ATM address of an ATMARP server in order to establish a virtual connection. Since the ATM address of the attacker is not used for path finding during signaling, the attacker may select any ATM address during connection establishment with the ATMARP server. This makes it even harder to trace the origin of an attack, as the address information in the ATMARP server cannot be trusted.
Moreover this kind of attack is hard to trace. The reservation of resources is a common procedure in ATM networks so that each intermediate switch may have to refuse the establishment of a connection due to insufficient resources. If a switch refuses the establishment of a CBR or VBR CLIP connection, the client host cannot detect whether this is due to normal protocol processing or vicious bandwidth allocation. There is also no way to deduce an attack by bad performance over an unspecified bit rate (UBR) connection since the throughput of an UBR connection may degrade at any time due to normal resource allocation in an ATM network.
A problem arises by the fact that ILMI does not provide a mechanism for the authentication because the underlaying SNMP only uses clear text pass phrases as a weak authentication mechanism. Moreover the community name to access the ILMI management information base (MIB) is specified as `ILMI' [13, p. 147]. An attacker who does not need to authenticate himself can use the ILMI to register additional ATM addresses for his workstation. By using the additional registered address the attacker can bypass address filters which have been configured at the switch. The attacker could also try to register himself with the ATM address of an offline workstation. This is similar to the attack described in section 2.2. ILMI can also be used to automatically configure the interface type of an ATM switch-port. An attacker may use ILMI to pretend that he is a switch by setting the interface type to ``NNI'' (Network to Network Interface).
In order to attack the switch the UNI signaling has to be changed to NNI signaling. This has to be done prior to attacks on the switch to make sure, that the switch will recognize the P-NNI protocol as this will be used by the attacker.
We will briefly discuss a possible strategy an attacker could use in order to prepare for the attack on a switch (see the following section). In typical ``Plug and Play'' installations it is likely that the attacker's host is connected to an ATM switch that uses the ILMI protocol for automatic configuration. The host has already been detected by the switch and the interface (port) of the switch is configured for UNI signaling. In order to change the interface from UNI to NNI it is sufficient to use the following ILMI mechanisms:
Attacks based on the P-NNI protocol can use replies to `HELLO' messages of a peer group leader to inject malicious information about `link states'. The peer group leader in turn will broadcast these changes to its group members. Peer group members that have updated their link state information with faked information are likely to make the wrong routing decision.
Carsten Benecke, Uwe Ellermann / DFN-FWL