[Dailydave] Longer form questions

[Anton Chuvakin]

Wow, indeed, so 2007, this brings back memories ....

But on a more serious note: do you guys truly think that network security
monitoring (whether NIDS, network forensics / capture, "NTA / NDR", Bro /
Zeek and such) is "dead dead"? And there no hope for any
zombie-apocalypse-style revival? :-)

On Thu, Sep 5, 2019 at 2:41 PM Chris Rohlf <chris.rohlf at gmail.com> wrote:

> I’ve been happily ignoring Twitter the last few weeks so when I saw a DD
> post come in I got excited and felt nostalgic for 2007, which
> coincidentally this thread reminds me of. Not just because Dave is trolling
> Rob but also because I thought the idea of network based protocol and file
> parsers died around that time. How many HTTP implementation quirks does the
> Snort engine implement these days? Back then it was almost none. But what
> about now? Trick question, it doesn’t matter.
>
> Theres not enough memory or cpu in your average NIDS (or whatever they’re
> called now) to possibly keep state while monitoring the traffic volume in
> any real production deployment.
>
> I suppose theres only one RDP implementation whose quirks are worth
> reimplementing, but what are the chances they did it better than Microsoft?
> Does the MITM have as many mitigations as a modern Msft server OS? And are
> you willing to trust it with all those private keys? Does the MITM box have
> 2fa auth? Role based acl’s? What other disk did that key touch after your
> team exported it? If you’re a CISO who is losing sleep over these exploits
> but are not asking the questions above then you may not have your
> priorities straight.
>
> Chris
>
> On Thu, Sep 5, 2019 at 11:03 AM Dave Aitel <dave.aitel at gmail.com> wrote:
>
>>
>> https://blog.talosintelligence.com/2019/09/the-latest-on-bluekeep-and-dejablue.html
>>
>> Ok, so as someone pointed out in private email, they have a blog that
>> goes through a 20 step process to exporting your private key from your RDP
>> server to the MITM box that is parsing the protocol. I think this is an
>> unlikely configuration, but in theory it IS possible. An anomaly detection
>> algorithm might be a better option for real world detection, even though it
>> is not specific to the bug.
>>
>> In other words, just to annoy Rob Graham, maybe network defenses can't
>> really find every bug they want to - not just because they should not be
>> edge-devices with vast repositories of every private key on your network,
>> but because parsing requires state and state requires memory and you don't
>> have infinite memory.
>>
>> https://vimeo.com/357848836 <---also watch the INFILTRATE teaser! :)
>>
>> ALSO: I'm headed to Tel Aviv next week if there's any infosec stuff
>> happening there and anyone wants to say hi!
>>
>> -dave
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Sep 4, 2019 at 12:57 PM Dave Aitel <dave.aitel at gmail.com> wrote:
>>
>>> So I like the BLUEKEEP marketing train because it's a very hard bug to
>>> detect authoritatively for either endpoint protection or for network-based
>>> defenses. So when companies make claims about it, it's worth asking how
>>> they did that. Twitter is a terrible place for that, but since I know
>>> everyone in the industry who does this kind of thing is on this list I
>>> figured I'd ask here...
>>>
>>> -dave
>>>
>>>
>>> https://twitter.com/daveaitel/status/1169265348669005825
>>>
>>> [image: image.png]
>>>
>>> _______________________________________________
>> Dailydave mailing list
>> Dailydave at lists.immunityinc.com
>> https://lists.immunityinc.com/mailman/listinfo/dailydave
>>
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave
>


-- 
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin
Blog: https://blogs.gartner.com/anton-chuvakin/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.immunityinc.com/pipermail/dailydave/attachments/20190905/ef0a5cc7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 454315 bytes
Desc: not available
URL: <http://lists.immunityinc.com/pipermail/dailydave/attachments/20190905/ef0a5cc7/attachment-0001.png>