Photo Courtesy of techtwisted.com

The ability to choose what is disclosed to others is the essence of privacy today. Some would argue that this disclosure policy is not really privacy but equates more closely to confidentiality. Confidentiality deals with relationships and not individual privacy. Confidentiality “involves trusting others to refrain from revealing personal information to unauthorized individuals.”

It’s in this choice of disclosure that the essence of privacy resides. The fact that we willingly give information from ourselves to another entity does not inherently mean that we give permission for that entity to share it with others. Nor does it give the entity the permission to sell, use, or otherwise attempt to profit from that information. Yet that exact premise is what numerous businesses are built upon today. Privacy transference is a major problem.

We click through and digitally sign user agreements that give web properties the rights to share any and all data we upload to third parties. This includes online social networks, games, software as a service solutions, and especially mobile device applications and providers. Advertising is becoming more and more targeted thanks to the customer specific profiles being created. (See Veracode post – Mobile Apps Invading Your Privacy)

Three specific Internet phenomenon have exacerbated the privacy problem to that of high risk making it something that will have to be solved sooner rather than later. The quantity of data we are putting online is enormous and growing exponentially. The type of data that is being placed online is becoming increasingly more private, and in the event we are diligent and only put up public data, many times private information can be inferred. Finally, thanks to big data and the continually lowering cost of storage, we can be assured that all of the data that we place online will be there long after we are gone. The collection of content and the mapping of that data to create a detailed consumer profile is rapidly becoming a major issue for individuals world wide. The collection of detailed data crosses personal boundaries for those that feel it will be abused.

As always I’m sure people want to know how to fix the problem. I don’t have an answer. I wish I did because this is a real problem that requires intelligent solutions. My gut tells me that the problem will be solved eventually via government regulation and intervention. For the sake of businesses and consumers today I hope that we can police ourselves and do the right thing so that government intervention isn’t required. Businesses need to stop private data transference. Consumers must stop putting sensitive data online (I know, this one is a pipe-dream). And everyone must opt OUT of tracking by default and allow users who want the convenience of direct marketing to choose that service, not the other way around.

If you haven’t already seen it, be sure to check out the video game (Veracode Defender) we made to promote some of the recent changes we made to our reports. Click here to play

With tax season upon us, “Tax Season = Tax Scams, Prepare yourself,” by Stefanie Hoffman at the Fortinet Security blog uncovers some of the tactics and social engineering methods scammers are using to capture personal information, such as false emails to collect information and install malware, impersonating the IRS website, and even fielding fake phone calls.

In hacker news, the Sophos Naked Security Blog recently published an article by Graham Cluley in which the Police say they have arrested four suspected Anonymous hactivists in Madrid and Malaga. The four suspects are said to be involved in attacks on Spanish political parties, companies, and the Spanish Police force. Not only were these sites taken down by DDoS attacks, but some also experienced vandalism and stolen information.

Maria Korolov authored an article for Internet Evolution titled “The Cost of Data Breaches is Getting Higher.” In it, she explains how the cost of breaches are becoming higher for companies due to customer lawsuits and upcoming government penalties, such as a Texas law that will require companies that conduct business within its borders to notify all effected customers if a breach takes place – or face fines of up to $250,000.

At this week’s RSA Conference in San Francisco, CloudFlare CEO Matthew Prince shared the story of the battle between the government and hackivist group LulzSec fought on CloudFlare territory, and Stacy Cowley of CNN Money Tech has all the details. In June, the LulzSec site was the target of a DDoS attack launched by another group of hackers. To protect themselves, LulzSec signed up for CloudFlare, a website optimization and protection service. CloudFlare was able to gain a unique perspective on the attacks that the hackers themselves undergo.

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