Hi Sebastien,
Unfortunately SniffJoke does a lot more (sending RST with bogus seq numbers,
sending SYN/FIN/RST frames, etc, I have not looked at all the frames yet). It
would take quite some effort and code to analyse the frames and consider the
context to disregard them when doing a follow TCP stream. Even if we succeed
in doing so, the sole purpose of SniffJoke is to be evasive, so they will
definitely come up with new tricks and we end up in a battle writing code.
Then think of the gain for wireshark users? If they are running SniffJoke
themselves? Well then they know what data they did send, so no use in trying to
extract it for them. If they sniffed the packets in between source and
destination, let's keep the SniffJoke purpose intact and let the user have some
form of privacy, people in between networks have no use looking into the
payload IMHO, so lets not give them extra tools to do so ;-) Of course and
experienced WS user will be able to extract the data anyhow, just not easily.
And if the WS user is at the server end analysing a problem of some client that
is using SniffJoke, they see al the bogus traffic coming from the client and
will tell them to clean up their act. So who is to benefit from code that tries
to reassemble the SniffJoke traffic? Apart from the nice exercise to do so of
course ;-) But time is limited and there are more important things to be fixed!
Regarding the Expert Info, since there are packets with all kinds of TTL's and
it would take a broader look at all frames to discover the right TTL, I would
say it would be a bit tricky to create such an expert info item. Also,
filtering on TTL alone won't do it, as you would need to save these frames to a
new file first, otherise the bogus frames will still be used for reassembly.
Cheers,
Sake
- Original Message -
From: Sébastien Tandel
To: Developer support list for Wireshark
Sent: Monday, April 27, 2009 9:46 PM
Subject: Re: [Wireshark-dev] [Full-disclosure] SniffJoke 0.3
releaseandrequestfor feedback (forw)
Hi Sake,
ok, a (TTL-1) trick. Then if *every* tricks are based on this scheme, it
could be verified with an expert item. This way, people knowing about SniffJoke
could check this expert item and create a tcp filter based on the good ttl
and re-assemble the TCP stream.
What do you think?
Regards,
Sebastien Tandel
On Mon, Apr 27, 2009 at 15:54, Sake Blok s...@euronet.nl wrote:
Sebastien,
One of the tricks SniffJoke uses is to first determine how many hops there
are to the destination and then it sends bogus traffic with a TTL that is
just 1 lower. This means the receiving OS never gets to see that traffic, while
wireshark does (when it's in between the sender and the receiving end).
If the trace is made at the receiving end and wireshark is not able to
reassemble the stream, then that might be considered a bug. Does anyone use
SniffJoke? If so, could you please make a capture at the sending and the
receiving end?
Since WS does not know which of the packets will not arrive at the
receiving end, I'm no fan of incorporating code to handle those bogus frames.
Cheers,
Sake
- Original Message -
From: Sébastien Tandel
To: Developer support list for Wireshark
Sent: Monday, April 27, 2009 7:28 PM
Subject: Re: [Wireshark-dev] [Full-disclosure] SniffJoke 0.3 release
andrequestfor feedback (forw)
SniffJoke has a nice/interesting characteristic : It is *only* used by
the sender *not* by the receiver.
SniffJoke, thanks to some tricks - which *does not* have impact on the
receiver's TCP/IP stack (for all OSes?) -, is able fool sniffers and some
others network tools.
I would expect wireshark seeing the traffic as the OS is able to see
it ... IOW, if receiver's OS is able to re-assemble correctly the traffic,
wireshark should be able to do so too. Therefore, I would consider this as a
bug in wireshark since OSes (all?) would be able to reassemble the traffic
without any problem. (Although the next question would be : who will spend time
to analyze SniffJoke tricks and fixes the TCP dissector?)
Also, I'm not convinced people will think that wireshark would
consider it as a cracking tool since the receiver's OS is considering this
SniffJoke's traffic as valid ...
Regards,
Sebastien
On Mon, Apr 27, 2009 at 11:45, Sake Blok s...@euronet.nl wrote:
As the purpose of Wireshark is to display network traffic to analyse
problems, I see no use in competing in a race to cloak and uncloak
traffic
with Sniffjoke. That would put Wireshark in the list of cracking tools
which
might have a negative effect on the places where it is allowed to be
used.
So I would not consider this a bug and I would *not* consider being
able to
reassemble Sniffloke traffic a feature
