Struts OGNL Security Issue - Are You Vulnerable?

Background

A High rated vulnerability was discovered in the Struts framework a month or so ago. All versions of Struts from 2 to 2.3.1.1 are vulnerable According to the Struts team the vulnerability :

• "allows a malicious user to bypass all the protections (regex pattern, deny method invocation) built into the ParametersInterceptor, thus being able to inject a malicious expression in any exposed string variable for further evaluation."

Compass Security have put together a useful tutorial describing the issue.

A few questions:

• Is your company vulnerable?
• Would you even know  if you are vulnerable?
• Do you even know if your company is using Struts?

Simple Fix
The fix is pure and simple - Upgrade to Struts 2.3.1.2
But then to quote Oscar Wilde:

"The truth is rarely pure and never simple. "

Discussion
The problem is that there are huge numbers of applications running vulnerable versions of Struts which are unlikely to have been patched with the new version. This could be because companies neither know about the vulnerability nor know that their online applications are using Struts. In many cases the applications have been in production for a few years and the development teams have long since moved on.

While the applications may have been secure at launch, the discovery of the Struts vulnerability now means that these applications are vulnerable. This could well mean that a company is no longer PCI DSS compliant.

While the Simple Fix above is simple, the reality is that it won't be applied because organizations do not know that they are vulnerable.

This is especially a problem with open-source type libraries and frameworks. There is no standard mechanism for publishing information on vulnerabilities. They fall between the cracks. Operations staff are usually aware of OS type vulnerabilities, but not of these types of application frameworks or libraries.

A joint study conducted by Sonatype and Aspect Security found that more than 50 percent of the world’s largest corporations have open source applications with security vulnerabilities.

Real Fix
The real fix lies in having a proper Secure Development Life Cycle in place - in particular a post-production process for identifying newly discovered security vulnerabilities and ensuring that appropriate security fixes are applied.

So here are suggested steps:

1. When a new application is being rolled out to production, make sure that it is registered with the corporate Asset Register. This should include information about any frameworks, libraries etc. that the application relies on.
2. The operational risk team should monitor for any vulnerabilities in the libraries and frameworks.
3. If vulnerabilities are discovered, the operational risk team can look in the corporate Asset Register to identify any impacted applications
4. Appropriate fixes can then be applied

Useful Links:

• Details on Apache Struts Website 
• Compass Security Movie - Tutorial 
• Struts 2.3.1.2.
• Sonatype and Aspect Security Study on use of vulnerable Open Source Components
• Oscar Wilde Quote 

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

The Economist on Passwords

This week's edition of  "The Economist" has both a leader and  article devoted to computer passwords.

According to the leader: "An analysis by Verizon, an American telecoms firm, found that the biggest reason for successful security breaches was easily guessable passwords"

The following extract from the article is especially relevant for developers:

"One obvious answer would be for sites to limit the number of guesses that can be made before access is blocked, as cash machines do. Yet whereas the biggest sites, such as Google and Microsoft, do take such measures (and more), many do not. A sample of 150 big websites examined in 2010 by Mr Bonneau and his colleague Sören Preibusch found that 126 made no attempt to limit guessing.

How this state of affairs arose is obscure. For some sites, laxity may be rational, since their passwords are not protecting anything particularly valuable, such as credit-card details. But password laxity imposes costs even on sites with good security, since people often use the same password for several different places.

One suggestion is that lax password security is a cultural remnant of the internet’s innocent youth—an academic research network has few reasons to worry about hackers. Another possibility is that because many sites begin as cash-strapped start-ups, for which implementing extra password security would take up valuable programming time, they skimp on it at the beginning and then never bother to change. But whatever the reason, it behoves those unwilling to wait for websites to get their acts together to consider the alternatives to traditional passwords."

When developing your websites, how you manage passwords is vital.

A few ideas:

• Disable account (at least temporarily) after a number of failed logon attempts
• Don't allow the most common x hundred passwords. You can get lists from the internet.
• When people create new passwords remind them not to use the same password as they have used elsewhere.
• Use the chip shop approach - hash and salt the passwords to store them. In other words, don't store passwords in cleartext.

Links:

• Economist Leader: A security patch for your brain 
• Economist Article: Speak, friend, and enter 

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

Kia Cee'd

Judge: Your client is accused of trying to hack into the website of Mr Smith's garage - using a technique which I understand is called "SQL Injection".

Defense Lawyer: Your Honour, my client was only doing a search for a Kia Cee'd, which he is interested in purchasing

***********************
Do a Google Search for Kia Cee'd SQL and you will conclude that Kia should really have been a bit more careful when choosing this name!

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot