Send Dailydave mailing list submissions to
dailydave@lists.immunitysec.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.immunitysec.com/mailman/listinfo/dailydave
or, via email, send a message with subject or body 'help' to
dailydave-requ...@lists.immunitysec.com
You can reach the person managing the list at
dailydave-ow...@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: Exploits matter. (c0lists)
2. Re: Exploits matter. (security curmudgeon)
3. Re: Exploits matter. (Ilfak Guilfanov)
4. Re: Exploits matter. (Matthew Wollenweber)
5. Re: Exploits matter. (Tom Parker)
----------------------------------------------------------------------
Message: 1
Date: Wed, 7 Oct 2009 20:17:45 -0400
From: c0lists <li...@carnal0wnage.com>
Subject: Re: [Dailydave] Exploits matter.
To: security curmudgeon <jeri...@attrition.org>
Cc: dailyd...@lists.immunityinc.com
Message-ID:
<5c2b0f0b0910071717y418a8374y9ed66ec1e92e8...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Oct 7, 2009 at 7:49 PM, security curmudgeon
<jeri...@attrition.org>wrote:
>
>
> On Wed, 7 Oct 2009, c0lists wrote:
>
> : Because all those databases are incomplete it would be nice if "someone"
> : would start putting that information in their db to say immunity has the
> : exploit or core impact has the exploit.
>
> It would also be nice if these companies would provide a little better
> public mechanism for disclosing that information, that can be easily
> referenced by a VDB. Dave posted to the list about the recent
> vulnerability, but there are hundreds more Immunity developed with no
> easily referenced date or details.
>
> Because vulnerability information is valuable, we also run into the
> problem of not knowing if two companies have the same vulnerability
> figured out, if a vendor's recent announcement about fixing an 'overflow'
> is the same one as a researcher's, etc. This is becoming a big headache
> for VDBs; the VulnDisco work by Evgeny is a good example.
>
I agree. It would seem to be in their best interest to allows maintainers of
exploit databases to have access to the exploit metadata even if it wasnt in
real time (perhaps quarterly) and would be very little overhead. Most of the
updates go into their monthly "download our new version" or "updated
moduels" emails anyway.
That certainly doesnt address all the issues you brought up but would be a
step in the right direction. Maybe Immunity can start :-)
-CG
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.immunitysec.com/pipermail/dailydave/attachments/20091007/aa5a1875/attachment-0001.htm
------------------------------
Message: 2
Date: Thu, 8 Oct 2009 08:05:53 +0000 (UTC)
From: security curmudgeon <jeri...@attrition.org>
Subject: Re: [Dailydave] Exploits matter.
To: Wouter Slegers <wou...@yourcreativesolutions.nl>
Cc: dailyd...@lists.immunityinc.com
Message-ID: <pine.lnx.4.64.0910080726140.22...@forced.attrition.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi Wouter,
: > Ten thousand or not, I cannot download the exploit from Immunity's web site,
: > milw0rm or anywhere else, correct? To me, and to OSVDB who tracks that
: > metric, that is flagged as 'rumored/private'.
: >
: > Can our industry really put a numeric line on public vs private in the
: > scenario you describe? Do 9,999 CANVAS customers = private, but 10,000
: > CANAVAS customers = public?
: In the more formalized evaluation worlds (Common Criteria, EMVco, etc), the
: concept "public/private" is really just one input for the calculation of the
: cost to the attacker. In those terms, the costs in dollars over time would be
: something like this:
: * Prior to discovery that that part of the SMBv2 implementation had a
: potential place to attack: fuzzing+analysis, what about 6 person months (this
: is really a wild guess, anyone have a good number on this?), so say ~$60.000.
: * From discovery to CANVAS-integrated attack: 3 person months, so say ~$30.000
: * Now in CANVAS (and you'll get way more goodies with it): ~$4.000
: * When it will be on milw0rm etc: time to make it work properly, ~$200?
:
: So the "public/private" discussion in my view is a discussion between a $4.000
: and a $200 attack, both of which I cannot understand that youwould call be an
: investment that is too steep for a real attacker.
:
: Although I can understand from OSVDB point of view that they cannot confirm
: the status, it is disturbing that apparently people are using the uncertainty
: of the measurement (of the OSVDB in this case) to doubt whether it is in the
: $30.000 or $200 range.
Uh, either I do not fully understand your point, or I do not fully
understand where you misunderstood how the economy works, at least in the
U.S.
The difference betwene $US 30 and $US 200 is big. The difference between
$US 30,000 and $200 is even bigger. I mention that because I believe your
. in the 30.000 value really means 30,000, which is a huge difference to
us Americans. Regardless of your use of . vs , anyone versed in math or
economics could lecture on percentages of 30 and 200, or 200 and 30000.
As applies to OSVDB, if I am doubting our ability to intellectually track
"public vs private", then the debate over the dollar value should not be
very relevant, especially in a historic context.
: I'd expect that the vulnerability database crowd would have a "X claims
: to have the exploit working, here is X's history of those claims so X
: seems to be truthful in his claims"-construction to cover this. If so,
: if it is easy to provide such info to the vulnerability database it
Oh sweet jesus, no you didn't!
What you propose is based on what the VDB world calls "researcher
confidence". Meaning, the VDBs actually track a history of disclosure for
a given individual, track the vulnerabilities they publish, the severity
of those vulns, the products they were found in, the number of third-party
disputes, the number of vendor-disputes, and several other metrics, to
calculate a 'resarcher confidence' score.
OSVDB actually began to track classification entries that help calculate
such scores with "third-party verified", "third-party disputed", "vendor
verified" and "vendor disputed". There was a slight method to our madness.
This has been in demand for more than five years, not only by OSVDB, but
by specific people at CVE and other VDBs as well. For mostly political
reasons, OSVDB has been slowly working toward the ability to track this
metric while the others watched with anticipation. In the last few years,
we have also begun to discuss and implement a framework for tracking
*vendor confidence*. It isn't only researchers that are flaky and
ill-equipped to handle vulnerability disclosure. =)
While beating my chest in primitive style, and hopped up on too many
glasses of scotch, i'll go ahead and say that only OSVDB has really begun
to address and implement such scoring mechanisms. Disclaimer: really smart
guys from other VDBs have given input in our discussions, but cannot
implement such a system on their own. Disclaimer #2: Even after all the
discussion, we're left with a classic problem of deciding a system that is
a perfect balance between 'over simplified' (and inaccurate) and 'overly
complex' (and convoluted).
Long story short, we're working on a better way to classify both resarcher
and vendor confidence scores. Even a small hint of that, has caused some
notable panic in the *vendor* world, not the researcher world.
: would seem good marketing for vendors of tools like CANVAS to fill it
: with "we can already do this". That way, someone researching the
: potential vulnerabilities in his shiny new Windows server will find the
: remark that SMBv2 could be a serious problem, and see the hint that
: CANVAS could be used to check. Or is this too simple in the market
: reality?
I'll go ahead and throw the gauntlet down to Dave and Immunity. OSVDB has
discussed ways to better implement some of these metrics, specifically an
overhaul to our classification system regarding exploit availability, as
well as "vulnerability framework" vendors, free and commercial, to share
with us a better understanding of what they have in their arsenal without
giving away details that are a detriment to their commercial advantage.
(that last sentences makes me sick on one level, fascinated on another)
Would *any* vendor out there, developing exploits, give OSVDB a matching
of CVE or OSVDB ID, along with their commercial capability to exploit the
vulnerability? More specifically, not just a yes/no, but a date they had
developed such an exploit? If the vendor was considered reliable (yes,
we've been tracking to some degree in sekrit), we'd make such information
a part of our database.
OSVDB would in turn break from tradition, and offer a link back to that
vendor, under the 'Tools & Filters' section of our display. While it may
seem rather unassuming, it would be the first time we did not link to a
public/free resource, and fully demonstrate the capability and full
arsenal your company had to offer. Hell, even giving us a 75% matching
(say, delayed by 30 days?) would be a fascinating metric to track.
So far, the only companies that have shown us a *hint* of this information
are iDefense, Tipping Point and some random guy named Evgeny Legerov.
Bottom line, we'd love to track more information, develop more meaningful
metrics and produce more relevant analysis. However, we're limited by the
reliable dataset we have available.
: BTW, more philosophical: it does show the enormous cost decrease to the
: attacker over time (~2-3 months calender time?), i.e. 0days custom
: developed are orders more expensive, and the hidden cost of
: "weaponizing" it is what tools like CANVAS solve for quite a cheap
: price.
It does, you are right. But one thing keeps sticking in my mind. While
companies like Immunity spend 30 days with X researchers to write a
vulnerability, companies like Tenable, SAINT and Qualys are taking 2 - 5
days to reverse and figure out a working vulnerability check. Not an
exploit, but a way of determining exploitability, both locally and
remotely. Those vendors have to be putting extra pressure on shops like
Immunity or others, as they severely limit the window between 2-5 and 30
days, as many high value targets patch their systems, before a working /
weaponized exploit is developed. Yet another variable in determining the
value or timeframes of everything discussed.
------------------------------
Message: 3
Date: Thu, 08 Oct 2009 10:47:19 +0200
From: Ilfak Guilfanov <i...@hexblog.com>
Subject: Re: [Dailydave] Exploits matter.
To: Steve Shockley <steve.shock...@shockley.net>
Cc: dailydave@lists.immunitysec.com
Message-ID: <4acda717.6040...@hexblog.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sorry for my ignorance, are NULL pointer dereference bugs exploitable today?
Steve Shockley said the following on 7/10/2009 15:56:
> On 10/6/2009 10:12 AM, dave wrote:
>> But if you are like me, you are thinking "But it's still worth it". And
>> here's why: Without exploits, you have no way to know what matters. Or,
>> more realistically, what doesn't matter. I.E. in this case, 64 bit
>> computers are not going to be exploited with SMBv2 any time soon, of at
>> all. Since enterprises skipped Vista and use 64 bit for their Windows
>> 2008 servers, SMBv2 didn't hurt as badly as you would expect.
>
> Doesn't that just mean that *you* can't exploit it right now? Not
> trying to insult your haxxor skillz, but a few years ago you couldn't
> get a virus via email or Word, and null pointer dereference bugs could
> never be exploited.
> _______________________________________________
> Dailydave mailing list
> Dailydave@lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
--
Best regards,
Ilfak mailto:i...@hexblog.com
------------------------------
Message: 4
Date: Thu, 8 Oct 2009 09:58:26 -0400
From: Matthew Wollenweber <m...@cyberwart.com>
Subject: Re: [Dailydave] Exploits matter.
To: c0lists <li...@carnal0wnage.com>
Cc: dailyd...@lists.immunityinc.com
Message-ID:
<5fb633320910080658q6c0de3a8h57fa12713721b...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
It might be a little more informative to add an extra field to various
databases. I say maybe, as unless the databases actually test the
exploits accuracy would be questionable. But I think the marginal
difference between the terms "private/rumored" and "private/for sale"
doesn't examine the underlying problem -- which is what Matt Olney and
I believe Dave were getting at. The practical distinction between
public and private doesn't mean much. For $1000 you can have the
exploit from Immunity -- or you can likely get it for free if you know
someone. That's not a particularly high bar, but most organizations
treat private exploits (and by that I mean anything not on milw0rm,
metasploit, or bugtraq) as an unfathomable problem. So they obviously
ignore it.
Now the above is precisely the problem (IMO). It's pretty easy to buy
"private" exploits. It's pretty easy to write simple stack buffer
overflows that you'll find in vast amounts of in-house software. It's
pretty easy to use a packer to get past most or all AV. All of the
above will generally be near completely immune to most defenses. These
are insurmountable problems in the eyes of most businesses. When
considering defending against these threats, you might have better
luck convincing them to train school kids to defend against the
military. This is why they focus on whether one can easily download
the exploit or not. If so, then they have a problem that's in their
process to tackle. If not, it's too hard and they accept the risk.
They prefer the latter.
When you consider that it's "pretty easy" to do several things that
are insurmountable problems to most businesses then you really begin
to see the problem.
Defense security people like to gripe about people that release
exploits. It's a natural response given that their lives are made more
difficult. Ultimately, they're going to have to tackle the above type
problems, and (IMO) full-disclosure pushes them one step closer to
admitting the current security balance isn't acceptable. Since many
exploits are more difficult these days, there's going to be more
private/for-sale exploits and hopefully they'll begin to tackle these
problems. Until then, I expect to hear much more whining.
/rant.
On Wed, Oct 7, 2009 at 8:17 PM, c0lists <li...@carnal0wnage.com> wrote:
>
>
> On Wed, Oct 7, 2009 at 7:49 PM, security curmudgeon <jeri...@attrition.org>
> wrote:
>>
>>
>> On Wed, 7 Oct 2009, c0lists wrote:
>>
>> : Because all those databases are incomplete it would be nice if "someone"
>> : would start putting that information in their db to say immunity has the
>> : exploit or core impact has the exploit.
>>
>> It would also be nice if these companies would provide a little better
>> public mechanism for disclosing that information, that can be easily
>> referenced by a VDB. Dave posted to the list about the recent
>> vulnerability, but there are hundreds more Immunity developed with no
>> easily referenced date or details.
>>
>> Because vulnerability information is valuable, we also run into the
>> problem of not knowing if two companies have the same vulnerability
>> figured out, if a vendor's recent announcement about fixing an 'overflow'
>> is the same one as a researcher's, etc. This is becoming a big headache
>> for VDBs; the VulnDisco work by Evgeny is a good example.
>
> I agree. It would seem to be in their best interest to allows maintainers of
> exploit databases to have access to the exploit metadata even if it wasnt in
> real time (perhaps quarterly) and would be very little overhead. Most of the
> updates go into their monthly "download our new version" or "updated
> moduels" emails anyway.
>
> That certainly doesnt address all the issues you brought up but would be a
> step in the right direction. Maybe Immunity can start :-)
>
> -CG
>
>
> _______________________________________________
> Dailydave mailing list
> Dailydave@lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>
>
------------------------------
Message: 5
Date: Thu, 8 Oct 2009 10:01:14 -0400
From: Tom Parker <t...@rooted.net>
Subject: Re: [Dailydave] Exploits matter.
To: security curmudgeon <jeri...@attrition.org>
Cc: dailyd...@lists.immunityinc.com, dave <d...@immunityinc.com>
Message-ID:
<a664ede0910080701i79b4be81l77b7fdc83ff18...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Oct 7, 2009 at 2:39 PM, security curmudgeon
<jeri...@attrition.org>wrote:
> Ten thousand or not, I cannot download the exploit from Immunity's web
> site, milw0rm or anywhere else, correct? To me, and to OSVDB who tracks
> that metric, that is flagged as 'rumored/private'.
> Can our industry really put a numeric line on public vs private in the
> scenario you describe? Do 9,999 CANVAS customers = private, but 10,000
> CANAVAS customers = public?
>
While I understand the challenge of verifying the existence and nature of
commercial exploitation tools, down playing exploits by databases like OSVDB
is damaging to the industry and is creating a false sense of security
amongst organizations - especially those who charge their security programs
to vanilla CISSP's. Case in point - large company runs an automated scanner
over their network on a monthly basis, which regularly finds flaws. They
prioritize remediation of findings based on CVSS scores, which have been
calculated in part through utilizing data from OSVDB. Days, months, weeks
later the organization is attacked/audited by a group who
paid/stole/borrowed a copy of Canvas/Core/et al. Organization gets owned.
The past two VzB data breach reports have demonstrated a trend, that a large
number of compromises (around 70% if memory serves), resulted from
exploitation of vulnerabilities that at time of compromise had been patched
by the vendor for a year or more. I'm not sure how you would go about
obtaining this kind of data (or indeed how VzB gets their data), but it
would be an interesting metric to see how many of those known/vendor-patched
issues had been neglected/de-prioritized due to misconceptions about their
level of exploitability.
It would indeed be a good thing if Immunity et al would publish some kind of
unified database of their proprietary exploits, mapped to CVE-ID etc, but
I'm not sure if it's their responsibility to do so. IMO, the scanning
vendors, Qualys, Rapid7, nCircle etc are missing a trick if they aren't
buying themselves a copy of CANVAS and ensuring that when their scanner
finds a vulnerability supported by it [CANVAS], they are providing users a
CVSS score based on the fact that they have independently verified the
existence of robust exploit code for the respective vuln.
-Tom
> .b
> _______________________________________________
> Dailydave mailing list
> Dailydave@lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.immunitysec.com/pipermail/dailydave/attachments/20091008/034080ac/attachment.htm
------------------------------
_______________________________________________
Dailydave mailing list
Dailydave@lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave
End of Dailydave Digest, Vol 51, Issue 3
****************************************
