Re: [Dailydave] Latency is a demogorgon

[Parity]

A fun question to ask is, *"why wasn't that Cisco ASA remote patched?"*

Because EQGRP didn't tell Cisco about it, duh.

But, wait, if you're EQ and suddenly a bunch of your vulns are in the wind,
you're bloody well going to rethink the equities there, right? Especially
knowing that an adversary was suddenly in possession of a bunch of your
unpatched vulnerabilities...

Unless, of course, you didn't know.

pty

(Alternative explanations: 1. the vuln just got lost in the bureaucracy; 2.
meh, it's just a persistence bug, and notifying the vendor would be a tell;
3. some bugs get disclosed, some bugs don't, and, say, an inquiring mind
might discern a thing or two about the equities process by reviewing which
ones got patched, and when, and which ones didn't.)


On Wed, Aug 17, 2016 at 8:01 AM, dave aitel  wrote:

>
>
> So every remote access trojan framework has a high level interpreter built
> into it these days. It brings you back to something from that Zero Day
> movie (which we all watched drunk to make it bearable, admit it) where a
> Kaspersky analyst talked about Stuxnet being "Big but amazingly BUG FREE".
> Not having subtle bugs is something you can do much more easily in
> Python/Lua/Ruby/etc than in C/C++. There are other good reasons to have a
> high level language in your RAT system, but that is a major one.
>
> One of the other major reasons is that you can push complex logic to the
> endpoint that only lives there temporally. By complex logic, we mean
> full-on exploits. You can drive CANVAS's entire MSRPC libraries inside
> INNUENDO , without ever
> touching disk. And we often do (MSRPC is still important in the world even
> though the last good public bug was MS08-026).
>
> And this is a good reason to choose Python instead of Lua in your RAT.
> You're going to want to write your exploits in Python. You're going to want
> to run your exploits on the remote side - because of Latency.
>
> Latency is a funny thing. Inside all networking code is a hellish mishmash
> of timeouts, MTUs, retries, and buffers. That mishmash does
> Murphy-law-level chaotic things in the face of what you might consider very
> reasonable network conditions. Sat hops are one second latency bombs. Add a
> couple of those, and a bit of packet loss, and TCP breaks down in some hard
> to debug ways that will drive your exploits from "Working \o/" to "Not
> worky worky sadface". This is hard to emulate on VMWare or other software
> stacks for some reason.
>
> In any case, there are bad things about putting Python in your RAT, but
> one GOOD thing is that no soon-to-be-fired-for-extreme-idiocy operator
> will ever upload an entire package to some random redirector box on the
> Internet to avoid latency issues.
>
> That said, I still lean towards HUMINT being a source for the EQGRP leak.
> It's kinda a happy battle between colossal stupidity and insane malice at
> this point?
>
> -dave
>
> TL;DR: https://twitter.com/itsDanielSuarez/status/764898078663012356
>
>
>
>
>
> ___
> Dailydave mailing list
> Dailydave@lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave
>
>
___
Dailydave mailing list
Dailydave@lists.immunityinc.com
https://lists.immunityinc.com/mailman/listinfo/dailydave

Re: [Dailydave] Latency is a demogorgon (dave aitel)

[Jeffrey Carr]

Thanks for this post, Dave. I enjoyed reading it.

Regarding the EQ Group leak, I think that there's a good case to be made
that an insider or an ex-employee was responsible. I hope to have some
reasons posted on why that is in the next few days.

Jeff Carr


On Wed, Aug 17, 2016 at 9:00 AM, <dailydave-requ...@lists.immunityinc.com>
wrote:

> Send Dailydave mailing list submissions to
> dailydave@lists.immunityinc.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.immunityinc.com/mailman/listinfo/dailydave
> or, via email, send a message with subject or body 'help' to
> dailydave-requ...@lists.immunityinc.com
>
> You can reach the person managing the list at
> dailydave-ow...@lists.immunityinc.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dailydave digest..."
>
>
> Today's Topics:
>
>1. Latency is a demogorgon (dave aitel)
>
>
> --
>
> Message: 1
> Date: Wed, 17 Aug 2016 11:01:50 -0400
> From: dave aitel <d...@immunityinc.com>
> To: "dailydave@lists.immunityinc.com"
> <dailydave@lists.immunityinc.com>
> Subject: [Dailydave] Latency is a demogorgon
> Message-ID: <71567dae-6b09-6e93-472b-c5642f5ba...@immunityinc.com>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> So every remote access trojan framework has a high level interpreter
> built into it these days. It brings you back to something from that Zero
> Day movie (which we all watched drunk to make it bearable, admit it)
> where a Kaspersky analyst talked about Stuxnet being "Big but amazingly
> BUG FREE". Not having subtle bugs is something you can do much more
> easily in Python/Lua/Ruby/etc than in C/C++. There are other good
> reasons to have a high level language in your RAT system, but that is a
> major one.
>
> One of the other major reasons is that you can push complex logic to the
> endpoint that only lives there temporally. By complex logic, we mean
> full-on exploits. You can drive CANVAS's entire MSRPC libraries inside
> INNUENDO <https://immunityinc.com/products/innuendo/>, without ever
> touching disk. And we often do (MSRPC is still important in the world
> even though the last good public bug was MS08-026).
>
> And this is a good reason to choose Python instead of Lua in your RAT.
> You're going to want to write your exploits in Python. You're going to
> want to run your exploits on the remote side - because of Latency.
>
> Latency is a funny thing. Inside all networking code is a hellish
> mishmash of timeouts, MTUs, retries, and buffers. That mishmash does
> Murphy-law-level chaotic things in the face of what you might consider
> very reasonable network conditions. Sat hops are one second latency
> bombs. Add a couple of those, and a bit of packet loss, and TCP breaks
> down in some hard to debug ways that will drive your exploits from
> "Working \o/" to "Not worky worky sadface". This is hard to emulate on
> VMWare or other software stacks for some reason.
>
> In any case, there are bad things about putting Python in your RAT, but
> one GOOD thing is that no soon-to-be-fired-for-extreme-idiocy operator
> will ever upload an entire package to some random redirector box on the
> Internet to avoid latency issues.
>
> That said, I still lean towards HUMINT being a source for the EQGRP
> leak. It's kinda a happy battle between colossal stupidity and insane
> malice at this point?
>
> -dave
>
> TL;DR: https://twitter.com/itsDanielSuarez/status/764898078663012356
>
>
>
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <https://lists.immunityinc.com/pipermail/dailydave/
> attachments/20160817/520a7d61/attachment-0001.html>
>
> --
>
> ___
> Dailydave mailing list
> Dailydave@lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave
>
>
> End of Dailydave Digest, Vol 57, Issue 8
> 
>



-- 
Jeffrey Carr (jeffreycarr.com)
CEO, Taia Global, Inc. (taiaglobal.com)
Founder, Suits and Spooks (suitsandspooks.com)
Author, "Inside Cyber Warfare: Mapping the Cyber Underworld" (O'Reilly
Media, 2009, 2011)


THE CONTENTS OF THIS EMAIL ARE FOR THE RECIPIENT'S EYES ONLY AND MAY NOT BE
DUPLICATED OR DISTRIBUTED WITHOUT PRIOR PERMISSION.
___
Dailydave mailing list
Dailydave@lists.immunityinc.com
https://lists.immunityinc.com/mailman/listinfo/dailydave

[Dailydave] Latency is a demogorgon

[dave aitel]

So every remote access trojan framework has a high level interpreter
built into it these days. It brings you back to something from that Zero
Day movie (which we all watched drunk to make it bearable, admit it)
where a Kaspersky analyst talked about Stuxnet being "Big but amazingly
BUG FREE". Not having subtle bugs is something you can do much more
easily in Python/Lua/Ruby/etc than in C/C++. There are other good
reasons to have a high level language in your RAT system, but that is a
major one.

One of the other major reasons is that you can push complex logic to the
endpoint that only lives there temporally. By complex logic, we mean
full-on exploits. You can drive CANVAS's entire MSRPC libraries inside
INNUENDO , without ever
touching disk. And we often do (MSRPC is still important in the world
even though the last good public bug was MS08-026).

And this is a good reason to choose Python instead of Lua in your RAT.
You're going to want to write your exploits in Python. You're going to
want to run your exploits on the remote side - because of Latency.

Latency is a funny thing. Inside all networking code is a hellish
mishmash of timeouts, MTUs, retries, and buffers. That mishmash does
Murphy-law-level chaotic things in the face of what you might consider
very reasonable network conditions. Sat hops are one second latency
bombs. Add a couple of those, and a bit of packet loss, and TCP breaks
down in some hard to debug ways that will drive your exploits from
"Working \o/" to "Not worky worky sadface". This is hard to emulate on
VMWare or other software stacks for some reason.

In any case, there are bad things about putting Python in your RAT, but
one GOOD thing is that no soon-to-be-fired-for-extreme-idiocy operator
will ever upload an entire package to some random redirector box on the
Internet to avoid latency issues.

That said, I still lean towards HUMINT being a source for the EQGRP
leak. It's kinda a happy battle between colossal stupidity and insane
malice at this point?

-dave

TL;DR: https://twitter.com/itsDanielSuarez/status/764898078663012356




___
Dailydave mailing list
Dailydave@lists.immunityinc.com
https://lists.immunityinc.com/mailman/listinfo/dailydave