Author Archive: Peleus Uhley

The Simplest Form of Secure Coding

Within the security industry, we often run into situations where providing immediate security guidance isn’t straightforward. For instance, a team may be using a new, cutting edge language that doesn’t have many existing security tools or guidelines available. If you are a small startup, then you may not have the budget for the enterprise security solutions. In large organizations, the process of migrating a newly acquired team into your existing tools and trainings may take several weeks. What advice can we give to those teams to get them down the road to security today?

In these situations, I remind them to go back to their original developer training. Many developers are familiar with the term “technical debt which refers to the “eventual consequences of poor system design, software architecture or software development within a codebase.” Technical security debt is one component of an application’s overall technical debt. The higher the technical debt is for an application, the greater the chance for security issues. Moreover, it’s much easier to integrate security tools and techniques into code that has been developed with solid processes.

To a certain extent, the industry has known this for awhile. Developers like prepared statements because pre-compiled code runs faster, and security people like it because pre-compiled code is less injectable. Developers want exception handling because it makes the web application more stable and they can cleanly direct users to a support page which is a better user experience. Security people want exception handling so that there is a plan for malicious input and because showing the stack trace is an information leak. However, let’s take this a step further.

If you search the web for “Top 10″ lists for developer best practices and/or common coding mistakes, then you will see there’s a clear overlap in traditional coding principles and security principles across all languages.  For example, the Modern IE  Cross Browser Development Standards & Interoperability Best Practices is written for developers and justifies these points using concepts that are important to clean development. However, I can go through the same list and justify many of their points using security concepts. Here are just a few of their recommendations and how they relate to security:

  • Use a build process with tools to check for errors and minify files. On the security side, establishing this will enable you to more easily integrate security tools into the build process.
  • Always use a standards-based doctype to avoid Quirks Mode. Quirks Mode makes it easier to inject XSS vulnerabilities into your site.
  • Avoid inlineJavaScript tags in HTML markup. In security, avoiding inlineJavaScript makes it easier to support Content Security Policies.

Switching to Ruby on Rails, here’s a list of the 10 Most Common Rails Mistakes and how to avoid them so developers can create better applications. When you look at those errors from a security perspective, you will also see overlaps:

  • Common Mistake #1-3: Putting too much logic in the controller/view/model. These three points all deal with keeping your code cleanly designed for better maintainability. Security is a common reason for performing code maintenance. Often times, your response to active attacks against your system will be slowed down because the code cannot be easily changed or is too complex to identify a single validation point.

    This section also reminds us that the controller is the recommended place for first-level session and request parameter management. This allows for high-level sanity checking before the data makes it into your model.

  •   Common Mistake #5: Using too many gems. Controlling your third-party libraries also helps to limit your attack surface and reduce the maintenance costs of keeping them up-to-date for security vulnerabilities.
  •   Common Mistake #7: Lack of automated tests. As mentioned in the HTML lists, using an automated test framework enables you to also include security tests. This blog refers to use techniques such as BDD for which there are also Ruby-based BDD security frameworks like Gauntlt.
  •  Common Mistake #10: Checking sensitive information into source code repositories. This is clearly a security rule. In this example, they are referring to a specific issue with Rails secret tokens. However, this is a common mistake for development in general. Separating credentials from code is simply good coding hygiene – it can prevent an unintended leak of the credential and permit a credential rotation without having to rebuild the application.

Even if you go back to a 2007 article in the IBM WebSphere Developer Technical Journal on The Top Java EE Best Practices, which is described as a “best-of-the-best list of what we feel are the most important and significant best practices for Java EE,” then you will see the same themes being echoed within the first five principles of the list:

  •   Always use MVC.This was also mentioned in the Rails Top 10. Centralized development allows for centralized validation.
  •  Don’t reinvent the wheel. This is true for security, as well. For instance, don’t invent your own cryptography library wheel!
  •  Apply automated unit tests and test harnesses at every layer. Again, this will make it easier to include security tests.
  •  Develop to the specifications, not the application server.This point highlights the importance of not locking your code into a specific version of the server. One of the most frequent issues large enterprises struggle with is migrating from older, vulnerable platforms, because the code is too dependent on the old environment.This concept is also related to #16 in their list, “Plan for version updates”.
  • Plan for using Java EE security from Day One. The idea here is similar to “Don’t reinvent the wheel.” Most development platforms provide security frameworks that are already tested and ready to use.

As you can see, regardless of your coding language, security best practices tend to overlap with your developer best practices. Following them will either directly make your code more secure or make it easier to integrate security controls later. In meetings with management, developers and security people can be aligned in requesting adequate time to code properly.

It’s true that security-specific training will always be necessary for topics such as authentication, authorization, cryptography, etc. And security training certainly shows you how to think about your code defensively which will help with application logic errors. However, a lot of the low-hanging bugs and security issues can be caught by following basic good, old-fashioned coding best practices. The more you can control your overall technical debt, the more you will control your security debt.

Peleus Uhley
Lead Security Strategist

An Overview of Behavior Driven Development Tools for CI Security Testing

While researching continuous integration (CI) testing models for Adobe, I have been experimenting with different open-source tools like Mittn, BDD-Security, and Gauntlt. Each of these tools centers around a process called Behavior Driven Development (BDD). BDD enables you to define your security requirements as “stories,” which are compatible with Scrum development and continuous integration testing. Whereas previous approaches required development teams to go outside their normal process to use security tools, these frameworks aim to integrate security tools within the existing development process.

None of these frameworks are designed to replace your existing security testing tools. Instead, they’re designed to be a wrapper around those security tools so that you can clearly define unit tests as scenarios within a story. The easiest way to understand the story/scenario concept is to look at a few examples from BDD-Security. This first scenario is part of an authentication story. It verifies that account lockouts are enforced by the demo web application:

Scenario: Lock the user account out after 4 incorrect authentication attempts
Meta: @id auth_lockout
Given the default username from: users.table
And an incorrect password
And the user logs in from a fresh login page 4 times
When the default password is used from: users.table
And the user logs in from a fresh login page
Then the user is not logged in

The BDD frameworks take this human readable statement about your security policy and translates it into a technical unit test for your web application penetration testing tool. With this approach, you’re able to phrase your security requirements for the application as a true/false statement. If Jenkins sees a false result from this unit test, then it catches the bug immediately and can flag the build. In addition, this human readable approach to defining unit tests allows the scenarios to double as documentation. An auditor can quickly read through the scenarios and map them to a threat model or policy requirement.

In order to interact with your web site and perform the log in, the framework will need a corresponding class written in a web browser automation framework. The BDD example above used a custom class that leverages the Selenium 2 framework to navigate to the login page, find the login form elements, fill in their values and have the browser perform the submit action. Selenium is a common tool for web site testers so your testing team may already be familiar with it or similar frameworks.

Writing custom classes that understand your web site is good for creating specific tests around your application logic. However, you can also perform traditional spidering and scanning tests as in this second example from BDD-Security:

Scenario: The application should not contain Cross Site Scripting vulnerabilities
Meta: @id scan_xss
#navigate_app will spider the website
GivenStories: navigate_app.story
Given a scanner with all policies disabled
And the Cross-Site-Scripting policy is enabled
And the attack strength is set to High
And the alert threshold is set to Medium
When the scanner is run
And false positives described in: tables/false_positives.table are removed
Then no Medium or higher risk vulnerabilities should be present

For the BDD-Security demo, the scanner that is used is the OWASP ZAP proxy. Although, BDD frameworks are not limited to tests through a web proxy. For instance, this example from BDD-Security shows how to run Nessus and ensure that the scan doesn’t return with anything that is severity 2 (medium) or higher:

Scenario: The host systems should not expose known security vulnerabilities

Given a nessus server at https://localhost:8834
And the nessus username continuum and the password continuum
And the scanning policy named test
And the target hosts
|hostname |
|localhost  |
When the scanner is run with scan name bddscan
And the list of issues is stored
And the following false positives are removed
|PluginID   |Hostname   |  Reason                                                                      |
|43111      |127.0.0.1    |  Example of how to add a false positive to this story  |
Then no severity: 2 or higher issues should be present

There are a lot of good blogs and presentations (1,2,3) that further explain the benefits of BDD approaches to security, so I won’t go into any further detail. Instead, I will focus on three current tools and highlight key differences that are important to consider when evaluating them.

Which BDD Tool is Right for You?

To start, here is a quick summary of the tools at the time of this writing:

Mittn Gauntlt BDD-Security
Primary Language Python Ruby Java
Approximate Age 3 months 2 years 2 years
Commits within last 3 months yes yes yes
BDD Framework Behave Cucumber jbehave
Default Web App Pen Test Tools Burp Suite, radamsa Garmr, arachni, dirb, sqlmap, curl Zap, Burp Suite
Default SSL analysis sslyze heartbleed, sslyze TestSSL
Default Network Layer Tools N/A nmap nessus
Windows or Unix Unix Unix** Both

** Gauntlt’s ‘When tool is installed” statement is dependent on the Unix “which” command. If you exclude that statement from your scenarios, then many tests will work on Windows.

If you plan to wrap more than the officially supported list of tools or have complex application logic, then you may need custom sentences, known as “step definitions.” Modifying step definitions is not difficult. Although, once you start modifying code, you have to consider how to merge your changes with future updates to the framework.

Each framework has a different approach to their step definitions. For instance, BDD-Security tends to encourage formal step definition sentences in all their test cases which would require code changes for custom steps. With Gauntlt you can store additional step definition files in the attack_adapters directory. Gauntlt also provides flexibility through a few generic step definitions that allow you to check the output of arbitrary raw command lines, as seen in their hello world example below:

Background:
Feature: hello world with gauntlt using the generic command line attack
  Scenario:
    When I launch a “generic” attack with:
      “””
      cat /etc/passwd
      “””
    Then the output should contain:
      “””
      root
      “””

Similarly, you should also consider how the framework will handle false positives from the tools. For instance, Mittn allows you to address the situation by tracking them in a database. BDD-Security allows you to address false positives statements within the scenario, as seen in the Nessus example from above or in a separate table. Gauntlt’s approach is to leverage “should not contain” statements within the scenario.

Since these tools are designed to be integrated into your continuous integration testing frameworks, you will want to evaluate how compatible they will be and how tightly you will need them integrated. For instance, quoting Continuum Security’s BDD introduction:

BDD-Security jobs can be run as a shell script or ant job. With the xUnit and JBehave plugins the results will be stored and available in unit test format. The HTML reports can also be published through Jenkins.

Mittn is also based on Behave and can produce JUnit XML test result documents. Gauntlt’s default output is handled by Cucumber. By default, Gauntlt supports pretty StdOut format and HTML output but you can modify the code to get JUnit output. There is an open improvement request to allow JUnit through the config file. Guantlt has documentation for Travis integration, as well.

Overall, the tools were not difficult to deploy. Gauntlt’s virtual box demo environment in its starter kit can be converted to be deployed via Chef in the cloud with a little work. When choosing a framework, you should also consider the platform support of the security tools you intend to use and the platform of your integrated testing environments. For instance, using a GUI-based tool on a Linux server will require an X11 desktop to be installed.

All of these tools have promise depending on your preferences and needs. BDD-Security would be a good tool for web development teams who are familiar with tools like Selenium and want tight integration with their processes. Gauntlt’s ability to support “generic” attacks makes it a good tool for teams that want to use a wide array of tools in their testing. Mittn is the youngest entry and doesn’t yet have features like built-in spidering support. Although, Python developers can easily find libraries for spidering sites, and Mittn’s external database approach to tracking issues may be useful for teams who have other systems that need to be notified of new results.

Before adopting one of these tools, an organization will likely do a buy-vs.-build analysis with commercial continuous monitoring offerings. For those who will be presenting the build argument, these tools provide enough to make a solid case in that discussion.

Where these frameworks add value is by allowing you to take your existing security tools (Burp, Nessus, etc.) and make them a part of your daily build process. By integrating with the continuous build system, you can immediately identify potential issues and ensure a minimum baseline of security. The scenario-based approach allows you to map requirements in your security policy to clearly defined unit tests. This evolution of open-source security frameworks that are designed to directly integrate with the DevOps process is an exciting step forward in the maturity of security testing.

Peleus Uhley
Lead Security Strategist

Retiring the “Back End” Concept

For people who have been in the security industry for some time, we have grown very accustomed to the phrases “front end” and “back end.” These terms, in part, came from the basic network architecture diagram that we used to see frequently when dealing with traditional network hosting:

 Picture1

The phrase “front end” referred to anything located in DMZ 1, and “back end” referred to anything located in DMZ 2. This was convenient because the application layer discussion of “front” and “back” often matched nicely with the network diagram of “front” and “back.”  Your web servers were the first layer to receive traffic in DMZ 1 and the databases which were behind the web servers were located in DMZ 2. Over time, this eventually led to the implicit assumption that a “back end” component was “protected by layers of firewalls” and “difficult for a hacker to reach.”

How The Definition Is Changing

Today, the network diagram and the application layer diagrams for cloud architectures do not always match up as nicely with their network layer counterparts. At the network layer, the diagram frequently turns into the diagram below:

 Picture2

In the cloud, the back end service may be an exposed API waiting for posts from the web server over potentially untrusted networks. In this example, the attacker can now directly reach the database over the network without having to pass through the web server layer.

Many traditional “back end” resources are now offered as a stand alone service. For instance, an organization may leverage a third-party database as a service (DBaaS) solution that is separate from its cloud provider. In some instances, an organization may decide to make their S3 buckets public so that they can be directly accessed from the Internet.

Even when a company leverages integrated solutions offered by a cloud provider, shared resources frequently exist outside the defined, protected network. For instance, “back end” resources such as S3, SQS and DynamoDB will exist outside your trusted VPC. Amazon does a great job of keeping its AWS availability zones free from most threats. However, you may want to consider a defense-in-depth strategy where SSL is leveraged to further secure these connections to shared resources.

With the cloud, we can no longer assume that the application layer diagram and the network layer diagrams are roughly equivalent since stark differences can lead to distinctly different trust boundaries and risk levels. Security reviews of application services are now much more of a mix of network layer questions and application layer questions. When discussing a “back end” application component with a developer, here are a few sample questions to measure its exposure:

*) Does the component live within your private network segment, as a shared resource from your cloud provider or is it completely external?

*) If the component is accessible over the Internet, are there Security Groups or other controls such as authentication that limit who can connect?

*) Are there transport security controls such as SSL or VPN for data that leaves the VPC or transits the Internet?

*) Is the data mirrored across the Internet to another component in a different AWS region? If so, what is done to protect the data as it crosses regions?

*) Does your threat model take into account that the connection crosses a trust boundary?

*) Do you have a plan to test this exposed “back end” API as though it was a front end service?

Obviously, this isn’t a comprehensive list since several of these questions will lead to follow up questions. This list is just designed to get the discussion headed in the right direction. With proper controls, the cloud service may emulate a “back end” but you will need to ask the right questions to ensure that there isn’t an implicit security-by-obscurity assumption.

The cloud has driven the creation of DevOps which is the combination of software engineering and IT operations. Similarly, the cloud is morphing application security reviews to include more analysis of network layer controls. For those of us who date back to the DMZ days, we have to readjust our assumptions to reflect the fact many of today’s “back end” resources are now connected across untrusted networks.

Peleus Uhley
Lead Security Strategist

 

 

 

The Cloud as the Operating System

The current trend is to push more and more of our traditional desktop tasks to the cloud. We use the cloud for file storage, image processing and a number of other activities.  However, that transition is more complex than just copying the data from one location to another.

Desktop operating systems have evolved over decades to provide a complex series of controls and security protections for that data. These controls were developed in direct response to increasing usage and security requirements. When we move those tasks to the cloud, the business requirements that led to the evolution of those desktop controls remain in place. We must find ways to provide those same controls and protections using the cloud infrastructure. When looking at creating these security solutions in the cloud, I often refer back to the desktop OS architectures to learn from their designs.

 

Example: File storage

File storage on the desktop is actually quite complex under the hood. You have your traditional user, group and (world/other/everyone) classifications. Each of these classifications can be granted the standard read, write and execute permissions. This all seems fairly straightforward.

However, if you dig a little deeper, permissions often have to be granted to more than just one single group. End users often want to provide access to multiple groups and several additional individuals. The operating system can also layer on its own additional permissions. For instance, SELinux can add permissions regarding file usage and context that go beyond just simple user level permissions. Windows can provide fine-grained permissions on whether you can write data or just append data.

There are several different types of usage scenarios that led to the creation of these controls. For instance, some controls were created to allow end users to share information with entities they do not trust. Other controls were driven by the need for services to perform tasks with data on the user’s behalf.

 

Learning from the Desktop

While the technical details of how we store and retrieve data changes when we migrate data to the cloud, the fundamental principles and complexities of protecting that data still persist. When planning your file sharing service, you can use the desktop as a reference for how complex your permissions may need to be as it scales. Will end users have complex file sharing scenarios with multiple groups and individuals? Will you have services that run in the background and perform maintenance on the user data? What permissions will those services need to process the data? These are hard problems to solve and you don’t want to reinvent these critical wheels from scratch.

Admittedly there is not always a direct 1:1 mapping between the desktop and cloud. For instance, the desktop OS gets to assume that the hard drive is physically connected to the CPU that will do the processing. In the cloud, your workers or services may be connecting to your cloud storage service across untrusted networks. This detail can add additional authentication and transport level security controls on top of the traditional desktop controls.

Overall, the question that we face as engineers is how can we best take the lessons learned from the desktop and progress them forward to work in a cloud infrastructure. File storage and access is just one aspect of the desktop that is being migrated to the cloud. Going forward, I plan to dig deeper into this idea and similar topics that I learn from working with Adobe’s cloud teams.

Peleus Uhley
Lead Security Strategist

A First Experiment with Chef

Security professionals are now using cloud solutions to manage large-scale security issues in the production Ops workflow. In order to achieve scale, the security processes are automated through tools such as Chef. However, you can also leverage the automation aspects of the cloud regardless of whether or not you plan to scale it to hundreds of machines. For example, one of my first cloud projects was to leverage Chef to resolve a personal, small scale issue where I might have previously used a VM or separate machine.

Using the cloud for personal DevOps

At Adobe, we’re constantly hiring third party security consultants to test our products. They require environments for building and testing Adobe code, and they need access to tools like Cygwin, Wireshark, SysInternals, WinDbg, etc. For my personal testing, I also require access to machines with a similar set up.  Using the cloud, it is possible to quickly spin up and destroy these types of security testing environments as needed.  

For this project, I used Adobe’s private cloud infrastructure – which is just an implementation detail – this approach can work on any cloud infrastructure. Our IT department also provides an internal Chef server for hosting cookbooks and managing roles.

In order to connect the Chef server and the cloud environment, I decided to set up a web server which would copy the Chef config files to the cloud instance and launch chef-client. For this, I chose Windows IIS, C# and ASP.NET because I had an unrelated goal of learning more about WMI and PowerShell through a coding project. Vagrant for Windows would be an alternative to this approach but it wasn’t available when I began the project. My personal Linux box was used to write the Chef recipes and upload the cookbook to the Chef server.

The workflow of the set-up process is as follows:

1.    Request a new Windows 7 64-bit instance from the cloud and wait for the response saying it is ready.

2.    The user provides the domain name and administrator password for the Windows 7 instance to the web page. If I need to set up additional accounts on the machine, I can also collect those here and run command lines over WMI to create them.

 3.   Using the admin credentials, the web server issues a series of remote WMI calls to create a PowerShell script on the Windows 7 instance. WMI doesn’t allow you to directly create files on remote machines, so I had to use “echo” and redirect the output.

 4.   By default, Windows doesn’t allow you to run unsigned PowerShell scripts. Although, with admin privileges you can use a command line to disable the signature check before executing the script. Once the script was done, the signature check is re-enabled.

 5.    The PowerShell script will download the client.rb file and validator.pem key needed to register the Windows 7 instance with the chef server.

 6.   WMI can then be used to run the chef-client command line which will register the new Windows 7 instance with the chef-server.

 7.    Since chef requires a privileged user to assign roles to the Win7 node, a separate chef key and a copy of the knife utility are stored locally on the web server. The C# server code will execute knife using the privileged key to assign the appropriate role to the new Windows 7 node in Chef.

 8.    Lastly, the web server uses WMI to run chef-client on the Windows 7 instance a second time so that the recipes are executed. The last chef recipe in the list will create a finished.txt file on the file system that the web server can verify that the process is completed.

Lessons Learned from Writing the Recipes

Using Chef, I was able to install common tools such as WinDbg, Cygwin (with custom selected utilities), SysInternals, Wireshark, Chrome, etc. Chef can be used to execute VBScript which allowed me to accomplish tasks such as running Windows Update during the setup process. For most recipes, the Opscode Windows cookbook made writing the recipes fairly straightforward.

Some of the installers will require a little legwork. For instance, you may have to search the web for the command line flags necessary for silent install. If you cannot automatically download an installer from the web, then the installers can be stored on the Chef server along with the recipes. For Wireshark, it was necessary to download and install winpcap before downloading and installing Wireshark. One client installer was not Chef-friendly, which lead to the creation of a Chef script that would have Windows Task Scheduler install the software instead. 

As a specific example, Cygwin can be one of the more complicated installs because it is a four-step process. There are some public cygwin recipes available for more advanced installs but this is enough to get it installed just using the Opscode Windows cookbook. For a robust deployment, additional code can be added to ensure that it doesn’t get run twice if Cygwin is already installed. The demo workflow below uses windows_package to download the setup executable. The windows_batch commands will then run the executable to install the default configuration, download additional utilities and then install the additional utilities:

 include_recipe “windows”

 windows_package ‘cygwin64′ do
     source ‘http://cygwin.com/setup-x86_64.exe
     installer_type :custom
     action :install
     options ‘–download –quiet-mode –local-package-dir c:\\cygwin_downloads –root c:\\cygwin64 -s http://mirror.cs.vt.edu/pub/cygwin/cygwin/’
end

windows_batch ‘cygwin_install_from_local_dir‘ do
code <<-EOH

    #{Chef::Config[:file_cache_path]}/setup-x86_64.exe –local-install –quiet-mode –local-package-dir c:\\\\cygwin_downloads –root c:\\\\cygwin64

   #{Chef::Config[:file_cache_path]}/setup-x86_64.exe –download –quiet-mode –local-package-dir c:\\\\cygwin_downloads –root c:\\\\cygwin64 -s http://mirror.cs.vt.edu/pub/cygwin/cygwin/ –packages vim,curl,wget,python,cadaver,rats,nc,nc6,git,subversion,flawfinder,stunnel,emacs,openssh,openssl,binutils

   #{Chef::Config[:file_cache_path]}/setup-x86_64.exe –quiet-mode –local-package-dir c:\\\\cygwin_downloads –root c:\\\\cygwin64 -s http://mirror.cs.vt.edu/pub/cygwin/cygwin/ –packages vim,curl,wget,python,cadaver,rats,nc,nc6,git,subversion,flawfinder,stunnel,emacs,openssh,openssl,binutils -L

    Exit 0
EOH
end

Post-Project Reflections

There are definitely alternative approaches such as using a baseline VM snapshot or a pre-built AMI with all of these tools installed. They each have their own pros and cons. For instance, local VMs launch faster but the scaling is limited by disk space. I chose Chef recipes because it provides the flexibility to create custom builds and ensures that everything is current. If needed, the system is able to scale quickly. The extra work in writing the server meant that I could make the process available to other team members.

Overall, despite having to be creative with some recipes, the project didn’t require a huge investment of time. A large portion was written while killing time in airports. The fact that I was able to go from a limited amount of knowledge to a working implementation fairly quickly speaks to the ease of Chef. If you are interested in learning more about the cloud, you don’t need a large, massively scalable project in order to get your hands dirty. It is possible to start with simple problems like creating disposable workstations.

PeleusUhley
Lead Security Strategist

Approaching Cloud Security From Two Perspectives

Last month, I was in Amsterdam to give a talk at SecureCloud 2014, a conference hosted by the Cloud Security Alliance. The conference attendees included a number of governmental policy-makers, and provided an opportunity for people from around the world to discuss the future of cloud computing security.

This conference was co-sponsored by the European Union Agency for Network and Information Security, or ENISA. They are actively working toward assisting Europe in adopting cloud technologies and simplifying governmental regulations across Europe. Therefore, they were able to attract representatives from several governments to share ideas on leveraging the cloud for the betterment of Europe.

EU Governments are Adopting Cloud Technology

To set context for the state of cloud adoption, Udo Helmbrecht, the Executive Director of ENISA, shared this slide during his presentation depicting the deployment model of government clouds in different countries. This information was from ENISA’s  Good Practice Guide for securely deploying Governmental Clouds

EU Slide

 

According to their numbers, at least 14 EU countries have developed a national cloud strategy or digital agenda. The European Commission is spearheading a number of initiatives, such as “Unleashing the Potential of Cloud Computing in Europe“, aimed at encouraging further uptake of cloud computing services in the EU, both in the public and private sector. ENISA is working together with the European Council on several of those initiatives such as defining the role of cloud certification schemes.

One example of governments taking advantage of the cloud was given by Evangelos Floros, the product manager for Okeanos. Okeanos is a public cloud built for the Greek academic and research community. In addition, Arjan de Jong presented on how the Dutch government is experimenting with a closed, government cloud for internal use. If their experiment is successful, then they will progress towards expanding the scale of their cloud offerings. Many of the presentations from SecureCloud can be found on their website.

A Different Perspective from Amsterdam

It was interesting to see all the different top-down, government perspectives from policy-makers at the CSA SecureCloud conference last month. This month, I will be back in Amsterdam for the Hack in the Box conference and Haxpo. This will be a very different group of people who help secure the Internet from the bottom up through innovative exploit techniques and secure implementations. Karthik Raman and I will be presenting there on the topic of securing cloud storage. Our presentation will involve a mix of cloud strategy as well as some technical implementation solutions. If you are attending, please come by our talk or the Adobe booth to say hello.

Peleus Uhley
Lead Security Strategist

 

 

ColdFusion 11 Enhances the Security Foundation of ColdFusion 10

Tuesday marked the release of ColdFusion 11, the most advanced version of the platform to date. In this release, many of the features introduced in ColdFusion 10 have been upgraded and strengthened, and developers will now have access to an even more extensive toolkit of security controls and additional features. 

A few of the most significant ColdFusion 11 upgrades fall into three categories. The release includes advances in the Secure Profile feature, access to more OWASP tools, and a host of new APIs and development resources.

1.       More OWASP Tools

 In ColdFusion 11, several new OWASP tools have been added to provide more integrated security features. For instance, features from the AntiSamy project have been included to help developers safely display controlled subsets of user supplied HTML/CSS. ColdFusion 11 exposes AntiSamy through the new getSafeHTML() and isSafeHTML().

In addition, ColdFusion 11 contains more tools from OWASP’s Enterprise Security API library, or ESAPI, including the EncodeForXPath and EncodeForXMLAttribute features. These ESAPI features provide developers more flexibility to update the security of existing applications and serve as a strong platform for new development.

2.       Flexible Secure Profile Controls

Secure Profile was a critical feature in ColdFusion 10, because it allowed administrators to deploy ColdFusion with secure defaults. In the ColdFusion 11 release, admins have even more flexibility when deploying Secure Profile.

In ColdFusion 10, customers had the choice to enable secure install or not, only at the time of installation,depending on their preferences. But with ColdFusion 11, customers now have the ability to turn Secure Profile off or on after installation, whenever they’d like, which streamlines the lockdown process to prevent a variety of attacks.

Further improvements to the Secure Profile are documented here.

3.       Integrating Security into Existing APIs

 ColdFusion 11 has many upgraded APIs and features – but there are a few I’d like to highlight here. First, ColdFusion 11 includes an advanced password-based key derivation function – called PBKDF2 – which allows developers to create encryption keys from passwords using an industry-accepted cryptographic algorithm. Additionally, the cfmail feature now supports the ability to send S/MIME encrypted e-mails. Another ColdFusion 11 update includes the ability to enable SSL for WebSockets. More security upgrade information can be found in the ColdFusion 11 docs.

Overall, this latest iteration of the platform increases flexibility for developers, while enhancing security. Administrators will now find it even easier to lock down their environments. For information on additional security features please refer to the Security Enhancements (ColdFusion 11) page and the CFML Reference (ColdFusion 11).

Peleus Uhley
Lead Security Strategist

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

 

Mass Customization of Attacks Talk at RSA

Business consultant Stanley Davis defined mass customization as the “customization and personalization of products and services for individual customers at a mass production price.” Anyone who has ever ordered a custom PC is no stranger to mass customization: that particular combination of components wasn’t assembled into a PC until the customer initiated an order.

As we responded to zero-day exploits in the past couple of years, we took stock of some of the properties that separated them from mass malware, which affect older, patched vulnerabilities. For example, we noticed zero-day attacks starting to target more than one version of a platform on one or more operating systems. In addition, we observed that zero-day attacks contain more than one exploit possibly affecting multiple vendors’ products. Our thesis can be stated as follows: The exploit creation industry is maturing; by combining the features of mass malware with multiple zero-day exploits, they can create mass-customized attacks.

 masscustomizedattacks

 

We expand on this thesis in our upcoming talk at the RSA 2014 conference and use several case studies to prove it.

If you’re going to be attending RSA on Tuesday, Feb. 25, please swing by our talk at 2:40 p.m. in the West Room 3006. We look forward to sharing our research and the conversations with our friends and partners in the industry!

Peleus Uhley, Platform Security Strategist
Karthik Raman, Security Researcher

Flash Player Sandbox Now Available for Safari on Mac OS X

Over the last few years, Adobe has protected our Flash Player customers through a technique known as sandboxing. Thus far, we have worked with Google, Microsoft and Mozilla on deploying sandboxes for their respective browsers. Most recently, we have worked with Apple to protect Safari users on OS X. With this week’s release of Safari in OS X Mavericks, Flash Player will now be protected by an OS X App Sandbox.

For the technically minded, this means that there is a specific com.macromedia.Flash Player.plugin.sb file defining the security permissions for Flash Player when it runs within the sandboxed plugin process. As you might expect, Flash Player’s capabilities to read and write files will be limited to only those locations it needs to function properly. The sandbox also limits Flash Player’s local connections to device resources and inter-process communication (IPC) channels. Finally, the sandbox limits Flash Player’s networking privileges to prevent unnecessary connection capabilities.

Safari users on OS X Mavericks can view Flash Player content while benefiting from these added security protections. We’d like to thank the Apple security team for working with us to deliver this solution.

Peleus Uhley
Platform Security Strategist