Posts in Category "Security"

Join Us at ISSE EU in Brussels October 14 – 15!

Adobe will be participating again this year in the ISSE EU conference in Brussels, Belgium, Oct. 14-15, 2014. This conference attracts senior decision makers in IT Security from a wide range of industries and governmental organizations. There are numerous sessions tackling many of the current hot topics in security including cloud security, identity management, the Internet of Things (IoT), data protection & privacy, compliance & regulation, and the changing role of IT Security professionals adapting to these changes. 

Adobe will be talking about a few of our security initiatives and programs during the event, specifically highlighting our security training program which I currently manage. The materials from this program now form the basis of the open-source, free security training program from SAFECode (https://training.safecode.org). Many organizations have now used these materials to develop their own security training programs. I will be available on-site to answer questions about these programs. 

We will also have three sessions during the conference. Director of Product Security David Lenoe will present a keynote presentation on “Maintaining a Security Organization That Can Adapt to Change” on Tuesday, Oct. 14, at 11:45 a.m. According to Forrester Research, “51 % of organizations said it’s a challenge or major challenge to hire security staff with the right skills” – and keeping them happy, productive, and nimble is also a major challenge. This session will discuss Adobe’s approach to addressing these issues in our organization that we believe may provide valuable insight into handling these issues in your own organization. 

On Tuesday at 3:10 p.m., Mohit Kalra, senior manager for secure software engineering, will provide insight into “Deciding the Right Metrics & Dashboards for Security Success.” This session will discuss what makes a “good” security roadmap and then how to properly measure and share progress against that roadmap to help ensure success.  

Last but not least, on Wednesday, Oct. 15, at 2:40 p.m. I will discuss how “Building Security In Takes Everyone Thinking Like a Security Pro.” While we realize this is a mouthful, it’s probably best description I can give for the goal of the ASSET Certification Program (http://blogs.adobe.com/security/2013/05/training-secure-software-engineers-part-1.html) at Adobe. We as an industry not only need to increase our security fluency, we also need to have people that can look at the product they are working on with a hacker’s eye and raise a flag when they see something that may become an issue in the future.  

In this talk, I will spend most of the time dedicated to the experiential elements of the program that gives us the ability to build our experts. For example, people have taught themselves how to perform manual penetration testing. On the flip side there are a lot of projects where candidates have created ways to automate scanning or other processes. One of the more innovative projects was the creation of the Hackfest (http://blogs.adobe.com/security/?s=hackfest&submit=). As one security champion, Elaine Finnell, puts it, “For myself, pursuing the brown belt (in the program) has pushed me beyond simply absorbing information and into doing. Similar to how a science classroom has a lab, putting the information I learn both during the training and during outside trainings into practice helps to solidify my understanding of security principles. While I’m still not an expert on executing penetration testing, fuzzing, or architecture analysis, every experience I have doing this type of work alongside experts serves to improve my ability to be a security champion within my team.”

I love to talk about this stuff. I’ll be available in Adobe’s booth on the expo floor and if you’re going to be there, so please hit me up. I’m also available on Twitter – @JoshKWAdobe. More information about the training program can also be found in our new white paper available at http://www.adobe.com/content/dam/Adobe/en/security/pdfs/adobe-security-training-wp-web.pdf and on the Security@Adobe blog (http://blogs.adobe.com/security/2013/05/training-secure-software-engineers-part-1.html).

You can follow @AdobeSecurity for the latest happenings during ISSE EU as we will be live tweeting during the event – look for the hashtag #AdobeISSE. Also, more information about all of our security initiatives can be found at http://www.adobe.com/security.   

 


Josh Kebbel-Wyen 

Senior Security Program Manager 

Top 10 Hacking Techniques of 2013: A Few Things to Consider in 2014

For the last few years, I’ve been a part of the annual ranking of top 10 web hacking techniques organized by WhiteHat Security. Each year, it’s an honor to be asked to participate, and this year is no different. Not only does judging the Top 10 Web Hacking Techniques allow me to research these potential threats more closely, it also informs my day-to-day work.

WhiteHat’s Matt Johansen and Johnathan Kuskos have provided a detailed overview of the top 10 with some highlights available via this webinar.  This blog post will further describe some of the lessons learned from the community’s research.

1. XML-based Attacks Will Receive More Attention

This year, two of the top 15 focused on XML-based attacks. XML is the foundation of a large portion of the information we exchange over the Internet, making it an important area of study.

Specifically, both researchers focused on XML External Entities. In terms of practical applications of their research, last month Facebook gave out their largest bug bounty yet for an XML external entity attack. The Facebook attack demonstrated an arbitrary file read that they later re-classified as a potential RCE bug.

Advanced XML features such as XML external entities, XSLT and similar options are very powerful. If you are using an XML parser, be sure to check which features can be disabled to reduce your attack surface. For instance, the Facebook patch for the exploit was to set libxml_disable_entity_loader(true).

In addition, JSON is becoming an extensively used alternative to XML. As such, the JSON community is adding similar features to the JSON format. Developers will need to understand all the features that their JSON parsers support to ensure that their parsers are not providing more functionality than their APIs are intended to support.

2. SSL Takes Three of the Top 10 Spots

In both the 2011 and 2012 Top 10 lists, SSL attacks made it into the top spot.  For the 2013 list, three attacks on SSL made it into the top 10: Lucky 13, BREACH and Weaknesses in RC4. Advances in research always lead to more advances in research. In fact, the industry has already seen our first new report against SSL in 2014.  It will be hard to predict how much farther and faster research will advance, but it is safe to assume that it will.

Last year at BlackHat USA, Alex Stamos, Thomas Ptacek, Tom Ritter and Javed Samuel presented a session titled “The Factoring Dead: Preparing for the Cryptopocalypse.” In the presentation, they highlighted some of the challenges that the industry is facing in preparing for a significant breach of a cryptographic algorithm or protocol. Most systems are not designed for cryptographic agility and updating cryptography requires a community effort.

These three Top 10 entries further highlight the need for our industry to improve our crypto agility within our critical infrastructure. Developers and administrators, you should start examining your environments for TLS v1.2 support. All major browsers currently support this protocol. Also, review your infrastructure to determine if you could easily adopt future versions of TLS and/or different cryptographic ciphers for your TLS communication. The OWASP Transport Layer Protection Cheat Sheet provides more information on steps to hard your TLS implementation.

3. XSS Continues to Be a Common Concern for Security Professionals

We’ve known about cross-side scripting (XSS) in the community for over a decade, but it’s interesting that people still find innovative ways to both produce and detect it. At the most abstract level, solving the problem is complex because JavaScript is a Turing-complete language that is under active development. HTML5 and CSS3 are on the theoretical edge of Turing-Completeness in that you can implement Rule 110 so long as you have human interaction. Therefore, in theory, you could not make an absolute statement about the security of a web page without solving the halting problem.

The No. 1 entry in the Top 10 this year demonstrated that this problem is further complicated due to the fact that browsers will try to automatically correct bad code. What you see in the written code is not necessarily what the browser will interpret at execution. To solve this, any static analysis approach would not only need to know the language but also know how the browser will rewrite any flaws.

This is why HTML5 security advances such as Content Security Policies (CSP) and iframe sandboxes are so important (or even non-standards-based protections such as X-XSS-Protection).  Static analysis will be able to help you find many of your flaws. However, due to all the variables at play, they cannot guarantee a flawless site. Additional mitigations like CSP will lessen the real world exploitability of any remaining flaws in the code.

These were just a few of the things I noticed as a part of the panel this year. Thanks to Jeremiah Grossman, Matt Johansen, Johnathan Kuskos and the entire WhiteHat Security team for putting this together. It’s a valuable resource for the community – and I’m excited to see what makes the list next year.

Peleus Uhley

Lead Security Strategist

 

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, Part 2: Criteria, content and metrics

This is Part 2 in our series of posts on the Adobe ASSET Software Security Certification Program which formed the basis for the newly released SAFEcode security training. In the first post, I gave an overview of the program. This second post deals with the logistics of creating your own certification program or supplemental training, and tracking your progress.

Setting Criteria
As I mentioned in the previous post, the ASSET (Adobe Secure Software Engineering Team) certification program is a four-tiered system, where people earn a “belt” per level attained: white, green, brown and black. Let’s start with the first two belt levels – the computer based trainings (CBTs).

It was important to us that participants set their own pace for going through the training. We knew that an average developer or quality engineer would not want to sit in, nor get a lot out of an eight hour classroom session delivered in a single day. Long sessions aren’t scalable for what we were trying to achieve – that is, basic security training for people that need to know security concepts as part of their job, but don’t necessarily want to be security professionals. We wanted security to be a necessary skill-set of everyone involved in development at Adobe.

Our original criteria for the training is that it must:

  • Be around 30-40 minutes in length (we have since shortened our goal length to 15-20 minutes)
  • Employ as simple an approach to the concepts discussed as possible
  • Use real-life examples from Adobe code and web sites
  • Have direct bearing on the job functions of our audience

Creating the Content
Security topics were divided up among the researchers on the ASSET team. Researchers chose topics either based on their own areas of expertise or areas where they wanted to become stronger. A subset review team critiqued the training and helped create tests for each training module, consisting of 10 to 15 questions about the most important elements of the training modules. Content took about two weeks of research per topic and a week of revisions. The CBT’s (computer based training) consist of PowerPoint decks with recorded voice-overs and some animated demos. As examples, we used Adobe code to drive issues home to developers who may have created, or at least worked with similar code. Fortunately, Adobe has an excellent multi-use product called Adobe Connect that, among other things, can be used as a Learning Management System (LMS). We were lucky to be able to adopt something native to our company rather than have to re-train people to use something new.

Using Metrics
We wrote a web tool called Tessa to interface with Adobe Connect to allow people to check the status of their progress through the training and provide an automated way for managers to follow-up with team members about their certification status. Status is visible to anyone within the company, which is a subtle way of encouraging competition among teams and individuals.

Ninja blog post

Above is a screen shot for Brad Arkin’s org. The yellow buttons allow him to automatically send a “nag” email to any slackers in his org. Clicking on a yellow button opens his email client and populates a message with the appropriate content to the person he has selected to nag. That way, all he has to do is hit “send”.

Going Public
We’ve also used this data to pull reports on geographies and business units to help spur competition. We found that our biggest success comes from the India offices, which have about twice the compliance level of the US and Europe combined. People get so into the program that they have requested paper certificates, signed by CSO, Brad Arkin, which we then mail to them.

Ultimately, per product certification status rolls up to an overall “Security Health” dashboard which is reviewed by executives at quarterly operations meetings.

In my next post: Tips for supplementing the SAFEcode Software Security training or building your own.

Josh Kebbel-Wyen
Sr. Program Manager

 

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

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

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)

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)