[Snort-users] Trying to use snort with TALOS-2016-0219

Yuri Niyazov yuri at ...17684...
Mon Nov 28 20:51:32 EST 2016


Thank you very much for your help. After I included the correct filter, it
still didn't work. I then noticed that all the outgoing packets in the new
capture file had bad checksums; I disabled NIC-level checksumming ("ethtool
-K eth0 tx-checksum-ip-generic off") and did another capture, which worked
fine without disabling snort-level checksumming.

Is there a way to tell snort, while capturing, to properly calculate
checksums for packets that are outgoing from the machine? "-k all" didn't
seem to do it.

On Mon, Nov 28, 2016 at 1:03 PM, Patrick Mullen <pmullen at ...1935...>
wrote:

> Yuri,
>
> By "asymmetric," Joel means your pcap is broken.  :)  Your "works" config
> modified snort such that it ignores the fact that it can only see half of
> the traffic.  Please note that while this configuration means you did alert
> in this situation, in the long run it opens you up to evasions and other
> issues so it's not an ideal solution.
>
> I suspect that when you created your pcap, you probably did a filter like
> "dst host 162.243.66.145 and port 11211", which filtered out return traffic
> from that host.  If you instead used the filter "host 162.243.66.145 and
> port 11211", the host filter would be bidirectional (the ip could be the
> dst or src) so you should see the entire set of traffic and snort should
> alert for you without needing to change the configuration.
>
>
> Thanks,
>
> ~Patrick
>
>
> On Mon, Nov 28, 2016 at 11:17 AM, Joel Esler (jesler) <jesler at ...589...>
> wrote:
>
>> Your traffic is “asymmetric”.  This is why turning off stream makes it
>> “work”.
>>
>> Snort needs both sides of the traffic flow in order to process the
>> traffic correctly.
>>
>>
>> *--*
>> *Joel Esler *| *Talos:* Manager | jesler at ...589...
>>
>>
>>
>>
>>
>>
>> On Nov 25, 2016, at 10:41 PM, Yuri Niyazov <yuri at ...17684...> wrote:
>>
>> Hi everyone,
>>
>>   Snort newbie here. I am trying to detect the latest memcache
>> vulnerabilities, http://www.talosintelligence.c
>> om/reports/TALOS-2016-0219/
>>
>> Output of snort -V, as requested in the instructions for posting reports
>> to this list:
>>    ,,_     -*> Snort! <*-
>>   o"  )~   Version 2.9.8.3 GRE (Build 383)
>>    ''''    By Martin Roesch & The Snort Team:
>> http://www.snort.org/contact#team
>>            Copyright (C) 2014-2015 Cisco and/or its affiliates. All
>> rights reserved.
>>            Copyright (C) 1998-2013 Sourcefire, Inc., et al.
>>            Using libpcap version 1.5.3
>>            Using PCRE version: 8.31 2012-07-06
>>            Using ZLIB version: 1.2.8
>>
>> So, I have a packet capture that is the proof-of-concept exploit (code
>> copy-pasted from the vulnerability announcement). That packet capture is
>> attached. It is detected when I run "snort -c etc/works.conf -r
>> /var/log/snort/memcachedump.1480128874", I get the text below in
>> /var/log/snort/alert:
>>
>> [**] [3:40474:2] SERVER-OTHER TRUFFLEHUNTER TALOS-CAN-0219 attack attempt
>> [**]
>> [Classification: Attempted Administrator Privilege Gain] [Priority: 1]
>> 11/26-02:54:44.674785 162.243.66.145:57162 -> 162.243.91.201:11211
>> TCP TTL:63 TOS:0x0 ID:47627 IpLen:20 DgmLen:1100 DF
>> ***AP*** Seq: 0xF7EF58B0  Ack: 0x1E0819C9  Win: 0x1C9  TcpLen: 32
>> TCP Options (3) => NOP NOP TS: 3334822 5964160
>> [Xref => http://www.talosintelligence.com/reports/TALOS-2016-0219]
>>
>> However, when I run "snort -c etc/broken.conf -r
>> /var/log/snort/memcachedump.1480128874" the alert doesn't happen
>>
>> The difference between works.conf and broken.conf is that broken.conf
>> includes the stream5_global, stream5_tcp and stream5_udp preprocessors as
>> they are configured in the latest downloadable ruleset (these aren't the
>> files I will end up using, these are just the smallest difference I was
>> able to isolate between "working" and "not working").
>>
>> Now, if I understand things correctly, the streaming preprocessor
>> provides important functionality that shouldn't just be turned off blindly,
>> so, the question is: what in that preprocessor configuration could be
>> masking the memcached exploit?
>>
>>
> --
> Patrick Mullen
> Response Research Manager
> Cisco TALOS
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20161128/ba9f23a4/attachment.html>


More information about the Snort-users mailing list