Tuesday, December 8, 2009

IP Spoofing

If you are using any sort of IP based filtering within your application, then you need to evaluate how IP spoofing attacks affect your security controls. In order to make a fair evaluation you will need a basic understanding of IP spoofing attacks.

Let's look at two different scenarios.

Scenario #1 Attacker wants to spoof an arbitrary IP address and the attacker is not on the same subnet (broadcast domain) as the targeted IP address. Example: attacker is 1.2.3.4 and wishing to spoof 4.5.6.7

Scenario #2 Attacker wants to spoof an IP address of someone on his own subnet (broadcast domain). Example: attacker is 192.168.1.55 and wishing to spoof 192.168.1.58 (assuming subnet of 255.255.255.0)


Scenario #1

The attacker can create forged TCP packets and modifies the source IP address to be any value. One tool that can do this is HPING2.

What can you (the attacker) do:
  • Send an initial TCP packet with any source IP address
  • Send a series of UDP packets with any source IP address
  • Send a series of unrelated TCP packets from the same or varying IP addresses
What can't you (the attacker) do:
  • Receive any responses to your forged messages. The responses, if sent, would go to the forged IP address.
  • Send a string of related TCP packets (e.g. reconstruct an actual TCP exchange). This is because you can't complete the handshake or guess the necessary information to continue the TCP connection.
Scenario #2

The attacker can perform a variety of attacks to forge or take-over the IP address on the same subnet.

Attack Options:

  • Simplest - Statically define your IP address to the target IP address
  • Switch your MAC address to the MAC address of the current NIC for the target IP address and attempt to assume control of IP
  • Execute man in the middle attack via arp spoofing (see tool Cain & Abel) and then gain control of user's unencrypted transmissions. You could likely modify or redirect traffic to accomplish your original spoofing goal.
What can you (the attacker) do:
  • Assume control of the IP address. Note: This means you can send/receive valid data using the targeted IP address as your own. It does not grant you access to existing sessions that the user had with any websites (because you don't have the user's session cookies).
What can't you (the attacker) do:
  • Intercept encrypted (e.g. SSL/TLS) communication destined for the target IP address without alerting the targeted user in some way (browser warning message for MitM invalid certificate).
Hope this is helpful. This is by no means an exhaustive list of attack techniques, but something to consider if your are using IP related controls within an application.

-Michael Coates

6 comments:

  1. In Scenario #2 couldn't the spoofer just use SSLStrip to intercept SSL communications?

    ReplyDelete
  2. Excellent question. The answer is it depends. SSLStrip will work if a site does SSL wrong (and there are many ways). However, if the user initially types HTTPS for the website and the site is doing SSL correctly, then there is no way (currently known) for the MitM to hijack that stream without the victim seeing a certificate browser error message.

    Take a look at the OWASP TLS Cheat Sheet to see the different considerations for correctly using SSL/TLS

    http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_sheet

    ReplyDelete
  3. That OWASP link should have been this:

    http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

    ReplyDelete
  4. I take it, By "What can you do?" / "What can't you do?" you mean "What can the attacker do?" / "What can't the attacker do?".

    Stephan

    ReplyDelete
  5. Yes, "you" is the attacker. I'll update the post with that info. Good catch.

    ReplyDelete
  6. With regards to Scenario #2:
    - The success of this technique is dubious as it is currently described; I'm not sure what "attempt to assume control of IP" really means. Sounds like a "hopeful" approach at best.

    - One potential way of doing this is to actually DoS the client machine and getting it off the network. THEN you can possibly assume that IP address. How you carry out a Layer-2 DoS is beyond the scope of this post.

    - Even the success of the above method is not guaranteed if proper Layer-2 security is configured on the network in question. Such attacks can in fact be easily blocked & detected in a properly locked down environment.

    ReplyDelete

Note: Only a member of this blog may post a comment.