Author Archive: Brad Arkin, Chief Security Officer

Illegal Access to Adobe Source Code

Adobe is investigating the illegal access of source code for Adobe Acrobat, ColdFusion, ColdFusion Builder and other Adobe products by an unauthorized third party.  Based on our findings to date, we are not aware of any specific increased risk to customers as a result of this incident.

Adobe thanks Brian Krebs, of KrebsOnSecurity.com, and Alex Holden, chief information security officer, Hold Security LLC. holdsecurity.com  for their help in our response to this incident.

We are not aware of any zero-day exploits targeting any Adobe products. However, as always, we recommend customers run only supported versions of the software, apply all available security updates, and follow the advice in the Acrobat Enterprise Toolkit and the ColdFusion Lockdown Guide. These steps are intended to help mitigate attacks targeting older, unpatched, or improperly configured deployments of Adobe products.

For more information on Acrobat security, please visit the Acrobat Developer Center.

For more information on ColdFusion 10 security, please visit the ColdFusion Developer Center.

 

Brad Arkin

Chief Security Officer

Training Secure Software Engineers

SAFECode today announced the release of a software security training program. This is an exciting new resource, not just for anyone interested in learning more about writing secure code in the real world, but for software security leaders responsible for integrating security into how the development organization builds code. SAFECode’s ambition is that this training resource will provide building blocks for folks to develop a successful customized training program for their environment. I encourage you to check out the training and I also want to provide some context about how this SAFECode release came to be.

When I first joined Adobe, nearly five years ago, my top priority was raising the security IQ across the various roles responsible for getting code out the door: from people who write and test code to the many flavors of managers (product, program, people) and everyone in between. After looking at a lot of options, we built the ASSET Software Security Certification Program and have seen thousands of Adobe employees certified every year, since the launch in early 2009.

I have received many inquiries about sharing our course materials. Rather than publishing one-off drops of the Adobe training content, we instead worked with the other SAFECode members to use our courses as the seed for the software security training site launched today. With the pooled resources of all the SAFECode contributors and a place to focus the broader community of software security champions on training, we aim to have the biggest impact.

Please stay tuned as Josh Kebbel-Wyen, Senior Security Program Manager for ASSET (Adobe Secure Software Engineering Team) publishes a series of blog posts describing the ASSET certification program at Adobe. He will offer insights into how the program helped us establish a security culture at Adobe and share tips and tricks based on lessons learned along the way.

 

Brad Arkin
Chief Security Officer

Adobe Sponsors Microsoft Security Development Conference

Brad here. With the Microsoft Security Development Conference coming up on May 14th and 15th, in San Francisco, I want to take a minute to talk about my plans for the week.

On Tuesday, May 14th, at 3:00 p.m., I’ll present the topic “Never Waste a Crisis: Take 2. ” This presentation is based on the original one I gave at the RSA Conference in 2012, sharing some lessons on how to prepare for a crisis and what to do to ensure you leave your software security program in a stronger position once it’s all over. This time, I’ll talk about how we put these lessons to work with respect to another crisis: the inappropriate use of a code signing certificate which happened at Adobe in September 2012. In this second take on the topic of crises, I’ll grade my own advice — and my own performance at following that advice — with lessons learned from the code signing incident.

Then on Wednesday, May 15th at 9:45 a.m., I’ll present a keynote on: “Accepting Defeat: Changing the Battle Plan.” I’ll talk about how to acknowledge when the current approach to a problem isn’t working, abandoning a long-standing strategy and looking for new approaches. I’ll give two examples of how this worked for us at Adobe.

If you haven’t registered yet for the Microsoft Security Development Conference, I encourage you to go ahead. You can use this discount code: ADB@SDC!@

I’m looking forward to catching up with everyone who plans to attend. See you there.

Brad Arkin
Chief Security Officer

New Role – Chief Security Officer

For those who may have seen the news and are looking for more context, I’ve put together a quick post about my new role as Adobe’s Chief Security Officer. While this is a newly created role at Adobe, it’s an expansion of responsibilities that builds upon on the initiatives I’ve been leading for nearly five years at the company.

As CSO, I will report to Bryan Lamkin, SVP of Technology and Corporate Development, and will work in partnership with Adobe’s global information technology team led by our CIO Gerri Martin-Flickinger. I will continue to oversee the Adobe Secure Software Engineering Team (ASSET), responsible for implementing our Secure Product Lifecycle that engineers products to be robust against attacks, as well as the Product Security Incident Response Team (PSIRT), responsible for managing response to product security incidents. In my new role, I have the opportunity to lead Engineering Infrastructure Security, a team that builds and maintains security-critical internal services relied on by our product and engineering teams, such as code signing and build environments. I will also continue to manage and foster two-way communication with the broader security community, a vital part of the central security function.

The driving goal behind our security work is to protect our customers from those who would seek to harm them. Adobe has some of the most widely-deployed software in the world and we are keenly aware that this makes us a target. We remain committed to doing everything we can to defend against the bad guys. I am excited to continue  leading the charge at Adobe!

Brad Arkin

Chief Security Officer

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

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

Flash Player 11.3 delivers additional security capabilities for Mac and Firefox users

Today’s release of Flash Player 11.3 brings three important security improvements:

  • Flash Player Protected Mode (“sandboxing”) is now available for Firefox users on Windows.
  • For Mac users, this release will include the background updater for Mac OS X.
  • This release and all future Flash Player releases for Mac OS X will be signed with an Apple Developer ID, so that Flash Player can work with the new Gatekeeper technology for Mac OS X Mountain Lion (10.8).

Flash Player 11.3 brings the first production release of Flash Player Protected Mode for Firefox on Windows, which we first announced in February. This sandboxing technology is based on the same approach that is used within the Adobe Reader X Protected Mode sandbox. Flash Player Protected Mode for Firefox is another step in our efforts to raise the cost for attackers seeking to leverage a Flash Player bug in a working exploit that harms end-users. This approach has been very successful in protecting Adobe Reader X users, and we hope Flash Player Protected Mode will provide the same level of protection for Firefox users. For those interested in a more technical description of the sandbox, please see the blog post titled Inside Flash Player Protected Mode for Firefox authored by ASSET and the Flash Player team.

The background updater being delivered for Mac OS X uses the same design as the Flash Player updater on Windows. If the user chooses to accept background updates, then the Mac Launch Daemon will launch the background updater every hour to check for updates until it receives a response from the Adobe server. If the server responds that no update is available, the system will begin checking again 24 hours later. If a background update is available, the background updater can download and install the update without interrupting the end-user’s session with a prompt.

With Mac OS X Mountain Lion (10.8), Apple introduced a feature called “Gatekeeper,” which can help end-users distinguish trusted applications from potentially dangerous applications. Gatekeeper checks a developer’s unique Apple Developer ID to verify that an application is not known malware and that it hasn’t been tampered with. Starting with Flash Player 11.3, Adobe has started signing releases for Mac OS X using an Apple Developer ID certificate. Therefore, if the Gatekeeper setting is set to “Mac App Store and identified developers,” end-users will be able to install Flash Player without being blocked by Gatekeeper. If Gatekeeper blocks the installation of Flash Player with this setting, the end-user may have been subject to a phishing attack. That said, a reminder that Flash Player should only be downloaded from the www.adobe.com website.

Working Together on Keeping Our Mutual Customers Up-to-Date

No doubt, staying up-to-date on the latest security patches is critical in today’s threat environment. In addition to the many security initiatives we engage in as a vendor to help keep our products and our users safe, the single most important advice we can give to users is to always stay up-to-date. The vast majority of users who ever encountered a security problem using Adobe products were attacked via a known vulnerability that was patched in more recent versions of the software. This is why we’ve invested so much in the Adobe Reader/Acrobat update mechanism introduced in 2010, and more recently in the Flash Player background updater delivered in March of this year and used for the first time with last week’s Flash Player security update. Both update mechanisms give Windows users the option to install updates automatically, without user interaction. A Mac version of the Flash Player background updater is currently in beta and will be available very soon—stay tuned.

In the meantime, we welcome today’s initiative by Apple to encourage Mac users to stay up-to-date: With the Apple Safari 5.1.7 update released today, Apple is disabling older versions of Flash Player (specifically Flash Player 10.1.102.64 and earlier) and directing users to the Flash Player Download Center, from where they can install the latest, most secure version of Flash Player. For more information, visit http://support.apple.com/kb/HT5271.

Remember: The single most important thing we can do to protect ourselves from the bad guys is to stay up-to-date. A thank you to the security team at Apple for working with us to help protect our mutual customers!

RSA Conference Schedule

Brad Arkin here. RSA Conference is upon us once again. There are some exciting talks and events on the calendar, but I’m looking forward to the informal “hallway track” the most.

In the days leading up to RSA Conference, everyone in the industry seems to be reminding each other of the sessions you “absolutely should not miss.” Here’s my pitch—and a summary of where you can find me and members of the Adobe Secure Software Engineering Team at RSA Conference:

MONDAY, FEBRUARY 27, 2012

On Monday, February 27, you’ll find me at the “Improving Application Security Seminar” (SEM-002), along with experts from Symantec, Cigital, Fortify Software, HP, Microsoft, and Veracode. This full-day seminar for delegates will kick off at 8:30 a.m. in Room 305 at the Moscone Center.

In the evening, please join the Adobe Security Team from 6:30 to 9:30 p.m. at Roe Restaurant (10 Hawthorne Street, two blocks from the Moscone Center) for food, drinks, and a lively discussion on the current challenges facing the security industry. Please note that this is a limited capacity event, so please register for this event as soon as possible to save your spot.

TUESDAY, FEBRUARY 28, 2012

Join Adobe’s Kyle Randolph and other participants from EMC, Cigital, Symantec and Microsoft for a panel discussion titled “Making Sense of Software Security Advice: Best vs. Practiced Practices” (ASEC-106) at 1:10 p.m. on Tuesday, February 28, in Room 302. The panel, moderated by EMC’s Reeny Sondhi, will help you make sense of the different software security advice available and discuss how to apply it to your work.

WEDNESDAY, FEBRUARY 29, 2012

If you are an early riser, join me at 8:00 a.m. on Wednesday, February 29, in Room 302 for a panel discussion moderated by Chenxi Wang from Forrester, titled “War Stories: The Good, Bad and the Ugly of Application Security Programs” (ASEC-201). I’ll be participating on the panel along with Doug Cavit from Microsoft and James Routh from JPMorgan Chase & Co. We look forward to your questions and comments!

Afterwards, don’t miss my talk “Never Waste a Crisis – Necessity Drives Software Security Improvements” (ASEC-203), which will take place from 10:40-11:30 a.m. in Room 302. I’ll share some general lessons on both how to prepare for a crisis and what to do once it arrives. And I’ll provide step-by-step instruction on what to do through every phase of a crisis with an eye towards promoting the priority of software security activities throughout.

THURSDAY, MARCH 1, 2012

On Thursday, March 1, I’ll be moderating a SAFECode panel discussion titled “What Motivated My Company to Invest in a Secure Development Program?” (ASEC-301). Other panelists include Steven Lipner from Microsoft, Gunter Bitz from SAP, Janne Uusilehto from Nokia, and Gary Phillips from Symantec. Don’t miss what promises to be a lively discussion from 8:00-9:10 a.m. in Room 302!

We hope to see you at RSA Conference!

Background on Adobe Reader and Acrobat Ship Schedule – CVE-2011-2462 (APSA11-04)

We have just posted Security Advisory APSA11-04 regarding a new vulnerability (CVE-2011-2462) that is currently being exploited in the wild in limited, targeted attacks against Adobe Reader 9.4.6 on Windows. Here is a summary of our approach to address this issue:

  • We are planning to release an out-of-cycle security update for Adobe Reader and Acrobat 9.x for Windows no later than the week of December 12, 2011.
  • Because Adobe Reader X Protected Mode and Adobe Acrobat X Protected View would prevent an exploit targeting this vulnerability from executing, we are planning to address this issue in Adobe Reader and Acrobat X for Windows with the next quarterly security update on January 10, 2012.
  • The risk to Macintosh and UNIX users is significantly lower. We are therefore planning to address this issue in Adobe Reader and Acrobat X and earlier versions for Macintosh as part of the next quarterly update on January 10, 2012. An update to address this issue in Adobe Reader 9.x for UNIX is planned for January 10, 2012.

The reason for addressing this issue quickly for Adobe Reader and Acrobat 9.4.6 for Windows is simple: This is the version and platform currently being targeted. All real-world attack activity, both in this instance and historically, is limited to Adobe Reader on Windows. We have not received any reports to date of malicious PDFs being used to exploit Adobe Reader or Acrobat for Macintosh or UNIX for this CVE (or any other CVE).

Focusing this release on just Adobe Reader and Acrobat 9.x for Windows also allows us to ship the update much earlier. We are conscious of the upcoming holidays and are working to get this patch out as soon as possible to allow time to deploy the update before users and staff begin time off. Ultimately the decision comes down to what we can do to best mitigate threats to our customers.

I’d like to take this moment to encourage any remaining users still running Adobe Reader or Acrobat 9.x (or worse, older unsupported versions) to PLEASE upgrade to Adobe Reader or Acrobat X. We put a tremendous amount of work into securing Adobe Reader and Acrobat X, and, to date, there has not been a single piece of malware identified that is effective against a version X install. Help us help you by running the latest version of the software!