In addition to their other capabilities, Fortify Java Annotations can be used to identify new vulnerabilities in code. For example, the following code writes sensitive user information to a log file, but Fortify SCA cannot report a warning out-of-the-box because it has no knowledge of the sensitivity of the data in question.

String query = "Select credentialA, keyB, elementC from userTable where userid = ?"; PreparedStatement pstmt = connection.prepareStatement(query); pstmt.setInt(1, userid); ResultSet results = pstmt.executeQuery();  // extract data from the ResultSet while (results.next()) {   String credentialA = results.getString(1);   int keyB =  results.getInt(2);   Blob elementC = results.getBlob(3); 	   String stringBlobRepresenation = new String(elementC.getBytes(1, (int) elementC.length()));   logger.info("Retrieved info for user " + userid + ": " + stringBlobRepresenation); } 

This code snippet queries the application’s database using Java Prepared statements to retrieve information about the user userid. The userTable table contains a sensitive column elementC that must never be handled in an insecure way. As part of the debugging effort, a developer has insecurely logged elementC to disk, thus compromising the sensitive information it contains.

By adding the @FortifyPrivate annotation to the code above, a developer can tell Fortify that elementC is sensitive and allow Fortify SCA to identify dangerous uses of this variable.

String query = "Select credentialA, keyB, elementC from userTable where userid = ?"; PreparedStatement pstmt = connection.prepareStatement(query); pstmt.setInt(1, userid); ResultSet results = pstmt.executeQuery();  // extract data from the ResultSet while (results.next()) {   String credentialA = results.getString(1);   int keyB =  results.getInt(2);   @FortifyPrivate Blob elementC = results.getBlob(3); 	   String stringBlobRepresenation = new String(elementC.getBytes(1, (int) elementC.length()));   logger.info("Retrieved info for user " + userid + ": " + stringBlobRepresenation); } 

Fortify SCA now reports the privacy violation that occurs when elementC is logged.

As we mentioned in a previous post, Fortify 360 2.0 and the Q1-2009 update to the Fortify Secure Coding Rulepacks now recognize the following Fortify Java Annotations:

• Dataflow: Source, Sink, Passthrough, and Validation
• Field and Variable: Password, NotPassword, Private, NotPrivate, NonNegative, NonZero
• Other: Dangerous Class, Method, Field, and Variable and CheckReturnValue

A detailed sample that demonstrates the full capabilities of Fortify Java Annotations is available with supported versions of Fortify 360 and through the Premium Content section of the Customer Portal.

Technorati Tags: annotations java false positives false negatives libraries jars libs

Who's reading this blog? The author(s) of Conficker, apparently. Here's the story.

Anyway, hello Conficker crew. F*** you very much for your attention.

Technorati Tags: Conficker SHA-3 MD-6

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:

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

Fortify Java Annotations allow developers to give Fortify SCA hints about how their code works, which can prevent both false positives or false negatives. Like custom rules, annotations work by augmenting Fortify's model of the program with additional information and allow for more accurate analysis.

Consider the following code, which loads a password prompt for a login screen, logs it, and returns the loaded string to its caller.

private String loadPasswordLabel() {   String passwordLabel = props.getProperty("passwordLabel");    logger.info("Password label loaded: " + passwordLabel); // false positive!   return passwordLabel; } 

A rule built into the Fortify Secure Coding Rulepacks causes Fortify SCA to guess that the contents of the variable passwordLabel are sensitive because its name contains the string 'password', which causes Fortify SCA to report a false positive privacy violation issue when the variable is written to the log.

The code below demonstrates how Fortify Java Annotations can be used to eliminate this false positive:

private String loadPasswordLabel() {   @FortifyNotPassword String passwordLabel = props.getProperty("passwordLabel");    logger.info("Password label loaded: " + passwordLabel); // no issue reported   return passwordLabel; } 

The @FortifyNotPassword annotation informs Fortify SCA that the variable to which it is applied does not contain a password.

As of Fortify 360 2.0 and the Q1-2009 update to the Fortify Secure Coding Rulepacks, Fortify SCA recognizes the following Fortify Java Annotations:

• Dataflow: Source, Sink, Passthrough, and Validation
• Field and Variable: Password, NotPassword, Private, NotPrivate, NonNegative, NonZero
• Other: Dangerous Class, Method, Field, and Variable and CheckReturnValue

A detailed sample that demonstrates the full capabilities of Fortify Java Annotations is available with supported versions of Fortify 360 and through the Premium Content section of the Customer Portal.

Technorati Tags: annotations java

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.