In 2014, approximately 1 billion records of personably identifiable information were compromised as a result of cybersecurity vulnerabilities. In the face of this onslaught of compromises, it is important to examine fundamental insecurities that CERT researchers have identified and that readers of the CERT/CC blog have found compelling. This post, the first in a series highlighting CERT resources available to the public including blogs and notes, focuses on the CERT/CC blog. This blog post highlights security vulnerability and network security resources to help organizations in government and industry protect against breaches that compromise data.

The most visited posts on the CERT/CC blog center around a critical area of research: SSL Certificates as a core foundation of trust transmissions on the Internet along with certificates. These posts explore weaknesses in those trust relationships as implemented in mobile platforms and also highlight tools that have been created at CERT to explore those vulnerabilities. Before we take a deeper dive into SSL Certificates, let's take a look at the top 10 posts (as measured by number of visits) on the CERT blogs:

SSL Tools

The three most popular posts on the CERT blogs were written by CERT researcher Will Dormann and stemmed from his analysis of network traffic man-in-the-middle (MITM) techniques (HTTP and HTTPS) by using MITM tools/techniques. While there are plenty of MITM proxies, such as ZAP, Burp, Fiddler, mitmproxy, and others, Dormann wanted a transparent network-layer proxy, rather than an application-layer one. After a bit of trial-and-error investigation, he found a software combination that works well for this purpose, CERT Tapioca.

Dormann wrote The Risks of SSL Inspection, the most popular post on the CERT blogs, after he started examining the SuperFish and PrivDog vulnerabilities and realized that the SSL inspection techniques used by those two applications are similar to trusted enterprise software that performs SSL inspection. When he started looking into SSL inspection software in general, he realized that many of them are making mistakes that put clients at risk.

Here is an excerpt:

Recently, SuperFish and PrivDog have received some attention because of the risks that they both introduced to customers because of implementation flaws. Looking closer into these types of applications with my trusty CERT Tapioca VM at hand, I've come to realize a few things.
In this blog post, I will explain

1. The capabilities of SSL and TLS are not well understood by many.
2. SSL inspection is much more widespread than I suspected.
3. Many applications that perform SSL inspection have flaws that put users at increased risk.
4. Even if SSL inspection were performed at least as well as the browsers do, the risk introduced to users is not zero.

The complete post, The Risks of SSL Inspection, can be read here.

The CERT/CC post that Dormann wrote that introduced CERT Tapioca, is the second most visited post on the CERT/CC blog in the last six months. In that post, Dormann introduces CERT and takes readers through a test run using the tool.

Here is an excerpt:

Once you start performing MITM testing of HTTPS traffic, you hopefully will have a better idea of the level of trust that you should be giving HTTPS. Let's consider the situation where you type https:// and the domain name in your web browser's address bar for the site that you want to visit. If you don't get a certificate warning, what does that mean? It really just means that the certificate provided by the server was issued by any one of the root CAs trusted by your browser. For example, the current version of Mozilla Firefox comes pre-loaded with over 90 trusted root CAs. Any one of these sites may provide a dozen or more individual trusted root CA certificates.

If you are using a system that you don't manage, and you're relying on HTTPS to keep your web traffic from prying eyes, you may want to think twice. Just like we can silently intercept HTTPS traffic by having the mitmproxy root CA certificate installed, you must assume that enterprises with managed desktop systems are employing similar techniques to monitor traffic. It is their network, after all.

But it is also worth noting the impact the compromise of a single root CA can have. It's happened in the past with DigiNotar and Comodo. Without getting too sidetracked here, Moxie Marlinspike's blog entry SSL And The Future Of Authenticity goes into a good amount of detail about the problems with SSL and trust.

The complete post, Announcing CERT Tapioca for MITM Analysis, can be read here.

In Finding Android SSL Vulnerabilities with CERT Tapioca, a follow-up to the post introducing CERT Tapioca, Dormann introduces the use of CERT Tapioca in the automated discovery of SSL vulnerabilities in Android applications.

Here is an excerpt:

As mentioned in my previous blog post, one of the uses of CERT Tapioca is discovering applications that fail to properly validate SSL certificates for HTTPS connections. As a proof-of-concept experiment, I took an Android phone and loaded some apps onto it. By bridging the "inside" network adapter of Tapioca to a wireless access point, I was able to create a WiFi hotspot that would automatically attempt to perform MITM attacks on any associated client.

Using a physical phone worked fine, and I was able to easily and quickly test a handful of apps. The problem is that this sort of testing environment doesn't scale. The Google Play store currently has about 1.3 million applications, of which about 1 million are free. If it takes me 60 seconds to test each application, and if I've done my math correctly, it would take me a bit over 8 years to test each free Android application, assuming that I put in a 40 hour week for 52 weeks a year. While it was fun to test a handful of applications, I'm pretty sure that I would get bored before I made it through all of them. And I'd like to think that there are more valuable uses of my time.

Automation to the Rescue

Computers are great for performing tedious, boring work. Why not let them do the work? So how can we automate testing Android applications?

First, I started with the Android Emulator that comes with the Android SDK. I installed it in a Linux virtual machine and created an Android virtual device. Because ARM Android is emulated rather than virtualized, it's very slow. So after the Android Virtual Device (AVD) completely powered up, I took a snapshot of the powered-on Linux virtual machine that it was running in.

I also had an instance of CERT Tapioca providing network connectivity to the Android Emulator VM. The inside network adapter of Tapioca was connected to the same virtual network as the adapter for the Android Emulator VM.

With that done, I wanted to control the AVD as well as the Linux OS running it.

The complete post, Finding Android SSL Vulnerabilities with CERT Tapioca, can be read here.

The remainder of this SEI blog post highlights the most visited posts on the CERT/CC blog in the area of vulnerability discovery.

Vulnerability Discovery

By paying greater attention to the early phases of the development lifecycle, CERT researchers aim to change the nature of the software development process to detect and eliminate--and later avoid--vulnerabilities before products are released. We work to achieve this goal by placing knowledge, techniques, and tools in the hands of software vendors to help them understand how vulnerabilities are created and discovered so that they can learn to avoid them. CERT researchers have developed a suite of tools to help vendors make more secure software. As the post below illustrates, researchers also try to help improve the public's understanding of security concepts.

In the post Differences Between ASLR on Windows and Linux, Dormann explains how one of the major exploit mitigations (ASLR) is different on the Windows platform vs. Linux.

Here is an excerpt from the post:

A program or library that is linked with the /DYNAMICBASE option will be compatible with ASLR on Windows. According to the Windows ISV Software Security Defenses document:

In general, ASLR has no performance impact. In some scenarios, there's a slight performance improvement on 32-bit systems. However, it is possible that degradation could occur in highly congested systems with many images that are loaded at random locations. The performance impact of ASLR is difficult to quantify because the quantity and size of the images need to be taken into account. The performance impact of heap and stack randomization is negligible.

For this reason, there really is no reason to link anything without the /DYNAMICBASE option, which enables ASLR. With /DYNAMICBASE enabled, a module's load address is randomized, which means that it cannot easily be used in Return Oriented Programming (ROP) attacks. When it comes to Windows applications, we recommend that all vendors use both DEP and ASLR, as well as the other mitigations outlined in the Windows ISV Software Security Defenses document. If vendors have not elected to use /DYNAMICBASE, users have the ability to force ASLR through the use of Microsoft EMET.

The complete post Differences Between ASLR on Windows and Linux, can be read here.

In the post Vulnerability Coordination and Concurrency Modeling, CERT researcher Allen Householder highlights recent work in the area of cybersecurity information sharing and the ways it can succeed or fail. In the introduction, Householder explains that in vulnerability discovery and cybersecurity information sharing work, he often learns the most by examining the failures in part because the successes are often just cases that could have failed, but didn't.

Here is an excerpt from the post:

One of the first things you notice when you start thinking about vulnerability coordination is that there are more ways for it to go wrong than there are for it to go right. But we'll get to that. It all starts with a vulnerability (vul). Let's leave aside how that vul got there. We don't really care. It's simply a given for our model.

Oh, right, we haven't talked about models yet. Well, in this post I'm using Petri nets to demonstrate the coordination process. Petri nets are a way of modeling systems that operate with concurrency, and concurrency is often mentioned as one of the most challenging aspects of modern system engineering.

If you've never seen a Petri net before, here is a quick introduction:

• Petri nets model distributed processes as a network of nodes and arcs.
• Nodes can be either places (circles), or transitions (boxes).
• Arcs (arrows) connect places to transitions and vice versa. Places can't connect to places, and transitions can't connect to transitions.
• Places can hold tokens, which mark the state of a process.
• Transitions represent events that change the state of the process. A transition can fire when all the places immediately upstream of it are occupied by tokens (i.e., when it is enabled). When a transition fires, it consumes tokens from its inputs and places tokens in its outputs.

The complete post, Vulnerability Coordination and Concurrency Modeling, can be read here.

In the final post in the vulnerability research area, Vulnerabilities and Attack Vectors, Dormann describes a few of the more interesting cases he has encountered through his research in examining attack vectors as a source for potential vulnerabilities. The post was published in 2013 and remains among the most popular on the CERT/CC blog.

Here is an excerpt:

Attack vector analysis is an important part of vulnerability analysis. For example, reading an email message with Microsoft Outlook can be used as an attack vector for the Microsoft Jet Engine stack buffer overflow (VU#936529). With the Microsoft Windows animated cursor stack buffer overflow (VU#191609), reading an email message with Microsoft Outlook Express in plain text mode can also be used as an attack vector. With both cases, it's the analysis of the different attack vectors, not the underlying vulnerabilities that improve our understanding of the severity. Below are some recent examples where attack vector analysis took an important role.

The complete post, Vulnerabilities and Attack Vectors, can be read here.

CERT Vulnerability Notes

In addition to the blog, another valuable public resource is the CERT Vulnerability Notes Database, which provides timely information about software vulnerabilities. Vulnerability notes include summaries, technical details, remediation information, and lists of affected vendors. Many vulnerability notes are the result of private coordination and disclosure efforts. Industry organizations cite vulnerability notices as part of technical notifications to customers and users.

Visitors to the Vulnerability Notes Database can search for specific information, such as

• the 10 most recently updated vulnerabilities
• a list of vulnerabilities that affect control systems
• a list of vulnerabilities discovered using the Basic Fuzzing Framework (BFF)

CERT researchers also provide an archive of all public vulnerability information from the database.

Looking Ahead

The past six months have been an important time for the CERT/CC Blog in terms of keeping our stakeholders informed and helping them protect themselves against ever-present cyber threats. The next blog post in this series will highlight the most popular post on the CERT Insider Threat blog, which aims to help organizations protect against insider threat.

As always, we welcome your ideas for future posts and your feedback on those already published. Please leave feedback in the comments section below.

Additional Resources

For more information about CERT Tapioca or to download the tool, please visit
www.cert.org/vulnerability-analysis/tools/cert-tapioca.cfm.