My Security Planet » Justice League

Justice League

2011 CTO Year in Review

Posted: December 7th, 2011, 12:47pm CST by gem

Tags: Software Security [edit]
Part of my job as software security pundit and “hood ornament” of Cigital is spreading the word about software security far and wide. 2011 was a year like many others in that respect. Here is a “tripometer” graph showing talks I give and trips I take each year going back a decade.

The good news from my perspective is that talks are up (clocking in at 40) even while trips are down (coming in at 27). Those are the kinds of trends I can live with.

I gave nine keynote talks this year to large audiences. They included:
- Software Security and the BSIMM, Fannie Mae CSO Security Summit (Washington, DC)
- Architecture Risk Analysis, RSA Innovation Sandbox (San Francisco, CA)
- How Do I Secure my Software?, Hotel Technology Next Generation (San Diego, CA)
- Software Security: State of the Practice, SAP Quality Day (Heidelberg, Germany)
- Software Security and the BSIMM, Software Experts Summit (Mountain View, CA)
- Software Security and the BSIMM, AERES (Vienna, Austria)
- Attack Trends 2012, SNI Security Summit (Knoxville, TN)
- Attack Trends 2012, Automated Control Systems Security (Washington, DC)
- The Building Security In Maturity Model, NESSOS, Internet Days EU (Poznan, Poland)
I also gave talks at thirteen universities, including Uva, Harvard, Umass, NCSU, Georgetown, the Naval Postgraduate School, JHU, UMd, Northern Kentucky University, Columbia, Indiana University, JMU, and UC Santa Barbara. It is always a blast to interact with students. They seem to get younger every year.

If you have a speaking opportunity for us, we would love to hear from you! Cigital has a bunch of very talented speakers.

My monthly column for informIT continues apace into its fifth year. Here is a listing of the last 12 articles in the series (still working on December’s). I think my favorite one is the Zombies paper…that one should live on for a while.
- Third-Party Software and Security (November 30, 2011)
- Software Security Training (October 31, 2011)
- BSIMM3 (September 27, 2011)
- Balancing All the Breaking with some Building (August 30, 2011)
- Software Security Zombies (July 21, 2011)
- Computer Security and International Norms (May 30, 2011)
- vBSIMM (BSIMM for Vendors) (April 12, 2011)
- Modern Malware (March 22, 2011)
- Software Patents and Fault Injection (February 28, 2011)
- Comparing Apples, Oranges, and Aardvarks (or, All Static Analysis Tools Are Not Created Equal) (January 31, 2011)
- Driving Efficiency and Effectiveness in Software Security (December 29, 2010)
My 2011 writing also included interaction with the Washington D.C. policy wonks at the Center for a New American Security. CNAS ran a study on cyber security for policymakers. CNAS CEO and Iraq War author Nate Fick co-authored a paper with me meant to inform lawmakers about what cyber security really should be: Separating the Threat from the Hype: What Washington Needs to Know About Cyber Security in AMERICA’S CYBER FUTURE: SECURITY AND PROSPERITY IN THE INFORMATION AGE VOLUMES I AND II, Center for a New Amercian Security [PDF] (June 2011).

With the purchase of Fortify Software by HP at the end of 2010, a long and very successful technology transfer path was completed. From our invention of security scanning in the labs at Cigital, through Kleiner-Perkins, to worldwide distribution through HP, code review for security is here to stay. I wrote the story up in IEEE Software: Technology Transfer: A Software Security Marketplace Case Study [PDF] (September/October 2011).

And there is always the Silver Bullet security podcast. The last 12 interviews included some really solid episodes. I think my favorite this year was an in depth interview with Ralph Langner about Stuxnet. Ralph is the guy who discovered that the payload was aimed at Siemens Control systems.
2012 should look much the same when it comes to trips and talks, though one of these years I need to find the time to write another book!
2011 CTO Year in Review

Posted: December 7th, 2011, 7:47am CST by Cigital

Tags: Software Security [edit]
Part of my job as software security pundit and “hood ornament” of Cigital is spreading the word about software security far and wide. 2011 was a year like many others in that respect. Here is a “tripometer” graph showing talks I give and trips I take each year going back a decade.

The good news from my perspective is that talks are up (clocking in at 40) even while trips are down (coming in at 27). Those are the kinds of trends I can live with.

I gave nine keynote talks this year to large audiences. They included:
- Software Security and the BSIMM, Fannie Mae CSO Security Summit (Washington, DC)
- Architecture Risk Analysis, RSA Innovation Sandbox (San Francisco, CA)
- How Do I Secure my Software?, Hotel Technology Next Generation (San Diego, CA)
- Software Security: State of the Practice, SAP Quality Day (Heidelberg, Germany)
- Software Security and the BSIMM, Software Experts Summit (Mountain View, CA)
- Software Security and the BSIMM, AERES (Vienna, Austria)
- Attack Trends 2012, SNI Security Summit (Knoxville, TN)
- Attack Trends 2012, Automated Control Systems Security (Washington, DC)
- The Building Security In Maturity Model, NESSOS, Internet Days EU (Poznan, Poland)
I also gave talks at thirteen universities, including Uva, Harvard, Umass, NCSU, Georgetown, the Naval Postgraduate School, JHU, UMd, Northern Kentucky University, Columbia, Indiana University, JMU, and UC Santa Barbara. It is always a blast to interact with students. They seem to get younger every year.

If you have a speaking opportunity for us, we would love to hear from you! Cigital has a bunch of very talented speakers.

My monthly column for informIT continues apace into its fifth year. Here is a listing of the last 12 articles in the series (still working on December’s). I think my favorite one is the Zombies paper…that one should live on for a while.
- Third-Party Software and Security (November 30, 2011)
- Software Security Training (October 31, 2011)
- BSIMM3 (September 27, 2011)
- Balancing All the Breaking with some Building (August 30, 2011)
- Software Security Zombies (July 21, 2011)
- Computer Security and International Norms (May 30, 2011)
- vBSIMM (BSIMM for Vendors) (April 12, 2011)
- Modern Malware (March 22, 2011)
- Software Patents and Fault Injection (February 28, 2011)
- Comparing Apples, Oranges, and Aardvarks (or, All Static Analysis Tools Are Not Created Equal) (January 31, 2011)
- Driving Efficiency and Effectiveness in Software Security (December 29, 2010)
My 2011 writing also included interaction with the Washington D.C. policy wonks at the Center for a New American Security. CNAS ran a study on cyber security for policymakers. CNAS CEO and Iraq War author Nate Fick co-authored a paper with me meant to inform lawmakers about what cyber security really should be: Separating the Threat from the Hype: What Washington Needs to Know About Cyber Security in AMERICA’S CYBER FUTURE: SECURITY AND PROSPERITY IN THE INFORMATION AGE VOLUMES I AND II, Center for a New Amercian Security [PDF] (June 2011).

With the purchase of Fortify Software by HP at the end of 2010, a long and very successful technology transfer path was completed. From our invention of security scanning in the labs at Cigital, through Kleiner-Perkins, to worldwide distribution through HP, code review for security is here to stay. I wrote the story up in IEEE Software: Technology Transfer: A Software Security Marketplace Case Study [PDF] (September/October 2011).

And there is always the Silver Bullet security podcast. The last 12 interviews included some really solid episodes. I think my favorite this year was an in depth interview with Ralph Langner about Stuxnet. Ralph is the guy who discovered that the payload was aimed at Siemens Control systems.
2012 should look much the same when it comes to trips and talks, though one of these years I need to find the time to write another book!
UK Spooks’ Recruiting Tactic: Very Low Pound to Genius Ratio

Posted: December 2nd, 2011, 3:29pm CST by Guest

Tags: Cyber Security [edit]

(This is a guest post by Adam Zabrocki, a consultant at Cigital.)

The UK intelligence agency, GCHQ, (roughly analogous to the US’s NSA) posted an online challenge recently at [canyoucrackit.co.uk] (read more). Given essentially no information other than what are pretty obviously hex digits, candidates are invited to attempt to “crack” an opaque puzzle. It isn’t even clear what the puzzle is (is it an encrypted document? is it a program? Is it a virus?).

Ostensibly the puzzle will help GCHQ identify very clever candidates to come work at the agency, fighting the good fight in cyberwarfare. Other high-profile companies have tried similar strategies in the past (like Google and Microsoft) to find highly qualified candidates.

The puzzle requires unraveling x86 instructions, finding a few bits of essential data hidden steganographically in the image itself, and putting it all together into a program that reveals a final URL to visit. The skills required to do this are similar to those required for reverse engineering unknown malware and trying to figure out what it does–especially when only part of it is present. It’s part systematic sleuthing, part guesswork, and part forensics.

As the UK, the US, and many other wealthy nations attempt to build their defences against cybercrime (and cyberwar), they are trying to identify good guys who have what it takes to understand what the bad guys do. It’s great fun to solve a problem like this, and it’s great fun to imagine doing that for a living to serve your country. But when you discover that the government’s salary is a fraction of the salary of being a private-sector good guy (not to mention what the bad guys might make), it’s no wonder they are struggling to find recruits.

The details of how I solved it are on my personal blog.
UK Spooks’ Recruiting Tactic: Very Low Pound to Genius Ratio

Posted: December 2nd, 2011, 10:29am CST by Cigital

Tags: Cyber Security [edit]

(This is a guest post by Adam Zabrocki, a consultant at Cigital.)

The UK intelligence agency, GCHQ, (roughly analogous to the US’s NSA) posted an online challenge recently at [canyoucrackit.co.uk] (read more). Given essentially no information other than what are pretty obviously hex digits, candidates are invited to attempt to “crack” an opaque puzzle. It isn’t even clear what the puzzle is (is it an encrypted document? is it a program? Is it a virus?).

Ostensibly the puzzle will help GCHQ identify very clever candidates to come work at the agency, fighting the good fight in cyberwarfare. Other high-profile companies have tried similar strategies in the past (like Google and Microsoft) to find highly qualified candidates.

The puzzle requires unraveling x86 instructions, finding a few bits of essential data hidden steganographically in the image itself, and putting it all together into a program that reveals a final URL to visit. The skills required to do this are similar to those required for reverse engineering unknown malware and trying to figure out what it does–especially when only part of it is present. It’s part systematic sleuthing, part guesswork, and part forensics.

As the UK, the US, and many other wealthy nations attempt to build their defences against cybercrime (and cyberwar), they are trying to identify good guys who have what it takes to understand what the bad guys do. It’s great fun to solve a problem like this, and it’s great fun to imagine doing that for a living to serve your country. But when you discover that the government’s salary is a fraction of the salary of being a private-sector good guy (not to mention what the bad guys might make), it’s no wonder they are struggling to find recruits.

The details of how I solved it are on my personal blog.
Third-Party Software, Vendor Control, and the BSIMM Community

Posted: November 30th, 2011, 3:36pm CST by gem

Tags: BSIMM [edit]
Cigital recently hosted a second BSIMM Community Conference near Portland, Oregon. The Conference was outstanding, and was a great opportunity for like-minded software security professionals to compare notes. Firms participating in the BSIMM include:
- Adobe
- Aon
- Bank of America
- Capital One
- The Depository Trust &
  Clearing Corporation (DTCC)
- EMC
- Fannie Mae
- Fidelity
- Google
- Intel
- Intuit
- Mashery
- McKesson
- Microsoft
- Nokia
- QUALCOMM
- Sallie Mae
- SAP
- Scripps Networks Interactive
- Sony Ericsson
- Standard Life
- SWIFT
- Symantec
- Telecom Italia
- Thomson Reuters
- Visa
- VMware
- Wells Fargo
- Zynga
The BSIMM project describes and measures the work of 786 SSG members, who together with a satellite of 1750 people, have direct impact on the work of 185,316 developers. (Download a copy today and get your firm involved in the BSIMM Project.)

The BSIMM is mostly about SSDL activities and governance. However, third-party software plays a major role in all of the BSIMM firms and is an important risk factor that must be managed. In addition to talks from member firms, the BSIMM Community Conference also featured a workshop on third-party software and security.

Sammy, Brian, and I wrote up the results in an informIT article that was posted today.

The interesting aspect of our workshop was that it was made up approximately of 50% software vendors and 50% financial services firms. This made for a very interesting conversation around vendor control.
Open Source and Software Maturity Models

Posted: November 15th, 2011, 6:45pm CST by jOHN

Tags: Admin [edit]
I’m at the BSIMM3 Conference, in an open source breakout session. The context: you’re an organization with a reasonable application security program. The question, “How to apply that same process maturity to open source where no ‘throat to choke’ exists?” Your organization and its software-providing vendors may not be perfect but at least you can choke someone if vulnerability exists. If you believe in the value of SSF activities for built and purchased software, you understand that assurance activities (source code review or penetration testing) may apply to open source, but applying others (such as training, or SDL gating/exceptions, and so forth) might be as impossible shooting ghosts. So, we have a control problem:

We can’t tackle the “process improvement” problem with our open source provides like we can with those who build our software in-house, or those vendors from whom we acquire code.

Understanding, based on this, we lack as many ‘knobs and dials’ for improving the cleanliness of the pipes through which open source software flows… we may have a flow rate problem as well. Though I lack hard evidence, I’d bet this represents a proverbial iceberg’s tip:

An organization may deploy as much or more open source code as their own in-house developed code.

It’s interesting to think about the money organizations spend to secure the code they build vs. the amount of open source they consume in this light… (participants indicated they didn’t track this spend separate from their development efforts).

Harumph. Our breakout group generated great ideas worth sharing. First, we unearthed a lot of things attending organizations already do. Next, we brainstormed valuable next steps. Here’s categories of activities we came up with:
- Inventory & Inventory Control
- Vulnerability Identification (Assessment)
- Vulnerability Management
- Ownership of Open Source
- Policy (use)
- Policy (Contribution)
What did each entail?

Inventory & Inventory Control
- Identification – All Participating organizations had a manual discovery process for open source usage. Many wanted better automated schemes, despite some existing tool usage.
- Identification of masked open source – Many participating organizations realize that not only do they adopt open source software directly but that the 3rd party code (and open source) they absorb also contain open source software. Discovering this ‘masked open source’ software represents as big a problem as identifying the open source software used directly.
- Centralized open source distribution – Some organizations allow development & deployment of open source software from the web directly whereas others only allow access to and use of open source from a centrally managed repository. Centralizing deployment usage may provide only improved integrity, or may be used to implement an ‘approved package list’.
Vulnerability Identification (Assessment)
- Using assessment tools – About three-quarters of workshop respondents used the same tools they use to assess their application security posture on their open source assets. This, to me, seems worth its own blog entry. I had to wonder aloud, “as organizations move from detective assessment schemes (SCR, PT) to so-called preventative (threat modeling, architecture analysis, misuse/abuse cases) how do they consider open source?” I’m finding that organizations blazing trails into security architecture work commonly omit discussion of their open source frameworks.
Ownership
- Maintain a white list of open source – Seemingly related to the “centralized distribution” item (but surprisingly uncorrelated in our survey), this meant that someone, from security, owned assessing the risk and proffering a “thumbs-up” or “thumbs-down” that can inhibit white list membership.
- Revisit white list – Organizations expressed that they found value in pruning the approved list of open source software based on non-use, newly identified risk, and similar factors. About one-quarter of our group engaged in this activity.
- Ownership of identified risk – Some participants avidly encouraged use of open source within their applications. In these organizations, when a developer chooses to include open source (as opposed to writing a widget themselves), they own any newly identified risk when in that open source. This reminded me eerily of Wall St. traders. Equity investment creates risk. Margin calls create leveraged risk. In this metaphor, choosing to adopt open source seems like a margin call. It’s very possible that a developer can absorb more risk into the organization than they themselves could effectively own up to in black-swan scenarios. It’s unclear how to measure this exposure when adopting open source.
- Collaboration – Certainly an organization-specific and an unsolved problem, participants indicated there may be a “third stakeholder” in the process of identifying and managing open source vulnerability. Two examples given were 1) clearing houses from which organizations purchase open source software and 2) support organizations (a la RedHat).
Vulnerability Management
- Root Cause Analysis – When a vulnerability is found (regardless of means or source: internal/external), organizations sometimes can point to a person or group who understands the vulnerable component (notable exceptions exist for purchased software or that software maintained by a development team that’s vanished). In open source, the organization must expend resources in order to “get smart” on vulnerability’s root cause and make trade-offs about mitigation strategies and their impacts. This represents extra cost on which I’d enjoy having greater visibility.
- Vulnerability Impact Analysis – Almost every participant had some regime by which they discovered (through assessment, feeds, or other means) new vulnerabilities within their adopted open source code base. Everybody possessed some ability to figure out which lines-of-business or development teams might be affected by newly discovered vulnerabilities.
- Patch Management – Only about one half of participants had, in their minds, a good strategy–having assessed the impacted teams–for distributing a patch that remediated open source vulnerability in an organization-wide manner. More strategically, several schemes seemed available to organizations beyond the straightforward “penetrate-and-patch” loop here. Alternatives included:
  2. Wrapping open source
  3. Hardening open source (and centrally distributing)
  4. Sandboxing/compartmentalizing open source
Policy (Use)
- Security Policy/Standards – About half participants had some kind of security policy or standards addressing how to securely use open source software within the organization.
- Training – About one quarter of participants trained their developers to use some portion of their open source securely. Interestingly enough, the one quarter of our respondents that trained developers did not line up well with the one half that had security standards. Wild.
Policy (Contribution)
- Legal permission to contribute to open source – Some organizations see open source contribution as a key activity. Others did but have suffered clamp-down from their legal departments because legal fears liability. Others never liked the idea.
- Community Notification on Vulnerability – When an organization contributes to open source and later finds (or is notified of) vulnerability in its contributions, it may need a way to notify the broader community. Organizations also complained about very high latency in the community notifying them of vulnerability in their code. This proved a surprising problem in our brainstorming session. Why? Contributors complained that this was because, often, their contributions were either 1) forked or 2) baked into other products that masked use of the contributions. In either case, it wasn’t evident to those disclosing the vulnerability that the (contributing) organization was responsibly for vulnerable code.
I will absolutely not let it go without saying that though this entry contains many of my own thoughts it heavily relies on the work of many in our breakout session, well-lead by HP’s Brian Chess. Thanks all for a great discussion.
-jOHN
Training by the Numbers

Posted: November 7th, 2011, 2:18pm CST by sammy

Tags: Software Security [edit]
- 1992: Cigital (then Reliable Software Technologies) gets started and also delivers some training on software quality
- “a few hundred”: ILT days delivered from 1992 through 2006
- 5,000: ILT students trained from 1992 through 2006
- 575: ILT and tutorial days delivered from 2007 through today
- 9,000: ILT students trained from 2007 through today
- 100,000: current students with access to our eLearning
Here are those numbers again in the context of a few things we’ve learned:

Cigital has always included instructor-led training (ILT) as part of its knowledge transfer to clients. From our founding in 1992 through 2006, we trained an estimated 5000 students on various aspects of software quality and software security. This was done in only “a few hundred” sessions. In addition, from the launch of our formal training offerings in January 2007 through September 2011, we delivered approximately 525 ILT days to over 7700 students. Throw in “about 50” conference tutorial sessions and other non-client-specific training sessions (but not normal conference talks or similar things) and the student number grows to about 9000, for a total of about 14,000.

There has been some shift in demand over that time. For the first 10 years or so, everything was custom. We typically spent weeks and even months building training that was very specific to platforms, frameworks, coding standards, policies, and even specific problems-of-the-day. This training was usually for relatively small numbers of people all working on something very similar. For the firm, that becomes a very expensive proposition when you get to hundreds or even thousands of developers working in multiple technologies, stacks, languages, tools, and related items. There simply isn’t enough time or dollars to make custom training for everyone.

Starting in 2006, we saw a real market demand for more standardized software security training (as differentiated from the plethora of network security, tool-specific, and generic “security” training in the marketplace, or the deep-dive, single-topic courses for things like reversing malware or DLL hooking). This demand was and continues to be much more centered on foundational training for all SDLC stakeholders (business analysts, architects, developers, quality testers, pen testers, audit, risk/compliance, and so on) and advanced training for small groups (e.g., lead architects and developers).

From early 2007 through October 2011, Cigital also deployed eLearning to firms that represent over 100,000 students who are developers, architects, testers, managers, business analysts, security operations folks, and others. The majority of clients are using our eLearning in their internal learning management systems for access by employees as well as contractors integrated into the client’s ecosystem. For external contractors without access to internal client systems, clients are using our training portal.

There has been shift in the eLearning landscape as well.
- We see almost all large firms having their own learning management system and wanting to take our material in-house. Meanwhile, smaller firms are looking to out-source everything and simply purchase access to our LMS for a given number of seats.
- There is a growing demand for tightly-focused topical modules that can be consumed in an hour or less.
- There was an initial demand for custom eLearning and then off-the-shelf became all the rage as the economy changed.
- There’s a trend to moving training closer to the activity. For example, inserting some defensive programming training directly into the developer’s IDE. We’ve actually developed plug-in technology for this one.
- As everyone sees the possibilities represented by more advanced instructional design, there is an increasing demand for what can only be described as virtual reality and flying monkeys with every image and word indexed and a holographic interface that instantly takes the student to the exact second in the module that answers with cut-and-paste content whatever question the student is pondering. Oh, and it needs to run on any device from laptops to smart phones to microwaves and in-dash satellite radios. Of course, we’re all over this, too.
As an off-shoot of our continuing BSIMM activities, Gary and I also recently wrote an article on software security training. Here are some additional thoughts.
Cigital helps to create cyber security plans

Posted: October 11th, 2011, 1:59pm CDT by Guest

Tags: Cyber Security [edit]

(This is a guest post by Evgeny Lebanidze, a managing consultant at Cigital.)

Cigital has been working one-on-one with Rural Electric Co-ops across the US to help them raise their cyber security bar, starting with the creation of their own custom cyber security plan. To facilitate this process, Cigital provided the Co-ops with several artifacts, including a Guide to Developing a Cyber Security and Risk Mitigation Plan and an associated Cyber Security Plan Template, developed by Cigital for the National Rural Electric Cooperative Association (NRECA). The following video captures testimonials from Rural Electric Co-ops that have worked with Cigital to create their cyber security plans, along with feedback from industry experts and practitioners on the cyber security risk management approach and toolkit developed by Cigital.
Announcing BSIMM3

Posted: September 27th, 2011, 7:30am CDT by sammy

Tags: BSIMM [edit]

We announced BSIMM in March 2009 and BSIMM2 in May 2010. It’s now time for BSIMM3. Long live the BSIMM.

Since the first BSIMM interview in October 2008, we’ve progressed from nine to 30 to 42 firms (and more, at this point). We’ve also measured 11 firms twice—about 19 months between measurements on average—and that has provided the BSIMM community with some unique insight on how software security initiatives change over time. Assessing 42 individual firms and performing 11 re-assessments required 81 sets of interviews in just a shade less than three years.

For my money, that’s not bad for a backyard project.

Of the 42 firms in the data pool, 27 have graciously allowed us to name them as BSIMM participants. They are: Adobe, Aon, Bank of America, Capital One, The Depository Trust & Clearing Corporation (DTCC), EMC, Fannie Mae, Google, Intel, Intuit, McKesson, Microsoft, Nokia, QUALCOMM, Sallie Mae, SAP, Scripps Networks Interactive, Sony Ericsson, Standard Life, SWIFT, Symantec, Telecom Italia, Thomson Reuters, Visa, VMware, Wells Fargo, and Zynga. To these and the other 15 firms, thank you very much for participating. You are directly responsible for advancing the cause of software security.

The BSIMM3 document is freely available under a Creative Commons license. You can get it from [bsimm.com]. Go ahead; it’s a good read. Even if you’re down the road with your software security initiative, you can get a glimpse into the actual software security activities conducted by your peers and competitors. If you’ve yet to get started, BSIMM will give you some great ideas.

As always, we are looking for more people who are interested in participating in the BSIMM study. We’d love to hear from you.

–Sammy.
BEAST and SSL/TLS

Posted: September 26th, 2011, 10:02am CDT by Guest

Tags: Defects Bugs and Flaws [edit]
This is a guest post by Amit Sethi, Technical Manager at Cigital.

There has been a lot of talk about BEAST (Browser Exploit Against SSL/TLS) lately. The attack against SSL 3.0 / TLS 1.0 was recently publicized by Thai Duong and Juliano Rizzo. Do you know what the risks are, and how to protect yourself?

How does it work?

The attack has two components, and the goal is for the attacker to get your cookie so that he can hijack your session:
- Some client-side code (Java applet, Silverlight application, etc.) that is injected into a page delivered over HTTP that can make requests to a site that uses HTTPS. This may require bypassing (or finding loopholes in) same-origin security policies.
- A sniffer on the network that the victim is on, to record encrypted data generated by the client-side code. The sniffer and the client-side code need to communicate with each other for the attack to work.
- The easiest way to carry out this attack is over a public Wi-Fi network; however, attackers on other types of networks including wired networks can also do this. The main requirement is that the attacker and the victim need to be on the same LAN. The attacker will need to conduct a man-in-the-middle attack to inject malicious code into a HTTP page that can make requests to the targeted HTTPS site. This attack only works if the HTTPS connection is established using SSL 3.0 or TLS 1.0 and a block cipher (e.g. 3DES or AES) in CBC mode is chosen. Unfortunately, most HTTPS sites currently support only SSL 3.0 and TLS 1.0, and prefer using block ciphers in CBC mode.
Some technical details

The main techniques used by the attack are described below. Feel free to skip this section if you don’t care about the technical details.
- Some types of client-side code (Java applets, Silverlight applications, etc.) have the ability to send partial HTTPS requests. They keep the SSL/TLS connection open, and send data as it becomes available. With SSL 3.0 / TLS 1.0, each time a new block of data is sent, a new random initialization vector is not generated. The data is simply appended to the previous stream. An attacker who sees the last ciphertext block and can control the next plaintext block can gain complete control over the next ciphertext block (this is a consequence of how CBC mode works).
- Since HTTP headers preceding cookie headers are predictable and can be obtained by an attacker who sniffs a single HTTP request from the victim, and since the attacker can control the URL of requests, he can control exactly where the cookie header’s bytes end up in relation to ciphertext block boundaries.
- If an attacker knows the previous block of ciphertext and can completely control the next block of plaintext, he can determine whether a previously seen block of ciphertext corresponded to a given block of plaintext. Let’s assume that the attacker wants to determine whether the plaintext, Pi, for a previously seen block of ciphertext, Ci was x. Now, the attacker knows Cj-1, the last block of ciphertext, and wants to set Pj, the next block of plaintext to be encrypted, to a value that helps him determine whether Pi was equal to x. If he sets Pj = Cj-1 ⊕ Ci-1Pi ⊕ x (note that Cj-1 and Ci-1 are sniffed from the network, and x is the attacker’s guess), and Pi was indeed equal to x, then Cj = E(Cj-1 ⊕ Pj) = E(Cj-1 ⊕ Cj-1 ⊕ Ci-1 ⊕ x) = E(Ci-1 ⊕ x) = E(Ci-1 ⊕ Pi) = Ci. Therefore, if the attacker’s guess is correct, then the next block of ciphertext, Cj, will equal the previously seen block of ciphertext, Ci.
Given the above details, let’s say that an attacker makes a request to /AAAAAAAAAA, and knows that it will result in a block of ciphertext containing part of the cookie header: “ookie: x” (this is realistic if a 3DES cipher suite is used). Now, the attacker can make all 256 possible guesses for x, and can determine the first byte of the cookie header. Next, the attacker can make a new HTTP request to /AAAAAAAAA (one less A, which shifts the cookie header one position to the left such that the ciphertext block is now “okie: xy”) and can guess y. The attacker can continue in this manner until he guesses all bytes of the cookie. In reality, there are a lot less than 256 possibilities for each byte of the cookie header, and so the attack requires less work. There are also several details required for the attack to work that are omitted here.

Why the problem can’t be fixed quickly

TLS 1.1, which fixes this issue, was defined in April 2006. As you may have guessed, this problem was known before April 2006. However, it was considered mostly a theoretical issue until Thai Duong and Juliano Rizzo showed how it can be used to decrypt cookies sent over HTTPS. Even though this issue has been known for a while, it is probably not going to be fixed anytime soon because most websites do not support TLS 1.1 or TLS 1.2. According to Opera, only about 0.25 percent of web servers support TLS 1.1, and only 0.02 percent of web servers support TLS 1.2. There are workarounds that some browser vendors are currently implementing and testing; however, this problem is not going to be completely fixed until most web servers start supporting TLS 1.1 or TLS 1.2.

Risks

Should you be worried? Probably not. This does not significantly increase the risk of connecting to untrusted networks. There are easier attacks that can be used to steal your cookies (or your username and password) for many websites, or even install arbitrary software on your computer if you connect to untrusted networks. Some examples are:
- Many websites do not set the ‘secure’ flag on their session cookies, which means that a tool like sslstrip can be used by an attacker on your network to get your cookie.
- Many websites provide login forms over HTTP (even though your password may actually submitted over HTTPS), and attackers on your network can modify the login pages to get your username and password.
- Many users ignore certificate warnings provided by browsers, or may not even notice that a tool like sslstrip is being used and that they are not actually accessing a site over HTTPS before entering their credentials.
- Tools such as Evilgrade can be used to install arbitrary software on your computer by leveraging software that has insecure automatic update mechanisms.
Protecting yourself

If you want to protect yourself against BEAST-like attacks, you can take several steps:
- Delete all your cookies before you connect to an untrusted network.
- Limit the amount of time you spend authenticated to HTTPS sites on untrusted networks, and remember to log out as soon as you are done.
- Until your browser vendor releases a fix, disable all cipher suites that use block ciphers in your browser (leave only cipher suites with RC4 enabled).
Note that the last workaround may cause you to be unable to access many websites. Of course, when browser vendors release security updates, install them immediately.

← SecurityFocus News Schneier on Security →

My Security Planet » Justice League

Feeds

Justice League

Posted: December 7th, 2011, 12:47pm CST by gem

Tags: Software Security [edit]

Posted: December 7th, 2011, 7:47am CST by Cigital

Tags: Software Security [edit]

Posted: December 2nd, 2011, 3:29pm CST by Guest

Tags: Cyber Security [edit]

Posted: December 2nd, 2011, 10:29am CST by Cigital

Tags: Cyber Security [edit]

Posted: November 30th, 2011, 3:36pm CST by gem

Tags: BSIMM [edit]

Posted: November 15th, 2011, 6:45pm CST by jOHN

Tags: Admin [edit]

Posted: November 7th, 2011, 2:18pm CST by sammy

Tags: Software Security [edit]

Posted: October 11th, 2011, 1:59pm CDT by Guest

Tags: Cyber Security [edit]

Posted: September 27th, 2011, 7:30am CDT by sammy

Tags: BSIMM [edit]

Posted: September 26th, 2011, 10:02am CDT by Guest

Tags: Defects Bugs and Flaws [edit]