Framing Packets
reported by: sil
(ARCHIVE: http://web.archive.org/web/20010603171111/http://www.antioffline.com/framingpackets.html)
Framing Private Ryan on the packet layer is not more difficult than one would expect it to be since it is a well known fact that networks all around the world would have to be entirely secure in order to prevent a malicious user from sending bad data, and creating havoc as the identity of someone else. This does not need to apply to networks running IPSec where Point A and Point B are predefined although they too can be trivial.

Only when (in typical terms without thinking of tunneling and IPSec based technologies) the entire connection between every single host, router, switch, and machine connected to every host connected to every other and so forth, can we be sure of the integrity of data traversing a network.

Spoofing packets throughout a network isn't a difficult task as many may think it to be and there are many programs which will automate it for you. DHCP spoofing where we think of a typical person logging unto their ISP, authenticating via a username and password combination and being assigned an IP address is something many have overlooked at times, and it should be explained in more detail but I do not feel the need to type much so a recent e-mail will hopefully suffice.

=====================
To: Vuln-Dev
Subject: Re: IP Spoofing with DHCP ?
Date: Mon Sep 18 2000 15:09:57
Author: Nathan Einwechter < ceo@investigatecanada.com >

Actually, this has been an attack which has been demonstrated, written on, and used in the cable networks which are currently present.

What you can do is basically DoS, or wait, untill the other persons box is down. At this point, it is possible to statically assign your IP to the same as yours.

Using this method, you can effectively frame someone for doing net attacks etc. There may be other interesting things you can do with this hijacking of the IP though, which I haven't thought of. It is also possible to hijack an SSL or HTTPS session if this is done with the right timing, and a packet sniffer is utilised. I have actually demonstrated this a few times in the past.

Hope this helps.
Original Posting

=====================

So many spoofs so little time. Packet Injection Tools such as Nemesis may allow for tactics such as forging information into an existing data stream or creating a new stream of data filled with bad information as anyone you'd like to assume the identity of quickly, effectively, and possibly criminally.

Blind TCP injection of data along with some careful mathematics of sequence information can quite possibly cripple even the toughest firewalls as was proven many times judging by the mirror of hacks on some of the top sites on the Internet. NASDAQ, New York Times, E-Bay, I highly doubt any of these sites had any phf, Cold Fusion, IIS issues, yet still someone was able to bypass most measures to get in.

Could someone have sniffed out data and perhaps injected information into a datastream of the webpage editor while he was editing a site, causing his firewall to think he may have been uploading a defaced page based on only his packet information? (Sequence Number, ID, IP)

It is very possible and not far fetched and one wouldn't need to see the resulting ACK packets to perform such an attack.

Borrowed from "A Stateful Inspection of Firewall-1" and merely used for references on the extent of spoofing on the firewall level.

IP Spoofing Protection IP spoofing protection on FireWall-1 is configured per network object at the interface level. Several options are possible, but the typical configuration looks something like this:

DMZ and intranet interfaces set to ``This Net'' or perhaps ``This Net +'', restricting valid source IP addresses on the interface to those directly on its network, or routable to its network.

External interface set to ``Others'', disallowing packets purporting to originate from any of the DMZ or intranet networks.

While this configuration seems simple enough, it leaves out spoofing protection for one important IP address -- the external interface of the firewall.

Denial of spoofed packets coming from firewall interfaces is apparently enabled by default in all versions of FireWall-1 other than version 4.1 Service Pack 1. Coupled with the default rule to allow ISAKMP packets, this hole allows an attacker to send any UDP datagram to the external firewall interface.

Another possibility for evading IP spoofing protection is to use the all-hosts multicast address (224.0.0.1) as a mechanism for delivering packets to the underlying operating system of the firewall. For our demonstration, we used FWZ encapsulation to spoof a packet from the multicast address to our attack host, allowing us to respond with a packet sent to the multicast address, passed on to the firewall itself.

This attack can also be performed with broadcast addresses.


So now it can be re-stated that even with preventive amounts of crafty work, a user can pretend to be someone he or she isn't on most levels of networking.

In order to not jump off base with info I'll try to keep in focus the Packet Layer which is the intent of this doc, so right back to the barebones of it all.

The attack begins using my account as the victim and another account as the attacker, which we'll call rwxr--r--. (which is my irc handle)

rwxr--r-- is upset with sil@antioffline.com simply because he is jealous and wishes to discredit him and everything surrounding him. rwxr--r-- happens to be a script kiddie with no good intentions on his mind and decides he wants to make it seem as if sil is going to issue DoS based attacks to the NSA.

rwxr--r-- jumps online and sees sil in irc and does a simple /whois lookup in order to gain his information.

| sil (sil@dhcp517.someinternetprovider.com) (Internic Commercial)
ircname : sil
| channels : #openbsd
server : irc.Prison.NET (The server that Elian Gonzalez IRCed from...)
: idle : 0 hours 0 mins 4 secs (signon: Wed Oct 25 18:13:49 2000)


Using this info rwxr--r-- gains sil's user info and traceroutes the address of dhcp57.someinternetprovider.com (Obviously a sample address) and goes out and downloads APSend, Jolt2, Punk, and Smurftools in order to launch multiple attacks using sil's address he resolved with a simple look up.

These programs generate spoofed Denial of Service attacks with a few keystrokes, and the sender can be forged in an effort to make it seem as anyone you specify has sent them. Its a very dangerous game to play and people will play it.

Hailstorm is definitely a tool for any security administrator to have as it has many features for testing security on a network. It also has the perfect neccessities for someone to forge data via methods of spoofing in an elegant fashion. Anyone with bare knowledge of TCP/IP and motive may use a program such as this for causing other havoc.

Using the sniffer function of the tool, lets say John and Joe are employees who are at odds because Joe received a bigger salary for a lousier job, Joe who may know a bit about TCP/IP and security decides he just wants to get even, besides Joe just purchased a brand new house and brand new car and without a raise he won't be able to afford the luxuries or so.

Joe decides to sniff the network using Hailstorm and focuses on packets designated for Joe's workstation. He notices Joe has his banking information online and decided to assume Joe's identity and tinker with his accounts, while this may seem a bit outrageous and dangerous, Joe simply has to watch the sessions and get a couple of packet captures using Hailstorm. After a day or maybe even a week Joe has filtered out the packet information and is only filtering when money is being transferred or a bill being paid.

Hailstorm allows you to recreate full packets including payloads, sequences, addresses, you name it, and Hailstorm is not the only program to do so. Joe modifies a packet to inform the bank to pay something John did not agree to, or perhaps transfers funds into some account. Get the picture?

Sure John will fight to the finish but in the digital sense, the bank's connection gathered the information from John via his IP address which is the bottom line, but is not correct and should never be thought of as a definitive way to identify someone especially on an Internet of billions.

May sound lame, people may think its ludicrous but it can and I am sure it has happened in the past and will eventually be something which law makers, lawyers, courts, experts will have to recognize and weigh factors when dealing with "e-related crimes".