[prev in list] [next in list] [prev in thread] [next in thread] 

List:       patchmanagement
Subject:    Re: Is MS08-067 Wormable?
From:       Emin <emin.atac () gmail ! com>
Date:       2008-11-26 8:20:13
Message-ID: de7c23870811260020g2a0dea23qe4b247399524163c () mail ! gmail ! com
[Download RAW message or body]

FYI,

http://blogs.technet.com/mmpc/archive/2008/11/25/more-ms08-067-exploits.aspx
"It is also interesting to note that the worm patches the vulnerable
API in memory so the machine will not be vulnerable anymore. It is not
that the malware authors care so much about the computer as they want
to make sure that other malware will not take it over too..."

me> This is simply QA in malware production process.

> Quoting "Emin"
> VG article about ASLR mitigation
> MS08-067 Worm in the wild?
> http://isc.sans.org/diary.html?storyid=5275

> 31/10 "Proof of Concept Binaries for MS08-067 Targeting English Windows OS's"
> http://www.f-secure.com/weblog/archives/00001525.html
> "Its function is to add the guest account to the administrators group,"

> 3/11 "Worm Exploiting MS08-067 in the Wild"
> http://www.f-secure.com/weblog/archives/00001526.html
> "The dropped components include a kernel mode DDOS-bot"

> me> IOW, it's a rootkit and by nature it aims at remaining stealth...

> me> All what we see confirm that there's a malware industry outside
> that's trying to make money.
> me> I'm also glad to see that the industrial production of malware
> arose early this year is being slow down because of QA requirements in
> development.

> 5/11
> http://blogs.technet.com/msrc/archive/2008/11/05/latest-on-ms08-067.aspx

> Quoting "Susan Bradley, CPA "

> http://msinfluentials.com/blogs/jesper/archive/2008/11/04/is-ms08-067-wormable.aspx
> 
> A couple of weeks ago Microsoft released an out-of-band security update
> in bulletin MS08-067
> <http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx>.
> Looking at the type of vulnerability and the fact that the issue was
> already being exploited in the wild at the time, this was a good
> decision. If you have not already installed this security update, you
> should stop reading this right now and return after you have installed
> the update.
> 
> The problem fixed in MS08-067 is eerily reminiscent of the
> vulnerabilities that resulted in the Blaster and Sasser worms.
> Therefore, for obvious reasons, the question arises whether MS08-067 is
> wormable or not. Microsoft claimed in various outlets that it was
> wormable "on older systems.
> <http://blogs.technet.com/msrc/archive/2008/10/23/ms08-067-released.aspx>"
> Michael Howard backs that up with some interesting analysis on the SDL
> blog <http://blogs.msdn.com/sdl/archive/2008/10/22/ms08-067.aspx>. The
> Secure Windows Initiative <http://blogs.technet.com/swi/> (SWI) blog
> also discusses the issue and points to a number of mitigations designed
> to reduce the "wormability" on newer operating systems. By "older
> systems" Microsoft really means "not Vista and Server 2008." This leads
> to the question of why the vulnerability cannot be used to create a worm
> on Windows Vista and Server 2008, and whether the claim is correct or not.
> 
> The claim that MS08-067 cannot be used to create a worm on Vista and
> Server 2008 is based largely on two defenses used on those operating
> systems. The first is that the vulnerable end-point is not anonymously
> accessible on those operating systems. That's a pretty good defense out
> on the general Internet. However, on a corporate network it provides
> little defense. Anyone with user-level credentials on a host can exploit
> the vulnerability. Thus, if a single computer gets infected and then is
> brought inside the corporate network, it can infect any other computers
> on the corporate network by authenticating to them. It would take a
> little more coding to write an exploit that does that, but it is
> certainly not an impossibility.
> 
> The second defense is Address-Space Layout Randomization
> <http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx>
>  (ASLR). ASLR causes the addresses used for code in memory to change from
> execution to execution. Each time you execute a program it will be
> loaded into a portion of memory; but, under ASLR, that memory is offset
> at one of 256 possible memory locations. Many exploits rely on knowing
> where in memory certain structures are. Prior to ASLR those locations
> were deterministic within an Operating System, Serice Pack, and Patch
> Level combination. However, under ASLR, they are, as I mentioned, no
> longer deterministic. This makes exploitation much more difficult.
> 
> However, do these defenses, and specifically, ASLR, really make a
> vulnerability "not wormable?" I would argue that the answer is "we do
> not know" but that it is tending toward "no." The problem is that we
> really do not understand the spreading patterns of worms well enough to
> make a claim one way or the other. Let us take a neutral scientific
> approach to understanding this claim.
> 
> Worms rely on spreading from computer to computer. Each computer that is
> infected with the worm can infect countless additional computers. The
> only thing that moderates it is time. The spread, however, is
> exponential. The more infected computers there are, the more computers
> there are that can spread the infection. Eventually, some form of
> critical mass is reached at which point the spread turns uncontrollable.
> Unfortunately, we do not know where that inflection point is.
> 
> To see how this works, let us take a hypothetical worm, and let us
> assume that ASLR is not used. Let's say the infection takes 1/8th of a
> second per computer. In other words, if computer A is infected and
> targets the worm at computer B, 1/8th of a second later, computer B is
> ready to start infecting computer C. In one second, a single computer,
> computer A, can spread the infection, directly or indirectly, to 64
> other computers. The total impact of the worm is t/r^2, where t is the
> time and r is the rate of spread measured in the time it takes to infect
> an additional computer. Using that formula, we can see that after 1
> second 64 computers could be infected. After 2 seconds, 256 computers
> can be infected, and so on.
> 
> Now let's apply ASLR to this. Using ASLR, the memory address space is
> allocated over 256 possible addresses. In other words, under a very
> tight assumption the infection will fail in all but 1/256 cases. The
> assumption is that we cannot predict where the locations are, and that
> the randomization will actually cause the infection to succeed in only
> one case of 256. Let us just say this assumption holds because it lets
> us analyze a worst-case scenario for the worm. Under ASLR then, we can
> consider the rate of spread to be 1/256th that of the non-ASLR worm. In
> other words, rather than infecting the next computer in 1/8th of a
> second, computer A can only infect one new computer in 32 seconds. This,
> obviously, slows down the spread of the worm, but is it enough? The
> spread is *still* exponential. It just takes longer to spread. Consider
> this chart:
> 
> This chart maps the number of infected computers over a 24-minute
> period, assuming there is an infinite number of computers to infect, and
> ASLR is in use on all of them. It is clear from this graph that the
> spread is exponential. After 24 seconds, 2,025 computers are infected.
> By contrast, without ASLR, it would take less than 6 seconds to infect
> that many computers. The point, however, is that ASLR would not stop a
> worm, it would only slow it down. What we do not know is whether slowing
> down a worm is effectively enough to stop it. My inclination would be to
> say that it is probably not enough unless we can slow it down by many
> orders of magnitude.
> 
> In addition to ASLR, the affected service on Windows Vista and Server
> 2008 would only restart twice before staying down indefinitely. This is
> important because unsuccessful exploitation would almost certainly cause
> the service to crash. However, I do not consider that as a defense
> against worms, because more than likely, the user would at that point
> either restart the computer or just the service. Given that the restart
> behavior would only serve to further slow the spreading rate. It would
> not change the exponential nature of the spread. Again, we arrive at the
> same conclusion: none of the defenses make a vulnerability non-wormable.
> They merely slow the spread down.
> 
> This is important because there is a risk that people will avoid
> patching because a vulnerability is not wormable. Make no mistake,
> remotely exploitable vulnerabilities are still wormable, and within an
> hour, you could easily have your entire corporate network infected. As
> if that weren't bad enough, using a remotely exploitable vulnerability,
> someone with far worse intentions could take over your computers and use
> them as an entry point into your network. For that the criminal needs
> only one computer, not a whole network of them. Wormability, or lack
> thereof, is irrelevant against a targeted attack, which means that ASLR
> is essentially irrelevant against a targeted attack. in most cases the
> attacker needs *a* computer, not *a particular* computer. Being able to
> only gain a foot hold on one computer in 256 is likely to be enough
> because after the initial entry, the vulnerability plays no further part
> in the compromise of your network. In other words, do not consider ASLR
> to be a reason not to patch some particular vulnerability.
> 
> Now, do I think we will see a worm for MS08-067? No. Not in the
> traditional sense of Blaster. The time of worms, like Blaster, that are
> inherently non-destructive, has passed. At this point, criminals are not
> interested in simply writing worms that self-replicate. They are
> interested in one of the three big things: money, ideology, or national
> supremacy. While we may still see massive worms, they will be
> fundamentally different than the ones of old, and they will probably
> take a bit longer to write. The new breed will be more targeted, more
> silent, more deliberate, and more dangerous. Once the objectives change,
> so do the attack patterns.
> 
> In short, please do not use wormability, or lack thereof, as a decision
> factor in deciding whether to patch a vulnerability or not. Wormability
> is an irrelevant and potentially dangerously misleading metric.
> 

---
When posting or replying to messages on this list, please send all
emails in plain text format.  HTML formatted messages will not be accepted.

PatchManagement.org is hosted by Shavlik Technologies

To unsubscribe send a blank email to leave-patchmanagement@patchmanagement.org
If you are unable to unsubscribe via this email address, please email
owner-patchmanagement@patchmanagement.org


[prev in list] [next in list] [prev in thread] [next in thread]