By: Kunal Vohra
In a previous article, I discussed ARP poisoning and password detection tools. This takes that article to the next level and discusses how to hijack sessions. Sniffing networks (or ARP poisoning to sniff switched networks) is a great way to collect passwords. Unfortunately, tools like Dsniff and ettercap aren't always capable of detecting every password that crosses the network. This is where session hijacking can become your friend (or your worst enemy depending on which side of the infosec coin you're on.) In this article I will detail Netflood's test results and the techniques we used to hijack active sessions.
Abstract:
In order to session hijack traffic, multiple attacks or techniques may have to take place. For example, one may have to DoS attack a server in order to keep it from sending RST (reset) packets to the victim. If I were to detail a DoS technique (with every available argument) it would distract thoughts away from the real topic of this article.Some knowledge will have to be gleaned from RFC's, man pages, code comments, by researching on your own, or by merely using your intelligence to conceive of vulnerabilities not discussed herein; Hence, the word "primer". No one wrote me a little "session hijacking for dummies" book and I figured it out, so you can too.
Disclaimer:
This paper describes nothing more than some vulnerabilities of the Transmission Control Protocol and tools/thoughts which exploit those vulnerabilities. It is intended for educational use only. You are responsible for what you do with this information. I am no more responsible for people committing crimes with this information then chemistry instructors are responsible for people who construct bombs or chemical warfare devices. [Insert expensive lawyer jargon here to stave off unfounded FBI allegations ala Sil]. All your base are belong to us.
Contents:
A look at TCP
Local Network Session Hijacking
Remote Network Session Hijacking
Defending against session hijack attacks
A Look At TCP
Transmission Control Protocol (TCP) is addressed in RFC 793. For the sake of brevity, I will only cover relevant portions of the RFC; adding information to it when necessary.
The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks.
TCP must recover from data that is damaged, lost, duplicated, or delivered out of order by the internet communication system. This is achieved by assigning a sequence number to each octet transmitted, and requiring a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within a timeout
interval, the data is retransmitted. At the receiver, the sequence numbers are used to correctly order segments that may be received out of order and to eliminate duplicates. Damage is handled by adding a checksum to each segment transmitted, checking it at the receiver, and discarding damaged segments.
A fundamental notion in the design is that every octet of data sent over a TCP connection has a sequence number. Since every octet is sequenced, each of them can be acknowledged. The acknowledgment mechanism employed is cumulative so that an acknowledgment of sequence number X indicates that all octets up to but not including X have been received. This mechanism allows for straight-forward duplicate detection in the presence of retransmission. Numbering of octets within a segment is: the first data octet immediately following the header is the lowest numbered, and the following octets are numbered consecutively.
It is essential to remember that the actual sequence number space is finite, though very large. This space ranges from 0 to 4294967295 (2**32)-1. Since the space is finite, all arithmetic dealing with sequence numbers must be performed modulo 2**32 (4294967296). This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. There are some subtleties to computer modulo arithmetic, so great care should be taken in programming the comparison of such values.
So you see that the ISN can be any number between 0 and 4294967295. You also hopefully noticed that every octet has a sequence number, not every session. The server (TCPB) will respond to the client (TCPA) with it's own sequence number, while acknowledging the clients sequence number. See below for an example:
Sequence prediction to take over networks was first written about in 1985 (or thereabouts) by none other than Robert T. Morris (his son created the first Internet worm). The first attack employing this technique did not occur until Christmas of '94, this is known as the Mitnick hack of Shimomura (or "Christmas hack"). Over the years, OS's have become more random in deriving the ISN, but we all know that computers are not random thinkers. Eventually over time, even computers choosing random numbers will repeat themselves, because the randomness is based on an internal algorithm. There is a great in-depth article, which can be found here, that explores sequence number generation and prediction in more detail.
Once a sequence number has been agreed to, all following data will be the ISN+1. This makes injecting data into the communication stream possible, if one were so inclined. The tricky part is not hijacking the session, but in finding out the ISN. Once the ISN (or the ISN increment) is discovered, everything else is gravy.
3 requirements to hijack non-encrypted TCP communications:
1. There must be non-encrypted session oriented traffic.
2. Attacker must be able to recognize TCP sequence numbers and predict what the next sequence number will be.
3. Attacker must spoof a hosts MAC or IP address to receive communications which are not destined for the attackers host
If the attacker is on your local segment, they can sniff the connections and therefore see what the ISN+1 number is, they can also have the traffic routed back to them by poisoning the ARP cache. This is why implementing internal network protocol encryption is so important (albeit rarely done).
Local Network Session Hijacking
Rather then reinvent the wheel, we used a tool that's readily available, called Hunt (downloadable @ netflood.net). We will use the newest version (1.5) because it runs on WindowsME (that's just a joke to get the kiddies hopes up), you'll actually need Linux or some other *nix variant (though you may have to port Hunt to work with your specific OS). In my case, I have a test machine running Redhat 7.1 and it works fine. You shouldn't have a problem using Hunt with any Linux 2.X kernel.
1. Start hunt
2. Select the "u" option (host up tests). This will enable you to see TCP connections on your network (ie. victims)
3. Enter the victims IP address or your network address
4. Enter victims IP address again or the broadcast address of your local network (This will insure that our entire network can be victims of this attack).
5. Choose the default answers unless you know what you're doing.
Hunt will now look for victims (based on the range) using a variety of techniques such as ARP broadcasting and pinging.
6. Choosing "yes" for net ifc promisc test (arp method) option will enable Hunt to do a promiscuous interface test using an ARP broadcast.
7. Pick the default MAC address
8. Hunt will now want to do a promiscuous test using ping, choose "yes" and default MAC address for remaining options.
At this point you will be returned to the main menu.
"l" to list all active TCP connections
"w" and choosing a connection will enable you to watch the connection (ie. see all unencrypted communication between the hosts)
Since there is only one TCP session, we'll choose that option by typing "0 " .
We will be prompted if we want to see just source or destination traffic (client/server) or traffic destined in both directions, choose "both" as only seeing one side of the communication is boring. Don't print both characters, unless you absolutely need to (if you don't know why you'd need to, then you don't need to).
We can now watch the entire communication. So if the victim telnets to a server, we will see him authenticating and doing whatever he decides to do. If he telnets from that server to another server we can watch him log in and get any information we need. We could just sit and watch the communication all night but the problem is the victim is typing extremely slow, and that can be irritating for those of us who type fast. Since that's the case, we should now take over and type for him.
Press control-c and when prompted, to end the show you've just been watching. You will then be presented with the main screen. We are going to do an "arp/simple hijack" so we choose option "a".
We are again presented with a list of TCP sessions. I'll choose option "0" (or whatever communication I choose).
I'm going to spoof all addresses, so I'll use the "yes" defaults.
Any old source MAC address will do, so I'll keep the defaults.
I'll press enter and accept the raw input mode.
Since I want to see everything I will dump all connections.
Choose whether or not to print source and destination same characters, in my case I will choose "no".
I now need to press control-c to input myself into the connection.
An Arp spoof with a destination IP in another network will fail but that's ok because I don't need to spoof the server, I just need to spoof the client to communicate with the server. If it asks you to force the the ARP spoof, choose "no" as it's impossible to ARP spoof a client on a remote network.
I have now hijacked the victims session and I can do anything the user was allowed to do.
You may be asking why you choose any MAC address instead of yours. The answer is because we are cache poisoning the devices which will relay the traffic to us, whether it is a switch, a router, or every host on our network segment. This was covered in a previous netflood article here.
If you are wondering why we shouldn't "force the ARP spoof", keep reading. it's actually fundamental networking concepts. This option would only be valid if we were attempting to hijack a session that was taking place between two hosts on our network segment.
Remote Network Session Hijacking:
This is far more difficult to do today then it was in yesteryear, but it is not impossible. As this is only a "primer", I'm not going to go into exact details for determining an ISN (you can go here for more), but I will give you the fundamental knowledge necessary to help you with the next steps.
Remote Network Session Hijacking (RNSH) leaves the attacker blind. This is why RNSH is also referred to as "blind spoofing". The reason is because we are exploiting trust relationships between client and server on a remote network. The trust relationship is established by the rhosts file created when using services such as rlogin, rsh, or rcp. We cannot spoof a trusted host (found in the rhosts file) on a different network and see the reply packets because they are never routed back to us. We cannot ARP cache poison machines on remote networks because routers do not route ARP broadcasts across the Internet (newbie note: ARP is a layer2 function, routers work at layer3 ). Since we cannot receive the reply traffic we must anticipate the responses from the victim and keep the host we are pretending to be (spoofing) from sending a RST to the victim.
RNSH takes advantage of trust relationships between computers and you are spoofing the trusted client. If the correct spoof rules are configured on edge routers or border gateways, you will have a tremendously hard time performing a RNSH.
Necessary Steps:
1. Gauge the ISN algorithm by connecting to the machine multiple times from a machine which will receive the responses (ie. not spoofed). You can see the generated ISN by using any number of sniffers available. Sniffers available from netflood.
1A. From the incremented ISN's figure out what the next ISN will be.
1B. You will need to create packets in order to initiate the hijack.
2. DoS attack the person we will pretend to be. This makes them unresponsive when the server (victim) sends the SYN-ACK. It also keeps them from sending the dreaded RST (which will become our friend later on in the TCP DoS section).
3. Spoof the IP address of the trusted host and send a SYN (with the correct ISN) at the appropriate time. Calculating what the appropriate ISN is, shouldn't be too complicated (that's why we did #1). This should tell the computer to place the next bits of data into the receive buffer.
4. Now add 1 to the ISN and inject your data. (cat + + >> ~/.rhosts) -command courtesy of here. Obviously more commands can be used and adding the cat + + command is only useful in certain situations.
The best way for you to see blind spoofing in action is to read Shimomura's breakdown of Mitnicks *cough* alleged *cough* attack.
Defending against session hijack attacks
1. Use encrypted protocols, like those found in the OpenSSH suite
The OpenSSH suite includes the ssh program which replaces rlogin and telnet, scp which replaces rcp, and sftp which replaces ftp. Also included is sshd which is the server side of the package, and the other basic utilities like ssh-add, ssh-agent, ssh-keygen and sftp-server.
2. Use strong authentication (like Kerberos) or peer-to-peer VPN's.
3. Configure the appropriate spoof rules on gateways (internal and external).
4. Monitor for ARP cache poisoning, by using IDS products or ARPwatch.
No comments:
Post a Comment