Re: RE: This mornings Security Wire Perspectives - Ira's proof of concept code article.

[Julio Patel <smerdyakovv () gmail com>]

On Mon, 29 Nov 2004 07:08:56 -0800, robert () dyadsecurity com

> > So-called proofs of concept have been around for awhile. While it is
> > otherwise completely legitimate to search for security flaws in
> > products, putting together a proof of concept, then distributing and
> > publicizing it is just plain wrong. Frankly, these people are
> > enablers to criminals and vandals around the world.
>
> So are gun makers, and the Sharpie pen company, spray paint
> manufacturers, baseball bat makers, etc. etc.  The tools have dual
> purposes.  Security Researchers are not responsible for the criminal
> actions of others.

Upper Bound.  Lower Bound.  Anyone wanna shoot for something in between?

> > There is a big difference between responsibly finding and reporting
> > vulnerabilities, and going the extra step to put out proof of concept
> > code. Finding vulnerabilities and getting them fixed is clearly
> > important. When done responsibly, discoverers tend to be acknowledged
> > in the associated vendor alerts and, if significant, tech
> > publications as well.
>
> "If I do all of the security Quality Assurance work for the vendor for
> free, I should be thrilled that they get to dictate when that
> information can be made public.  If I'm a good little security
> researcher and work on their schedule, they might just be nice enough to
> give me credit in their version of the advisory".

Easy there.  We know you're with Dave.

> > However, more attention is generated by distributing actual attacks
> > to compromise systems. When someone releases a new attack, especially
> > within the first three months of an available patch, it isn't due
> > solely to wanting exposure, or to be perceived as being elite.
>
> I think proof of concept code and advisories should come out before a
> patch is available.  Who is the security research community serving ..
> the end user or the vendor? As an information owner, I would ideally
> know my risks as soon as possible. Remember folks, the problem is still
> there whether I know about it yet or not.  Just because a "good guy" was
> willing to share the security problem they found doesn't mean that it
> wasn't already found by a "bad guy".  I am far more concerned about
> directed malice than I am worms.

Are you talking for all the end users?  Oddly, I might want the patch
before the exploit code...it depends on the situation.

> While a a worm's impact can account for a large amount of total "loss",
> the overall impact to any individual organization is far less than that
> of a directed malicious attack.  A worm is annoying.  A directed attack
> can be devastating.  We need to not punish security researchers for the
> work they are doing for us.
>
> I'm reminded of a childhood experience.  When I was 6 my parents bought
> me a bike.  I had a chain to lock up my bike when I was away from home.
> One day my little sister was playing with the lock and broke it.  I was
> angry with her for finding this vulnerability in my security system
> until my father pointed out that if my little sister could easily break
> my lock, then so could a person who wanted to steal my bike.  Sometimes
> it's better to know your risks so you don't make uninformed decisions
> based on a perception of security.

HAHA.  Yeah, but you woulda been pissed if your sister broke the lock
and then told the other kids about it before giving you the chance to
put it in the garage with daddy's beemer.

> > Anyone who claims that security professionals need access to the
> > attacks so that they can test their clients for susceptibility to the
> > exploit doesn't understand the true job of a security professional.
> > Security professionals need to test for the presence of the
> > underlying vulnerability, but this can be done with a scanning tool
> > or examining the software version and settings -- it doesn't require
> > the exploit.
>
> People who follow this advice clearly have no concept of what their
> automated scanners are doing or even how they are developed.

apparently, neither do you.  You do know that many scanners check for
package versions, registry keys, dlls, etc. locally, right?  I'm not
saying that all scanners and all checks use local access.  I am saying
that many do include the ability to do the 'scanning' this way.  Ira
took an extreme, you've taken up the flag for the other extreme, and
the truth....well, it's out there somewhere.

> > Some perform penetration testing and may need to legitimately use the
> > attack, but I would contend that these people should be capable of
> > writing their own attack after reviewing the documentation, use
> > commercially available tools, or just use other exploits to
> > accomplish their mission.
>
> Ira, what do you mean by this statement?  It's not a matter of being
> able to write an exploit, it's a matter of being able to Verify findings
> versus Identify findings in a reasonable time frame.  It's one thing to
> say "based on version information, we believe this application may be
> vulnerable" and quite another to say "This application has been verified
> to be vulnerable".  Oh, and how exactly would "other exploits" be of any
> use?  I'm not sure if your original words got edited, but that last
> paragraph illustrates a fundamental misunderstanding of thorough
> security testing.

hmmm.  i took Ira's statement to mean that if you're a pen-tester
worth half a chit, you'll be able to come up with a way to test for
the vuln on your own.  Note that I'm not saying that Ira is worth half
a chit...but, if you're contracted to scan a newtork and can't come up
with your own stuff, then your precentage of chit is on the decline.


> > The benefit provided by one legitimate use does not overcome the large
> > scale malicious use of an attack by hackers around the world. If the
> > attack is incorporated into worms, which happened with the Blaster
> > worm, the damage goes into the billions of dollars.
>
> I'd like to throw the "monoculture" crap back at you on this one.  If
> the attack payload is easily identifiable and reused, then the gateway
> devices should be able to mitigate the risk.  I've never been a fan of
> IDS or IPS systems as I don't believe they are properly labeled.  They
> do not detect or prevent intrusions.  However they are getting
> particularly good at detecting and in some cases preventing (at the
> gateways) worms.  This is where your Worm Prevention System (WPS/WDS)
> can help you... that is of course until a vulnerability is distributed
> to attack them :).

one, you're contradicting yourself above.

two, this is about as silly as the 'encrypting email' post.  re-read
what you just posted.  are you saying that gateway devices should be
doing signature matching on known exploits?


Julio Patel
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave