Re: SourceFire RNA

[Jason <security () brvenik com>]

Renaud Deraison wrote:

> [ The second half of this post is more related to VA scanners in general,
> and may be considered as being off-topic. 
> Moderator : kill this message if you do not think it belongs here]

ditto...

> On Tue, Dec 02, 2003 at 05:27:57PM -0500, Jason wrote:
>
> > - Checking the registry requires administrative privilege, this is in 
> > essence advertising the administrative credentials to everyone that is a 
> > recipient of the probe.
>
>
> The credentials are sent under the form of a hash (NTLMv2 or kerberos).
> This is not a vulnerability per se.

per se, until 30 secs later when the hash is cracked open.

> > - Attempting to elicit a specific response only identified that a patch 
> > had been installed, if alternative methods of resolution were taken like 
> > disabling DCOM then the check was ineffective and inaccurate.
>
>
> If you disable DCOM, then the attack vector is not here any more -> you 
> are not vulnerable. So the active probe actually did its job well.

except that normal patching and administrative activity can silently re 
enable the service hence leaving it open and unknown until the next 
round of scans while producing a not vulnerable result for a period of time.

> > - It resulted in a false sense of security for many because the patch 
> > was ineffective and resulted in a 100% false negative for any integrated 
> > system that relied solely on this information for vulnerability management.
>
>
> The initial patch _was_ effective - it fixed _a_ form of the overflow.
> If the patch was properly applied, msblaster would not propagate.

If it applied properly and the method of checking was sufficient.

Ineffective is relative to systems that were reported patched even 
though the patch failed to apply correctly. I am aware of scanners that 
incorrectly reported a system patched and required a verification of the 
actual files in use. Some of these were discussed on the lists.

> Unfortunately, there were other flaws in MSRPC and others vectors were
> not fixed by this patch, and were not known either when it was written.
>
>
> > The passive approach was able to identify, with a high degree of 
> > certainty, the likely vulnerable systems before patching even began
>
>
> Absolutely not ! Passively you CAN NOT determine if the patch has been
> applied. If all the VA tools out there are sending a tortured series of
> MSRPC packets there is a good reason for that. 
>
> Passively you can at best determine that you have a bunch of Windows 
> hosts out there. Some might have been patched, some might not. And in
> the end, you don't even know if you've seen ALL of them.

What more do you need to know?

it is a WinXXX system.
Those systems were built with X configuration.
Those systems had the last patch applied on X.
These other systems here do not fit the X build profile, hmmm.

Of course then the statement can be made, what if you did not have a 
normal build procedure, what if it came from the manufacturer, what if 
we allow users to patch on their own...

To this I say that you need to touch each and every one of them and get 
that knowledge if you hope to ever be successful. Everything else is an 
attempt to put a bandage on the problem. Need a comprehensive list of 
systems that need to be touched?

To the ALL of them statement, there is never going to be a 100% 
assurance that you have gotten all systems. There is however a high 
degree of confidence that you will get all of the ones that pose a 
threat if you have properly deployed a passive system at key points.

And as an added benefit when those ones that were off get turned on you 
can get them immediately.

> > , it 
> > was able to identify the change in behavior even though the host was 
> > supposed to have been patched... 
>
>
> Correct. This is the job of an IDS, though. Also, if a host changes
> behavior because it has been infected by the MSRPC worm, you're quite
> screwed, security-wise.

The job of an IDS is to detect intrusions, not changes. Changes have 
value in identifying potential intrusions but it is not the sole domain 
of an IDS.

> > In this way you can foresee possible 
> > and actual vulnerabilities without ever touching the host directly. With 
> > this information you can target your response to the high risk systems 
> > and handle the situation more effectively.
>
>
>
> You did not foresee anything. You saw that a 

???

"What more do you need to know?

it is a WinXXX system.
Those systems were built with X configuration.
Those systems had the last patch applied on X.
These other systems here do not fit the X build profile, hmmm."

> > Next we have evasion, it is trivial to evade any active probe, 
> > especially routine ones. When we start thinking about threat management 
> > this scenario is an even greater concern. An attacker can easily evade 
> > and active probe from scanning machines and continue to provide services.
>
>
> It's easy to evade active probes ONCE you've broken in the target. Then
> it's obviously too late for pro-active security, this is why there are
> IDSes out there.

Unless the local administrator blocked the traffic at the border, having 
the net result of slowing the scan while they were at it.

Unless the host has a firewall

Unless the host was on the road

Unless the host was turned off

Unless the host was recently smacked in the mouth and currently rebooting.



> > I hope I have illustrated why passive is the best way to go when 
> > considering the true threats and the alternatives.
>
>
> Your "illustration" is based on a total misundertanding of the facts.

It is unfortunate that challenging the status quo and discussing a 
different perspective is interpreted by some as a misunderstanding of 
the facts.

>                                 -- Renaud


---------------------------------------------------------------------------
---------------------------------------------------------------------------