How does Veracode look for the presence of frameworks in Java code? Because our customers upload the application packages that they deploy or distribute (as EARs, WARs, or JARs), we can observe the presence of framework classes, configuration files, and other artifacts in the application. We record the prevalence of the framework so that we can mine the anonymized data later. We resample the data every few months to get an idea of relative framework prevalence and to see if any trends can be observed.

Below is our most current Top 10 list for Java frameworks. This list is based on a sample of over 5400 customer applications and was sampled on December 7, 2011. Note that we have decomposed one of the larger framework families, Spring, into its component frameworks to get a better idea of the usage of its individual parts. The percentages reflect the number of Java applications (not individual scans) in which the framework was observed, so an application that was scanned multiple times only counts once in the rankings.

1. Spring MVC (23%)
2. Struts 1.x (15%)
3. Apache Axis (15%)
4. Apache Xerces (14%)
5. Hibernate (12%)
6. JDOM (12%)
7. Java Applet (8.1%)
8. Apache Velocity (7.9%)
9. Apache ORO (7.0%)
10. JAX-WS (6.5%)

A couple of interesting findings here. First, the relative prevalence of Spring MVC and Struts is unsurprising, but the fact that Struts 1.x is #2 on the list and Struts 2 is not even in the Top 10 is a little surprising. (It came in 24th in the overall rankings, in fact, showing up in just 1.8% of the Java applications scanned).

Second, it’s interesting to note that there are multiple frameworks for web services in the top ten, and that Axis appears to have an edge on popularity over JAX-WS.

Third, the relatively high number of applications scanned that contained Java applets was interesting. It’s hard to imagine that 8% of all Java applications have a customer facing applet. One is tempted to speculate that in many cases these applets are administrative interfaces to framework or server code that are left in the application distribution inadvertently or unknowingly, and thus that these represent potentially forgotten attack surfaces for the application.

We’re just starting to mine the data that we’re seeing regarding frameworks. I think that this data should be interesting to development teams looking to choose frameworks that are more widely used. From a security perspective, too, this is a useful reminder that applications rely on third party frameworks, and that some of these may come with their own attack surface (e.g. applets) that shouldn’t be forgotten when planning secure deployments.

He examines the impact of this trend on the adoption of cloud platforms, and what this means for the security of applications being migrated to the cloud. The post sheds light on some of the vulnerabilities in applications that are becoming more prevalent, and also reveals interesting stats on high profile data breaches in 2011. Evan highlights the importance of application security testing in the cloud, and the need to implement testing solutions that are delivered quickly, accurately and at a price point that makes this a valued service.

Read the full post here.

Veracode Security Guides

Data Security Resources

What’s interesting to me about this breach is that Zappos is renowned for their customer service, so watching how they communicate in the coming days and weeks should be an interesting case study. A few notable points so far:

• Tony Hsieh, the CEO, posted a copy of the internal email that they had sent to all their employees. And tweeted about it. The only difference from the customer-facing email was that it stated the number of records affected. But it’s unusual for a company to share internal communication like this.
• Zappos expired everybody’s password, forcing customers to follow the password reset workflow before regaining access to their account. Usually a company will urge you to change your password but won’t force you to do so. This was a good move on their part. The servers seemed very overloaded though; around 9pm last night it took me a few minutes (and a couple of server timeouts) to successfully reset my password.
• Around the same time, Zappos disabled international access to their website, meaning that anybody outside the US couldn’t reset their password as instructed in the email. This seemed a bit odd. As I am writing this post, the site is still unavailable to international customers. This has understandably frustrated some customers.
• In the customer-facing email, Zappos notes that credit card numbers were not affected, but “cryptographically scrambled” passwords were. This is where I believe they ought to be more forthcoming. What does “cryptographically scrambled” entail? An unsalted MD5 hash, Stratfor style? Salted hashes? Symmetric encryption? A homegrown algorithm? Something stronger like bcrypt or scrypt? This detail is critical, because it indicates how easy it will be for attackers to recover the original passwords from the affected customers and try to use them on other sites like Gmail, Facebook, Twitter, and others. Customers might be more likely to change their password on other websites if they understood the relative risk.
• The email does not disclose how long customer data was exposed prior to the breach notification. This is an important detail that was omitted.
• Zappos has been actively engaging with customers on their @Zappos_Service Twitter account. In fact, last night when I posed a question to the CEO’s Twitter alias, @Zappos_Service responded 4 minutes later. They didn’t have an answer, but they responded.
• They turned off their phone system because they felt responding via email would be more efficient (and their phone system couldn’t handle the volume anyway). Still, can you imagine a “typical” company doing this? It seems simultaneously crazy and brilliant.
• It takes a long time to send 24+ million emails. I received mine last night at 8:34pm and 9:03pm, but a colleague here at Veracode mentioned he didn’t get his until this morning. So assuming they’re going out alphabetically by e-mail address, that’s how long it took to get from “c” to “r”.
• Since both Zappos.com and 6pm.com were affected, it’s possible that they shared a single database. There are a bunch of scenarios though. It could be a vulnerability in application code shared by both sites. It could have also been an insider attack, but the fact that credit card numbers were not compromised suggests to me that the attack was external.

For me, the two things to watch for now are how quickly they restore international access and whether or not they disclose how passwords were stored and what “cryptographically scrambled” means in that context. Security breaches happen to the best of companies and these days what differentiates you is how you respond. So far I believe Zappos is on the right track.

(Incidentally, Tony Hsieh’s book, Delivering Happiness, is a fantastic read. I have a lot of respect for how this company operates, and not just because my shoes arrive overnight.)

Veracode Security Guides

Data Security Resources

Just before the holidays, we detected a cross-site scripting (XSS) vulnerability while running a web application scan for one of our customers. Nothing special about that; we detect thousands of these things every week. But as we discussed this particular finding, we noticed that the layout of the website looked… familiar. As it turned out, the discussion forum where we found the XSS was a SaaS-based product called Lithium.

From Lithium’s website: “The world’s most innovative companies such as AT&T, Barnes & Noble, Best Buy, Sephora, Univision, Home Depot, and HP use Lithium to engage their customers in breathtaking new ways (literally, breathtaking).” Run this Google search and you’ll find a bunch of Fortune 500 companies using their software.

So now, instead of one XSS, we have hundreds. It’s not just our customer who is impacted. Suddenly it’s kind of a big deal.

Here’s how everything played out. We’ll do this timeline CORE Security style (all times EST).

• 2011-12-15 5:29 PM. We fire off a quick email to the address listed on Lithium’s Security page.
• 2011-12-15 6:12 PM. We receive a response from Misha Logvinov, Lithium’s CIO.
• 2011-12-15 6:23 PM. We encrypt and send over the vulnerability details to Lithium.
• 2011-12-15 11:40 PM. Lithium reports they have a patch ready to go and will update in the morning.
• 2011-12-16 2:30 PM. We do a little poking around and it seems the vulnerability is patched for some domains but not others. We email for a status check.
• 2011-12-16 2:37 PM. Lithium confirms that the patch is in the process of being rolled out and will be completed by close of business.
• 2011-12-16 COB-ish. We’re not seeing any more vulnerable instances.

Anybody who has reported vulnerabilities before can appreciate how unusual it is for a vendor to respond this quickly. Everything was accomplished in under 24 hours! That is practically unheard of.

From a “big picture” perspective, this whole situation illustrates some important application security themes:

• It’s a canonical example of software supply chain risk. A single XSS vulnerability simultaneously affected hundreds, maybe thousands of customers. No matter how securely these companies developed software internally, they were still exposed to vulnerabilities in third-party software.
• It emphasizes the ecosystem effect of vendor security assessments. One Lithium customer did an analysis of third-party code they were operating. A defect was found, and the vendor fixed it. Now all Lithium customers benefit, without having to lift a finger! Imagine if all companies assessed their third-party code and insisted on fixes from their suppliers.
• It shows that SaaS can have huge security benefits. Imagine if Lithium had been deployed as an on-premise product at each customer sites, requiring each customer to download and install a fix themselves. Some companies would probably never get around to patching their servers. The flip side is if the SaaS company dragged their feet — or simply refused — to patch the software, leaving the customer without a viable mitigation.
• It demonstrates that application security response can be done right. Lithium engaged quickly, took the vulnerability report seriously, and wasted no time in fixing the problem. It’s not uncommon for some vendors to take months.

Increasingly, we’re seeing our customers rethink how they vet the software they purchase or license from third-party suppliers. I hope success stories like these become commonplace as we start holding software suppliers — both SaaS and on-premise — accountable for security, not just functionality.

Veracode Security Guides

Data Security Resources

• Application security performance declines steeply when the current threat landscape is taken into account in the evaluation criteria
• XSS and SQL injection affect a higher proportion of government applications relative to other industry verticals
• Greater knowledge of application security — as derived from eLearning test scores — is associated with improved security quality scores
• Android applications with hard-coded crypto keys are more common than you might expect

Download the full report, then come back here to discuss!

Dark Reading said, “No one was immune: not social networks, not financial institutions, and not even security firms.” I thought I would take a look at how many of these breaches were due to an application vulnerability. These are the breaches that most likely would have been prevented if the organizations had an application security program that built and tested applications with security in mind.

Information about some of the breaches was not available. Specifically I couldn’t find any details about how Epsilon, WordPress, Cyworld or Steam were penetrated. Most of the news reports on those incidents said something to the effect of, “XYZ is investigating the root cause of the breach.” As is often the case there is no followup news report after the root cause is determined. Thankfully there is information on how 6 of the breaches occurred. The following table details the cause of the breach and any application specifics if applicable.

Looking at the breaches that we know details about we can see that four out of the six, or 66% of the breaches, were due to an application vulnerability. This is an even higher percentage than I expected. It is clear that software security defects are being leveraged by attackers to breach major amounts of data at large and sophisticated organizations.

Diving down a level to the details about the specific category of the vulnerability we see that it turns out to be different in every case. Comodo was breached by a very common and easy to find flaw: SQL Injection (SQL Injection Attack Exposes Comodo Partner Customer Data). RSA was done in by a memory corruption bug in Adobe Flash plus a very convincing spearphishing email (Attack on RSA used zero-day Flash exploit in Excel). It isn’t entirely clear what was the exact cause of the Sony Playstation Network breach. Sony said it was a vulnerability in software running on an application server (Sony apologizes, details PlayStation Network attack). Citibank’s data breach was caused by missing authorization that allowed attackers to iterate through the data using many accounts numbers (Revealed: How Citigroup hackers broke in ‘through the front door’ using bank’s website).

If anyone knows of the details for the Epsilon, WordPress, Cyworld or Steam breaches please send them to me so I can update this post. The more we understand about the root cause of breaches the more accurately we can use a risk based approach for security. By understanding the attacks that are succeeding we can commit resources to preventing, mitigating and detecting those attacks. The knowledge that 66% of major breaches are due to application vulnerabilities should be a wake up call for organizations that are not performing application security prevention and mitigation as part of their SDLC and software acquisition processes.

So today I am going to crank up the wayback machine and look to some of the original concepts of the binary analysis vision which we are still working on today. I wrote the following for USENIX’s :login; Magazine in 2004.

Putting Trust in Software Code

The premise of the talk was that developers and security teams should communicate and work better together — hard to find fault with that. But after flipping through the slides and watching the accompanying developer rant video I really took issue with the way this message was delivered. To paraphrase, Dinis puts the burden on the security practitioners to change their ways to work within the existing development culture, no matter how dysfunctional that culture may be.

There is no doubt that security practitioners need to better understand where the developer is coming from, but it needs to go both ways. Developers need to understand that the security guys have expertise that they don’t have. Imagine if the engineers of a jet engine didn’t listen to the test team responsible for modeling real-world hazards such as birds flying into the engine. The engineers can say that time to market, fuel economy, noise level, and cost are all they care about. But it won’t be true. They have to care about the safety of real-world incidents. Who cares if a jet engine can carry a plane across the country silently with one gallon of gas if a small bird can take the plane down? The same goes for security of software. You can have the coolest app in the world but if a script kiddie can take you down with a few single quotes, you’ve failed.

Here are a couple slides from Dinis’ presentation that further illustrate the mentality that security professionals are up against:

The difference between “lecturing” and “advising” is a matter of perspective. For instance, you can describe the same XSS vulnerability to two different developers, in exactly the same words, and get two different reactions: one asks questions wanting to understand the situation better, the other folds his arms and fires back with responses like this. What’s the difference? One is acting defensively while the other is not.

I don’t need to understand the full context of your application to know you have a real vulnerability. SQL injection is SQL injection. The guys testing the jet engine don’t necessarily know how to build the engine. Dinis argues that security is useless without understanding application context. I concede that security may become more valuable with context but can still provide plenty of value on its own.

Really, how stubborn is it to think that there is absolutely nothing useful you could learn by taking some security training? I don’t think I even need to elaborate on this one.

So what now? Truthfully, both sides need to make some concessions for there to be any real progress. I don’t think the answer is becoming the developer’s best friend. Progress starts with both sides acting professionally, not making too many assumptions, and acknowledging that they may be able to learn something from the interaction. Remember that both sides are interested in making the product better.

I’ll leave you with a recent tweet from Dan Cornell, another OWASP luminary:

My variation on this might be “I’m not telling you your baby is ugly. I’m telling you his diaper is about to leak all over your upholstery and you might want to do something about it.”

Veracode Security Guides

Data Security Resources

So as I look back over the last 10 years I don’t see much of a change in the vulnerability-scape, if you will, but in the threat landscape. New classes of attackers have gone mainstream and global. They are sophisticated and effective. But our defenses have barely gotten better. There has been an incremental approach to defenses: deeper packet inspections, more heuristic anti-malware, more auto-update patching, but it hasn’t been able to keep up. I hope over the next 10 years there are some radical changes in how we perform security or the problem will get dramatically worse. The criminals, spies, and hacktivists are here to stay unless we stop them.

It sounds a bit pessimistic but I mean it to be a wakeup call. The still current trend of reactive security, where we detect more things ever faster and share signatures ever wider, will not solve our problems. Attackers will counter by being more targeted and changing attack signatures quicker. They are operating inside the reactive defenders OODA loop and are not going to give up this advantage unless we change the model on them.

I am not advocating eliminating reactive security. Detection and sharing is important. We need smoke detectors and fire departments. But just like those fire safety capabilities alone don’t give us safe living and working environments, IDS in its various forms will not give us safe computer networks. We need to add building codes on top of reaction. We need to use the computer analogs of “fire proof materials” and have less risky behaviors with flammable materials. This means building the software that makes up our infrastructure more securely and having public standards to test that it really is more secure. It is a harder problem than inspecting buildings but we have to solve this problem or the attackers will always be able to burn us down.

Veracode Security Solutions

Security Alternatives

Security Threat Guides