The Evolution of Exploit Sophistication

When we look at the exploits that Adobe patched from February and March of this year, it is clear that today’s zero-day exploits are increasingly more sophisticated. This increase in sophistication is not limited to the skills needed to find and exploit the vulnerability. The code used to exploit the environment is also more robust in terms of code quality and testing. In short, exploit creation today requires the same level of rigor as professional software engineering projects.

Today’s advanced exploits need to be written to work in any target environment. For instance, February’s Reader 0-day supported 10 different versions of Reader with 2 sub-versions dependent on the end-user’s language. In addition, Flash Player CVE-2013-0634 had shell code for Windows XP, Vista, Windows 7, Server 2003, Server 2003 R2, Server 2008 and Server 2008 R2 as well as supporting six versions of Flash Player. Variants of CVE-2013-0634 also supported Firefox and Safari on Mac OS X. An exploit developer would need a robust testing environment to ensure that the exploit would work in that many different environments for each version of Flash Player. The exploit writers even took into account different CPU architectures by including a signed 32-bit payload and a 64-bit payload. This reflects the fact that these exploits are written with professional code quality and stability requirements for distribution across a dynamic target base.

As vendors are increasing software defenses through techniques such as sandboxing, attackers are now combining multiple vulnerabilities from different vendors to achieve their goals.When I look at the reports from Pwn2Own and some of the recent zero-day reports such as CVE-2013-0643, attacks are moving toward combining vulnerabilities from multiple products, some of which are from different vendors. We are moving away from the model of single vulnerability exploits.

This is all a part of the natural evolution of the threat landscape and the commercialization of exploits. This will require an equal evolution on the part of vendors in their software defences. Karthik Raman and I will be discussing this topic, “Security Response in the Age of Mass Customized Attacks,” in more detail at the upcoming Hack in the Box Conference (HITB) Amsterdam next week. Please stop by our talk if you would like to discuss this further.

Peleus Uhley
Platform Security Strategist

Top 10 Web Hacking Techniques of 2012

I was honored that Jeremiah Grossman asked me to serve again on the panel for the Top 10 Web Hacking Techniques of 2012. During the process, I get to take a look at the year’s most interesting research in greater detail than what is normally allowed in my day-to-day schedule. It makes me question what I thought I knew about existing attack techniques and how this year’s top research reflects on the industry.

Ranking the entries is challenging when you are comparing an SSL cryptography bug vs. the server side request forgery attacks vs. attacks against Chrome add-ons. To do so, requires that you read the full research, review the source code that was written and try to determine what impact the research had on the community. I typically start by considering factors such as:

  • Is the research completely new or is it just an incremental improvement of a known issue?
  • How many end-users are impacted?
  • Is this an individual bug affecting one vendor or an industry-wide issue?
  • What does successful exploitation yield (XSS, file access, OS control, etc.)?
  • Is the exploit practical to conduct?
  • What was the depth of research (a white paper, a tool, etc.)?
  • Extra points for style or creativity?

Reviewing the research to this depth then leads to uncovering smaller bits that are interesting in their own right. For instance, the Blended Threats and JavaScript research leveraged HTML5 to create cross-site file upload capabilities. You will find links to tools that back up the research in entries such as Blended Threats, Attacking OData, Bruteforcing PHPSESSID, and the Chrome add-on research. In some cases, the research reminds you about how many of the old tricks can be re-purposed against new technologies.

As an example, in July, 1998 Microsoft issued security bulletin MS98-004 which allowed, “Unauthorized ODBC Data Access with RDS and IIS”. In 1999, new information was published regarding the bug and Bugtraq ID 529 said exploiting the vulnerability could result in, “obtaining access to non-public servers or effectively masking the source of an attack on another network”. Today, we would classify this type of attack as, “Server Side Request Forgery” (SSRF). Modern SSRF attacks can include both old and new attack techniques. For instance, the ERPScan paper discussed how to use the gopher: protocol in an XML External Entity to attack SAP gateways. Over a decade later, we now have a formal taxonomy for classifying these types of bugs. However, the core issue of effectively sandboxing a web application to a finite set of resources is not much easier than it was 15 years ago. If anything, it has become more difficult as the number of supported communication channels between endpoints has increased.

Finally, you begin to think about why these top 10 bugs are critical to the industry. The panel ranked,”Compression Ratio Info-leak Made Easy” (CRIME) in the top slot due to the overall difficulty of the research, the vendor action required to address it, and the importance of SSL to the security ecosystem. As we move more data to the cloud where we will access it via our mobile or tablet devices, we will increasingly rely on SSL to protect it in transmission. Another interesting trend in this year’s top list was the multiple SSRF entries. As I mentioned, it wasn’t a completely new concept but rather a concept that is seeing a renewed interest as more data moves to the cloud. There were three SSRF entries in the Top 15 and the SSRF entry that was ranked number 2 includes research by two separate groups. As our dependence on cloud storage grows, SSRF will become an increasingly used attack vector for reaching all the critical data that lies behind those front end cloud servers.

As everyone reviews the Top 15, I encourage you to find time to read through each entry. The final list represents great information by talented researchers. Also, I would recommend sharing the list with your engineers. When I shared the Top 15 list with our internal Adobe community a few months ago, I can attest that at least one developer recognized a flaw that existed in his system and corrected the issue. Thanks to Jeremiah Grossman for putting this together each year and allowing me to be a part of it.

Peleus Uhley
Platform Security Strategist

RSA Conference 2013

Brad here. With RSA around the corner, I want to take a minute to talk about my plans for the conference. On Wednesday morning at 9:20 a.m., in room 132, I’ll debate best-selling author John Viega on the topic “Software Security: A Waste of Time.” Who will take each side? Which side will win? Show up on time to find out. Based on the prep sessions, this one should be fun.

Then on Thursday morning, (again at 9:20 a.m., in room 132), I’ll present “To the Cloud! The Evolution of Software Security at Adobe.” I’ll give a look into how the Adobe Secure Software Engineering team retrenched and retooled to help the company secure new hosted service offerings such as the Adobe Creative Cloud and the Adobe Marketing Cloud. I’ll reprise the talk in a 20 minute format at 3:00 p.m. on Thursday, in the RSA studio, in room 300.

As with every conference, I’m most excited about the hallway track. Looking forward to catching up with everyone who plans to attend.

Brad Arkin
Sr. Senior Director of Security

Click-to-Play for Office is Here!

Last week, we introduced a new Flash Player feature that includes a new Microsoft Office click-to-play capability that determines whether Flash Player is being launched within Microsoft Office and automatically checks the version of Office. Launching Flash Player 11.6 from within a version of Office older than Office 2010 will prompt the end-user before executing the Flash content, ensuring potentially malicious content does not immediately execute and impact the end-user. This feature adds another layer of defense against spearphishing attacks by allowing the end-user an opportunity to realize that they have opened a potentially malicious document and close it before the exploit executes.

Click-to-Play for Office should make this attack vector less attractive for attackers. Please update your environments to Flash Player 11.6 as soon as possible.

Peleus Uhley, Platform Security Strategist, ASSET

Raising the Bar for Attackers Targeting Flash Player via Office Files

Adobe has worked hard to make Flash Player more secure. We have worked with our partners Google and Mozilla to sandbox Flash Player in Google Chrome  on Windows, Mac, Linux and Chrome OS, and in MozillaFirefox on Windows. We have also been working closely with Microsoft to deliver Flash Player with Internet Explorer 10 on Windows 8, which means Flash Player runs in Enhanced Protected Mode, further restricting the plugin’s privileges in the browser, and Flash Player updates are delivered through Windows Update. (I’ll be blogging on the protections Enhanced Protected Mode provides for Flash Player users in a separate blog post later this month.) We also welcomed Apple’s initiative to  encourage Mac users to stay up-to-date by disabling older versions of Flash Player and directing users to install the latest, most secure version of Flash Player, and Mozilla’s click-to-play feature in Firefox. And we have worked hard on improving the update mechanism in Flash Player to make it easier for our user s to stay up-to-date. Windows and Macintosh users receive critical security patches through regular update checks by the Flash Player update mechanism. These enhancements help to protect users as they browse the Web.

Over the last year, Adobe has been driving down the number of Flash (SWF)-based zero-days used in the wild. Since the introduction of Adobe Reader X Protected Mode (aka sandboxing) in November 2010, the most common Flash Player zero-day attack vector has been malicious Flash content embedded in Microsoft Office documents and delivered via email. In fact, today’s Flash Player update addresses CVE-2013-0633 and CVE-2013-0634, both of which are being exploited in targeted attacks leveraging this very attack vector. In the next feature release of Flash Player, which is currently in beta, we will be delivering a solution designed to help make this attack vector less attractive.

Microsoft Office 2010 includes a Protected Mode sandbox for limiting the privileges of content within the document. If the document originates from the Internet or Untrusted Zone, the Protected View feature will prevent Flash Player content from executing by default. However, not everyone has the ability to update to Office 2010. In Office 2008 and earlier, Flash Player content will run by default without sandbox protections, making it an attractive attack vector for targeted attacks.

To protect users of Office 2008 and earlier, the upcoming release of Flash Player will determine whether Flash Player is being launched within Microsoft Office and check the version of Office. If Flash Player is launched within a version prior to Office 2010, Flash Player will prompt the end-user before executing the Flash content with the dialogue below:

OfficeClickToPlayFP

Therefore, if an end-user opens a document containing malicious Flash content, the malicious content will not immediately execute and impact the end-user. This extra step requires attackers to integrate a new level of social engineering that was previously not required.

We’ve seen these types of user interface changes lead to shifts in attacker behavior in the past and are hopeful this new capability will be successful in better protecting Flash Player users from attackers leveraging this particular attack vector as well.

We’ll post an update here as soon as this new feature in Flash Player becomes available. Stay tuned!

Peleus Uhley, Platform Security Strategist, ASSET

Firefox Click-to-Play Helps Protect Our Customers

The Adobe team has worked hard to improve patch adoption by delivering background updaters for Flash Player and Adobe Reader. In addition, we have worked with partners, such as Microsoft and Google, to reduce update fatigue by delivering patches through existing update mechanisms. However, one of the hardest challenges in protecting end users is reaching what is sometimes referred to as the “long tail” in an update graph. These are the users who, for various reasons, have not updated their systems in several months or even years. Reaching these last few end users can be difficult if they have disabled their update mechanisms. Unfortunately, they are also the users who are most likely to be successfully attacked.

Yesterday, Mozilla announced an update to the Firefox click-to-play feature that will warn users when they try to play plugin content with an out-of-date browser plugin. Since Mozilla will now be assisting plugin vendors in reminding these users to update, we will hopefully be able to convert more of them to patched versions. At the same time, Mozilla is helping to protect these users from those who would use older vulnerabilities to infect their systems. We support Mozilla in their efforts to protect and inform our mutual customers.

Adobe is a Sponsor for the Nation’s Largest Student Cyber Security Competition

ASSET team members Karthik Raman, Bronwen Matthews and I recently attended the NYU Poly CSAW IX Cyber Security competition  in Brooklyn, New York. The annual event first took place in 2003 and has since grown from a small, local cyber security competition to a worldwide event. This year, more than 10,000 students from high school to Ph.D level registered to compete in a total of seven CSAW challenges.

Karthik and I contributed four Web challenges to the “Capture the Flag” competition, which were designed to be similar to real-world scenarios hackers face. The challenges were related to commonly found bugs, but required the hacker to deduce the nature of the bug without much feedback from the website. The students responded with a pragmatic approach to the problems, and the competition was won by a team from Carnegie Mellon University. There was also an embedded systems challenge, a forensics challenge and an applied research competition.

Adobe sponsored the “Security Awareness” video challenge, open to high school and college students worldwide. The contest challenged students to develop a consumer-friendly educational video on an important security topic with the theme: “Securing Every Device, Everywhere.” Adobe provided access to the free version of Adobe Creative Cloud for all participants, enabling them to use our latest video production tools. Guest judges from the security teams at Adobe, Microsoft, VMWare, Facebook, and the NSA selected the final winners. The first place winner of the challenge this year was Ethan Bain of the Illinois Mathematics and Science Academy in Aurora, Illinois. You can watch his winning video here.

The first day of the event focused on mobile security, with presentations from Dan Guido, Vincenzo Iozzo and Dino Dai Zovi from Trail of Bits, as well as Mike Arpaia.  Other presenters included:  Collin Mulliner of Northeastern University, Jon Oberheide of DUO Security, and Chris Rohlf of LeafSR.

Ryan Naraine from Kaspersky Lab moderated an interesting panel discussion entitled: “If a Cybercriminal is Determined to Hack You, Can You Do Anything About it?” Panelists included representatives from Kaspersky, Harvard University IT and NYU Poly.

The high school students competed in a challenging, live security quiz, sponsored by DHS. (We played along in the audience. Let’s just say we got most of the answers right.)

It was a fun couple of days. We met some excellent students doing interesting and important work in security. It is reassuring to know that the next wave of security researchers coming out of some of our high schools and colleges are way ahead of the game in cyber security.

Rajat Shah
Security Researcher
Adobe Secure Software Engineering Team (ASSET)

BSIMM Community Conference 2012

Last week, ASSET team members Jim Hong, Josh Kebbel-Wyen and I attended the BSIMM Community Conference 2012, which took place in Galloway, NJ. This year, despite hurricane Sandy, the conference had about 90 attendees representing 30 organizations.

The Building Security In Maturity Model (BSIMM) is a data-driven descriptive model of existing security initiatives across various companies. Adobe was one of the nine original participants in measurements for the first version of BSIMM and has participated in subsequent BSIMM surveys.

This year, participants such as Intel, Symantec and JP Morgan Chase held talks during the conference, covering topics such as strategy, architecture analysis, training and penetration testing, with each talk describing how the organizations had customized the best practice in their particular environment.

In addition to the talks, there were three parallel workshops on Security Fraud, Third Party Security Controls and Agile Methods in SSDLs. These workshops provided discussion on the nuances of security and how each organization deals with the challenges associated with them.

The talks and workshop were informative but of equal or maybe even greater value, was the opportunity to network and compare notes on security initiatives and best practices with peers from across participating organizations. The benefit from this kind of interaction is immense.

Mohit Kalra
Senior Manager Secure Software Engineering

 

New Security Capabilities in Adobe Reader and Acrobat XI Now Available!

This week, Adobe released the next generation of Adobe Reader XI and Acrobat XI with improved security features, among many other enhancements.

Adobe Reader X represented a milestone release in terms of security with the introduction of Adobe Reader Protected Mode (aka “sandboxing”), which created a more secure environment for our customers. We followed the Adobe Reader X release with the introduction of Adobe Acrobat X (10.1) Protected View. Since we added sandbox protection to Adobe Reader and Acrobat, we have not seen any exploits in the wild that break out of the Adobe Reader and Acrobat X sandbox.

Over the last year, we have continued to work on adding security capabilities to Adobe Reader and Acrobat, and today, we are very excited to present Adobe Reader and Acrobat XI with a number of new or enhanced security features.

Adobe Reader XI Protected Mode (Enhanced)

In our Adobe Reader X sandbox implementation, the sandboxing architecture’s primary focus was on “write protection” to prevent the attacker from installing malware on the user’s machine and from monitoring the user’s keystrokes when the user interacts with another program.

In Adobe Reader XI, we have added data theft prevention capabilities by extending the sandbox to restrict read-only activities to help protect against attackers seeking to read sensitive information on the user’s computer.

Adobe Reader Protected View (New) and Adobe Acrobat Protected View (Enhanced)

To provide an additional layer of defense and strengthen the sandbox protection in Adobe Reader and Acrobat even further, we have implemented a separate desktop and WinStation in Adobe Reader and Acrobat XI, which will block, for instance, screen scraping attacks. For additional insights into implementing a separate desktop to provide an additional layer of defense, see David LeBlanc’s Web log entry Practical Windows Sandboxing – Part 3. For details on WinStations and desktops in general, click here.

This mode effectively introduces a new Protected View in Adobe Reader and enhances the Protected View implementation in Adobe Acrobat even further. Protected View behaves identically for Adobe Reader and Acrobat, whether viewing PDF files in the standalone product or in the browser. For more information, administrators can refer to the Enterprise Toolkit for Acrobat Users.

Force ASLR Support in Adobe Reader/Acrobat XI

Adobe Reader and Acrobat leverage platform mitigations such as Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), etc. In Adobe Reader and Acrobat XI, we have enabled support for Force ASLR on Windows 7 and Windows 8. Force ASLR improves the effectiveness of existing ASLR implementations by ensuring that all DLLs loaded by Adobe Reader or Acrobat XI, including legacy DLLs without ASLR enabled, are randomized. By enabling Force ASLR in Adobe Reader and Acrobat XI, we are making it even more difficult for an attacker to exploit vulnerabilities. For more information on ASLR and Force ASLR, please refer to Microsoft’s Knowledge Base article on the topic.

PDF Whitelisting Framework

For high-assurance, managed enterprise environments, we’ve added the Adobe PDF Whitelisting Framework, which allows administrators to selectively enable advanced functionality, such as JavaScript for specific PDF files, sites or hosts, on both Windows and Mac OS.

Support for Elliptic Curve Cryptography

And last but not least, we have added support for Elliptic Curve Cryptography (ECC) for digital signatures in the area of content security. Users can now embed long-term validation information automatically when using certificate signatures and use certificate signatures that support elliptic curve cryptography (ECC)-based credentials.

We’re excited about these additional security capabilities in Adobe Reader and Acrobat XI, which mark the latest in our continued endeavor to help protect our customers by providing a safer working environment.

Priyank Choudhury
Security Researcher, Adobe Secure Software Engineering Team (ASSET)

Inappropriate Use of Adobe Code Signing Certificate

We recently received two malicious utilities that appeared to be digitally signed using a valid Adobe code signing certificate. The discovery of these utilities was isolated to a single source. As soon as we verified the signatures, we immediately decommissioned the existing Adobe code signing infrastructure and initiated a forensics investigation to determine how these signatures were created. We have identified a compromised build server with access to the Adobe code signing infrastructure. We are proceeding with plans to revoke the certificate and publish updates for existing Adobe software signed using the impacted certificate. This only affects the Adobe software signed with the impacted certificate that runs on the Windows platform and three Adobe AIR applications* that run on both Windows and Macintosh. The revocation does not impact any other Adobe software for Macintosh or other platforms.

Sophisticated threat actors use malicious utilities like the signed samples during highly targeted attacks for privilege escalation and lateral movement within an environment following an initial machine compromise. As a result, we believe the vast majority of users are not at risk.  We have shared the samples via the Microsoft Active Protection Program (MAPP) so that security vendors can detect and block the malicious utilities.

Customers should not notice anything out of the ordinary during the certificate revocation process.  Details about what to expect and a utility to help determine what steps, if any, a user can take are available on the support page on Adobe.com.

Sample Details

The first malicious utility we received is pwdump7 v7.1.  This utility extracts password hashes from the Windows OS and is sometimes used as a single file that statically links the OpenSSL library libeay32.dll.  The sample we received included two separate and individually signed files. We believe the second malicious utility, myGeeksmail.dll, is a malicious ISAPI filter. Unlike the first utility, we are not aware of any publicly available versions of this ISAPI filter. More details describing the impacted certificate and the malicious utilities, including MD5 hash values for the files, are included in the Adobe security advisory.

In addition to working with your security vendors to ensure you have the latest updates containing protections against these utilities, system administrators for managed desktop Windows OS environments can create a Software Restriction Policy (SRP—via Group Policy) that disallows the execution of the malicious utilities and blocks them on the basis of the individual file hashes.

Our internal testing indicates that moving the impacted Adobe certificate to the Windows Untrusted Certificate Store does not block threat actors from executing the malicious utilities on a victim machine. However, this configuration does have a negative impact on the user experience and execution of valid Adobe software signed with the impacted certificate. Adobe does not recommend using the Untrusted Certificate Store in this situation.

Adobe Code Signing Infrastructure

The private keys associated with the Adobe code signing certificates were stored in Hardware Security Modules (HSMs) kept in physically secure facilities. All entities authorized to request digital signatures were provisioned according to an established procedure that verified the identity of the entity and verified that the release engineering environment met the relevant assurance criteria. All code signing requests were submitted via mutually authenticated Transport Layer Security (TLS) connections to the code signing service and were performed only if the requesting entity came from the originally provisioned IP address.

Within minutes of the initial triage of the first sample, we decommissioned our signing infrastructure and began a clean-room implementation of an interim signing service for re-signing components that were signed with the impacted key after July 10, 2012 and to continue code signing for regularly scheduled releases. The interim signing solution includes an offline human verification to ensure that all files scheduled for signature are valid Adobe software. We are in the process of designing and deploying a new, permanent signing solution.

Compromised Build Server

We have identified a compromised build server that required access to the code signing service as part of the build process. Although the details of the machine’s configuration were not to Adobe corporate standards for a build server, this was not caught during the normal provisioning process. We are investigating why our code signing access provisioning process in this case failed to identify these deficiencies. The compromised build server did not have rights to any public key infrastructure (PKI) functions other than the ability to make code signing requests to the code signing service.

Our forensic investigation is ongoing. To date we have identified malware on the build server and the likely mechanism used to first gain access to the build server. We also have forensic evidence linking the build server to the signing of the malicious utilities. We can confirm that the private key required for generating valid digital signatures was not extracted from the HSM. We believe the threat actors established a foothold on a different Adobe machine and then leveraged standard advanced persistent threat (APT) tactics to gain access to the build server and request signatures for the malicious utilities from the code signing service via the standard protocol used for valid Adobe software.

The build server used a dedicated account to access source code required for the build. This account had access to only one product. The build server had no access to Adobe source code for any other products and specifically did not have access to any of Adobe’s ubiquitous desktop runtimes such as Flash Player, Adobe Reader, Shockwave Player, or Adobe AIR. We have reviewed every commit made to the source repository the machine did have access to and confirmed that no source code changes or code insertions were made by the build server account. There is no evidence to date that any source code was stolen.

Next Steps

The revocation of the impacted certificate for all code signed after July 10, 2012 is planned for 1:15 pm PDT (GMT -7:00) on Thursday October 4, 2012. To determine what this means for current installations and what corrective steps (if any) are necessary, please refer to the support page on Adobe.com. The certificate revocation itself will be included in the certificate revocation list (CRL) published by VeriSign; no end user or administrator action is required to receive the updated CRL.

Through this process we learned a great deal about current issues with code signing and the impact of the inappropriate use of a code signing certificate. We plan to share our lessons learned as well as foster a conversation within the industry about the best way to protect users and minimize the impact on users in cases where the revocation of a certificate becomes necessary (as in this example). Please stay tuned for more details in the coming weeks.

* Adobe Muse and Adobe Story AIR applications as well as Acrobat.com desktop services