Session Hijacking& ARP PoisoningWhy web security depends on communications security and how TLS everywhere is the only solution.

ARP Cache PoisoningHow the outdated Address Resolution Protocol can be easily abused to carry out a Man In The Middle attack across an entire network.

Introduction

The Address Resolution Protocol (ARP) facilitates communications on a Local Area Network (LAN).

It does this by providing a means for clients to resolve a Layer 3 Internet Protocol (IP) Address (192.168.1.5) to a Layer 2 Hardware Address (af:23:b4:7d:f5:c9) or Media Access Control (MAC) address.

The ARP protocol employs no form of security or authentication and is a simple request and reply protocol.

ExampleFor Scott to send packets to Dave over the LAN he needs to know Dave’s MAC address.

Scott

DaveARP Request

Who is 192.168.0.6, FF:FF:FF:FF:FF:FF?I’m Scott, 192.168.0.5, A3:DD:B4:12:3A:4F.

192.168.0.5A3:DD:B4:12:3A:4

F

192.168.0.6B7:C2:11:F2:BB:E

6

ARP Response

Hi Scott, 192.168.0.5, A3:DD:B4:12:3A:4F.I’m Dave, 192.168.0.6, B7:C2:11:F2:BB:E6.

Example

Scott

192.168.0.5A3:DD:B4:12:3A:4

F

ARP Request

Who is 192.168.0.6, FF:FF:FF:FF:FF:FF?I’m Scott, 192.168.0.5, A3:DD:B4:12:3A:4F.

Scott was able to send the ARP request to Dave without knowing his MAC address by using the broadcast address FF:FF:FF:FF:FF:FF.

A packet with the broadcast address as the destination is delivered to every client on the current LAN segment, ensuring Dave will receive it. Once we have Dave’s MAC address, we can send packets to him instead of everyone on the network.

Example

Dave

192.168.0.6B7:C2:11:F2:BB:E

6

ARP Response

Hi Scott, 192.168.0.5, A3:DD:B4:12:3A:4F.I’m Dave, 192.168.0.6, B7:C2:11:F2:BB:E6.

When Dave received the ARP request, he identified it was for him and responded to the request using the details in the initial request.

Scott

Dave

192.168.0.5A3:DD:B4:12:3A:4

F

192.168.0.6B7:C2:11:F2:BB:E

6

Example

Now Scott and Dave have exchanged details they can communicate with each other directly. They both store a record in their ARP Cache of the other clients IP and MAC address so they can perform a lookup later if needed. This prevents the need for subsequent ARP requests and reduces network traffic.

The Problem

Scott

Dave

192.168.0.5A3:DD:B4:12:3A:4

F

192.168.0.6B7:C2:11:F2:BB:E

6

During the ARP request/response exchange neither client took any steps to verify the identity of the responding client, or the authenticity of the response sent. This presents an opportunity for a 3rd party to impersonate clients on the network.

Scott

Dave

192.168.0.5A3:DD:B4:12:3A:4

F

192.168.0.6B7:C2:11:F2:BB:E

6

The Problem

Attacker

ARP Requests are sent to all clients on the network as they use the broadcast MAC address FF:FF:FF:FF:FF:FF.

192.168.0.7C4:D3:46:B1:EE:B

A

Scott

Dave

192.168.0.5A3:DD:B4:12:3A:4

F

192.168.0.6B7:C2:11:F2:BB:E

6

Attacker

ARP Responses are not verified and if any client receives a new response they will update their ARP cache assuming the sender has changed their MAC or IP address.

192.168.0.7C4:D3:46:B1:EE:B

A

The ProblemHi Scott, 192.168.0.5,

A3:DD:B4:12:3A:4F.I’m Dave, 192.168.0.6, C4:D3:46:B1:EE:BA.

Scott

Dave

192.168.0.5A3:DD:B4:12:3A:4

F

192.168.0.6B7:C2:11:F2:BB:E

6

Attacker

As long as the attacker regularly sends the forged response to the target (Scott), they will continue to send traffic to the wrong location. If the Attacker then resends the traffic to the correct destination there is no interruption on the LAN and Dave is not aware the Attacker can view his traffic.

192.168.0.7C4:D3:46:B1:EE:B

A

The ProblemHi Scott, 192.168.0.5,

A3:DD:B4:12:3A:4F.I’m Dave, 192.168.0.6, C4:D3:46:B1:EE:BA.

Scott

Dave

192.168.0.5A3:DD:B4:12:3A:4

F

192.168.0.6B7:C2:11:F2:BB:E

6

Attacker

192.168.0.7C4:D3:46:B1:EE:B

A

The ProblemTo Dave,

192.168.0.6, C4:D3:46:B1:EE:BA.The password is “SuperSecret1234”.From Scott, 192.168.0.5A3:DD:B4:12:3A:4F

To Dave, 192.168.0.6, B7:C2:11:F2:BB:E6.The password is “SuperSecret1234”.From Scott, 192.168.0.5A3:DD:B4:12:3A:4F

This is a successful implementation of a MITM attack and allows the attacker to view all traffic sent by Scott to Dave.

The Scope

Attacker

192.168.0.7C4:D3:46:B1:EE:B

A

At this point, the attacker can choose which targets on the network he wants to MITM and impersonate them using forged ARP packets to poison their ARP Cache.

Client

Client

Client

Client

Client

The Bigger Problem

A gratuitous ARP can be sent by a client at any point, usually when their IP address or MAC address has changed for some reason. This allows other clients to update their ARP cache and maintain current records. An attacker can send out a forged gratuitous ARP without needing to wait for an ARP request from a target on the network.

Default Gateway

192.168.0.7C4:D3:46:B1:EE:B

A 192.168.0.1D7:AD:F1:C3:A4:D

9

To Everyone! Here are my updated details!192.168.0.1 C4:D3:46:B1:EE:BA

Broadcast

The attacker has just told all clients on the network that he is the default gateway!

Attacker

The Bigger Problem

192.168.0.7C4:D3:46:B1:EE:B

A

Attacker

Default Gateway

192.168.0.1D7:AD:F1:C3:A4:D

9

Client

Client

Client

Client

Client

Client

Here the attacker can monitor all Internet traffic on the LAN that isn’t being sent using TLS. He could also simply not forward on the traffic and bring the entire network down as no clients would be able to communicate at all. This is known as a Denial of Service (DoS) attack.

Mitigation• There is no replacement for ARP on a LAN so ARP Cache

Poisoning is a difficult threat to defend against.

• You can create static ARP entries on client machines for important things like the default gateway. The only problem is if the IP or MAC genuinely changes no client will listen to the new details and depend upon the incorrect static entries which now need to be updated.

• ARP Cache Poisoning actually has genuine advantageous uses. If a web server on your LAN went down, you could invisibly direct all clients to a backup server without needing to alter any configurations. Simply broadcast a forged ARP packet with the MAC address for the new server.

• You can employ monitoring software to listen and try to detect forged ARP packets. They are easy to spot by maintaining a historic record of ARP broadcasts and looking for an ARP packet with the same IP address but a different MAC address to one previously reported.

Introduction

Transport Layer Security (TLS), and its predecessor Secure Sockets Layer (SSL) as many will know it, are cryptographic protocols used to offer communication security over the Internet.

Hypertext Transfer Protocol Secure (HTTPS) is not actually a protocol in and of itself. It is actually the use of Hypertext Transfer Protocol (HTTP) on top of TLS which affords the standard HTTP communications protocol the protection of TLS.

Session Hijacking (a.k.a. Session Sidejacking) is a form of Man In The Middle (MITM) attack in which a malicious attacker has access to the transport layer and can eavesdrop on communications. When communications are not protected they can steal the unique session ID and impersonate the victim on the target site. This grants the attacker access to your account and data.

• To verify the website you are connecting to is the genuine website. • To ensure the privacy of your data during transit.

• To ensure the integrity of your data during transit.

Why do we use TLS?

Example

When first visiting the site you are using HTTP.

The sensitive login form is loaded over HTTPS.

Example

The login form is loaded over HTTPS to ensure the integrity of the form in transit. This prevents a man in the middle from altering the form.

The login form then submits the user credentials over HTTPS to ensure the same man in the middles can’t read the credentials in transit.

The TLS certificate also allows us to be confident that the website we are viewing is actually the website it claims to be.

The fact that TLS has been utilised is an acknowledgement that a man in the middle could access or modify data during transit.

Example

The problem arises when the site reverts back to loading content over HTTP once the user has authenticated. The assumption is that now the sensitive user credentials have been exchanged we no longer need to protect the traffic during transit.

Why does this matter?

• Once you have logged in on the secure login page, your session ID lets the server remember you have logged in without having to keep sending your username and password to prove your identity.

• Once the website reverts back to HTTP your session ID still has to be sent but is no longer afforded the protection offered by TLS.

• HTTP and HTTPS are stateless protocols. This means each time you request some new content from the site (a page, image or any form of media) the server does not know who you are, it does not remember you.

• To combat this, when you first visit a site you are issued a unique session ID. With each request you send to the site, your session ID is sent with it. This is how the site identifies you.

Summary

TLS (HTTPS) was used to protect your username and password during the logon process to prevent a man in the middle viewing the content of your traffic and stealing your credentials. The session ID is not being afforded the same level of protection but an attacker could use it to impersonate you on the target website. All they need to do is substitute their own session ID with your session ID and the server will believe the attacker is you. Once your session ID has been obtained this is a trivial task. The attacker is then logged in to your account and can do anything that you could do.

So to conclude Session Hi-jacking

• Whilst obtaining your session ID does not generally reveal your username or password the attacker can still access your account as if they were logged in as you.

• This attack is possible because TLS is not used across the entire site.

• We accept an attacker could access our traffic, which is why we need TLS in the first instance.

• Sites regularly fail to protect the session ID which can be considered an equivalent to your user credentials on the target website.

• Forcing all traffic to the site over HTTPS would completely mitigate a session hijacking attack.

Conclusion

Whilst you could statically assign all ARP entries on the network this is not a realistic solution and near impossible to maintain on large networks. Detection software can let you know when someone is attempting to ARP poison clients on your network and event attempt to mitigate it but this is still a reactive measure and not a form of prevention.

ARP Cache Poisoning presents a serious threat over a LAN (this includes WiFi) which stems from an inherent lack of security in the protocol itself.

The easiest way to protect your Internet traffic whilst using a network that may contain malicious clients is to use sites protected with TLS.

As TLS offers end to end encryption the attacker would only be able to view the encrypted version of your traffic and as such it is useless to them.

There are of course other options like using a Virtual Private Network (VPN), but require considerable cost and maintenance.

This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/

Thanks to Scott Helme for these notes. Check out his site at http://scotthel.me