Wireshark-dev: Re: [Wireshark-dev] [Full-disclosure] SniffJoke 0.3 releaseandrequestfor feedbac

Date Prev · Date Next · Thread Prev · Thread Next
Date Index · Thread Index · Other Months · All Mailing Lists
From: "Sake Blok" <sake@xxxxxxxxxx>
Date: Mon, 27 Apr 2009 22:14:03 +0200
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 -----
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 <sake@xxxxxxxxxx> 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 -----
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 <sake@xxxxxxxxxx> 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 to implement.

Just my $0.02


Sake

----- Original Message -----
From: "Joerg Mayer" <jmayer@xxxxxxxxx>
To: <wireshark-dev@xxxxxxxxxxxxx>
Sent: Monday, April 27, 2009 3:53 PM
Subject: [Wireshark-dev] [Full-disclosure] SniffJoke 0.3 release and
requestfor feedback (forw)


> Should it be considered a bug if WS can be fooled by a tool like Sniffjoke
> to incorrectly reassemble a TCP stream?
> The webpage has two sample traces that seem to be handeled incorrectly by
> HEAD indeed.
>
> Ciao
>   Joerg
> ----- Forwarded message from vecna <vecna@xxxxxxxxxx> -----
>
> Delivered-To: jmayer@xxxxxxxxxxxxxxxxxxxxxxxxx
> Delivered-To: full-disclosure@xxxxxxxxxxxxxxxxx
> Date: Wed, 15 Apr 2009 09:27:39 +0200
> From: vecna <vecna@xxxxxxxxxx>
> Organization: SALVIA & MENTA, azione TOTALE, aiuta a prevenire placca,
> carie
> e disturbi gengivali.
> To: full-disclosure@xxxxxxxxxxxxxxxxx
> Subject: [Full-disclosure] SniffJoke 0.3 release and request for feedback
> Errors-To: full-disclosure-bounces@xxxxxxxxxxxxxxxxx
>
> Some days ago I've relased this:
>
> SniffJoke is a "connection scrambler" for Linux with the purpose of
> preventing packet sniffers from reassemble network sessions of the user.
> The "sniffer evasion" technology is well known since almost 10 years.
> SniffJoke implements the most efficents techniques. Using a local fake
> tunnel it is able to manage outgoing and ingoing packets without
> disturbing the kernel. With the local web interface the user can easily
> start/stop and configure SniffJoke. At the moment, Wireshark, the most
> famous packet analyzer, is unable to correctly reconstruct TCP flow
> mangled by SniffJoke. I would like to update the list of victim
> sniffers, so please send me a report if you test SniffJoke with other
> network protocol analyzers.
>
> http://www.delirandom.net/20090402/sniffjoke-03/
> http://www.delirandom.net/sniffjoke/
>
>
> Any comments appreciate
>
> Regards,
> vecna
>
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
> ----- End forwarded message -----
>
> --
> Joerg Mayer                                           <jmayer@xxxxxxxxx>
> We are stuck with technology when what we really want is just stuff that
> works. Some say that should read Microsoft instead of technology.
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
>


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe