Re: Dailydave Digest, Vol 16, Issue 6

[djuti thoth <thothics () gmail com>]

After reading Dave's post with regard to foriegn outsourcing I wanted
to say that it's drawing conclusions that I think are similar to why
people choose close sourced large corporations versus smaller firms
who will open source for advantage.  Specifically, the following
passage caught my attention:
 "For what it's worth, normal businesses usually do consider this,
which is why they will buy
CANVAS instead of using Metasploit - because they have someone to sue.
In a sense, we provide a specialized insurance policy."
During the sales cycle of enterprise security tools I've seen RFP's
that specifically ask questions regarding the size and quality of the
company.
Will the company be around in the next few years?  
What if the company gets bought out?  
Despite what people may think, being a acquisition target is not a
favorable idea in the eyes of your large potential client.
All these things can scare a potential sale since "support", which is
essentially what we are talking about here, should be a steady thing
to a client.  Clients want to know that for the lifetime of their
license agreement everything about your company, product, support
staff will remain the same or improve as per their suggestion.
In this case, Metasploit vs. Canvas, Immunity can offer more support
then Meta and should things go terribly wrong, e.g. crashing a
critical server that interrupts a revenue stream, renumeration can be
sought from the vendor.


P.S. Best comment to be taken out of context from Dave's email :)
"Immunity spent time thinking about ways to trojan our customers and
we've come up with some considerations"

On Thu Sep 09 13:25:15 PDT 2004,
dailydave-request () lists immunitysec com
<dailydave-request () lists immunitysec com> wrote:
> Send Dailydave mailing list submissions to
>         dailydave () lists immunitysec com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://www.immunitysec.com/mailman/listinfo/dailydave
> or, via email, send a message with subject or body 'help' to
>         dailydave-request () lists immunitysec com
>
> You can reach the person managing the list at
>         dailydave-owner () lists immunitysec com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dailydave digest..."
>
> Today's Topics:
>
>    1. Re: RE: Network Exploitation Tools aka    ExploitationEngines;
>       Re: (esos03a () bvoe de)
>    2. Tanks and Foster's Lager. (Dave Aitel)
>    3. Self updating worms? (Jonathan Wilkins)
>    4. Re: Self updating worms? (Gadi Evron)
>    5. RE: Self updating worms? (Kohlenberg, Toby)
>    6. RE: Self updating worms? (Anton A. Chuvakin)
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 7 Sep 2004 15:44:27 -0600
> From: esos03a () bvoe de
> Subject: Re: [Dailydave] RE: Network Exploitation Tools aka
>         ExploitationEngines; Re:
> To: esos03a () bvoe de
> Cc: "'Clarke, Tyronne \(Contractor\)'" <Tyronne.Clarke.ctr () dcma mil>,
>         pen-test () securityfocus com, focus-ms () securityfocus com,
>         dailydave () lists immunitysec com
> Message-ID: <10709843.1094724071898.JavaMail.esos@SRVLX073>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>         reply-type=response
>
> Python is pretty intelligent aboutit, and let's say you have something you
> collected as numerical data (say a port number), but now you need to treat
> it as a text string for some function that expects a text string, simply
> str(foo) so that whatever you are passing it to doesn't complain "foo is an
> integer".
>
> Kurt Seifried, kurt () seifried org
> A15B BEE5 B391 B9AD B0EF
> AEB0 AD63 0B4E AD56 E574
> http://seifried.org/security/
>
> ------------------------------------------------------------------------------
> Ethical Hacking at the InfoSec Institute. All of our class sizes are
> guaranteed to be 12 students or less to facilitate one-on-one interaction
> with one of our expert instructors. Check out our Advanced Hacking course,
> learn to write exploits and attack security infrastructure. Attend a course
> taught by an expert instructor with years of in-the-field pen testing
> experience in our state of the art hacking lab. Master the skills of an
> Ethical Hacker to better assess the security of your organization.
>
> http://www.infosecinstitute.com/courses/ethical_hacking_training.html
> -------------------------------------------------------------------------------
>
> ------------------------------
>
> Message: 2
> Date: Thu, 09 Sep 2004 08:33:49 -0400
> From: Dave Aitel <dave () immunitysec com>
> Subject: [Dailydave] Tanks and Foster's Lager.
> To: dailydave () lists immunitysec com
> Message-ID: <1094733229.3408.388.camel@localhost.localdomain>
> Content-Type: text/plain
>
> A number of people seem offended at the previous email, so I'll try to
> clarify my comments. Obviously I don't think all outsourcing to foreign
> nationals is bad. Immunity does a fair bit of that, since we have 4
> people and we cover three continents (four, if you count California as
> its own continent, which I'm pretty sure they do).
>
> But if the reason you're are running a penetration test is that you
> believe there is a national intelligence threat against an information
> system, then the tools you are using to assess that threat need to be
> carefully analyzed. The trivial solution from a security perspective is
> to use only in-house tools, which is fine if you are a massive
> organization with colossal resources.
>
> However, if you are (and you probably are) going to be using external
> tools to perform an assessment, then the risk of getting owned by those
> very tools does need to be taken into account. For what it's worth,
> normal businesses usually do consider this, which is why they will buy
> CANVAS instead of using Metasploit - because they have someone to sue.
> In a sense, we provide a specialized insurance policy.
>
> But for a more sensitive customer base, that's not enough. As they say,
> people are in harm's way. These extra considerations extend not just to
> the US military, of course, but to every government's sensitive
> information systems. A lot of our customers in the EU and around the
> globe are purchasing CANVAS from what is basically a potential foreign
> intelligence service, as far as they are concerned.
>
> It was therefor important to our business to look at this risk and find
> a way to ameliorate it. As an exercise, Immunity spent time thinking
> about ways to trojan our customers and we've come up with some
> considerations. This is one of the reasons why CANVAS is the way it is,
> as an all-source distribution, despite the huge pain this causes us in
> every other area (piracy, licensing validation, etc).
>
> Assume I can modify CANVAS. Even if I'm not working at Immunity, assume
> I can walk down to the Immunity co-location where we host our servers,
> and pay the nice Russian man there who manages the network for a few
> hours of console time. It's likely this is a couple grand at most, less
> if you communicate in Russian or play false-flag games, perhaps. It
> would probably cost you more to hack someone at Immunity, but it's no
> doubt possible.
>
> I can then trojan CANVAS in several places:
>
> 1. The encoders or shellcode
>
> This is the most obvious place. Most of CANVAS uses MOSDEF (and by 5.0,
> all of it will), so all of the shellcode is in source form. This makes
> it harder to trojan specifically in the shellcode (and it's not like it
> changes every day either). One promising place to look would be the
> MOSDEF assembler and compiler. For example, you could have a bogus
> instruction that "assembled" into a mini-shellcode trojan.
> Unfortunately, the compiler, while a pain to debug, is pretty hard to
> trojan, since it just generates intermediate language, and you can print
> that out to look for anomalies (which is easier than it sounds). So the
> assembler is your best bet. The assembler is basically a table,
> something easily verified with the Intel manuals. Also, a secondary
> shellcode, even a small one, would look really out of place in the code.
> (MOSDEF is available as public LGPL code, so not easy to trojan
> un-noticeably).
>
> And again, shellcode is small. It's not hard to disassemble it and
> reverse it manually, even the massively overweight CANVAS shellcode.
>
> Targeting would become a problem with shellcode as well. Although
> machines that the shellcode runs on are unlikely to be watched closely
> in some cases, in other cases they're likely to be very carefully
> analyzed, as many people do a lot of CANVAS testing in the lab before
> doing it in the wild. So you'd want to rate-limit your trojan to do a
> 1/10 chance of triggering. And because you're in shellcode, exfiltration
> of data is a problem. You'd want to write a HTTP-proxy friendly trojan
> in shellcode.
>
> Writing compilers is a pain in the ass. Trojaning compilers is even more
> so, since the compiler doesn't see a stream of data and search and
> replace. It's a tree structured algorithm. The binary data is shooting
> out very far away, and until then, each step is fairly structured. If
> somewhere in the code was a "push blob, push blob, push blob, retesp",
> it would be pretty easy to spot out.
>
> Trojaning something is a delicate balance. I want to trojan something in
> particular, but I don't want to trojan everything because I'll get
> caught.
>
> 2. A misplaced .pyc
>
> This is probably one of my favorites. We don't distribute .pyc files,
> but if we slipped one in, it could be completely different from the
> source, could manage its date (touch -r /tmp/ self.pyc), and is a
> generally good way. It's a reasonably covert way to trojan a Python
> program, but if it's found out, it's easy to decompile and analyze, and
> an obfuscated de-compilation is pretty obviously hostile.
>
> 3. Python trickery
>
> Some of Sinan Eren's code is trickery to me, since he uses map() and
> other functional derivatives. This is still rare in the CANVAS codebase,
> and use of exec is extremely rare. Someone could easily audit the
> codebase itself, and then use that as a baseline and watch for malicious
> patches with "diff". With a binary, it's a lot harder to do that. Binary
> analysis tools are a lot harder to use than "diff" and there's valid
> reasons for that. Also, reading 100K lines of Python is a lot easier on
> the eyes than reading 100K lines of assembly (or 20Meg of assembly,
> which is more likely).
>
> 4. Ogg files
>
> We use OGG files as our sound delivery system. We play them with ogg123,
> if you have it installed. Theoretically we could hunt down a bug in
> ogg123 that we could exploit with a malicious .ogg file. This is my
> second favorite next to the .pyc. Pretty unlikely though.
>
> 5. Callbacks from the Python code itself
>
> CANVAS doesn't track use in any sense. It has no reason to be calling
> back to a central server. It doesn't check for updates. It doesn't ask
> if your license is valid. It doesn't grab OSVDB entries on the fly. This
> is, in large part, a design decision to enable our customers to trust
> us.
>
> So to sum up, trojaning CANVAS is difficult, even for us, and
> intentionally so. This is the consideration I was talking about in the
> previous email. Even without the considerations we put into the design
> of CANVAS, binaries are a lot easier (several orders of magnitude) to
> trojan than source trees.
>
> For most businesses, this is a non-issue. They've purchased the
> insurance. For people who have to normally consider an
> intelligence-level threat, I believe this is an issue they should be
> considering. CANVAS's very design (as full source, no callbacks, etc)
> takes this into consideration. That's what I meant.
>
> --
> Thanks,
> Dave Aitel
> Senior Security Architect
> Immunity, Inc.
>
> ------------------------------
>
> Message: 3
> Date: Thu, 9 Sep 2004 07:48:54 -0700
> From: "Jonathan Wilkins" <jwilkins () microsoft com>
> Subject: [Dailydave] Self updating worms?
> To: <dailydave () lists immunitysec com>
> Message-ID:
>         <6821B525A6670F4A92B9A1E5DE138372037A6CFE () RED-MSG-41 redmond corp microsoft com>
>
> Content-Type: text/plain;       charset="us-ascii"
>
> It occured to me at CanSec this year that tools such as Core's Impact,
> Immunity's Canvas and the open source Metasploit Framework (not to
> mention the various worm development languages that Tom Ptacek, Joae
> Nazario and Dave Aitel have been discussing) open up a new possibility
> for worm automation.  By using standardized payloads, they allow for
> extraction of injector code.  This opens the possibility of worms
> learning of new exploits in a totally automated fashion.
>
> I know this is no trivial task, but it would allow a stealthy worm to
> continue to exploit new hosts long after it's initial release.  One
> major disadvantage for a slow spreading worms has been that the longer
> it takes to spread, the more hosts will be patched when it finally
> attempts an attack.  If a slow spreading worm was able to get new
> information on current exploits techniques long after initial release
> this disadvantage would disappear.  Previously, worm authors have
> attempted to provide updates through web sites, IRC channels, Usenet,
> and the like, but the communication channels were easily disrupted.  By
> building code into the worm that can identify payloads and extract
> delivery code, the slow spreading worm could compromise thousands of
> hosts without becoming such a obvious presence on the network that it is
> discovered.  Further, since it's already examining network traffic, the
> addition of a cryptographically secure update and control mechanism adds
> obvious value (worm updates via spam?).
>
> Imagine a worm that starts off by scanning 10000 hosts, in the next
> generation, each instance would only scan 1000, then 100, then 10, then
> 1, then only scan with a 10% probability and so on.  Depending on the
> wait between generations, the vulnerability used could be quite
> different between different instances.
>
> Thoughts?
>
> ------------------------------
>
> Message: 4
> Date: Thu, 09 Sep 2004 17:27:04 +0200
> From: Gadi Evron <ge () linuxbox org>
> Subject: Re: [Dailydave] Self updating worms?
> To: Jonathan Wilkins <jwilkins () microsoft com>,
>         dailydave () lists immunitysec com
> Cc: th-research <th-research () linuxbox org>
> Message-ID: <41407648.2050602 () linuxbox org>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> VX-ers have been trying to get a good grip on updating their creations
> for a while now.
>
> Some attempts were made, as you mentioned, using IRC, web pages and
> network scanning.
>
> Let us examine these techniques for a second.
>
> 1. IRC.
> It is growing increasingly difficult to locate the echo channels, learn
> the interface commands and discover the right commands as well as gain
> privileges to kill them. And these drone armies are HUGE. Most of them
> are not considered worms at all but Trojan horses.
>
> To do all this you must first find them, and once found. "making like a
> drone" or infiltrating is becoming increasingly difficult over time.
>
> Once one Trojan horse was successfully installed, another soon follows
> through the same vulnerability - "door", or using the successful Trojan
> horse which got in to install yet another. I.e. using a backdoor rather
> than, possibly, the original exploit.
>
> Although this is old and at times not very easy to work out, IRC
> controlled drone armies are huge, about, and successful.
>
> Usually, they are unrelated to "worms", though. As such, much wider
> spread and a lot slower to spread.
>
> 2. Web pages.
> Once you see the web page in the code or on the network, you can block
> it. You can also try and take the page down with different percentages
> of success - depending heavily on the hosting company and their care of
> their abuse inbox. Still, a very successful technique for worms over
> short periods of time.
>
> History shows that even if updates come weeks later and these pages were
> empty (thus innocent), they will then most than likely still be on the
> air to be used for the update.
>
> 3. Network scans.
> I.e. find the open backdoor installed by the worm and use it to
> update/install a new one, much like specified above under "IRC".
>
> There are other ways. One recent "trick" was to use the hostile email
> messages an infected host sends out, to send IP lists of infected
> machines in that particular seeding attempt history.
>
> There have been some P2P attempts and the kiddies keep getting better.
>
> Personally? I look at the numbers.
>
> This is no longer a world open only to l33t asm coders. This is what I
> call "open source malware".
> Not to be confused with the open source initiatives and communities of
> the Internet. It only means that the source is freely available.
>
> Many VX-ers over the years released their source. From groups such as
> 29A through the good old DMSETUP at version 5, and others. Nowadays
> however kiddies can find the source for many of the big names out there,
> freely available, with updates AND support web forums. In contract to
> the closed communities of VX-ers.
>
> See the numbers. See how many of them are SDbots, Agobots and so on and
> so forth.. all originating from the one before them.. but let us not go
> into biological models.
>
> Over a thousand reported malware samples every month. There are a lot
> more. Most of these when they arrive at our doorstep (not known worms we
> all get flooded by, Trojan horses) are identified as something generic
> by heuristics.
>
> It's only going to get worse. Why bother with updating a worm, which is
> a dead end as far as traceability - they want to remain anonymous - when
> they can simply release 30 new ones with minor modifications?
>
> There is more to this, naturally, but I'm trying to make a point.
>
> Worm controlling and drone army creation is going to keep becoming a
> bigger and bigger issue now that organized crime and spammers are
> involved - i.e. the people who see the return on their investment. And
> they do invest.
>
> Point is.. keeping a _trail_ in order to update a network, without
> throwing rocks blindly and hoping for success - leaves a _trail_. It
> doesn't have to be a legal trail, but it can sure lead back to them,
> ruining their infrastructure online and at the end not meet the simple
> test of cost vs. benefit.
>
> There are some promising technologies out there which may be the answer
> for their hopes and our fears... but that's not something I'd like to
> discuss here. They discuss it among themselves and have more resources
> than most security researchers as it is - when it comes to sharing
> information and finding samples.
>
> That's about it in a few lines...
>
>         Gadi Evron.
>
> --
> Email: ge () linuxbox org. Backup: ge () warp mx dk.
> Phone: +972-50-428610 (Cell).
>
> Jonathan Wilkins wrote:
>
> > It occured to me at CanSec this year that tools such as Core's Impact,
> > Immunity's Canvas and the open source Metasploit Framework (not to
> > mention the various worm development languages that Tom Ptacek, Joae
> > Nazario and Dave Aitel have been discussing) open up a new possibility
> > for worm automation.  By using standardized payloads, they allow for
> > extraction of injector code.  This opens the possibility of worms
> > learning of new exploits in a totally automated fashion.
> >
> > I know this is no trivial task, but it would allow a stealthy worm to
> > continue to exploit new hosts long after it's initial release.  One
> > major disadvantage for a slow spreading worms has been that the longer
> > it takes to spread, the more hosts will be patched when it finally
> > attempts an attack.  If a slow spreading worm was able to get new
> > information on current exploits techniques long after initial release
> > this disadvantage would disappear.  Previously, worm authors have
> > attempted to provide updates through web sites, IRC channels, Usenet,
> > and the like, but the communication channels were easily disrupted.  By
> > building code into the worm that can identify payloads and extract
> > delivery code, the slow spreading worm could compromise thousands of
> > hosts without becoming such a obvious presence on the network that it is
> > discovered.  Further, since it's already examining network traffic, the
> > addition of a cryptographically secure update and control mechanism adds
> > obvious value (worm updates via spam?).
> >
> > Imagine a worm that starts off by scanning 10000 hosts, in the next
> > generation, each instance would only scan 1000, then 100, then 10, then
> > 1, then only scan with a 10% probability and so on.  Depending on the
> > wait between generations, the vulnerability used could be quite
> > different between different instances.
> >
> > Thoughts?
>
> ------------------------------
>
> Message: 5
> Date: Thu, 9 Sep 2004 10:51:40 -0700
> From: "Kohlenberg, Toby" <toby.kohlenberg () intel com>
> Subject: RE: [Dailydave] Self updating worms?
> To: "Jonathan Wilkins" <jwilkins () microsoft com>,
>         <dailydave () lists immunitysec com>
> Message-ID:
>         <763EDB03559AA1428E4D41045B43F17B06A27C57 () fmsmsx406 amr corp intel com>
>
> Content-Type: text/plain;       charset="us-ascii"
>
> definitely possible and I don't know that it would be even that
> difficult. Consider- if the worm were able to hijack/modify/monitor
> DNS requests coming out of a compromised system, it could specify DNS
> servers to use and we could leverage some of the work that Dan
> Kaminsky's
> done on abusing DNS to feed updates to the worms very easily and in
> a quiet fashion.
>
> Frankly, I'm surprised this hasn't already been implemented many times
> over...
>
> t
>
> > -----Original Message-----
> > From: dailydave-bounces () lists immunitysec com
> > [mailto:dailydave-bounces () lists immunitysec com] On Behalf Of
> > Jonathan Wilkins
> > Sent: Thursday, September 09, 2004 7:49 AM
> > To: dailydave () lists immunitysec com
> > Subject: [Dailydave] Self updating worms?
> >
> >
> > It occured to me at CanSec this year that tools such as Core's Impact,
> > Immunity's Canvas and the open source Metasploit Framework (not to
> > mention the various worm development languages that Tom Ptacek, Joae
> > Nazario and Dave Aitel have been discussing) open up a new possibility
> > for worm automation.  By using standardized payloads, they allow for
> > extraction of injector code.  This opens the possibility of worms
> > learning of new exploits in a totally automated fashion.
> >
> > I know this is no trivial task, but it would allow a stealthy worm to
> > continue to exploit new hosts long after it's initial release.  One
> > major disadvantage for a slow spreading worms has been that the longer
> > it takes to spread, the more hosts will be patched when it finally
> > attempts an attack.  If a slow spreading worm was able to get new
> > information on current exploits techniques long after initial release
> > this disadvantage would disappear.  Previously, worm authors have
> > attempted to provide updates through web sites, IRC channels, Usenet,
> > and the like, but the communication channels were easily disrupted.  By
> > building code into the worm that can identify payloads and extract
> > delivery code, the slow spreading worm could compromise thousands of
> > hosts without becoming such a obvious presence on the network
> > that it is
> > discovered.  Further, since it's already examining network traffic, the
> > addition of a cryptographically secure update and control
> > mechanism adds
> > obvious value (worm updates via spam?).
> >
> > Imagine a worm that starts off by scanning 10000 hosts, in the next
> > generation, each instance would only scan 1000, then 100, then 10, then
> > 1, then only scan with a 10% probability and so on.  Depending on the
> > wait between generations, the vulnerability used could be quite
> > different between different instances.
> >
> > Thoughts?
> > _______________________________________________
> > Dailydave mailing list
> > Dailydave () lists immunitysec com
> > http://www.immunitysec.com/mailman/listinfo/dailydave
>
> ------------------------------
>
> Message: 6
> Date: Thu, 9 Sep 2004 16:18:57 -0400 (EDT)
> From: "Anton A. Chuvakin" <anton () chuvakin org>
> Subject: RE: [Dailydave] Self updating worms?
> To: "Kohlenberg, Toby" <toby.kohlenberg () intel com>
> Cc: dailydave () lists immunitysec com
> Message-ID: <Pine.LNX.4.43.0409091615160.3411-100000 () ns1 dac net>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> > Frankly, I'm surprised this hasn't already been implemented many times
> > over...
> I'd buy what Gadi Evron said over that. Why update a worm leaving a trail
> if you can make a new one? Resilient and untraceable worm update mechanism
> is a cool idea, but there might be no business case for it :-) in the
> realm of retail worms. Now, if you are talking custom stuff ... who knows.
>
> --
> Anton A. Chuvakin, Ph.D., GCIA, GCIH
>      http://www.info-secure.org
>    http://www.securitywarrior.com
>
> ------------------------------
>
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunitysec com
> http://www.immunitysec.com/mailman/listinfo/dailydave
>
> End of Dailydave Digest, Vol 16, Issue 6
> ****************************************
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave