Posts in Category "Security"

Reflections on Pwn2Own

Returning from CanSecWest left me reflecting on how the Pwn2Own competition has evolved over time. A lot has changed in the Pwn2Own competition over the years. The event has grown in attendance, competitors, and complexity, just as the industry has grown.

For the first contest in 2007, no one competed on the first day. Shane McCauley called fellow security researcher Dino Dai Zovi in NYC that night and urged him to compete. Dino was able to write the exploit over night and win the contest on the second day. Visually, the attacks seem no different from year to year. The contestant sits down at the machine, and “seconds” later the calculator (or notepad in this year’s case), pops up on the screen.  However, the preparation for the attacks from 2007 to 2016 are now drastically different, with contestants preparing attacks weeks in advance.

Media coverage around security advisories is often just a run down of how many CVEs a vendor released that month. People often imply from these articles that all the CVEs are easily exploitable and trivially weaponizable. This can lead to false perceptions that exploiting the software is a simple task. In reality, a CVE from a vendor is not a guarantee of exploitability. Even if the CVE can give the attacker the ability to overwrite memory, that is not a guarantee that it can be weaponized. Technologies such as ASLR (Address Space Layout Randomization) weren’t even released for Mac OS X when Dai Zovi competed in 2007. Today’s attackers have to work around defenses such as CFG (Control Flow Guard), Isolated Heaps, and a number of other technologies designed to prevent a crash from becoming an exploit.

In addition, competitors have to deal with the fact that the contest frequently occurs after Patch Tuesday where a vendor’s security improvements could interfere with their attack. Adobe has been aggressively adding mitigations to Flash Player over the last few months. In our release the week before the contest, we added changes to zero memory more often and leveraged the Windows’ low fragmentation heap. Both Adobe and Google found that some of the contestant’s entries overlapped with recent security reports. Part of the reason for the increasing payouts for the winners comes from the fact that the targets for the competition all have active security teams and external communities that are constantly working to improve the platform. As the community and vendors continue to mature their software, bug or mitigation collisions become more of a material risk for competitors. While it may not seem like it on the surface, the attackers are trying to hit moving targets.

The Flash Player updates prior to the contest led to some failed attempts at the competition. The failed attempts were by teams who had already won under different categories. Therefore, the competitors were clearly highly skilled and had already proven themselves to be capable of weaponizing exploits for the target platform. The reality is that what they are attempting to do is not easy and the failures serve to remind us how hard it is to get those wins. When any competition gets to a certain level, even the most skilled players are going to experience some losses.

That said, the contest always has its share of winners. Those wins demonstrate that there is always more that vendors can do in order to improve security. While the individual bugs help, Pwn2Own is truly valuable because it shows how different researchers will try to bypass the existing mitigations to create the fully weaponized exploit. That insight into different attack approaches inspires us as vendors to come up with the next generation of defenses.

Like many pros, the winning contestants always make it look easy. Although, as an industry we are often too quick to lump everything in the same “it is easy because it is completely vulnerable” bucket. Companies like Adobe, Microsoft, and Google are in a constant sprint with attackers. The security industry has progressed from the days of just trying to write clean, well validated code. Today, we are adding in large platform features that serve no other purpose than trying to thwart attackers. These types of features are added at an increasingly frequent basis. The companies who are on the front line of this battle will change and grow over time. It is important for those vying to one day be on the defender’s side of Pwn2Own to understand the current table stakes.

Overall, Pwn2Own is a fun contest to interact with security researchers and to push the industry forward. Beneath the high level pageantry of smoking jackets and large prizes, is a low-level escalation between offensive and defensive strategists. While the visual results from watching in the room seem similar from year to year, the innovation and challenge required to achieve those results increases every year.

Peleus Uhley
Principal Scientist

Adobe @ Women in Cybersecurity 2016

Adobe was a supporter of the Women in Cybersecurity (WiCys) conference again this year. This year’s conference was organized by Tennessee Tech and held in Dallas, Texas. We had a great experience over the three days of the conference which saw women from across industry and academia come together to discuss important security topics and encourage more women to pursue careers in security. Adobe was joined by several major industry peers including Google, Facebook, Cisco, and IBM.

The conference provided a good mix of technical and non-technical sessions. First off was a keynote by Heather Adkins, Director of Information Security at Google. She talked a little bit about how she became the first woman hired in an operational role at Google and also the first woman on Google’s corporate security team. She then discussed her ideas for structuring an incident response organization. Key components of a good incident response organization per Ms. Adkins are: 1) Figure out what happened (forensics), 2) Are we still under attack (Monitoring), 3) Who did it (Threat intelligence), and 4) Restoring the business (Remediation). It was helpful to hear how another large peer organization like Google handles incident response.

One of the workshop sessions we found most interesting was on the topic of “Big Data Analytics for Cyber Security Applications.” It discussed how to leverage big data frameworks in the field of cyber security. The workshop taught us how to create smaller data sets from the huge amount of threat intelligence information received nowadays and process the data sets using tools such a Hadoop or Spark. It also described the varying levels of sanitization and risk associated with using different malware data sets. Data sets in academia are highly sanitized, and low risk, but typically out-of-date. Research data sets are moderately sanitized and have moderate risk associated with download, but are more current. Individual malware collections are the least sanitized, and have the most risk associated with download, but are up-to-date. Adversaries are thus actively modifying their patterns of behavior to avoid detection (polymorphism) – so multiple techniques and tools are needed to adapt our defenses.

We particularly enjoyed the non-technical sessions that included women leaders in the industry talking about their career journey and how they got to where they are today. Particularly impressive was the talk by Shelley Westman, VP of Operations and Strategic Initiatives, from IBM. Shelley talked about the various stages of her career and experiences as a woman at each of those stages. Shelley also discussed the importance of building relationships with male allies who will support opportunities for women in the workplace.

The conference also had some great networking opportunities during the social events hosted by several companies. We got a chance to attend one hosted by Facebook and participate in a “lean-in” circle conversation. We also attended the Cisco event where we had great interactions with their security team and got to learn more about their security and trust organization.

It was a great conference again this year and we’re happy that Adobe continues to support organizations working to make more opportunities available for women in our industry.

Disha Agarwal
Product Security Manager

Jeanette Azevedo
Security Engagement Specialist

Adobe Security Team Members Win Recent CTF Competition

Kriti and Abhiruchi from our corporate security team in Noida, India, were crowned the winners of the recent Winja Capture the Flag (CTF) competition hosted at the NullCon Goa security conference. Twelve (12) teams competed in this year’s contest. We would like to congratulate Kriti and Abhiruchi on their win. Adobe is an ongoing sponsor of the Nullcon conference. This competition was created by women to encourage their peers to enter the field of cybersecurity. It is a complete set of simulated web application security hacking challenges. Each challenge is separated into small tasks that can be solved individually by the competitors on each team. Each team works through the timed two (2) hour duration of the event in an attempt to attack and defend the computers and networks using prescribed tools and network structures.

Adobe is a proud supporter of events and activities encouraging women to pursue careers in cybersecurity. We are also sponsoring the upcoming Women in Cybersecurity conference March 31st to April 2nd in Dallas, Texas. Members of our security team will be there at the conference. If you are attending, please take the time to meet and network with them.

David Lenoe
Director, Product Security

New Security Framework for Amazon Web Services Released

The Center for Internet Security, of which Adobe is a corporate supporter, recently released their “Amazon Web Services Foundations Benchmark.” This document provides prescriptive guidance for configuring security options for a subset of Amazon Web Services with an emphasis on foundational, testable, and architecture agnostic settings. It is designed to provide baseline suggestions for ensuring more secure deployments of applications that utilize Amazon Web Services. Our own Cindy Spiess, web security researcher for our cloud services, is a contributor to the current version of this framework. Adobe is a major user of Amazon Web Services and efforts like this further our goals of educating the broader community on security best practices. You can download the framework document directly from the Center for Internet Security.

Liz McQuarrie
Principal Scientist & Director, Cloud Security Operations

Applying the SANS Cybersecurity Engineering Graduate Certification to Adobe’s Secure Product Lifecycle (part 2 of 2)

In the first part of this series I discussed how the SANS Cybersecurity Engineering Graduate Certificate helped me analyze the Heartbleed vulnerability and how it applied to static code analysis. This resulted in the paper “The Role of Static Analysis in Heartbleed.” Now I’ll focus on what was learned in the final part of the program and how we can apply this to our efforts here at Adobe.

The course on “Hacking Techniques and Incident Response” taught some of the techniques that attackers use to compromise systems. It also provided an overview of  the forensic tools that are used to detect those attacks. In addition to the labs, students were given access to the NetWars platform. NetWars is a simulated cyber range where you can practice offensive and defensive cybersecurity techniques against live systems. Practical hands on experience is key when doing incident response and the platform facilitates this learning. The highlight of the week was being able to use the NetWars system in a competition format solving real-world problems.

The final course on “Advanced Network Intrusion Detection and Analysis” started with “bit bootcamp” and explored the lower levels of the networking stack. We were taught how to decode packets and truly understand all of the network communication that is occurring on a given computing device. The second part of the class was focused on learning how to deploy network utilities like Snort, Bro, and Silk for network analysis. The SANS at Night talks were also very useful as they allowed me to hear about recent vulnerabilities faced by the security industry as a whole and discuss potential solutions.

There were numerous techniques taught in both of these classes and through Netwars that were directly relevant to working on Adobe Photoshop and our related Creative Cloud services. While I was familiar with Charles and BurpSuite to do web session debugging, these classes allowed me to truly understand how to use deeper features of these tools to determine types of traffic being sent across the network. They also helped me understand when and how to carve the network traffic in order to focus on a smaller set of packets which can then be manually inspected in tools like Wireshark. These tools are great for testing for accidental information disclosure as well as proper authorization checks on cookies.

Taking the techniques learned during professional development and applying them directly to a set of problems on the job is the best you can hope for in any training.  The tools and information  from these classes has already helped in our ongoing efforts to make Photoshop a more secure product.

Jeff Sass
Engineering Manager, Photoshop
GSEC, GCIH, GCIA

Better Security Through Automation

Automation Strategies

“Automate all the things!” is a popular meme in the cloud community. Many of today’s talks at security conferences discuss the latest, sophisticated automation tool developed by a particular organization. However, adding “automation” to a project does not magically make things better by itself. Any idea can be automated; including the bad ones. For instance, delivering false positives “at scale” is not going to help your teams. This blog will discuss some of the projects that we are currently working on and the reasoning behind their goals.

Computer science has been focused on automation since its inception. The advent of the cloud only frees our ideas from being resource bound by hardware. However, that doesn’t necessarily mean that automation must take up 100 scalable machines. Sometimes simple automation projects can have large impacts. Within Adobe, we have several types of automation projects underway to help us with security. The goals range from business-level dashboards and compliance projects to low level security testing projects.

 

Defining goals

One large project that we are currently building is a security automation framework focused on security assertions. When you run a traditional web security scanner against a site, it will try to tell you everything about everything on the site. In order to do that effectively, you have to do a lot of pre-configuration (authentication, excluded directories, etc.). Working with Mohit Kalra, the Sr, Security Manager for the ASSET security team, we experimented with the idea of security assertions. Basically, could a scanner answer one true/false question about the site with a high degree of accuracy? Then we would ask that one simple question across all of our properties in order to get a meaningful measurement.

For instance, let’s compare the following two possible automation goals for combating XSS:

(a) Traditional automation: Give me the location of every XSS vulnerability for this site.

(b) Security assertion: Does the site return a Content Security Policy (CSP) header?

A web application testing tool like ZAP can be used to automate either goal. Both of these tests can be conducted across all of your properties for testing at scale. Which goal you choose will decide the direction of your project:

Effort to implement:

(a) Potentially requires effort towards tuning and configuration with a robust scanner in order to get solid results. There is a potential risk to the tested environment (excessive DB entries, high traffic, etc.)

(b) A straight forward measurement with a simple scanner or script. There is a low risk to the tested environment.

Summarizing the result for management:

(a) This approach provides a complex measurement of risk that can involve several variables (reflected vs. persistent, potential value of the site, cookie strategy, etc.). The risk that is measured is a point-in-time assessment since new XSS bugs might be introduced later with new code.

(b) This approach provides a simple measurement of best practice adoption across the organization. A risk measurement can be inferred but it is not absolute. If CSP adoption is already high, then more fine grained tests targeting individual rules will be necessary. However, if CSP adoption is still in the early stages, then just measuring who has started the adoption process can be useful.

Developer interpretation of the result:

(a) Development teams will think in terms of immediate bugs filed.

(b) Development teams will focus on the long term goal of defining a basic CSP.

Both (a) and (b) have merits depending on the needs of the organization. The traditional strategy (a) can give you very specific data about how prevalent XSS bugs are across the organization. However, tuning the tools to effectively find and report all that data is a significant time investment. The security assertion strategy (b) focuses more on long term XSS mitigations by measuring CSP adoption within the organization. The test is simpler to implement with less risk to the target environments. Tackling smaller automation projects has the added value of providing experience that may be necessary when designing larger automation projects.

Which goal is a higher priority will depend on your organization’s current needs. We found that, in playing with the true/false approach of security assertions, we focused more of our energy on what data was necessary versus just what data was possible. In addition, since security assertions are assumed to be simple tests, we focused more of our design efforts on perfecting the architecture of scalable testing environment rather than the idiosyncrasies of the tools that the environment would be running. Many automation projects try to achieve depth and breadth at the same time by running complex tools at scale. We decided to take an intermediate step by using security assertions to focus on breadth first and then to layer on depth as we proceed.

 

Focused automation within continual deployment

Creating automation environments to scan entire organizations can be a long term project. Smaller automation projects can often provide quick wins and valuable experience on building automation. For instance, continuous build systems are often a single chokepoint through which a large portion of your cloud must pass before deployment. Many of today’s continuous build environments allow for extensions that can be used to automate processes.

As an example, PCI requires that code check-ins are reviewed. Verifying this process is followed consistently requires significant human labor. One of our Creative Cloud security champions, Jed Glazner, developed a Jenkins plugin which can verify each check-in was reviewed. The plugin monitors the specified branch and ensures that all commits belong to a pull request, and that the pull requests were not self merged. This allows for daily, automatic verification of the process for compliance.

Jed worked on a similar project where he created a Maven plug-in that lists all third-party Java libraries and their versions within the application. The plugin would then upload that information to our third-party library tracker so that we can immediately identify libraries that need updates. Since the plug-in was integrated into the Maven build system, the data provided to the third-party library tracker was always based on the latest nightly build and it was always a complete list.

 

Your organization will eventually build, buy or borrow a large scale automation tool that scales out the enumeration of immediate risk issues. However, before you jump head first into trying to build a robust scanning environment from scratch, be sure to first identify what core questions you need the tools to answer in order to support your program. You might find that starting with smaller automation tasks that track long term objectives or operational best practices can be just as useful to an organization. Deploying these smaller projects can also provide experience that can help your plans for larger automation projects.

 

Peleus Uhley
Principal Scientist

Improving Security for Mobile Productivity with Adobe Document Cloud

Recently Adobe announced that it is working with Microsoft to help improve security of mobile applications and productivity. We have integrated Adobe Acrobat Reader DC with Microsoft Intune, a solution for secure enterprise mobile application management. This gives I.T. management and security professionals more control over critical productivity applications deployed to their mobile device users. This functionality is currently available for Android devices and will soon be made available for iOS devices.

Our work with Microsoft is part of Adobe’s overall commitment to help keep our customers’ critical assets and data secure. We will continue to work with Microsoft and other security community partners to improve security across our products and services.

For more information about this solution, please see our post on the Adobe Document Cloud blog.

Bronwen Matthews
Sr. Product Marketing Manager, Security

Hacktoberfest 2015

Autumn has arrived, and National Cybersecurity Awareness Month with it. We wanted to celebrate and raise awareness about security at Adobe. What could be better than bringing hands on training, a capture the flag competition and beer together in a single day across the world? That is exactly what we did and we called it Hacktoberfest.

Around 160 people in the US, Europe and India came together on October 14th to take part in a full day focused on security. The day progressed from a broad, hands-on threat modeling training to learning tools like Burp Suite to a Capture the Flag event for prizes.

We saw a lot of new faces at this event; no doubt due to the prizes offered for the capture the flag. There was also a diverse skill set present in the room; from people in nontechnical roles to those that have a lot of experience pen testing internally. We learned that our community is hungry for training and a deeper understanding of security. All of the material, except for one training, was developed in-house.

When most people’s interaction with security training is spent with computer-based training, there is great value in bringing people together in a face-to-face event where they can interact not only with the trainers, but also with each other. While we’ve done smaller, more targeted trainings in the past, this was the first truly global event.

People really loved the hands on nature of the day, we had responses like: “I thought the capture the flag event was incredibly fun and engaging.” and “I liked the demonstration on how to use Burp Suite to attack a service/site.”

One of the unique aspects of the day was its global nature. Essentially two events were run, one in the US time zones and one in India. We did our best to create the same experience for the two groups while paying attention to their different content needs. All presentations were local and questions could be answered in real time.

Of course, the most popular event of the day was the Capture the Flag event. One of our researchers, took it upon himself to create an environment to host the game. It’s called WOPR and we will be providing more information on it soon. Two other researchers worked to create the challenges for the game.

There was quite a lot of energy in all of those conference rooms as people engaged with the training and the competition. The most important lesson we learned from this exercise is that people at Adobe, all around the world, care about securing our products.

 

Josh Kebbel-Wyen
Sr. Security Program Manager, Training

Security Collaboration at Adobe

At Adobe we recognize that our customers benefit when we take a collaborative approach to vulnerability disclosure.  We pride ourselves on the symbiotic relationship we’ve cultivated with the security community and continue to value the contributions that security researchers of all stripes make to hardening our software.

As a measure of the value we place in external code reviews and security testing, Adobe interfaces with the security community through a spectrum of engagement models, including (but not limited to):

  • Traditional third-party code reviews and pen-tests
  • Crowd-sourced pen-tests
  • Voluntary disclosures to our Product Security Incident Response Team (PSIRT)
  • Submissions to our web application disclosure program on HackerOne

Code reviews and pen-tests

Before Adobe introduces a major upgrade or new product, feature or online service offering, a code review and pen-test is often performed by an external security company.  These traditional third-party reviews provide a layer of assurance to complement our internal security assessments and static code analysis that are part of our Secure Product Lifecycle (SPLC).

Crowd-sourced pen-tests

To benefit from a larger pool of security researchers, Adobe also uses crowd-sourced pen-tests in tightly scoped, time-bound engagements involving an elite pool of pen-testers targeting a single service offering or web application.   This approach has helped supplement the traditional pen tests against our online services by increasing code coverage and testing techniques.

Disclosures to PSIRT

The Product Security Incident Response Team (PSIRT) is responsible for Adobe’s vulnerability disclosure program, and typically responds first to the security community’s submissions of vulnerabilities affecting an Adobe product, online service or web property.  In addition to its role as conduit with external researchers, PSIRT partners with both internal and external stakeholders to ensure vulnerabilities are handled in a manner that both minimizes risk to customers and encourages researchers to disclose in a coordinated fashion.

Disclosures via HackerOne

In March 2015, Adobe launched its web application vulnerability disclosure program on HackerOne.  This platform offers researchers the opportunity to build a reputation and learn from others in the community, while allowing vendors to streamline workflows and scale resources more effectively.

As new bug hunting and reporting platforms enable part-time hobbyists to become full-time freelance researchers, we look forward to continuing a constructive collaboration with an ever-widening pool of security experts.

 

Pieter Ockers
PSIRT Security Program Manager

Disha Agarwal
Product Security Manager

Recap: BlackHat 2015 and r00tz@DefCon 2015

This year Adobe security team members were out in force attending BlackHat 2015 and – new this year – helping inspire the next generation of security professionals at the r00tz @ DefCon conference for kids. Adobe was a major sponsor of the r00tz conference this year helping to set up and run a 3D printing workshop and hackfest for the young attendees.

BlackHat brings together the top experts in the security field to discuss and expose current issues in the information security industry. While there were a variety of talks covering a wide breadth of topics, here are some talks that stood out to us during our time there.

In the discussion panel “Is the NSA Still Listening to Your Phone Calls?” Mark Jaycox from the Electronic Frontier Foundation (EFF) and Jamil Jaffer, former member of the House Permanent Select Committee on Intelligence (HPSCI), talked about government surveillance, and the tradeoffs between keeping our privacy and using surveillance to defend against current threats. It was interesting to see two people on opposite sides of the spectrum openly discussing this complex issue. I felt that by listening to the two parties discuss their points I was able to walk away with a more informed opinion on the current stance of government surveillance in the country today.

James Kettle from Portswigger talked about server side template injection and showed techniques to identify and exploit it on popular template engines such as FreeMarker, Velocity, Twig and Jade. This vulnerability occurs when users are allowed to edit templates or untrusted user input is embedded in the template. It was interesting to see how this vulnerability can be used to directly attack web servers and perform remote code execution instead of cross site scripting. The talk raised awareness on the damage one can do if an application is vulnerable to template injection. Our researchers and security champions will be able to apply the information gained from this talk to identify and mitigate template injection in Adobe products.

In “The Node.js Highway: Attacks are at Full Throttle” talk, Maty Siman and Amit Ashbel discussed the security issues and demonstrated new attack techniques against Node.js applications. The attack on pseudo random number generator in Node.js which allows an attacker to predict the next number given 3 consecutive numbers was quite interesting. This means an application generating password using PRNG might reveal the passwords of all the users. The talk educated our researchers and security champions on new vulnerabilities to look for while reviewing a Node.js application.

In addition to all of the great learnings and networking at BlackHat 2015, many from our team stayed around after BlackHat to attend DefCon and help out at the r00tz @ DefCon conference for kids. This was Adobe’s first year sponsoring the r00tz conference. With the help of our awesome Photoshop engineering teams, we were able to get kid-ready workstations set up with our creative tools and hooked up to cool MakerBot 3D printers. It was a lot of fun helping kids take all of the ideas in their heads and translate them into physical objects they could then take home with them – with, of course, a lot of hacking involved to get many of the ideas to work. In addition to our 3D printing workshop, there were other exercises including a capture the flag contest and robot building contest. It was very rewarding for all of us to sponsor and be a part of inspiring these kids to pursue careers in technology.

 

Tim Fleer
Security Program Manager

Karthik Thotta Ganesh
Web Security Researcher