Presenting “Malware Classifier” Tool

Hi folks,

Karthik here from Adobe PSIRT. Part of what we do at PSIRT is respond to security incidents. Sometimes this involves analyzing malware.  To make life easier, I wrote a Python tool for quick malware triage for our team. I’ve since decided to make this tool, called “Adobe Malware Classifier,” available to other first responders (malware analysts, IT admins and security researchers of any stripe) as an open-source tool, since you might find it equally helpful.

Malware Classifier uses machine learning algorithms to classify Win32 binaries – EXEs and DLLs – into three classes: 0 for “clean,” 1 for “malicious,” or “UNKNOWN.” The tool extracts seven key features from a binary, feeds them to one or all of the four classifiers, and presents its classification results.

The tool was developed using models resultant from running the J48, J48 Graft, PART, and Ridor machine-learning algorithms on a data set of approximately 100,000 malicious programs and 16,000 clean programs.

Malware Classifier is available at Open @ Adobe.

I will be speaking about the research behind the tool at Infosec Southwest 2012 in Austin, TX, on April 1. If you’re going to be there, I look forward to meeting up and discussing product security and secure engineering at Adobe.

An Update for the Flash Player Updater

Peleus here with the second major 2012 security announcement for Flash Player. Today’s release of Flash Player contains a new background updater. This new background updater will allow Windows users to choose an automatic update option for future Flash Player updates.

If you read this September 2011 CSIS report, then you saw that 99.8 percent of malware installs through exploit kits are targeting out-of-date software installations. This point was reiterated recently in volume 11 of the Microsoft Security Intelligent Report. Also, attackers have been taking advantage of users trying to manually search for Flash Player updates by buying ads on search engines pretending to be legitimate Flash Player download sites. Improving the update process is probably the single most important challenge we can tackle for our customers at this time.

Overview of the background updater design

A full technical description of the new background updater design is available on DevNet, but here are the highlights:

After a successful installation of Adobe Flash Player 11.2, users will be presented with a dialog box to choose an update method. The following three update options are available to users:

  • Install updates automatically when available (recommended)
  • Notify me when updates are available
  • Never check for updates (not recommended)

For our initial release, we have set the new background updater to check for updates once an hour until it gets a response from Adobe. If the response says there is no new update, then it will wait 24 hours before checking again. We accomplish this through the Windows Task Scheduler to avoid running a background service on the system. If you are running multiple browsers on your system, the background updater will update every browser. This will solve the problem of end-users having to update Flash Player for Internet Explorer separately from Flash Player for their other open-source browsers. Google Chrome users, who have the integrated Flash Player, will still be updated through the Chrome update system.

Additionally, the user can change their update preferences at any time via the Flash Player Settings Manager, which for Windows users can be accessed via the Control Panel > Flash Player. In the Flash Player Settings Manager, the update preferences can be found and selected in the “Advanced” tab under “Updates.”

Organizations with managed environments do have the capability to disable the background updater feature through the Flash Player mms.cfg file. Also, those users who want to be notified of updates and do not want to be silently updated can continue to use the existing update mechanism. Lastly, the background updater feature is currently Windows-only for Windows XP and newer operating systems. A Mac version is currently under development.

I do want to note that we are not promising that all Flash Player updates going forward will be completely silent. We will be making the decision to silently install on a case-by-case basis. For instance, any update that changes the default settings of Flash Player will require confirmation from end-users even if they have already agreed to allowing background updates. Today’s update is an example of where confirmation would be required since we are changing how updates get applied to the user’s machine. However, we could apply a zero-day patch without requiring end-user confirmation, so long as the user has agreed to receiving background updates. Adobe will also continue to release feature-bearing releases that will trigger an update notification to users that highlight new and exciting features to the Flash Player.

The new background updater will provide a better experience for our customers, and it will allow us to more rapidly respond to zero-day attacks. This model for updating users is similar to the Google Chrome update experience, and Google has had great success with this approach. We are hoping to have similar success.

One last note

Since Flash Player 11 was first released in September 2011, we have continued to maintain Flash Player 10.3 with security updates for users who cannot update to the current version of Flash Player. In support of Microsoft’s initiative to get the world to drop Internet Explorer 6 and upgrade to a newer version of Internet Explorer for a safer browsing experience, Adobe will be dropping support for Internet Explorer 6 starting with today’s release of Flash Player 10.3.

While we will no longer include testing on Internet Explorer 6 in our certification process and strongly encourage users to upgrade to the newest version of Internet Explorer, we will not block the installation of newer versions of Flash Player 10.3 on systems running Internet Explorer 6 and expect functionality on those systems to remain unchanged.

Digital Signatures with PIV and PIV-I Credentials

In response to Homeland Security Presidential Directive (HSPD) 12, NIST created a program for improving the identification and authentication of Federal employees and contractors to Federal facilities and information systems.  This program is Federal Information Processing Standard (FIPS) 201, entitled Personal Identity Verification (PIV) of Federal Employees and Contractors, which as of September 2011 had issued over 5 million credentials.  PIV-I expands the interoperable secure PKI credentialing to Non-Federal Issuers (NFI) so that other organizations seeking identity federation can include their own employees.  Currently approved PIV-I providers include DigiCert, Entrust, Operational Research Consultants, VeriSign/Symantec, and Verizon Business.  The CertiPath bridge also supports PIV-I credential providers such as Citi and HID.

If you have a PIV or PIV-I card, and are interested in digitally signing documents for consent/approval signatures or certified publishing – Adobe Acrobat and Adobe Reader will automatically validate digital signatures via US Federal Common Policy.  Through the Adobe Approved Trust List  (AATL) program, the following trust anchors are included in version 9 and higher:

  • Common Policy — 2010 expiry — Common Hardware, Common High, Medium HW CBP
  • Common Policy — 2027 expiry — Common Hardware, Common High, Medium HW CBP
  • Federal Common Policy CA — 2030 expiry — Common Hardware, Common High, Medium HW CBP, SHA1 Hardware
To have the digital signature automatically validate for any recipient, whether or not they have a PIV/PIV-I credential, the signer’s system must build a complete certificate chain for path validation to reach one of the supported trust anchors.  If the signer’s system only has the signer’s certificate – it will not validate for anyone else automatically.  A recommendation to make this easier is for all of the issuing certificate authority public key certificates to be stored on the smartcard and available to the OS+applications.  That way the card can be truly portable and sign documents on any system.  Otherwise, the system administrator will need to ensure all of the certificates are otherwise installed into the OS and available to Adobe Acrobat/Reader.
As an example, below is an overview of configuring digital signatures with the HID PIV-I service.
After the customer application is approved and credentials are being issued, the user will need to install the chain of certificates on their signing systems.  The certificates required are:
  1. HIDSigningCA1
  2. HIDRootCA1
  3. Federal Bridge CA
  4. CertiPath Bridge CA – G2

There are several ways these certificates can be installed.  The easiest is to open the attached file HID_PIV-I_AdobeConfiguration.pdf, which provides a simplified installation experience into Adobe Acrobat and Adobe Reader.  You can also download the FDF directly here:  HID-PIV-I-Certs-AdobeReader.fdf

Now you can sign a PDF file and it will automatically validate for anyone with Acrobat or Reader version 9.1 or higher.

Sample HID PIV-I Signature document digitally signed with a production HID PIV-I card looks like this:

Here is the path that the digital signature follows for validation:

FIPS Validation Certificate for LiveCycle ES3

Adobe LiveCycle ES3 includes a FIPS 140 Certified RSA BSAFE Crypto-J 3.5 (cert#590) encryption module.  FIPS mode is configured in the product installer.

What is a Certified Document and when should you use it?

A Certified Document provides PDF document and forms recipients with added assurances of its authenticity and integrity.  Here are two frequent uses cases for Certified Documents that illustrate these capabilities:

  1. You publish files and want the recipients to know that the files really did originate from you and they have not been accidentally or maliciously modified since you published them.
  2. You distribute electronic forms with pre-populated information, and want to make sure recipients are not accidentally or maliciously modifying your form data when returning them to you.

To certify a document,you can use Acrobat on the desktop or LiveCycle Digital Signatures as part of an automated process on a server.  To verify the certification on a document, desktop users simply open PDFs with the free Adobe Reader or Adobe Acrobat.  If you would like an automated process to verify certified documents on a server, LiveCycle Digital Signatures can also verify certified document status.

When a document has valid certification, a blue ribbon in a blue bar will show above the document in the viewer, like this:

In this case, the document originated from the United States Government Printing Office.  It was published as part of an automated Adobe LiveCycle process, and the source document is publicly available here (http://www.gpo.gov/fdsys/pkg/BILLS-106s761enr/pdf/BILLS-106s761enr.pdf) as part of their Federal Digital System which has very specific requirements on authentication when publishing official US Government documents to the public.  In 2008, the Executive Office of the President, Office of Management and Budget (OMB) stated the White House was no longer ordering hard copy paper versions of the US Federal budget, and instead has posted certified PDF documents online.

Certified documents are also implemented at Antwerp Port Authority for electronic invoices and at a number of higher education institutions for delivering student transcripts electronically, including Penn State, Northwestern, Stanford, and more.

In addition to static documents, certifying a document increases the level of security in electronic forms workflows.  Here is an example:
a) Organization generates a form for recipient to complete and return
b) Form contains some specific transactional information, like an interest rate (3%) and term (15yrs).
c) Recipient decides they will change the rate and term to be more favorable, and then digitally signs it and returns it.

Typically, the form publisher would have to manually review every completed form to look for such errors, and they can often be overlooked.  The better solution is to certify the form as it is published to the recipient.  The added assurances here are that the recipient knows it’s an official form that hasn’t been tampered with, and when the publishing organization receives a completed and signed form back – they know that what was sent out has not been changed along the way.  The certification also allows the form author/publisher to specify which fields and form elements are locked, and which can be filled in by the recipient.

Here is an example of a certified form:

The source PDF file is available here as a Sample.

In either of these cases, if an unauthorized change is made to a certified document, the blue ribbon will turn to a red X – indicator.

More information on automating digital signatures for documents and forms is available in this previous post (LiveCycle Digital Signatures: Three Common Use Cases)

Certified documents utilize PKI and digital signatures to provide the assurances of authenticity and integrity.  These are capabilities built into the ISO 32000 standard PDF specification as well as Adobe Acrobat, Reader, and LiveCycle.  Adobe products utilize FIPS certified encryption implementations of RSA and SHA hashing algorithms (up to RSA4096 and SHA512).  The publisher/signer utilizes their private key certificate to sign documents on the desktop (Acrobat) or server (LiveCycle) and recipients simply use Acrobat or Reader to view them.

Recommendations and best practices:

A. Make sure your signing certificate is trusted by your recipient community.  This can be accomplished in several ways:

1) Utilize the Adobe CDS/AATL program, where certificates are automatically trusted and the recipients have zero configuration to validate digital signatures.  You can either obtain a certificate from a registered Adobe provider, or if you meet the strict program requirements – have your certificate authority automatically trusted.  NOTE: If you are publishing documents to the general public, CDS/AATL is the only recommended option.

2) Utilize enterprise install and management capabilities to push out trust anchors in pre-configured installations as well as maintained on an internal server

3) Utilize an enterprise desktop configuration setting to trust the existing certificate store in the operating system (e.g. Windows CAPI)

B) When certifying a document, make sure that all certificates from the trust chain are available on the signing system (desktop or server).  This includes not only the end-entity signing certificate, but also any intermediate certificates up to the trust anchor.  That way, the recipient only needs to have the trust anchor, as described in the previous section.

C) When publishing a certified document with a digital signature, make sure you are online and able to reach the revocation information published by the certificate authorities.  That way, long term validation (LTV) information is stored in the document.  If this information is not included, the certified document will no longer validate after a signing certificate expires.

D) By default certified documents utilize the system clock as a date/time indicator.  If you have higher assurance needs for time, utilize an RFC3161 based timestamp authority as part of the digital signature process

CanSecWest 2012

The team and I are about to head off to CanSecWest. While I have been attending CanSecWest for several years, this year will be a unique experience for me. During my talk, I will demo an open-source tool I just released, called Adobe SWF Investigator. The tool can be useful for developers, quality engineers and security professionals for analyzing SWF applications. It has been a pet project of mine for some time, and I decided to share it with a broader audience.

Within my current role, I have to look at all aspects of SWF applications from cross-site scripting issues to binary analysis. Therefore, the tool includes capabilities to perform everything from testing cross-site scripting to viewing the individual SWF tags within the file format. I am hoping that by releasing the tool as an open-source ActionScript application, it will encourage all ActionScript developers to learn more about security. The tool is designed to be an extensible framework everyone can build upon or modify. More information on the tool can be found in my DevNet article.

In addition to demonstrating the tool, I will also be talking about Advanced Persistent Response. Adobe has been the focus of hackers for some time, and I plan to discuss what we have learned and observed in the process of responding to those threats. My talk will be on Wednesday at 3:30pm, if you are interested. When I am not speaking, you can probably find me and the Adobe team either at the Adobe table or milling around the pwn2own contest for no particular reason. Please feel free to come by and talk with us. See you there!

When Do I Need to Apply This Update – Adding Priority Ratings to Adobe Security Bulletins

How urgently do I need to apply this update? That’s the most common question we get from customers in managed environments when we release a security bulletin. Our current severity ratings do a good job of objectively describing the worst-case scenario involved with a security issue, but they do not necessarily tell a customer all they need to know about the risk and priority of a particular security update. All critical security updates are not created equal. For example, if a Flash Player issue is being exploited in the wild, the update to resolve the vulnerability deserves a much higher priority than, say, a patch for a critical vulnerability in Photoshop. After all, Flash Player is a browser-based plugin with hundreds of millions of customers. Photoshop, on the other hand, has a much smaller customer base and would require significant social engineering to successfully exploit the product. So we started to wonder, how can we communicate the priority of our security updates more effectively?

We want to be as simple and direct as possible about the real-world risk associated with the vulnerabilities addressed in any given security update, and we decided that adopting a separate priority ranking scheme was the best way to accomplish this. Here is the priority scheme we are planning to use to rank security updates in the future:

Priority 1 Priority 2 Priority 3
This update resolves vulnerabilities being targeted, or which have a higher risk of being targeted, by exploit(s) in the wild for a given product version and platform. Adobe recommends administrators install the update as soon as possible. (for instance, within 72 hours). This update resolves vulnerabilities in a product that has historically been at elevated risk. There are currently no known exploits. Based on previous experience, we do not anticipate exploits are imminent. As a best practice, Adobe recommends administrators install the update soon (for instance, within 30 days). This update resolves vulnerabilities in a product that has historically not been a target for attackers. Adobe recommends administrators install the update at their discretion.

We’re going to base our priority ranking on historical attack patterns for the relevant product, the type of vulnerability, the platform(s) affected, and any potential mitigations that may be in place. This is a new system, so we may find that adjustments will need to be made. We also believe that continuing to use the current severity ratings makes sense, since this information has been helpful to many customers, so you can expect to see both ratings being used in future security bulletins.

We look forward to your feedback. Our goal is to help our customers in managed environments prioritize updates, so we’ll see if this new priority ranking scheme works to accomplish that! As we have been emphasizing a lot recently, the majority of attacks we are seeing are exploiting software installations that are not up-to-date with the latest security updates, so as always we recommend that users keep their software installations updated with the latest version of Adobe software.

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!

Buzz from Kaspersky SAS 2012

Hello world! Karthik here from Adobe Product Security Incident Response Team (PSIRT) engineering. Last week, I got to attend the Kaspersky Security Analyst Summit 2012 in Cancun, which was a melting pot of great security research and ideas. It was wonderful to meet researchers from industry and government and discuss Adobe’s security activities, such as product security incident response and product vulnerability sharing in the Microsoft Active Protections Program (MAPP). Thanks for listening and sharing your ideas. Let’s keep the conversation going.

On a lighter note, Team Adobe—consisting of Brad Arkin, Domingo Montanaro (general manager at iSIGHT Partners Brazil) and me—bagged the “Security Jeopardy” competition at the event on Friday evening. The winning answer only our team could come up with, ironically: “What is ‘zero knowledge.’”

SAS 2012 Security Jeopardy Winners

Until the next conference!

Karthik

Flash Player Sandboxing is Coming to Firefox

Peleus here. In December of 2010, I wrote a blog post describing the first steps towards sandboxing Flash Player within Google Chrome. In the blog, I stated that the Flash Player team would explore bringing sandboxing technology to other browsers. We then spent 2011 buried deep within Adobe laying the groundwork for several new security innovations.

Today, Adobe has launched a public beta of our new Flash Player sandbox (aka “Protected Mode”) for the Firefox browser. The design of this sandbox is similar to what Adobe delivered with Adobe Reader X Protected Mode and follows the same Practical Windows Sandboxing approach. Like the Adobe Reader X sandbox, Flash Player will establish a low integrity, highly restricted process that must communicate through a broker to limit its privileged activities. The sandboxed process is restricted with the same job limits and privilege restrictions as the Adobe Reader Protected Mode implementation. Adobe Flash Player Protected Mode for Firefox 4.0 or later will be supported on both Windows Vista and Windows 7. We would like to thank the Mozilla team for assisting us with some of the more challenging browser integration bugs. For Flash Player, this is the next evolutionary step in protecting our customers.

Sandboxing technology has proven very effective in protecting users by increasing the cost and complexity of authoring effective exploits. For example, since its launch in November 2010, we have not seen a single successful exploit in the wild against Adobe Reader X. We hope to see similar results with the Flash Player sandbox for Firefox once the final version is released later this year. In the meantime, please help us get these protections out to end-users as fast as possible by volunteering to download our beta and help test. Information on known bugs, configuration options and other information can be found on Adobe Labs in the “Getting Started” section.

P.S.: I will be speaking at CanSecWest on this and other exciting topics. I hope to see everyone there!