Learn Ethical Hacking & get free Hacking Tools

[Learn Ethical Hacking & Get free hacking tools and softwares]

Learn Ethical Hacking & get free Hacking Tools

---

• Programs that perform Session Hijacking
• Sequence Numbers - crucial to hijacking a session
• Types of session Hijacking
• Steps in Session Hijacking
• Spoofing Vs Hijacking
• Understanding session hijacking

Programs that perform Session Hijacking Posted: 25 Jul 2009 07:05 AM PDT Programs that perform Session Hijacking There are several programs available that perform session hijacking. Following are a few that belongs to this category: Juggernaut Hunt TTY Watcher IP Watcher T-Sight There are few programs/source codes available for doing a TCP hijack. Juggernaut TTY Watcher IP Watcher T-Sight Hunt Hacking Tool: Juggernaut Juggernaut is a network sniffer that can be used to hijack TCP sessions. It runs on Linux Operating systems. Juggernaut can be set to watch for all network traffic or it can be given a keyword like password to look out for. The main function of this program is to maintain information about various session connections that are occurring on the network. The attacker can see all the Juggernaut is basically a network sniffer that can also be used to hijack TCP sessions. It runs on Linux and has a Trinux module as well. Juggernaut can be activated to watch all network traffic on the local network. For example, Juggernaut can be configured to wait for the login prompt, and then record the network traffic that follows (usually capturing the password). By doing so, this tool can be used to capture certain types of traffic by simply leaving the tool running for a few days, and then the attacker just has to pick up the log file that contains the recorded traffic. This is different than regular network sniffers that record all network traffic making the log files extremely huge (and thus easy to detect). However, the main feature of this program is its ability to maintain a connection database. This means an attacker can watch all the TCP based connection made on the local network, and possibly "hijack" the session. After the connection is made, the attacker can watch the entire session (for a telnet session, this means the attacker sees the "playback" of the entire session. This is like actually seeing the telnet window). When an active session is watched, the attacker can perform some actions on that connection, besides passively watching it. Juggernaut is capable of resetting the connection (which basically means terminating it), and also hijacking the connection, allowing the attacker to insert commands in the session or even to completely take the session into his hands (resetting connection on the legitimate client). sessions and he can pick a session he wants to hijack. ---Regards, Amarjit Singh ---Regards, Amarjit Singh

Sequence Numbers - crucial to hijacking a session Posted: 25 Jul 2009 07:02 AM PDT Sequence Numbers Sequence Numbers are very important to provide reliable communication but they are also crucial to hijacking a session. Sequence numbers are a 32-bit counter, which means the value can be any of over 4 billion possible combinations. The sequence numbers are used to tell the receiving machine what order the packets should go in when they are received. Therefore an attacker must successfully guess the sequence number to hijack a session. TCP provides a full duplex reliable stream connection between two end points. A connection is uniquely defined by the IP address of sender, TCP port number of the sender, IP address of the receiver and TCP port number of the receiver. Every byte that is sent by a host is marked with a sequence number and is acknowledged by the receiver using this sequence number. The sequence number for the first byte sent is computed during the connection opening. It changes for any new connection based on rules designed to avoid reuse of the same sequence number for two different sessions of a TCP connection. We have sent the increment of sequence number in our discussion of the three way handshake. What happens if the sequence number is predictable? When the TCP sequence is predictable, an attacker can send packets that are forged to appear to come from a trusted computer. The next step taken was to tighten the OS implementation of TCP and introduce randomness in the ISN. This was done by the use of pseudo-random number generators (PRNGs). PRNGs introduced some randomness when producing ISNs used in TCP connections. However, adding a series of numbers together provided insufficient variance in the range of likely ISN values; thereby allowing an attacker to disrupt or hijack existing TCP connections or spoof future connections against vulnerable TCP/IP stack implementations. This implied that systems relying on random increments to make ISN numbers harder to guess were still vulnerable to statistical attack. In other words, with the passage of time, even computers choosing random numbers will repeat themselves, because the randomness is based on an internal algorithm that is used by a particular operating system. 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. Threat If a sequence number within the receive window is known, an attacker can inject data into the session stream or choose to terminate the connection. If the attacker knows the initial sequence number, he can send a simple packet to inject data or kill the session if he is aware of the number of bytes transmitted in the session this far. As this is a difficult proposition, the attacker can guess a suitable range of sequence numbers and send out a number of packets into the network with different sequence numbers - but falling within the range. Since the range is known, it is likely that at least one packet will be accepted by the server. This way, the attacker need not send a packet for every sequence number, but resort to sending an appropriate number of packets with sequence numbers a window-size apart. But how does he know how many packets are to be sent? This is obtained by dividing the range of sequence numbers to be covered by the fraction of the window size that is used as an increment. Why was this possible despite the introduction of PRNGs? The problem lay in the use of increments themselves, random or otherwise, to advance an ISN counter, making statistical guessing practical. The result of this is that remote attackers can perform session hijacking or disruption by injecting a flood of packets with a range of ISN values, one of which may match the expected ISN. The more random the ISNs are, the more difficult it is to carry out these attacks. ---Regards, Amarjit Singh ---Regards, Amarjit Singh

Types of session Hijacking Posted: 25 Jul 2009 07:01 AM PDT Types of session Hijacking There are two types of hijacking attacks: Active In an active attack, an attacker finds an active session and takes over. Passive With a passive attack, an attacker hijacks a session, but sits back and watches and records all of the traffic that is being sent forth. Session hijacking can be active or passive in nature depending on the degree of involvement of the attacker in the attack. The essential difference between an active and passive hijack is that while an active hijack takes over an existing session, a passive attack monitors an ongoing session. Generally a passive attack uses sniffers on the network allowing the attacker to obtain information such as user id and password so that he can use it later to logon as that user and claim his privileges. Password sniffing is only the simplest attack that can be performed when raw access to a network is obtained. Counters against this attack range from using identification schemes such as one-time password (e.g. skey) to ticketing identification (such as Kerberos). While these may keep sniffing from yielding any productive results, they do not insure the network from an active attack neither as long as the data is neither digitally signed nor encrypted. In an active attack, the attacker takes over an existing session by either tearing down the connection on one side of the conversation or by actively participating by being the man-in-the-middle. These have been discussed at length under the discussion covering the various steps involved in a session hijack. This requires the ability to predict the sequence number before the target can respond to the server. Sequence number attacks have become much less likely because OS vendors have changed the way initial sequence numbers are generated. The old way was to add a constant value to the next initial sequence number; newer mechanisms use a randomized value for the initial sequence number. ---Regards, Amarjit Singh ---Regards, Amarjit Singh

Steps in Session Hijacking Posted: 25 Jul 2009 07:00 AM PDT Tracking the session Desynchronizing the connection Injecting the attacker's packet How does an attacker go about hijacking a session? The hijack can be broken down into four broad phases. Tracking the connection The attacker will wait to find a suitable target and host. He use a network sniffer to track the victim and host or identify a suitable user by scanning with a scanning tool such as nmap to find a target with a trivial TCP sequence prediction. This is done to ensure that because the correct sequence and acknowledgement numbers are captured, as packets are checked by TCP through sequence and/or acknowledgement numbers. These will later be used by the attacker in crafting his own packets. Desynchronizing the connection A desynchronized state is when a connection between the target and host is in the established state; or in a stable state with no data transmission; or the server's sequence number is not equal to the client's acknowledgement number; or the clients sequence number is not equal to the server's acknowledgement number. To desynchronize the connection between the target and host, the sequence number or the acknowledgement number (SEQ/ACK) of the server must be changed. This can be done if null data is sent to the server so that the server's SEQ/ACK numbers will advance; while the target machine will not register such an increment. The desynchronizing is preceded by the attacker monitoring the session without interference till an opportune moment, when he will send a large amount of " null data" to the server. This data serves only to change the ACK number on the server and does not affect anything else. The attacker does likewise to the target also. Now both the server and target are desynchronized. Resetting the connection Another approach is to send a reset flag to the server and tearing down the connection on the server side. This is ideally done in the early setup stage. The goal of the attacker is to break the connection on the server side and create a new one with different sequence number. The attacker listens for a SYN/ACK packet from the server to the host. On detecting the packet, he sends an RST to the server and a SYN packet with exactly the same parameters such as port number but a different sequence number. The server on receiving the RST packet, closes connection with the target, but initiates another one based on the SYN packet - with a different sequence number on the same port. Having opened a new connection, the server sends a SYN/ACK packet to the target for acknowledgement. The attacker detects (but does not intercept) this and sends back an ACK packet to the server. Now, the server is in the established state. The target is oblivious to the conversation and has already switched to the established state when it received the first SYN/ACK packet from the server. Now both server and target are in desynchronized but established state. This can also be done using a FIN flag, but this will cause the server to respond with an ACK and give away the attack through an ACK storm. This results due to a flaw in this method of hijacking a TCP connection. When receiving an unacceptable packet the host acknowledges it by sending the expected sequence number and using its own sequence number. This packet is itself unacceptable and will generate an acknowledgement packet which in turn will generate an acknowledgement packet, thereby creating a supposedly endless loop for every data packet sent. The mismatch in SEQ/ACK numbers results in excess network traffic with both the server and target trying to verify the right sequence. Since these packets do not carry data they are not retransmitted if the packet is lost. However, since TCP uses IP the loss of a single packet puts an end to the unwanted conversation between the server and target on the network. The desynchronizing stage is added in the hijack sequence so that the target host is kept in the dark about the attack. Without desynchronizing, the attacker will still be able to inject data to the server and even keep his identity by spoofing an IP address. However, he will have to put up with the server's response being relayed to the target host as well. Injecting the attacker's packet Now that the attacker has interrupted the connection between the server and target, he can choose to either inject data into the network or actively participate as the "man in the middle", and pass data from the target to the server, and vice versa, reading and injecting data as he sees fit. Illustration: Alice opens a telnet session to Bob and starts doing some work. Eve observes the connection between Alice and Bob using a sniffer that is integrated into her hijacking tool. Eve makes a note of Alice's IP address and her hijacking software samples the TCP sequence numbers of the connection between Alice and Bob. Eve launches a DoS attack against Alice to stop Alice doing further work on Bob and to prevent an ACK storm from interfering with her attack. Eve generates spoofed packets with the correct TCP sequence numbers and connects to Bob. Bob thinks that he is still connected to Alice. Alice notices a lack of response from Bob and blames it on the network. Eve finds herself at a root prompt on Bob. She issues some commands to make a backdoor and uses the sniffer to observe the responses from Bob. After covering her tracks, Eve logs out of Bob and ceases the DoS attack against Alice. Alice notices that her connection to Bob has been dropped. Eve uses her backdoor to get directly into Bob. ---Regards, Amarjit Singh ---Regards, Amarjit Singh

Spoofing Vs Hijacking Posted: 25 Jul 2009 06:58 AM PDT A spoofing attack is different from a hijack in that an attacker is not actively taking another user offline to perform the attack. he pretends to be another user or machine to gain access. The early record of a session hijacking is perhaps the Morris Worm episode that affected nearly 6000 computers on the ARPANET in 1988. This was ARPANET's first automated network security incident. Robert T. Morris wrote a program that would connect to another computer, find and use one of several vulnerabilities to copy itself to that second computer, and begin to run the copy of itself at the new location. Both the original code and the copy would then repeat these actions in an infinite loop to other computers on the ARPANET. Though this has found reference time and again in the context of worms and denial of service, the basic working of the Morris worm was based on the discovery that the security of a TCP/IP connection rested in the sequence numbers and that it was possible to predict them Blind IP spoofing involves predicting the sequence numbers that the victimized host will send in order to create a connection which appears to originate from the host. Before exploring blind spoofing further, let us take a look at sequence number prediction. TCP sequence numbers are used to provide flow control and data integrity for TCP sessions. Every byte in a TCP session has a unique sequence number. Moreover, every TCP segment provides the sequence number of the initial byte (ISN), as part of the segment header. The initial sequence number does not start at zero for each session. Instead, the participants specify initial sequence numbers as part of the handshake process-a different ISN for each direction-and begin numbering the bytes sequentially from there. Blind IP spoofing relies on the attacker's ability to predict sequence numbers as he is unable to sniff the communication between the two hosts by virtue of not being on the same network segment. He cannot spoof a trusted host on a different network and see the reply packets because the packets are not routed back to him. He cannot resort to ARP cache poisoning as well because routers do not route ARP broadcasts across the Internet. As he is not able to see the replies he is forced to anticipate the responses from the victim and prevent the host from sending a RST to the victim. The attacker then injects himself into the communication by predicting what sequence number the remote host is expecting from the victim. This is used extensively to exploit the trust relationships between users and remote machines, these services include NFS, telnet, IRC, etc. IP spoofing is relatively easy to accomplish. The only pre-requisite on part of the attacker is to have root access on a machine in order to create raw packets. In order to establish a spoofed connection the attacker must know what sequence numbers are being used. Therefore, IP spoofing forces the attacker to have to predict the next sequence number. The attacker can use "blind" hijacking, to send a command, but can never see the response. However, a common command would be to set a password allowing access from somewhere else on the net. The attack became famous when Kevin Mitnick used it to hack into Tsutomu Shimomura's computer network. The attack exploited the trust that Shimomura's machines had with the other network. By SYN flooding the trusted host, Mitnick was able to establish a short connection which was then used to gain access through traditional methods. With Hijacking an attacker is taking over an existing session, which means he is relying on the legitimate user to make a connection and authenticate. Then take over the session. With IP Spoofing there is no need to guess the sequence number since there is no session currently open with that IP address. The traffic would get back to the attacker only by using source routing. This is where the attacker tells the network how to route the output and input from a session, and he simply sniffs it from the network as it passes by him. Source routing is an IP option used today mainly by network managers to check connectivity. Normally, when an IP packet leaves a system, its path is controlled by the routers and their current configuration. Source routing provides a means to override the control of the routers. When an attacker uses captured, reverse engineered or brute forced authentication tokens to take over the control of a legitimate user's session while he is in session, the session is said to be hijacked. Due to this attack, the legitimate user may loose access or be deprived of the normal functionality of the session to the attacker, who now acts with the user's privileges. Most authentications occur at the beginning of a TCP session, this makes it possible for the attacker to gain access to a target machine. A popular method attackers adopt is to use source-routed IP packets. This allows an attacker to become a part of the target - host conversation by deceiving the IP packets to pass through his system. The attacker can also carry out the classic man-in-the-middle attack using a sniffing program to monitor the conversation. In TCP session hijacking, a familiar aspect of the attacks is the carrying out of a denial-of-service (DoS) attack against the target / host to prevent it from responding by either forcing the machine to crash, or against the network connection to result in a heavy packet loss (e.g. SYN flood). Session hijacking is even more difficult than IP address spoofing. In session hijacking, John would seek to insert himself into a session that Jane already had set up with \\Mail. John would wait until Jane established a session, then knock her off the air by some means and pick up the session as though he was her. As before, John would send a scripted set of packets to \\Mail but would not be able to see the responses. To do this, he would need to know the sequence number in use when he hijacked the session, which could be calculated knowing the ISN and the number of packets that have been exchanged. Successful session hijacking is extremely difficult and only possible when a number of factors are under the attacker's control. Knowledge of the ISN would be the least of John's challenges. For instance, he would need a way to knock Jane off the air at will. He also would need a way to know the exact status of Jane's session at the moment he mounted his attack. Both of these require that John have far more knowledge about and control over the session than normally would be possible. However, IP address spoofing attacks can only be successful if IP addresses are used for authentication. An attacker cannot perform IP address spoofing or session hijacking if per-packet integrity checking is executed. Similarly, neither IP address spoofing nor session hijacking are possible if the session uses encryption such as SSL or PPTP, as the attacker will not be able to participate in the key exchange. Therefore the essential requirements to hijack non-encrypted TCP communications can be listed as: Presence of non-encrypted session oriented traffic, ability to recognize TCP sequence numbers and predict the next sequence number (NSN) and capability to spoof a hosts MAC or IP address to receive communications which are not destined for the attackers host. If the attacker is on the local segment, they can sniff and predict the ISN+1 number and have the traffic routed back to them by poisoning the ARP cache. ---Regards, Amarjit Singh ---Regards, Amarjit Singh

Understanding session hijacking Posted: 25 Jul 2009 06:56 AM PDT Understanding the flow of message packets over the Internet by dissecting the TCP stack. Understanding the security issues involved in the use of IPv4 standard Familiarizing with the basic attacks possible due to the IPv4 standard. At its simplest level, TCP hijacking relies on the violation of trust relationships between two interacting hosts. Before we go into the details of session hijacking, let us take a look at the TCP stack and the IPv4 protocol, to understand why this attack is possible. Consider the everyday scenario when you access the Internet with your browser - say IE. IE works at the application layer and accepts the initial datagram to be sent across the Internet. The transport protocol comes into action in the next layer - aptly called the transport layer - and the appropriate protocol header is added to the datagram. Here it is TCP header, as it is the TCP protocol that is being used. This ensures the reliability of data transported over inherently unreliable communication platforms, and also controls many of the aspects in the management and initiation of communication between the two hosts. In the network layer, routers offer the functionality for the datagram to hop from source to the destination, one hop at a time. This also sees the IP header being added to the datagram. The final layer that communicated with the physical hardware is the data link layer. This layer is responsible for the delivery of signals from the source to the destination over a physical communication platform, which in this case is the Ethernet. Now, the headers are peeled back on reaching the destination to reveal the original datagram. Having understood the TCP stack, let us look at IPv4. The original IPv4 standard needed to address three basic security issues - authentication, integrity and privacy. Authentication was an issue because an attacker could easily spoof an IP address and exploit a session. Spoofing was not restricted to IP address alone, but also extended to MAC addresses in ARP spoofing. An attacker sniffing on a network could sniff packets and carry out simple attacks such as change, delete, reroute, add, forge or divert data. Perhaps the most popular among these attacks is the Man-In-the-Middle attack. An attacker can grab unencrypted traffic from a victim's network-based TCP application, further tampering with the authenticity and integrity of the data before forwarding it on to the unsuspecting target. ---Regards, Amarjit Singh ---Regards, Amarjit Singh

You are subscribed to email updates from Learn Ethical Hacking & Get free hacking tools and softwares To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google Inc., 20 West Kinzie, Chicago IL USA 60610