When asked to comment on an article comparing Windows and Linux security I wrote up a few bullet points showing the pros and cons on each side. My commentary ended up posted as a guest blog on the LastWatchdog blog. You can check it out here.

Several months ago, the Fortify Security Research Group (SRG) published Crypto Manifesto -- a technical note that contains the guidelines for the usage of various cryptographic algorithms in a variety of popular programming languages. The blog entry that accompanied this publication is here. One of the guidelines we gave in the paper (and that we enforce in Fortify Secure Coding Rulepacks) states that keys for symmetric encryption algorithms (such as AES) should be no less than 128 bits in length, naturally implying that keys of 192 and 256 bits are better or at least are as good as those of 128 bits. It turns out, though, that this might not actually be the case.

A recent paper describes new cryptanalytic attacks on AES that are better than brute force. The attacks work only on AES-192 and AES-256, and the idea used for these attacks does not apply to AES-128, making it theoretically stronger than the other two variants of the block cipher, at least against these attacks. Interestingly enough, the attacks are based on the idea of local collisions -- the notion derived from the cryptanalysis of hash algorithms. This means that these attacks will have implications on AES-based hash functions. The publication of the paper raised many interesting questions about security of AES, and a lot of them are addressed by the authors in their FAQ.

How does this affect the guidance we've been giving? We do not think it does. Even though the new attacks are better than brute force, they are still a long way from being practical. As far as we are concerned, symmetric keys of 128, 192, and 256 (no less than 128) bits might not be safe forever, but they're still safe today.

Technorati Tags: crypto encryption keys AES

One of the challenges of an infosec practitioner is remaining knowledgeable about the emerging threats coming down the pipeline. The following are some of the online resources I leverage to seek out emerging threats and as well as manage the information:

• Google Alerts - This tool is a no brainer. As with any other Google alert, simply supply your search terms and sit back as Google does its magic. A few of search terms I have plugged in are "hacked security computer", and "security data breach databreach" "sql injection xss" with a configuration to email me the results once a day. Overall, this simple email alert is a very effective way to be updated on recent breaches.
• XSSed Alerts - XSSed.org is a site were users report cross-site scripting vulnerabilities as they are found. The site also allows one to monitor domains for newly discovered vulnerabilities. The submitted proofs-of-concept are valuable for determining how various XSS attacks are crafted.
• Twitter - As much as I bash Twitter for their lax security, I have gotten a lot of mileage out of the very active info security community that "tweet". Combined with the very liberal usage of hashtagged topics (#security, #vulnerability, #xss being amongst my favorites), Twitter provides a quick means for seeing what security topics, events, and incidents are "hot" at any given moment.
• RSS feeds - Another no brainer for the list. There's no need to elaborate on the benefits of RSS. Instead, I'll list some of my daily security reads. These are in no particular order of importance:
  • CGISecurity - Website and Application Security News
  • GNUCITIZEN
  • The Security Development Lifecycle
  • Wired: Threat Level
  • ha.ckers.org web application security lab
  • Dark Reading: Snake Bytes
  • Jeremiah Grossman

Technorati Tags: emerging threats

Recently, there has been a lot of talk and speculation regarding various cryptographic algorithms that are still widely used. Some security experts suggest banning a number of them; while others argue that some of these algorithms are still secure enough to be used for the time being. No wonder developers remain confused about the choice of which crypto to use in their code.

In order to clarify things, the Fortify Security Research Group (SRG) performed a thorough investigation of the subject. As a result, we came up with a set of guidelines that will be published later this week in the form of a Crypto Manifesto and is available immediately to Fortify customers through the Premium Content area of the Customer Portal. These guidelines cover four of the most critical topics: hash functions, encryption and encoding functions, encryption keys, and pseudo-random number generators (PRNGs). All of the guidelines will be enforced through the most recent version of the Fortify Secure Coding Rulepacks, which were released on February 27th, 2009.

The table below summarizes our guidelines on the usage of crypto in security sensitive contexts:

	Avoid	Use
Cryptographic Hashes	MD2, MD4, MD5, SHA-1	RIPEMD-160, SHA-224, SHA-256, SHA-384, SHA-512
Encryption and Encoding	RC2, RC4, DES	3DES, AES
Symmetric Keys (AES)	< 128 bits	>= 128 bits
Public Keys (RSA)	< 1024 bits	>= 2048 bits with OAEP padding
Pseudo-Random Number Generators (PRNGs)	Statistical PRNGs	Cryptographic PRNGs

When it comes to computing hashes on security sensitive data such as passwords, certificates, or any other kinds of digital security credentials where collision and pre-image resistance are important, MD2, MD4, MD5, and SHA-1 are no longer recommended. Collisions have been found in MD2 as early as 1997, while attacks on MD4, MD5, and SHA-1 were demonstrated in 2005. Furthermore, a much more recent research project showed at the end of December 2008 that it is possible to mount a man-in-the-middle attack on Secure Sockets Layer (SSL) via creating rogue certificates issued by rogue Certification Authorities (CAs), only with the help of a homegrown array of machines. Combine this work with Dan Kaminsky's Domain Name System (DNS) problems, and you got yourselves virtually undetectable phishing attacks on the internet.

Similarly to hashing algorithms, a number of encryption algorithms have recently been broken: RC2, RC4, and DES. Worse yet, base64 encoding is mistakenly thought of by many as an encryption scheme. It is important to point out that base64 encoding is useful when there is a need to transmit binary data over a communication channel that is designed to transmit character data. However considering that its character space is only of size 64, the scheme does not provide the same security guarantees as strong cryptographic encryption algorithms, and therefore should not be used for protecting secrets.

In addition to choosing the right encryption algorithm to protect sensitive data, it is important to generate appropriate keys to use with these schemes. Considering that hardware has been getting faster and faster in recent years, choosing appropriate encryption key lengths is becoming increasingly important as the rate at which attackers can make guesses grows. The National Institute of Standards and Technology (NIST) suggests using symmetric keys (particularly, AES keys) of no less than 128 bits in length and RSA keys of no less than 1024 bits, moving towards using 2048-bit keys by 2013. In the case of RSA keys, it is also important to choose the right padding scheme, which can prevent a number of attacks that potentially work against RSA without padding. Public-Key Cryptography Standard (PKCS) #1 v.2.1 recommends the use of Optimal Asymmetric Encryption Padding (OAEP) for new applications.

As for the pseudo-random number generators, when unpredictability is critical, which is the case in security-sensitive contexts, it is important to use strong cryptographic rather than statistical PRNGs. Unlike cryptographic PRNGs, statistical PRNGs produce highly predictable output, which makes it trivial for an attacker to guess the values they generate. However, statistical PRNGs are acceptable when predictability is not a concern - for example, for generating a random order in which images are displayed in a slideshow.

Technorati Tags: hashing encryption base 64 encoding keys PRNGs

Gunnar Peterson just posted an insightful response to a comment on a webcast that he and I (mostly he) did on SOA a while back. Most importantly, Gunnar reiterates the point that there's a big divide between most of the set folks with software knowledge and the set with security knowledge. Technology is great, and we're learning more and more ways to leverage it to productive ends, but arming the people responsible for building secure software with the right know-how is critical.

I've spent the last few months running around with Gary McGraw and Sammy Migues talking to organizations that represent the leading edge of software security. We talked to top software vendors, financial services companies, and technology companies. It's been fascinating for many reasons, not the least of which is how similar the leader's approaches are considering how different their businesses are. The result of these interviews is a new study we announced today called the Building Security In Maturity Model (BSIMM). BSIMM has it's own Web site. Take a look.

The meat of BSIMM is a set of real-world software security activities, all of which we observed in one or more of the organizations we studied. We've organized the activities so that you can determine where you stand with your software security initiative and how you can best evolve an initiative over time. Until now, the great majority of the published work in our field has been either small-scale (shown to works for one program or one programming team), or unproven (a bunch of good ideas that might or might not work outside the group that created them.) To my knowledge, this is the first real study of the software security practices across a range of successful organizations.

So far we've seen a warm reaction from the press and analysts. See this piece in the Wall Street Journal. But the best reactions have been from the participants. People have been really excited to see the results and learn about how they compare to their peers. We hope BSIMM will improve ties among the community of people who lead asoftware security initiative in their organization. We plan to continue adding new organizations to the model, so if you're interested, please drop me a line.

For those who would like to know more about our SHA-3 analysis:
NIST SHA-3 Competition Security Audit Results

NIST is currently holding a competition to choose a design for the SHA-3 algorithm (Bruce Schneier has a good description of secure hashing algorithms and why this is important). The reference implementations of a few of the contestants have bugs in them that could cause crashes, performance problems, or security problems if they are used in their current state. Based on our bug reports, some of those bugs have already been fixed. Here's the full story:

The main idea behind the competition is to have the cryptographic community weed out the less secure algorithms and choose from the remainder. A couple of us at Fortify (thanks to Doug Held for his help) decided to do our part. We're not hard-core cryptographers, so we decided to take a look at the reference implementations.

This competition is to pick an algorithm, but all of the submissions had to include a C implementation, to demonstrate how it works and test the speed, which will be a factor in the final choice. We used Fortify SCA to audit the 42 projects accepted into Round 1. We were impressed with the overall quality of the code, but we did find significant issues in a few projects, including buffer overflows in two of the projects. We have emailed the submission teams with our findings and one team has already corrected their implementation.

Confirmed issues:

Implementation	Buffer Overflow	Out-of-bounds Read	Memory Leak	Null Dereference
Blender	1	0	0	0
Crunch	0	0	0	4
FSB	0	0	3	11
MD6	3	2	0	0
Vortex	0	0	1	15

One of the projects with buffer issues was MD6, the implementation provided Professor Ron Rivest and his team. All of the problems came back to the hashval field of the md6_state struct:

 

     unsigned char hashval[ (md6_c/2)*(md6_w/8) ];

The buffer size is determined by two constants:

 

     #define w md6_w     /* # bits in a word                   (64) */      #define c md6_c     /* # words in compression output      (16) */

At several points, this buffer is read or written to using a different bound:

 

     if (z==1) /* save final chaining value in st->hashval */           { memcpy( st->hashval, C, md6_c*(w/8) );             return MD6_SUCCESS;           }

Further analysis showed that ANSI standard layout rules would make incorrect behavior unlikely, but other compilers may have allowed it to be exploited. The MD6 team has doubled the size of the vulnerable buffer, which eliminated the risk. In this case, Fortify SCA found an issue that would have been difficult to catch otherwise.

The other buffer overflow was found in the Blender implementation, from Dr. Colin Bradbury. This issue was a classic typo:

 

     DataLength sourceDataLength2[3];	// high order parts of data length      ...      if (ss.sourceDataLength < (bcount | databitlen)) // overflow           if (++ss.sourceDataLength2[0] == 0) // increment higher order count                if (++ss.sourceDataLength2[1] == 0) // and the next higher order                     ++ss.sourceDataLength2[3]; // and the next one, etc.

The developer simply mistyped, using 3 instead of 2 for the array access. This issue was probably not caught because it would not be exposed without a very large input. The other issues we found were memory leaks and null dereferences from memory allocation.

This just emphasizes what we already knew about C, even the most careful, security conscious developer messes up memory management. Some of you are saying, so what? These are reference implementations and this is only Round 1. There are a few problems with that thought.

Reference implementations don't disappear, they serve as a starting point for future implementations or are used directly. A bug in the RSA reference implementation was responsible for vulnerabilities in OpenSSL and two separate SSH implementations. They can also be used to design hardware implementations, using buffer sizes to decide how much silicon should be used.

The other consideration is speed, which will be a factor in the choice of algorithm. The fix for the MD6 buffer issues was to double the size of a buffer, which could degrade the performance. On the other hand, memory leaks could slow an implementation. A correct implementation is an accurate implementation.

We will put out a more detailed report on all the results soon.

Technorati Tags: sha-3 buffer overflow

When we published a report on voting back in October, our conclusion included the line:

Just as important, we must not forget about election systems until October 2012.

So, what has happened since then?

Well, November wasn't a huge disaster, which is good. It'll be awhile before people start putting out reports that can really tell us how things went but we have a result that no one can really dispute (at least in the presidential election - I'm just going to ignore Minnesota for now).

But since November, we've seen some interesting stuff. Everyone's favorite whipping boy, the-company-formerly-known-as-Diebold (Premier Election Solutions), has been in the news. The state of Maryland is suing the company for the $8.5 million they spent fixing security problems with the $65 million of touch-screen machines they bought in 2001. Meanwhile, controversy is brewing in California over tabulation software Diebold knew would randomly delete ballots.

I'm going to be an optimist for a moment and explain how these articles actually point to some positive steps:

• Maryland admits there are problems and has worked toward fixing them based on independent expert advice. One disturbing thing we found when we looked into the electronic voting security was that election officials tend to trust the voting manufacturers over security experts. I'm fully aware that this change of heart in Maryland is the result of a lot of bad publicity and lawsuits directed toward the state, but it's progress.
• Maryland is making Diebold pay for it's mistakes. This is the only way we will see these companies produce better products - by making it expensive and impractical to do otherwise.

In California:

• They figured out the ballots were missing because Humboldt County has implemented a public auditing program. All of the ballots included in the tally are scanned and posted online to allow anyone to do their own count. During this process, they discovered they had more scanned ballots then the system reported. This sounds like a pretty good rebuttal to those who keep insisting there is no need for a physical verification mechanism. It also sounds like a great program, I'd love to see this done more widely.

Of course, these articles also point to underlying screw-ups, but I'm going to focus on the possibility that these steps will lead to more steps and we'll be in a different place in October 2012.

Technorati Tags: electronic voting diebold security

When we published a report on voting back in October, our conclusion included the line:

"Just as important, we must not forget about election systems until October 2012."

So, what has happened since November? Everyone’s favorite whipping boy, the-company-formerly-known-as-Diebold (Premier Election Solutions), has been in the news. The State of Maryland is suing the company for $8.5 million spent fixing security problems with touch-screen machines they purchased in 2001 leading up to the 2008 election. Meanwhile, controversy is brewing in California over tabulation software that not only is known to randomly delete ballots, does not log such actions. However, I’m going to be an optimist for a moment and explain how these articles actually point to some positive steps: - Maryland admits there are problems and has worked toward fixing them based on independent expert advice. One of the overwhelming problems we found when we looked into the electronic voting security is the disturbing tendency for election officials to trust the voting manufacturers over security experts. I’m fully aware that this change of heart in Maryland is the result of bad publicity and lawsuits directed toward the state, but it’s progress. - Maryland is applying economic pressure. This is the only way we will see these companies produce better products, making it expensive and impractical to do otherwise. In California: - This problem was found because Humboldt County in California has implemented a public auditing program. All of the ballots included in the tally are scanned and posted online to allow anyone to do their own count. During this process, it was discovered the official count different from the number of scanned ballots. This sounds like a pretty good rebuttal to those who keep insisting there is no need for a physical verification mechanism. It also sounds like a great program, I’d love to see this done more widely. Of course, these articles also point to underlying screw-ups, but I’m going to focus on the possibility that these steps will lead to more steps and we’ll be in a different place in October 2012.