On Tue, 5 Oct 1999, Gilbert Ramirez wrote:
> I ran across this interesting article about defeating sniffers.
> Some of the advanced techniques in this article might be enough
> to fool ethereal's tcp re-sequencer; I'm not knowledgable enough
> about follow.c to know.
>
> http://www.phrack.com/search.phtml?view&article=p54-10
I can comment on a few of the attacks.
The One Host Design will not work against ethereal if you simply choose a
packet other than the "faked" SYN. All the information used to build the
filter is aquired from the packet that the user selects.
The Ip options attack will also not work, because our follow.c code
depends on packet-tcp to do all the tcp decoding and the packet-ip to take
care of ip. As long as the packet-*'s are working, then follow will get
the correct info.
The FIN and RST and playing with sequence number attack does not worked as
described, but I can think of ways you could play with the sequence
numbers and possibly get ethereal to puke. The method they describe in the
paper will not work against ethereal and follow.c will reconstruct the
packet correctly. However, if you send information through follow.c that
is not really a vaild TCP connection, we should expect that the code might
have some unpredictable behavior. I will look at this a little closer when
I get a chance. I guess the short answer is that we are fine with this
attack as described, but if you really throw some trash through the
sequence number tracking code, you could get it to mess up.
The insertion - data spoofing - attack. Well this one is interesting. I
have looked at the implementations of several stacks and they all treat
this differently. Since ethereal does track the sequence numbers, it will
handle this, but the question is _how_ does it handle it. Well, if you
receive an overlap packet, then only the data that has not already been
recorded is added. Some stacks overwrite the entire sequence number space.
An example. If you have a connection that starts with seq# 1000 and ends
with #10000.
after you have already seen all the packets up to #3450 you get a packet
that starts at #3400 and is 100 bytes large. Ethereal and many other
stacks I have seen will only add the "new" 50 bytes onto the end of the
recorded session. Some stacks will replace the 50 bytes from 3400 to 3450
with the new bytes sent in the later packet.
IP fragmentation is a problem. Unless all the IP fragments are
reassymebled and then sent through packet-tcp, follow.c will possibly
never see the packets.
The post connection SYN will work work against ethereal.
The pre connection SYN probably will work. I would need to see a trace of
this attack to know for sure. As far as I can tell there is no TCP
checksum testing. oops.
FIN and RST spoofing. Again here we are not checking the TCP checksum, but
follow.c does not care about FIN and RST so we should have no trouble.
Data Spoofing with short TTL. This is a neat one. We would get fooled if
they knew how ethereal tracked things.
Well, that is a short stab at what I think follow.c would do. I didn't
spend alot of time on this but I do think this is how the code would
react.
--Mike
+===================================================================+
| Mike Hall Real programmers dream in Java. |
| mlh@xxxxxx Linux rules! Everything else just works. |
+===================================================================+
| finger mlh@xxxxxx for public PGP key |
+===================================================================+
