IP spoofing and source routing..

I'm studying for the CCNA Security test and I have a question about IP spoofing. I dont really understand how the IP spoof technique would help an attacker intercept traffic on a network. He is one scenario discussed in the Cisco Press book:

1. "An attacker from outside the LAN spoofs an internal IP.."

--If thats the case, how is the attacker going to intercept any traffic? The router doesnt even pass internally destined traffic the outside interface of the router, right?

--Also, wont the OS detect a duplicate IP on the network?

--Even if the duplication somehow doesnt get detected, the legitimate host will receive the all the traffic because it's on the correct side of the router.

There's probably more to it that I havent got to yet, but I just want to make sure I'm not overlooking (or underlooking) anything.

What do you guys think about this?

Not necessary to be internal IP, spoofing is to hide the attackers IP so when they track the attack it won't lead them to the hacker. Also, the attacker could use several spoofed ip s so you got confused which one is the actual source of the attack. In case the attacker used internal IP, he/she will have to gain some sort of access (a Trojan for example) to retrieve that data back to his computer. But usually they just want to consume bandwidth and resources (DoS).
As for the duplicate IP, yes, it could be caught, but how many times you see an ip duplicate on your network and think of an attack?

cheers,

fliprich you have to do some reading because you are diving into some sensitive issues in security.

have a super read... i will give subsequent information later

ATTACKS - BLIND SPOOFING ATTACKS




The term "blind spoofing" is usually used to describe IP spoofing that will get you access to a system as a trusted host, but more specifically, it means that all IP spoofing is blind (even our DoS IP spoofing techniques above, but we need not to know what goes on in a DoS attack.) By this, it means that we do not know exactly what is going on, and we do not know immediately if what we have attempted has worked. We explored two kinds of blind IP spoofing: Sequence Number Prediction Attacks and single packet spoofing attacks. Sequence Number Attacks allow you to brute force or take educated guesses at the server's SYN|ACK packet's Sequence number, and thus form a connection, whereas ordinary packet spoofing just allows you to send a spoofed packet on it's own (maybe useful when spoofing a packet to a UDP port, or spoofing an ICMP request).






ATTACKS - BLIND SPOOFING ATTACKS - SEQUENCE NUMBER PREDICTION




This is the ultimate attack in IP spoofing. To gain a connection with a host by pretending to be another trusted host, all that is required is that the attacker can predict the sequence number of the server host's SYN|ACK packet after sending a SYN packet, but this task is not as simple as one might think. First, there is the issue of actually guessing the sequence number of this packet of interest, and secondly, there is the issue of the host you are spoofing of answering to the SYN|ACK packet, and sending a RST (reset connection) packet because it was not expecting the SYN|ACK packet. The second problem is actually simpler to deal with. A classic method of preventing the spoofed host from replying to the SYN|ACK packet with a RST is by SYN flooding it (see above for details). Now, on to how to solve our first problem.


There are three main ways that server's generate their sequence numbers. Thus, there are three main ways of taking an educated guess at the sequence number of the server's SYN|ACK packet. I explain them briefly below:



The 64k technique



Old Operating Systems use a strange, but easy to guess technique of generating its Sequence numbers. They use this simple set of rules:


* Increment the Sequence Number counter every second by 128000.

* Everytime a new connection is formed, increment the Sequence Number counter by 64000.


If you think about it, if you come across an old Operating System that still uses this method, it would be rather easy to spoof a connection. Some Operating Systems that use this simple method include some very old versions of SunOS, and some other old OS.



Time incrementation technique




Some Operating Systems use a method of generating Sequence Numbers. The technique used is again very simple, and thus pretty easy to break. It works like this:


"The Sequence Number counter is incremented by 'x unit of time'" This means that the Sequence Number counter is increased by 'x' every ‘unit of time'. For example, of some old Linux kernels, the Sequence counter might be increased one every microsecond ('1 usec' in this case).






Modern techniques



More modern Operating Systems (very modern) now use random number generators to generate Sequence Numbers. This makes the Sequence Number very hard to guess, almost impossible sometimes.


Now, onto the theory of how an attack could be done:



The 64k technique



All that an attacker would need to do is verify that the server host actually uses this method. This could be done by sending a packet (NOT spoofed) to the host, and examining the Sequence number, repeating the process and seeing if added together they can be divided by 64000.


When the attacker is sure of the method, he then proceeds to exploit it to get a connection making it look like it is from a "trusted" host, Host T.


* DoS Host T so that it does not respond to received packets with a RST (because it was not expecting packets from Host S (server)).


* Send a packet to Host S (server), which is NOT spoofed.


* Get the Sequence Number from the received packet, and from that, calculate the following:


GUESS = SEQ + 64000


* Now, you need to start a new connection. Spoof a SYN packet from Host T (trusted host).


* Wait, and then send an ACK packet, spoofed from Host T, with the ACK number set to GUESS + 1.


In theory, you should now have a spoofed connection between Host T, and Host S, which you can now be used to pretend to be Host T, and get access to everything Host T has access to. An example of when this would be useful is when you want to gain access to somebody’s shell via rlogin. Just say that Host S has a .rhosts file with the contents "root HostT". Host T is trusted, and automatically let in as root. If we do the above to spoof an rlogin session, theoretically we have cracked root on Host S.


One question that comes to mind now is " how can we reply to Host S with ACK packets if we don't know when it has sent them?” This is not so much of a problem as one might initially think. After a certain amount of time ("timeout") it will attempt to do a re-transmission of the data, and if then it doesn't receive an ACK packet from Host T, it will not send anymore data, but will still process your sent packets!




Time Incrementation techniques



If the system is using this method, it makes the job of the attacker considerably harder.


The same as above is done, but with a slight variation, obviously:


* DoS attack Host T, so that it does not respond with RST packets. Classically, a SYN flooding attack is used.


* Predict the correct Sequence Number (information below).


* Send a SYN packet to Host S, spoofed from Host T, to request a connection.


Wait, and send an ACK packet, with the ACKnowledgement number as the predicted Sequence Number + 1. Theoretically, there is now a connection between Host T, and Host S (server), that you can now use to pretend to be Host T (the trusted host), and access anything that Host T is allowed to access. However, as you may have realized, the main problem is actually guessing the correct Sequence Number. Since Host S is using this method of generating Sequence Numbers, it will be significantly harder than the previous method explained above (the 64k method). Virtually the only way you can guess the correct Sequence Number via Blind spoofing (i.e. you cannot see the packets, and thus examine them) is by brute forcing. One notable thing about the server host's reaction to wrong Sequence Number guesses is the fact that on some Operating Systems when a Sequence Number larger than the real one is sent, the server host sends a RST packet.




ATTACKS - BLIND SPOOFING ATTACKS - SEQUENCE NUMBER PREDICTION

TOOLS


There are many tools out there, most of them for free, available to assist an attacker whilst attempting to perform a blind spoofing attack. One of the most useful one is "SEQ-scan" which sends SYN packets to a target host, and from the received SYN|ACK packet's Sequence Numbers determines an educated guess at what the next sequence number would be. SEQ-scan can be used to determine the correct Sequence Numbers for both the old 64k Sequence Number generation technique, and the time related generation techniques.


SEQ-scan is available here:

www.thenewbiesarea.com/texts/anonym...ipspoofing2.htm


Some other good Sequence Number prediction tools include:


Mendax - rootshell.com/archive-j457nxiqi3gq5...endax_Linux.tgz

DSniff - www.monkey.org/%7Edugsong/dsniff/

Spoofit.h - www.thenewbiesarea.com/texts/anonym...ipspoofing1.htm






ATTACKS - BLIND SPOOFING ATTACKS - PACKET SPOOFING




Sometimes attackers do not actually need a connection with a server host; rather they just need to spoof a single packet, to do a certain thing. In this case, it is very much easier than the above spoofing technique; Sequence Number Prediction. In this case, all an attacker needs to do is inject a packet/datagram/segment, and set a fake source address. As you can probably see, this is quite a big flaw and security vulnerability in TCP/IP, as the TCP/IP suite makes absolutely no attempt at verifying that the supplied source address is actually the real one. Below, I will explain how an attacker could use this flaw to his/her advantage.


Say for example, there is a game that allows you to play against somebody over the Internet, but instead of using the TCP protocol for transferring the data to each opponent; it uses UDP for extra speed. imagine that the author of the game writes a little routine that made the play quit/submit the game if they send the string "LOSE" in the UDP datagram, and this option is accessed via a little menu on the game. All an attacker has to do to make his opponent lose the game is spoof a UDP datagram to appear as if it originated from your opponent, and inject the string "LOSE" into it. Here is a basic diagram of what would be happening during one of these packet-spoofing attacks:



******************************************


Host X: SRC (Host C), DATA ("LOSE") -> Host S


...Host S closes the session, and Host C loses the game...


******************************************


The datagram sent by Host X (the attacker) had a spoofed source address, pretending to be from Host C (the opponent). The game server receives the datagram, presumed it was from Host C, and consequently ended the game, leaving Host X as the winner.


This does not seem like a huge security flaw, but what if this was a login server we were attacking, which the author had written to automatically execute commands specified by the sender just by checking that the source address was right? Then the system would be at risk.


ATTACKS - BLIND SPOOFING ATTACKS - CONNECTION KILLING


As you probably know by now, the RST flag is a commonly used flag in packets, usually used to signal to the remote host that the connection should be reset. The only thing that is needed in a RST packet is the RST bit set to 1, the SEQuence number set to the client's SEQuence number + 1, and the source port. It is not as simple as simply sending a spoofed TCP packet with the RST flag set, and killing the connection.


Although this is still a serious vulnerability in TCP/IP, to exploit it we would again as above have to brute force both the source port (the port the client host is sending data from), and the correct Sequence number to send. To brute force the Sequence Number, see above. The process of brute forcing the source port is a little easier, as usually; the only possibility is the range 1024-65535.


Here is a basic diagram of what would happen during a connection killing attack:






******************************************


...Host T is communicating with Host S...


Host X: RST, SEQ (A), SRC (Host T, Port 1234) -> Host S


...Host S closes the connection because it thinks the RST packet was from

Host T...


******************************************


ATTACKS - BLIND SPOOFING ATTACKS - CONNECTION KILLING TOOLS




Although TCP connection killing is an interesting sub-topic in IP spoofing, there exist only a few tools for this purpose. A nice TCP connection-killing program written in C is "tcpkill".


You can grab the source code for tcpkill here:

packetstormsecurity.org.pk/groups/w...sniff/tcpkill.c


Note that tcpkill requires that you have libpcap installed on your UNIX machine.

You can download Libpcap here:

www.tcpdump.org/release/libpcap-0.7.2.tar.gz



ATTACKS - IP SPOOFING - SOURCE ROUTING


Source routing is an example of a classical spoofing attack and it is a pretty old trick itself. The theory behind a source routing attack is the idea that you can specify the route a packet takes, rather than just letting it go through the routers. This way, because it did not travel through routers, but through the route of the attacker's choice, packets sent can have a spoofed address, and the spoofing attack is non-blind. What is meant by non-blind is that unlike Sequence Number Prediction attacks for example, you can actually receive packets back.


Here is an example of how an attacker could spoof his address to appear to have originated from a trusted IP address, rather than his own:










******************************************


[hacker@mybox.org /root]# ifconfig eth0:0 inet 192.168.3.201 netmask

255.255.255.255


[hacker@mybox.org /root]# nc -g 192.168.3.197 -g 192.168.3.198 -g

192.168.3.199

192.168.3.200 21


******************************************

Here, the attacker attempts to initiate an FTP connection, with a spoofed source address of 192.168.3.201, by routing his connection through some other machines on the local network, instead of routers.


As we know, IP source routing is an option that can be used to specify a direct route to a destination and a return path to the origination. The route can involve the use of other routers or host that normally would be used to forward packets to the destination. Check the following scenario.


STEP 1 – the attack will spoof (change) his IP to match that of the trusted host.


STEP 2 – the attacker will construct a source route to the server that specifies the direct path the IP packets should take to the server and take back from the server to the attackers host using the client as the last hop in the route to the server.


STEP 3 – the attacker send a client request to the server using the source route.


STEP 4 – the server accept the client request as if it came from the trusted client and return reply to the trusted client.


STEP 5 – the trusted client using the source route forwards the packet unto the attackers host.



Many routers accept source routed packets and pass them on as the source route indicates, but some routers can be configured to block source routed packets




Although this attack is effective when successful, not all machines (UNIX and UNIX-like) are configured by default to relay source routed TCP stream packets. If one of machines an attacker attempts to route his packets through does not accept source routed TCP packets, the spoofing attack will consequently fail. One major upside to this attack for an attacker is that the attack is non-blind, meaning that he/she can see the packets, just like an ordinary connection, however it is limited to their local network. Although this is quite a serious vulnerability in the TCP/IP suite, it is very easily fixed. All that is needed is that the root user changes the contents of /proc/sys/net/ipv4/conf/all/accept_source_route to 0 in UNIX



ATTACKS - IP SPOOFING - FURTHER READING


You might want to read more about IP spoofing. Here are some good links for further reading on the subject:



IP spoofing




www.securityfocus.com/infocus/1674

www.hack.gr/Linux/gazette/issue63/sharma.html

www.cert.org/advisories/CA-1996-21.html

www.phrack.org/phrack/48/P48-14

bau2.uibk.ac.at/matic/spoofing.htm



ATTACKS - TCP SESSION HIJACKING


TCP session hijacking is the term used to describe an attacker who hijacks an already established connection usually allowing them to execute commands as the actual connected user.


It is usually due to slight design errors in the TCP/IP suite that makes these kinds of attacks. This situation makes it easy for the attacker to seize access to the connection and execute commands as the legitimate user.


There are various types of TCP session hijacking techniques, but the commonly used one, and arguably, the most popular of TCP hijacking techniques is the "Man-in-the-middle" attack.





ATTACKS - TCP SESSION HIJACKING - MAN-IN-THE-MIDDLE ATTACK


The "man-in-the-middle" attack is a common method of taking over a TCP connection between two hosts, and allowing the attacker who has gained access to the connection to execute commands as the client host. This is done by active passive sniffing of the network for packets traveling which are related to the target session, modifying them, and injecting them back into the Network so that the two connected hosts cannot easily tell that any modification of the packets has been done.


Before an attacker can carry out a man-in-the-middle attack between two connected hosts, they must first somehow get between the communications path of Host C and Host S. The classical way of doing this is known as "ARP spoofing" or "ARP poisoning". The ARP table on a host is just a method that a network host uses to keep track of MAC and IP address associations. Very often, one host on the network might send out an ARP request. An ARP request asks a question like this; "Is your IP address x.x.x.x? If so, send me your MAC address.” The message is then broadcast across the network, and the host with the IP address x.x.x.x replies to the ARP request, providing its MAC address with it. ARP spoofing therefore is sending out ARP replies (nobody has necessarily asked for it, the attacker just sends one) with a spoofed source address from the IP address you want the hosts to believe you are. The host will then update its own ARP cache table, now associating your machine's MAC address with the spoofed IP address, thus sending all traffic meant for x.x.x.x to you. In this case then, the attacker's need for ARP spoofing in his planned "man-in-the-middle" attack is the process of changing Host C's ARP cache to make it believe that the IP address of Host S is the attacker's IP address, and changing Host S's ARP cache to make it believe that Host C's IP address is the attacker's. All very interesting, but how do we actually do this? Here is a simple diagram of what happens during an ARP poisoning/spoofing attack:






******************************************

The attacker broadcasts an ARP reply, claiming that it infact owns the IP address x.x.x.x


Host X: DST (Host S), SRC (Host C), DATA ("I own x.x.x.x, my MAC address is xx:xx:xx:xx")


Host X: DST (Host C), SRC (Host S), DATA ("I own y.y.y.y, my MAC address is yy:yy:yy:yy.")


******************************************




What the attacker has done is forge an ARP reply to be pretending to originate from Host C, to Host S, saying that it in fact owns the IP address x.x.x.x, and that it's MAC address is xx:xx:xx:xx. Host S now believes that Host C's IP address is x.x.x.x, and it is, but it also believes now that Host C's MAC address is xx:xx:xx:xx, but it is not, it is the attacker's MAC address! Now every time Host S has a packet that it intends for Host C, it searches through its ARP cache, and determines that Host C's MAC address is xx:xx:xx:xx, but it is not. It is in fact the attacker's address but believes so because of your spoofed ARP reply!


Then the attacker spoofs an ARP reply to be pretending from Host S, to Host C, telling it that it owns the IP address y.y.y.y. It sees that the ARP reply is coming from yy:yy:yy:yy, and thus associates the IP address y.y.y.y with the attacker's MAC address yy:yy:yy:yy.


Now that the attacker has both hosts believing that each other's MAC addresses are in fact the attacker's, all he needs to do now is watch all packets traveling through his machine that are related to the connection between Host S and Host C. He modifies them accordingly, and then forwards them to the host they were originally intended for so that their connection is not interrupted.


Here is a small diagram of what would be happening during a Man-In-the-Middle session hijacking attack, assuming that the ARP poisoning attack had already taken place





******************************************


Host S: DST (Host C), DATA ("Welcome to the system. You are using the bash shell")


-> Host C ...sent to Host X (attacker) because of the earlier ARP poisoning attack.

Host X forwards the packet, not making any changes...


Host C: DST (Host S), DATA ("ls") -> Host S...again, Host X (attacker) receives this because it tricked Host C with the ARP poisoning attack above. Host X forwards the packet to Host S without any changes, because they are only issuing the 'ls' command...


Host S: DST (Host C), DATA ("tmp codes exploits Desktop mp3s") ->

Host C ...Host X again decides not to make any modifications to the packet, as Host S (the server) is only sending the directory listings back, nothing special...


Host C: DST (Host S), DATA ("passwd") -> Host S...The attacker's head shoots up. The user is going to change their password. The attacker can edit the packet in which the user specifies their new password, and set it to what they want. Host X forwards the packet to Host S without any changes...


Host S: DST (Host C), DATA ("(current) UNIX password: ") ->

Host C...Host X forwards the packet with out any modifications to Host C...


Host C: DST (Host S), DATA ("elitehacker") ->



Host S ...Host X receives the packet. Although the attacker now has the user's password, it does not really matter, because he will issue a new password is a few moments, and he (the attacker) will modify it...


Host S: DST (Host C), DATA ("New UNIX password: ") -> Host C


...Host X forwards the packet to Host C, with no modifications. The time is near to when the attacker will modify Host C's packets...


Host C: DST (Host S), DATA ("elitehacker123") -> Host S


...Host X receives the packet. The attacker modifies the packet data to now contain "elitehacker234", injects the packet back into the network, and forwards it to Host S....


Host S: DST (Host C), DATA ("Retype new UNIX password: ") -> Host C


...Host X forwards the packet with no modifications to Host C...


Host C: DST (Host S), DATA ("elitehacker123") -> Host S


...Host X receives the packet, the attacker modifies the packet, and edits the packet data to say "elitehacker234", and forwards the packet appropriately to Host S...


Host S: DST (Host C), DATA ("passwd: all authentication tokens updated successfully.")

-> Host C


...Host X receives the packet, and as usual, forwards it to Host C...


******************************************


At this point, the user on Host C happily presumes that their password has been changed successfully (they saw the messages themselves), and gets on with their daily work. However, little do they know that the attacker actually edited the packets, and the password is now "elitehacker234", not "elitehacker123" as the victim thinks.


In addition, in ARP poisoning the attacker can fill the CAM table of a switch with MAC - Port entries in order to try to change the switch back to a single collision domain. This would then in effect turn the switch into a hub as it does not have mappings to know what is on which port and therefore floods the traffic to all ports.


STOPPING MAN IN THE MIDDLE ATTACK


Fortunately, on high-end switches (at least 4500 and 6500) you can detect MAC address move by configuring "MAC-address-table notification MAC-move" command. You can also protect your network with features like port-security but it is hard to manage if you have many legal moves in your network (i.e. user with laptop).

For Small Networks
If you manage a small network, you might try using static IP addresses and static ARP tables. Using CLI commands, such as "ipconfig /all" in Windows or "ifconfig" in 'NIX, you can learn the IP address and MAC address of every device in your network. Then using the "arp -s" command, you can add static ARP entries for all your known devices. "Static" means unchanging; this prevents hackers from adding spoofed ARP entries for devices in your network. You can even create a login script that would add these static entries to your PCs as they boot.

However, static ARP entries are hard to maintain and impossible in large networks. That is because every device you add to your network has to be manually added to your ARP script or entered into each machine's ARP table. However, if you manage fewer than two dozen devices, this technique might work for you.

For Large Networks
If you manage a large network, research your network switch's "Port Security" features. One "Port Security" feature lets you force your switch to allow only one MAC address for each physical port on the switch. This feature prevents hackers from changing the MAC address of their machine or from trying to map more than one MAC address to their machine. It can often help prevent ARP-based Man-in-the-Middle attacks.

For All Networks
Your best defense is an understanding of what ARP Poisoning is and watching out for it. I would highly recommend deploying an ARP monitoring tool, such as ARPwatch to alert you when unusual ARP communication occurs. This kind of vigilance is still the greatest weapon against all kinds of attack.

In addition, ZoneAlarm can stop ARP poisoning. I have found a way in ZoneAlarm to prevent your computer from being spied on. ZoneAlarm is a personal firewall and you can get the free version online. The option is called "ARP Protection" in ZA, it might not be the same on other programs but this is how to enable it (It is off by default).

Open the ZA window and on the left hand side:

Click "Firewall"

Now on the bottom right of the new dialog that appears

Click the advanced button. You will be presented with a dialog like this: (Take note of all the other things ZA has available).

Next click the "Enable ARP Protection" checkbox and there you go!





ATTACKS - TCP SESSION HIJACKING - TOOLS


There are various interesting tools in relation to TCP session hijacking attacks. Here are a few popular ones:


HUNT - packetstormsecurity.nl/sniffers/hunt/

Ettercap - ettercap.sourceforge.net/


Further interesting tools related to TCP session Hijacking can be found at;


www.packetstormsecurity.org



ATTACKS - TCP SESSION HIJACKING - FURTHER READING


You might want to do a little further research after my brief explanation of attacks. Here are some few good links for further reading:


www.iss.net/security_center/advice/...ing/default.htm

staff.washington.edu/dittrich/talks...ora/hijack.html

www.cs.cornell.edu/Courses/CS519/20...Ctcphijack.html

weadmin.com/satish/talk/non_blind_s...ion_hijack.html

Thank you verymuch Sose. You have provided a execellent information.

Hell yeah Sose, thanks for that. I appreciate it.

I am glad to be helpful. when you are into security you read more than medical students. this is a small piece, you can go gurther than this to see the bits off the wire and even have more control processing by working on some C codes. C is a networking programming language.

keep in touch man...