Requirements to fully understood this page: scramble concepts.
Premature closing
implemented in fake_close_fin, and fake_close_rst, this attack aim to inject some plausible packets signaling the closure of the TCP session.
A sniffer whom tracking a lot of sessions has the needing to clean as much possible the connection table, and will search for the closure flags where possibile.
Attack details:, this couple of hacks will cause this scrambled injection:
a RST with a sequence number equal to the last ACKed +1 is send before the original packet. the ACK flag maybe presents.
a FIN + ACK is injected, ACKing the last received segment in TCP.ack_seq and using the same SEQ as the previously described.
FIN + ACK injected, ACKing the last received segment, using a SEQ anticipated by the amount of data will be ACKed the next time from the remote peer (some sniffer, like wireshark, expect the ACKing before accept a packet)
A sniffer whom tracking a lot of sessions has the needing to clean as much possible the connection table, and will search for the closure flags where possibile.
Attack details:, this couple of hacks will cause this scrambled injection:
a RST with a sequence number equal to the last ACKed +1 is send before the original packet. the ACK flag maybe presents.
a FIN + ACK is injected, ACKing the last received segment in TCP.ack_seq and using the same SEQ as the previously described.
FIN + ACK injected, ACKing the last received segment, using a SEQ anticipated by the amount of data will be ACKed the next time from the remote peer (some sniffer, like wireshark, expect the ACKing before accept a packet)
Bogus data embrace
This is in my option the best available attack, it was barely implemented also on the previous version of SniffJoke, and cause a sniffer to record a totally fake payload. Is implemented in fake_data plugin.
Attack introduction: a sniffer usuallyrecord the payload data indexing it by the sequence number (the relative sequence number is equal to the amount of data transmitted by one side of the communication), and when the TCP.ack_seq, cover the sequence previously recorded, the data is saved/dumped/recorded.
Every data packet will be ACKed only once, but will be transmitted much more time (eg: will be lost during the transmission, will corrupt the checksum at the last opt, etc...) a sniffer, should record the first packet for every sequence number, OR, with the same sequence number will update the current packet buffer (keeping the last packet for each SEQ).
Attack details the plugins wait a packet with some data inside, sniffjoke clone the packet twice, replace with a fake payload the packet, put the real packet in the middle between them and send it.
The two fake packet is scrambled, reach as first and third the destination host and begin discarded. the second packet is not scrambled, and is accepted. A sniffer record the 1st or the last, and so, has recorded a fake payload. when the server send back the tcp ACK, save the fake data.
Attack introduction: a sniffer usuallyrecord the payload data indexing it by the sequence number (the relative sequence number is equal to the amount of data transmitted by one side of the communication), and when the TCP.ack_seq, cover the sequence previously recorded, the data is saved/dumped/recorded.
Every data packet will be ACKed only once, but will be transmitted much more time (eg: will be lost during the transmission, will corrupt the checksum at the last opt, etc...) a sniffer, should record the first packet for every sequence number, OR, with the same sequence number will update the current packet buffer (keeping the last packet for each SEQ).
Attack details the plugins wait a packet with some data inside, sniffjoke clone the packet twice, replace with a fake payload the packet, put the real packet in the middle between them and send it.
The two fake packet is scrambled, reach as first and third the destination host and begin discarded. the second packet is not scrambled, and is accepted. A sniffer record the 1st or the last, and so, has recorded a fake payload. when the server send back the tcp ACK, save the fake data.
Invalid ACKing
When a sniffer see an ACK, use it as signal to records a payload (like explained in the attack before), when see an ack of a packet who don't have, will not presume an error, but presume to have loss the data packet. update him sequence, save with an error, save an empty section, override the previously saved... the behavior of the sniffer differs, but this attack will damage the sniffed incoming flow, the flow we could not mangle because sniffjoke works only client side. pretty useful in the http port. Is implemented in shift_ack plugin.
Attack detail: when a packet has the ACK flag sets, we duplicate it, scrambled as unacceptable by the remote host, has the ack_seq randomly pointing an offset inside the transmission window (note: has to be fixed with the various CWN, ECN and Window scaling TCP option), and thus totally plausible by the sniffers eyes. in wireshark cause a noisy [segment XXX was lost] inside the flow reassembly
Attack detail: when a packet has the ACK flag sets, we duplicate it, scrambled as unacceptable by the remote host, has the ack_seq randomly pointing an offset inside the transmission window (note: has to be fixed with the various CWN, ECN and Window scaling TCP option), and thus totally plausible by the sniffers eyes. in wireshark cause a noisy [segment XXX was lost] inside the flow reassembly
packets and fragment overlaps
This attack is under research, because has an OS-dependent behavior, is implemented in overlap_packets plugin.
The PUSH flag is used in the TCP transmission for signal, to the remote application, that the data send need to be passed to the application. If the client application is sending 2000 byte, and every packet will be almost large 1500 byte, mean that the first data packet will have NOT the push flag sets, but the seconds will have. of this 1500, 80 are used by IP and TCP headers and thus 1420 data byte are available.
The PUSH flag is used in the TCP transmission for signal, to the remote application, that the data send need to be passed to the application. If the client application is sending 2000 byte, and every packet will be almost large 1500 byte, mean that the first data packet will have NOT the push flag sets, but the seconds will have. of this 1500, 80 are used by IP and TCP headers and thus 1420 data byte are available.
Attack detail: The attack work sending an acceptable from the remote host, first packets, with the first 20 byte correct and the next 1400 of fake data. the relative sequence number is 1; usually, the next packet has the relative sequence number of 1421 and follow the lacking 580 byte to reach 2000. In this attack, the relative sequence number is set to 21, a packet with 1400 byte will follow. What's happen ? The 20 good byte are kept and the bad 1400 is replaced, directly in the remote kernel before the PUSH flag is used. Some Operating System will accept the replacement, some other will not. We could know this behavior by passive OS fingerprint or by guessing, but a sniffer, could implement in the high speed algorithm the emulation of different OSs ?
I don't know. If not: follow a fake data. If yep: downgrade multigiga bits to multikilo bits. :)
I don't know. If not: follow a fake data. If yep: downgrade multigiga bits to multikilo bits. :)