WO2009011659A1

WO2009011659A1 - Protocol remapping method and method of detecting possible attacks on a network

Info

Publication number: WO2009011659A1
Application number: PCT/SG2008/000253
Authority: WO
Inventors: Konstantinos Anagnostakis; Periklis Akritidis
Original assignee: Agency For Science, Technology And Research
Priority date: 2007-07-13
Filing date: 2008-07-14
Publication date: 2009-01-22

Abstract

Protocol remapping methods are disclosed herein. In a described embodiment, the remapping method comprises receiving a data packet (200) destined for an external network (104), remapping selected control information in the protocol header such as TCP sequence number. The data packet (200') with the remapped protocol header is then transmitted to the external network instead of the received data packet. A method of detecting possible attacks on a network is also disclosed.

Description

Protocol Remapping Method and Method of Detecting Possible Attacks on a Network

Background and Field of the Invention

This invention relates to protocol remapping method and method of detecting possible attacks on a network, more particularly but not exclusively, for a wireless network such as Wi-Fi.

The IEEE 802.11 standard denotes a set of wireless local area network (LAN) standard which includes multiple over-the-air modulation techniques that use the same basic protocol. When a station on a wireless LAN wants to transmit, the station communicates with a base station (or an access point) that functions as a bridge between the LAN and the "outside world". The communication with the access point is based on radio waves as a broadcast medium i.e. when one station transmits, all other station listens. This also means that any station on a wireless LAN can listen to all frames being transmitted in the network - it is simply a matter of having the right equipment and adjusting to an appropriate radio frequency. Thus, wireless networks are inherently open to interception.

The vulnerability of wireless networks also makes them susceptible to spoofing and injection attacks, which are also problems faced by wired, shared Ethernet. The basic idea is that an attacker could monitor the communication between stations on the wireless network or between a station on the wireless network and an external party. If the communication is not properly encrypted, the attacker can elicit session state through eavesdropping and if the communication is not authenticated, he can inject frames to one session endpoint pretending to come from another session endpoint.

Most network and session layer protocols such as DNS (Domain Network System), TCP (Transmission Control Protocol) and DHCP (Dynamic Host Configuration Protocol) can be susceptible to such attacks. In the case of DNS, the attacker can watch for outgoing DNS queries and inject responses pointing to a host under the attacker's control. For TCP the attack is similar - all the attacker needs to know is the current state of the connection in terms of sequence numbers. At connection setup, the attacker may even completely take over the connection by injecting the proper SYN-ACK, resulting in the legitimate endpoint being out of sync. Injection is also possible at any point in the connection as long as the attacker can time injection attempts to properly deliver TCP segments to the victim network stack. The DHCP protocol can be spoofed to have a victim use an IP address and default gateway that gives the attacker full control over all of his traffic. However, it may be less attractive than DNS and TCP spoofing as the attacker has to wait for the victim to refresh his DHCP lease, or else attack only hosts that have connected after the attacker has obtained access to the wireless network.

While in the 90's such attacks were seen as enablers for unauthorized access, in today's threat landscape they are more likely to be used for "modern" attacks such as phishing, spam and exploit injection. DNS spoofing is highly attractive for phishing, as, for example, the attacker may set up a mock banking website that would relay manipulated requests to the real site in a man-in-the-middle fashion. In this case, it should be noted that two-factor authentication is unlikely to help. Similarly, TCP injection can be used to insert redirection instructions, advertisements, or spam to seemingly legitimate Web pages. Sophisticated attacks can even subvert user's online services, such as using a victim's e-mail account, etc.

To address the above threats, wireless security measures such as the Wired Equivalent Privacy (WEP) and the subsequent Wi-Fi Protected Access (WPA) and WPA2 with stronger encryption and hard-to-guess passwords have been implemented. Unfortunately, despite the wide availability of such techniques, users do not seem to employ them. Even if this is simply because there have been no large-scale attacks yet, the use of passwords hinders usability and robustness. It is likely that even if such measures are implemented, in many cases the passwords are not going to be strong enough to resist brute force attacks. Further, such measures may not be strong enough to react to certain types of spoofing attacks.

It is an object of the present invention to provide a protocol remapping method and method of detecting possible attacks on a network to address at least one of the above prior art problems and/or to provide the public with a useful choice. Summary of the Invention

In a first aspect of the invention, there is provided a protocol remapping method comprising the steps of: receiving a data packet destined for an external network, the data packet having a protocol header and a data field; remapping selected control information in the protocol header; and transmitting the data packet with the remapped protocol header to the external network instead of the received data packet.

Since spoofing attacks require the control information, remapping selected control information in the protocol header would reduce success of such attacks. Also, remapping part of the header allows the operation to be performed transparent to the user, and thus, this may help promote adoption of such a measure.

Preferably, the method comprises hashing the selected control information to create a key. In the alternative, the method may comprise the step of performing a lookup based on the selected control information to obtain a corresponding value as a key.

After the key is created/obtained, the method may further comprise the step of using the key to remap the selected control information.

The control information may include a TCP sequence number, DNS identifier, source and/or destination address. Of course, the control information is not restricted to this and any information/field in the control information that might be a target of spoofing (or rather used in a spoofing attack) can be subject to the remapping.

The method may comprise the step of adjusting integrity data in the control information to take into account the remapped selected control information. The method may also comprise the step of checking presence or absence of an identifier to determine whether or not to perform the remapping step.

Incoming data packets are subjected to a reverse process and this forms a second aspect of the invention in which there is provided a protocol remapping method comprising the steps of: receiving a data packet from an external network, the data packet having a protocol header and a data field; remapping selected control information in the protocol header, and if the remapped control information matches with control information of a pending request, allowing the data packet to pass through, and if they do not match, rejecting the data packet.

The first and second aspect is particularly useful, but not exclusively, for remapping of data packets at higher protocol layers i.e. network layer and above. In a third aspect of the invention, there is provided a method of detecting possible attacks on a network, the method comprising the steps of monitoring communication traffic between different protocol layers defining the network; and identifying anomalies across the protocol layers as an indication of a possible attack.

With such a method, it is possible to circumvent potential flaws relating to ingress filtering. To elaborate, communication traffic or protocol dialogue is monitored for anomalies that would imply malicious insertion of modified messages.

As a specific example, the method may comprise the steps of monitoring number of protocol requests destined for an external network and number of responses from the external network, comparing the number of protocol requests against the number of responses, and if the number of responses is more than the number of protocol requests, identifying this as a possible attack.

The protocol requests may be DNS requests, or HTTP requests.

The method may comprise the step of: tracking a connection to an address that is not resolved through DNS as an indication of a possible whisper attack.

The method may also comprise the step of: tracking HTTP server hostnames from received DNS responses; and checking for anomalies as an indication of attack. The present invention is also concerned with an apparatus configured to perform the above methods. The apparatus may be a gateway or an access point for a wireless network.

Brief Description of the Drawings

An embodiment of the invention will now be described, by way of example, with reference to the accompanying drawings in which,

Figure 1 is a schematic diagram showing a station communicating wirelessly with an AP in order to access an external network; Figure 2 provides an overview of rewriting a data packet; Figure 3 is a flow chart showing how a packet is being rewritten as it passes through an AP;

Figure 4A is a flow chart illustrating how a spoof attack is detected for packets arriving from an external network; and

Figure 4B is a flow chart illustrating how a spoof attack is detected for packets arriving from an internal network.

Detailed Description of the Preferred Embodiment

Figure 1 is a schematic diagram showing a station 100 in a wireless local area network (LAN) 102 accessing an external network 104 such as the Internet via a gateway such as an access point (AP) 106. As discussed earlier, secured communications in wireless networks is paramount to the functioning of the network. There are three main objections in communications security and these are i) confidentiality - which protects data against interception by unauthorised parties; ii) integrity - which means that data has not been modified; and iii) authentication - to ascertain the origin of the data. In other words, users must ensure that data comes from the source it purports to come from. Authorization and Access control are implemented on top of authentication. Before granting access to a piece of data, system must find out who the user is (authentication) and whether the access operation is allowed (authorization).

It is appropriate to provide a background of how authorization and access control might be compromised using the Internet as an example. The basic protocol for communications over the Internet is the Internet Protocol (IP) and an IP data packet can be broadly divided into a frame header and a frame body (or data field which is the actual payload that is to be transmitted). The frame header contains a source address which defines the address that the data packet is sent from and a destination address which indicates where the packet is going to. To make it appear that the packet was sent by a different station, an attacker would forge the source address in the header and the station that receives the spooked packets would send a response back to the forged source address. In other words, the attacker has falsified the origin of a data packet thus compromising the security of the communication. Such an attack is normally called "spoofing".

To circumvent such spoofing attacks, a defence is for the AP to perform ingress filtering. Ingress filtering ensures that all traffic broadcast by the AP on the wireless network is checked in terms of IP address and the interface on which it is received. That is, traffic originating from the wireless network should have IP addresses on the local wireless network. (Similarly, but less relevant here, traffic from the external network should not have an IP address on the internal network.) A DNS request is usually sent to a resolver outside the wireless LAN, and therefore a DNS response is expected from an external address. A spoofed response is trivial to detect, as it arrives on the AP from the wireless interface and has an external IP address.

Ingress filtering can be implemented easily by adding a check for each packet against a set of allowed addresses, depending on the interface. The technique is stateless, and the list of addresses would typically be small e.g., a network mask or a list of specific addresses. In principle, it is easy for the AP to have knowledge on internal and external addresses. In the worst case, some configuration may be needed to communicate this knowledge to the AP.

However, ingress filtering may be easily circumvented by deploying an "external collaborator". In such an attack, the attacker is again eavesdropping on the wireless LAN tracking DNS requests, but instead of sending the spoofed response from within the wireless LAN, signals another host on the Internet (ie. external network) to send a spoofed response to the victim. Being able to eavesdrop is crucial, as it allows the attacker to relay the needed DNS identifier and port number information to the remote collaborator.

There are two constraints for the attacker that makes this attack more difficult. First, the remote collaborator needs to be able to send packets with the source IP address spoofed. Unfortunately, a recent study shows that spoofing is still possible on more than 30% of hosts due to the limited use of source filtering. Second, the remote collaborator needs to send the spoofed DNS response before the legitimate DNS response arrives. Thus, the attacker would need to locate a collaborator that is close by in terms of round-trip times.

Packet Rewriting Defence

A proposed defence against external collaborator attack is illustrated in Figure 2 which is to rewrite packets as they flow through the AP 106 to the external network 104 such as the internet. Information in the frame header is mapped so that it is difficult for an attacker 300 to access or forge the header fields. For example, the DNS ID and port number, TCP sequence numbers, etc., may be mapped to a different space, and the reverse is performed by the AP 106 on packets 200' on the way back. The eavesdropper 250 only knows the internal representation of these identifiers, and the attacker cannot relay the necessary information to the external collaborator 252. Any spoofed response from the external collaborator 252 is transformed to have an identifier that would result in the response getting dropped by the victim, making the attack ineffective. This defence is elaborated in Figure 3 using the example of mapping the DNS identifier, destination and source address, collectively called the internal identifier (intlD).

At step 300, the data packet 200 arrives at the AP 106 from within the wireless LAN 102. At step 302, the AP 106 first checks whether the data packet 200 contains a "critical identifier" that requires the control information of the packet to be rewritten. This is to differentiate between data packets that are important and those that are not important to balance the use of resources.

If the data packet 200 does not contain a critical identifier, then the AP 106 forwards the data packet 200 at step 320 to the external network 104. On the other hand, if the data packet contains the critical identifier, the AP proceeds to step 304 where it decides dynamically which type of mapping to use. Initially, the AP 106 uses a state-based mapping and maintains a counter on the number of entries in memory. If the number of entries exceeds a configurable threshold, the AP 106 switches over to a hash-based scheme for future requests. This may be necessary in case the AP 106 operates under memory constraints, in which case it is important to save memory, at the expense of increased computation resource.

Instead of dynamically deciding which mapping to use, the AP may also be preprogrammed to use either type of mapping. If hashing is chosen, then at step 306, an offset value or key is obtained by hashing the source address (src), destination (dst) address and a secret. Any conventional hashing algorithm may be used and likewise, the secret is generated randomly based on known method for doing so. It is appreciated that the offset should include the source address and the destination address to make the communication more secured. If only the source address is included in the hash function, then an attacker may be able to use a third party DNS server to map out the key space by sending a large number of requests with a spoofed source address and the third party DNS as destination. By including the destination in the hash, the attacker cannot then direct packets to a third party DNS server for analysis. Likewise, it is also important to include the source address since if the source address is unprotected, an attacker could set the source of the request to a host under the attacker's control in the external network, set the destination to a legitimate DNS server and have the legitimate DNS server bounce mappings to an external host under the attacker's control.

After obtaining the offset (or key), this is applied to the internal identifier (modulo the identifier space max number) to form the external identifier (extlD) at step 308 as the data packet 200 passes through the AP 106. In this embodiment, the identifier offset is 16 bits, in which the max number would be 65535. If the mapping is done based on known random offsets, these offsets are stored in the memory of the AP so that the AP can reverse the mapping for "returning" data packets. At step 310, integrity data in the frame header is adjusted to take into account the offset of the source and destination addresses and the "rewritten" data packet 200' with the remapped header information is then forwarded at step 320 to the external network 104.

As the packet 200' travels back from the external network 104 to the internal network 102, the offset is computed and the extlD reversed to an "intlD", and if the intlD does not match any pending request by the client, the packet is dropped. In this way, any spoofing attack from an external collaborator would fail since any spoofed response would have an identifier that would create a different offset and the response would be blocked by the AP.

Hashing usually requires substantial computational resource and an alternative is state-based transformation. This makes use of a look-up state table stored in the memory of the AP and at step 312, a lookup is performed to determine corresponding mapping of the source and destination addresses. At step 314, if the source and destination address are located in the lookup state table then, the corresponding mapped values are added to the identifier "intlD" to form the extlD at step 308. If at step 314, it is determined that the source and destination addresses are not found in the lookup state table, then an entry is created at step 318 and the state table updated.

The choice between state based transformation and hash function should depend on application and the availability of resources. If resources are available to support hashing, then this may be preferred instead of having to maintain the lookup state table. On the other hand, state tables may be more efficient as hashing introduces high per-packet cost that may result in a bottleneck.

802.11 level spoofing attack

As discussed, ingress filtering protects wireless LANs from internal spoofing attacks, and the packet rewriting defense protects wireless LANs from external spoofing attacks that involve an inside eavesdropper and an outside collaborator. Ingress filtering is based on the assumption that wireless frames are routed through the AP 106 as per the 802.11 protocol. That is, it assumes that all wireless frames are properly transmitted to the AP 106, which then broadcasts the frames back to the wireless LAN_as the protocol prescribes. In this case the AP 106 can act as an enforcement point to block illegitimate, spoofed frames. A sophisticated attacker can circumvent this defense by directly transmitting frames to the wireless LAN, as if they were transmitted by the AP, effectively spoofing the AP, and violating the 802.11 protocol. To do this, the attacker needs to modify the device driver and possibly the firmware of the WiFi adapter. While this may be difficult, and beyond the capabilities of most attackers, there exist hacked drivers for popular chipsets and tools, and thus this threat should not be easily discounted, as unlikely as it may seem. It should be appreciated that this attack survives both ingress filtering and packet rewriting.

It is possible to detect spoofed 802.11 frames by keeping track of all frames transmitted by the AP on the wireless LAN, and comparing them against frames seen while listening to the LAN. The AP needs to store identifiers (e.g. 802.11 link-layer sequence numbers) and record a content hash for every frame transmitted, to distinguish between genuine duplicates and frames retransmitted by the attacker with just the content altered. While this defense is likely to be effective, the implementation effort as well as the processing involved is likely to be costly.

Whisper attack

A variation of the above spoofing attack involves the attacker tuning the WiFi radio power so that the spoofed packets can reach the victim (station under attack), but not the AP (or external detection device) and this is called the whisper attack. The attack seems difficult to engineer, as it requires both the low-level driver/firmware hacks of the basic 802.11 spoofing attack, as well as careful tuning of the radio. Unfortunately, newer chipsets provide improvements in power control, and it is likely that the attacker can easily find the "right" power setting to launch the attack by probing both the victim and the AP with different power settings, all controlled through the driver API.

Cross-layer protocol dialog anomaly detection

"Cross layer" here refers to correlating information across layers and protocols, and not necessary between layers in the OSI or IP models. To address the above two forms of attack, it is proposed to monitor traffic for unusual events that may reveal a likely spoofing attack, as shown in Figures 4A and 4B. The monitoring may be carried out by the AP or complemented on an independent sensor or wireless system (WIDS).

Starting with Figure 4A, at step 400, a data packet 200 arrives from an external network 104 and is received by the AP 106. The AP 106 checks whether the data packet is a DNS reply or not at step 402. If the data packet is not a DNS reply, then it allows the data packet 200 to pass for forwarding to the destination station. If the data packet 200 is a DNS reply, at step 404, the AP 106 extracts from the HTTP connection the server hostname from the HTTP header and the server address from the IP header, and compares this pair against the hostname and IP pairs extracted from observed DNS replies. If a reply has been whispered, no DNS reply would match the HTTP header and thus, this indicates an attack. The AP 106 then generates a "Whisper Alert" at step 406 to alert the user of a possible whisper attack which may be via any appropriate channel. A user may also be redirected to a warning page.

It should be appreciated that the AP cannot "see" the whispered DNS reply but it can "see" all other DNS replies, as well as any follow-up HTTP header. As a result, the AP would "see" or rather detect an HTTP header to/from a server which does not have a matching DNS response. Therefore, the conclusion is that someone must have injected a spoofed response. In other words, the existence of a server name in the HTTP header that does not have a corresponding response is sufficient evidence of likely foul play. If there is no conflict between the server hostname and address, and what is compared against, the AP 106 next checks the number of DNS request versus the number of DNS replies at step 408. This check is based on the premise that a spoofing attempt would result in inconsistent DNS responses being received for the same query. The present embodiment employs Inconsistent Duplicate Detection heuristic (IDD) which tracks DNS requests and responses and tries to locate excess replies that disagree. The IDD successfully detects spoofing attempts as long as the legitimate packet is not dropped before it reaches the AP. However, an attacker is unlikely to want to rely on the relatively low probability of packet loss in order to successfully launch this attack, and the user should be alerted to any failed attempts (e.g., no packet loss).

Due to short DNS timeout settings, clients often retransmit requests and then receive multiple replies — one per transmitted request. As a result, when resolving a replicated service multiple, inconsistent replies may be received.

Detection is not be triggered as long as the number of replies is less than or equal to the number of requests and if this is the case, at step 410, the DNS response ID and content are added to the memory 500 of the AP 106, and the AP 106 proceeds to receive the next data packet to process at step 412. The stored DNS response ID and content is needed to check the integrity of the packets (see below, step 414).

If the replies are more than the requests, this indicates a possible spoofed attack and at step 414, the DNS replies are checked for conflicts. If an unaccounted-for-reply is found, the "victim" is denied access and the victim is redirected to a warning page at step 416 notifying him of a potential spoofing attack. The victim may be given an option to proceed (and re-issue the request) through temporary HTTP redirection or not. On the other hand, if the number of replies is not more than number of requests, step 410 is executed to store the DNS response ID and content in the memory 500 and the AP is ready to receive the next packet at step 412.

For IDD, the timing of detection and response is crucial: the AP 106 should raise an alarm when the second DNS response is detected, and there is no way to know if the attack was successful or the spoofed response came too late. If the spoofed response comes first, the detector cannot react before the second response comes in. Thus, the victim remains exposed for a short window, in which the attacker may be able to take action.

It should be appreciated that IDD is attractive as it is relatively easy to implement, convenient to deploy independently from the AP, and covers different types of attacks. Implementation-wise, the detector can be implemented in user-space as a standalone libpcap-based application, if manipulating kernel internals on the AP is undesirable. It can also be installed on a separate host, such as an independent wireless IDS. While this form of detection requires state, the amount of memory needed for the detector is reasonable, as the timeout threshold for expiring entries can be low, while DNS traffic is insignificant. Figure 4B is a flowchart that illustrates what happens when a data packet arrives at the AP 106 from the LAN 102 at step 420. At step 422, the AP 106 checks the data packet to determine whether it is a DNS request and if it is, at step 424, the DNS request ID is added to the memory of the AP. This ID is used as comparison with incoming data packets (i.e. received from the external network 104, as described earlier - see Figure 4A) to determine whether a response is a spoofed response or not. Thereafter, the AP 106 proceeds to accept a next data packet at step 426.

If the data packet is not a DNS request, then step 428 checks to see whether the data packet is a HTTP request or not. If not, the AP 106 proceeds to step 426, otherwise, the AP 106 proceeds to 430 which adds the server hostname and the server address into the memory of the AP 106. Thereafter, step 432 checks the DNS cache to determine a conflict between the server hostname and server address. If there is a conflict, a whisper alert is used to alert the user at step 406.

The following are further examples of anti-whisper approach of cross-layer correlation, involving TCP and DNS data.

Anti-whisper component

While there are no visible duplicates in this scenario, the AP can still detect the attack indirectly by inspecting traffic for anomalies in the protocol dialogue between the potential victim and the outside world. Transport-level: DNS+TCP

In case of a whisper-attack, the AP would observe the DNS request and the legitimate response, but no subsequent connection establishment to the IP returned in the DNS response, because the victim connected to the whispered reply. In addition, the AP would observe a connection to an address that has not been resolved through DNS and has been conveyed to the victim through the whispered spoofed DNS reply. Each condition can be legitimately observed on its own, but the concurrent presence of both indicates a whisper attack.

The inventors ran preliminary experiments to evaluate the false positives rate of this mechanism using a trace containing traffic from client machines in a research institute. The traffic is generated on wired LANs and thus does not include whisper attacks. The inventors measured a false positive rate of 0.007% over all TCP connections for a delta of 2 sec between DNS request and suspect SYN packet.

There are some potential problems with this approach involving the attacker may attempt to fake the missing messages that reveal the attack. Injected messages can be detected by observing 802.11 sequence numbers anomalies. Finally, the attacker may trick the victim into resolving the address of the fake site (e.g. by embedding it into a web page or email) and thus having the victim generate the missing message. The duplicate DNS replies will always be visible at the victim, even if invisible to the AP, and therefore a host-based solution would be ideal. Furthermore, a host-based defense can easily and robustly inform and protect the user, especially if it is well integrated with the user's browser. Deployment is always an issue, but such a solution could be easily bundled with anti-virus and firewall software.

The described embodiment should not be construed as limitative. For example, the described method is applicable for wired networks such as the Ethernet, not just for wireless networks.

Having now fully described the invention, it should be apparent to one of ordinary skill in the art that many modifications can be made hereto without departing from the scope as claimed.

Claims

1. Protocol remapping method comprising the steps of: receiving a data packet destined for an external network, the data packet having a protocol header and a data field; remapping selected control information in the protocol header; and transmitting the data packet with the remapped protocol header to the external network instead of the received data packet.

2. A method according to claim 1 , further comprising the step of hashing the selected control information to create a key.

3. A method according to claim 1 , further comprising the step of performing a lookup based on the selected control information to obtain a corresponding value as a key.

4. A method according to claim 2 or 3, further comprising the step of using the key to remap the selected control information.

5. A method according to any preceding claim, wherein the control information includes a TCP sequence number, DNS identifier, source and/or destination address.

6. A method according to any preceding claim, further comprising the step of adjusting integrity data in the control information to take into account the remapped selected control information.

7. A method according to any preceding claim, further comprising the step of checking presence or absence of an identifier to determine whether or not to perform the remapping step.

8. Protocol remapping method comprising the steps of: receiving a data packet from an external network, the data packet having a protocol header and a data field; remapping selected control information in the protocol header, and if the remapped control information matches with control information of a pending request, allowing the data packet to pass through, and if they do not match, rejecting the data packet.

9. A method of detecting possible attacks on a network, the method comprising the steps of monitoring communication traffic between different protocol layers defining the network; and identifying anomalies across the protocol layers as an indication of a possible attack.

10. A method according to claim 9, further comprising the steps of monitoring number of protocol requests destined for an external network and number of responses from the external network, comparing the number of protocol requests against the number of responses, and if the number of responses is more than the number of protocol requests, identifying this as a possible attack.

11. A method according to claim 10, wherein the protocol requests are DNS requests.

12. A method according to claim 10, wherein the protocol requests are HTTP requests.

13. A method according to claim 11 , further comprising the step of: tracking a connection to an address that is not resolved through DNS as an indication of a possible whisper attack.

14. A method according to claim 12, further comprising the step of: tracking HTTP server hostnames from received DNS responses; and checking for anomalies as an indication of attack.

15. A gateway configured to perform the method of any preceding claim.

16. An access point for a wireless network configured to perform the method of any of claims 1 to 14.