How bad is it?

Thank you to John Menerick and Ben Nagy for entertaining my questions on the Daily Dave list.

Q: Is the recent ie6 0-day anything special?

John: Not really. Not as special as the NT <-> Win 7 issue recently highlighted.

Q: How many similar 0-days are for sale on the black market?

John: Quite a few.

Ben: I'd love to see your basis for this assertion. I'm not saying that in the "I don't believe you" sense, only in the "everyone always says that but nobody ever puts up any facts" sense.

Q: What is the rate/difficulty for discovery of new windows-based 0-days for the common MS and Adobe products that are installed on almost every corporate client? (I heard Dave mention that discovery is getting more difficult)?

John: Not terribly difficult for someone who is dedicated. Then again, my idea of difficult is much different from the avg. person

Ben: I think that while finding 0-days might be 'not terribly difficult', selecting and properly weaponising useful 0-days from the masses of dreck your fuzzer spits out IS difficult - at least in my experience. There was some discussion of the 'too many bugs' problem on this list previously and I know several of the other fuzzing guys are currently researching the same area. Of course you'd explain this to your 'avg. person', as well as explaining that the skillset for finding bugs is not necessarily the same as the skillset for writing reliable exploits for them, and that 'dedication' may not sufficiently substitute for either.

Lurene Grenier: I really feel that the "selecting good crashes" problem is not that hard to overcome if you have a proper bucketing system, and the ability to do just a bit of auto-triage at crash time. For example, the fuzzer I use now both separates crashes by what it perceives to be the base issue at hand, and provides a brief notes file with some information about the crash and what is controlled. This requires just a bit of sense in providing fuzzed input, and very little smarts on the part of the debugger. I really think the next step is automating that brain-jutsu; much of it is hard to keep in your head, but not hard to do in code.

Using this output, it's pretty easy to spend a lazy morning with your coffee grepping the notes files for the sorts of things you usually find to be reliably exploitable. From there you can call in your 30 ninjas and have at.

Creating reliable exploits is for sure the hardest part, but once you've done the initial work on a program, the next few exploits in it are of course more quickly and easily done.

As for the thought experiment, I think that the benefit of the top four researchers is that they've trained themselves over a long period of time (and with passion) to have a very good set of pattern-recognition tools which they call instincts. They know how to get crashes, and they know having seen one crash what's likely to find more. They know how to think about a process to get proper execution, and they're rewarded by success emotionally which makes the lesson learned this time around stick for when they need it again.

I honestly think that there is more pattern recognition "muscle-memory" type skill involved in RE, bug hunting, and exploit dev than pure mechanical process, which is why the numbers are so

skewed. It's like taking 4 native speakers of a language (who love to read!) and 100 students of general linguistics with a zillion dollars. Who will read a book in the language faster?

Q: How easy is discovery for someone with resources like the Chinese government?

John: Much simpler.

Ben: Setting aside the previous point that discovery is only the start, I think it's instructive to consider which elements of the process scale well with money.

Finding the bugs: You need a fuzzing infrastructure that scales - running peach on one laptop with 30 ninjas standing around it with IDA Pro open is not going to work. Also consider tracking what you've already tested, tracking the results, storing all the crashes, blah blah blah. This does scale well with money, but it's an area that not as many people have looked at as I would like.

Seeing which bugs are exploitable: Using a naive approach, this scales horribly poorly with money - non-linearly, to put it mildly. There are only so many analysts you will be able to hire that have enough smarts to look at a non-trivial bug and correctly determine its exploitability. You only have to look at some of the Immunity guys' (hi Kostya) records with turning bugs that other people had discarded as DoS or "Just Too Hard" into tight exploits. Even for ninjas, it's slow. There is research being done into doing 'some' of this process automatically (well, I'm doing some, and I know a couple of other guys are too, so that counts), but I don't know of anyone that has a great result in the area yet - I'd love to be corrected.

Creating nice, reliable exploits: I'd assert that this is like the previous point, but even harder. To be honest, it's not really my thing, so probably one of the people that write exploits for a living would be better to comment, but from talking to those kind of guys, it's often a very long road from 'woo we control ebx' to reliable exploitation, especially against modern OSes and modern software that has lots of stuff built in to make your life harder. I don't know how much of the process can really be automated - I mean there are some nice things like the (old now) EEREAP and newer windbg extensions from the Metasploit guys that will find you jump targets according to parameters and so forth, but up until now I was labouring under the impression that a lot of it remains brain-jitsu, which is hard to scale linearly with money.

So, while I think that 'simpler' is certainly unassailable, I would need more than a two word assertion to be convinced that it is 'much' simpler. If you give one team a million dollars and 100 people selected at random from the top 10% graduating computer science and you give the other team their pick of any 4 researchers in the world and 3 imacs, whom does the smart money think will produce more weapons grade 0day after 6 months?

(No it's not a fair comparison. It's a thought experiment.)

Food for thought, perhaps, since sound bites need little care and feeding.

Q: How bad is it really?

John: Look at the CVSSv2 score and adjust it to the environments where you determine "how bad it is." It could be much worse.

Q: I suspect we are just looking at one grain of sand in a beach of 0-days....

John: Correct. No one wants to let everyone else know what cards they hold in their hand, the tools in their toolbox, etc....

If I were cyberczar

(Read to the tune of "Rage Against the Machine : Killing in the Name")

1) I would defeat SQL Injection. This would be a multi-phased plan focusing on programmer tools and programmer training. The main use of any Federal funding I could secure would be to build the worlds best open source SQL Escaping library so legacy code could be retrofitted.

2) I would lobby the Fed's to create a new branch of the military. ARMY - NAVY - AIRFORCE - CYBERFORCE - MARINES. The problem is that big, and we are losing the game.

3) I would take copious notes from day 1. This is a thankless job with heaps of responsibility and absolutely no power. Might as well get a good book deal out of the experience.

OWASP Top 5 rc1 released!

I'm very impressed with the latest OWASP Top 10 2010 release candidate . But if a 10 item list is to long for you in this era of 140 character tweets, I present to you the unauthorized reductionistic OWASP Top 5.

And the OWASP Top 5 is:

1) Injection Flaws

2) Broken Authentication

3) Broken Access Control

4) Broken Encryption

5) Security Misconfiguration

The OWASP Top 5 team felt that A2 (XSS) could be considered to be another kind of injection problem. Like most injection flaws, XSS is controlled by contextual encoding.

A4 (Direct Object Reference), A5 (CSRF), A6 (Failure to Restrict URL Access) and A8 (Unvalidated Redirects and Forwards) could be considered to be classes of access control/authorization flaws. I think that A4/A6/A8 all easily fit into the access control category. But CSRF as just an access control problem? Yes! Authentication validates WHO you are. Authorization/Access Control validates WHAT can you do. CSRF tokens are just a piece of that task/activity validation.

A9 (Insecure Cryptographic Storage) and A10 (Insufficient Transport Layer Security) are 2 sides of the same data-encryption-lifecycle.

Hat's off to the OWASP Top Ten team. This brief reductionism is just a form of OWASP Top 10 flattery! :)

Hardware Security

A recent article in "Foreign Affairs" magazine titled "Securing the Information Highway" (co-authored by General Clarke and Peter Levin) caught my attention. Interesting stuff. Focuses on hardware security.

http://www.foreignaffairs.com/articles/65499/wesley-k-clark-and-peter-l-levin/securing-the-information-highway

Their basic thesis is that there is just no way possible to stop the threat of "electronic infiltration, data theft, and hardware sabotage" and that securing the nation infrastructure is "neither cost effective or technically feasible".

They suggest:

1) Risk Management : "US must develop an integrated strategy that addresses ... the sprawling communications network to the individual chips inside computers"
2) Diversification of the country's digital infrastructure
3) Secure the hardware supply chain

Worthwhile read.

justifying the focus on insider threat

Thank you to Mat Caughron at mat@phpconsulting.com for authoring this most excellent blog entry.

It is common to have the insider threat dismissed as a scare tactic or
worst-case-scenario and I believe this is a mistake.

We are all about the business value of risk.

Most enterprise companies have to protect themselves from malicious
insiders at all times and this affects the design of their software,
specifically the need for least privilege and generally all
requirements surrounding logging and internal controls.  My thinking
is that if you want to have a seat at the table during the beginning
phases of the software development life cycle, it is best to master
the concerns and business needs imposed by this type of risk.

Granted, our industry seems to generate snake oil by the barrel, which
is all the more reason for us to take these threats seriously and
calmly seek publicly documented data on real cases.

Indeed, one would hope the information security professional is
someone who helps to establish the boundaries of trust in systems
being built, not someone who vacuums up the pieces of broken projects,
however well such housekeeping pays.


Some references not yet mentioned in this thread:

Report from 1999 by NSTISSAM:
  http://www.cnss.gov/Assets/pdf/nstissam_infosec_1-99.pdf
Focus is on mechanisms more than specific incidents though a few are mentioned.

U^S3 report with Carnegie Mellon on insider threat, focus on
infrastructure and financial services industries, dated 2004/05/08:
 http://www.secretservice.gov/ntac/its_report_050516.pdf
 http://www.secretservice.gov/ntac/its_report_040820.pdf
 http://www.treasury.gov/usss/ntac/gov%20ExecSummary%202008_0108.pdf
Each sampling set is around 50 incidents or less.

Department of Energy is grappling with this as the disruptions from
insiders could be high impact:
 http://www.cio.energy.gov/documents/Tues_1400_SalonII_Randall.pdf

Belani / Wilson web application incident response and forensics
considers insider threats with two great examples:
   www.blackhat.com/presentations/bh-usa-06/BH-US-06-Willis.pdf
Also presented in Seattle at an OWASP chapter meeting.

None of these reports, however, can compare in detail to the data set
of the Privacy Rights Clearinghouse' chronological list of data
breaches.
 http://www.privacyrights.org/ar/ChronDataBreaches.htm

Until about 2006, the PRC list identified inside threat incidents as
"Dishonest insider." After that, the number of employee instigated
events is described with greater detail but is therefore harder to
search.   A quick look here should be enough to convince most on this
webappsec list that the impact from insider threats is not
insignificant.

As software security professionals, we can help to mitigate insider
threat problems and our value in doing so should not be
underestimated.

The commonplace nature of OWASP-top-ten type flaws should not prevent
us from acknowledging their utility in the hands of a malicious
employee, developer, manager, etc.

Mat Caughron CISSP
(408) 910-1266

mat@phpconsulting.com

When to use OWASP AntiSamy?

OWASP AntiSamy is a software engineering tool that allows a programmer to verify user-driven HTML/CSS input against a whitelist policy to ensure that is does not contain XSS.

But when do you use it?

1) If you accept "normal text data" from a user, then

a) (input validation) Use the ESAPI validator for input valiation (functions OTHER than getValidSafeHTML)

b) (output encoding) Use the ESAPI encoding library for contextual output encoding when displaying dynamic data in a web browser

1. encodeForHTML

2. encodeForJavascript

3. encodeForHTMLEntity

4. encodeForCSS

2) If you accept HTML from a user, you need to use AntiSamy

a) (input validation) You must validate and CHANGE (make it safer) HTML that you accept from a user with AntiSamy (which can be called via ESAPI - getValidSafeHTML)

b) (output translation) You can optionally use AntySamy for output translation (it does not encode; it only makes HTML "safer")

1. This is crucial when you have legacy HTML in your data storage mechanism that may still contain XSS

Real world cookie length limits

Daniel Stenberg recently posted some interesting test code and browser results to http-state@ietf.org describing the maximum amount of data that can be stored in a cookie:

****

... I just went ahead and wrote a CGI script that redirects to itself and grows a
cookie and stores its length in a URL field like "cookie.cgi?len=200" until
the length in the URL and the actual cookie length no longer matches.

Here's a few results from various browsers:

Firefox 3.0.12: 4000
Firefox 3.5: 4000
curl 7.19.5: 4999
IE 8: 5000
Opera 10.00 beta: 4000
Android 1.5 browser: 4000
Chrome 3.0.195.6: 4000
Wget 1.11.4: 7000[*]
mobile safari (iphone): 8000
lynx 2.8.7dev.9: 4000

I think we can safely say that most browsers support at least 4000 characters
cookie contents.

[*] = this reports "500 Internal Server Error" on 8000, which I don't
understand why but haven't bothered much more about.

The test is live here: http://daniel.haxx.se/test/longcookie.cgi Feel free to
use it if you want to try out other browsers, without torturing it of course!

And the perl script that runs it looks like this:

require "CGI.pm";

$len = CGI::param('len');
$c = CGI::cookie('data');

print "Content-Type: text/html\n";

if($len == length($c)) {
$c .= "A" x 1000;
$len += 1000;
print "Set-Cookie: data=$c\n";

print "Location: longcookie.cgi?len=$len\n";
print "\nmoo\n";
}
else {
printf "\nMax cookie length: %d\n", length($c);
}