Archive: 2014-01

Hi, it's Allen. In addition to building fuzzers to find vulnerabilities (and thinking about adding some concurrency features to BFF in the process), I've been doing some work in the area of cybersecurity information sharing and the ways it can succeed or fail. In both my vulnerability discovery and cybersecurity information sharing work, I've found that I often learn the most by examining the failures -- in part because the successes are often just cases that could have failed, but didn't.

In this blog post I focus on an area of cybersecurity information sharing that's considerably less well understood than incident reporting, malware analysis, or indicator sharing. I'm talking about coordinated vulnerability disclosure and why it's hard.

Hello, this is Jonathan Spring with my colleague Leigh Metcalf. Today, we're releasing a CERT/CC whitepaper on our investigations into domain name parking. The title summarizes our findings neatly: "Domain Parking: Not as Malicious as Expected."

First, let's review some definitions to make sure we're all on the same page. Domain parking is the practice of assigning a nonsense location to a domain when it is not in use to keep it ready for "live" use. When a domain is "parked" on an IP address, the IP address to which the domain resolves is inactive or otherwise not controlled by the same entity that controls the domain.

Hi folks, Allen Householder here. I want to introduce some recent work we're undertaking to look at vulnerability discovery for emerging networked systems (including cyberphysical systems like home automation, networked cars, industrial control systems and the like). In this post I cover the background and motivation for this work, our approach, and some preliminary findings. In future posts I will cover additional results from this effort.

Hi, this is Angela Horneman from the CERT Situational Awareness Analysis team. Recently, Nathan Dell and I were asked to explore ways to improve network traffic data storage by determining what data to store to meet organizational needs. Our research, brainstorming, and discussions led us to create a methodology to help organizations determine what types of traffic to collect and what parts of the collected traffic to keep.

Hi, this is Leigh Metcalf. In this blog post I talk about a subversive use of SiLK, the open-source tool suite designed by the CERT/CC team at the SEI, available on the CERT website. This post is a technical walk through of how to use the SiLK tools to support analysis in interesting ways you may not have thought of.

Hi, this is Jonathan Spring with my colleague Leigh Metcalf. For some time now, we've been working through a problem we found, but it's time to discuss it more broadly. Using our passive DNS data source, we can observe cache poisoning. What we really observe are changes in the answers that are returned for certain domains, but after consulting with various experts, we believe the only behavior these changes indicate is a successful cache poisoning attack.

Hi folks, it's Will. Recently I have been investigating man-in-the-middle (MITM) techniques for analyzing network traffic generated by an application. In particular, I'm looking at web (HTTP and HTTPS) traffic. There are plenty of MITM proxies, such as ZAP, Burp, Fiddler, mitmproxy, and others. But what I wanted was a transparent network-layer proxy, rather than an application-layer one. After a bit of trial-and-error investigation, I found a software combination that works well for this purpose. I'm happy to announce the release of CERT Tapioca (Transparent Proxy Capture Appliance), which is a preconfigured VM appliance for performing MITM analysis of software.

Hi, it's Will. We are all probably annoyed by software that bundles other applications that we didn't ask for. You want a specific application, but depending on what the application is, where you downloaded it from, and how carefully you paid attention to the installation process, you could have some extra goodies that came along for the ride. You might have components referred to as adware, foistware, scareware, potentially unwanted programs (PUPs), or worse. Sure, these may be annoyances, but there's an even more important security aspect to these types of applications: attack surface.

The idea of a cyber-immune system sometimes circulates through the community. It seems that such proposals either do not properly frame how the immune system works, how good computer security would work, or both. I'm going to try to put both of those in context in order to make clear why cybersecurity is not like the immune system, but why it would be nice if it were.

Hey, it's Will. I was recently working on a proof of concept (PoC) exploit using nothing but the CERT BFF on Linux. Most of my experience with writing a PoC has been on Windows, so I figured it would be wise to expand to different platforms. However, once I got to the point of controlling the instruction pointer, I was surprised to discover that there was really nothing standing in the way of achieving code execution.

Hi, this is Vijay Sarvepalli, security solutions engineer in the CERT Division again. In the earlier blog entries for this series, I introduced set theory and standard deviation. This blog entry is about entropy, a physics principle that has made its way into many mathematical applications. Entropy has been applied in many informational science topics. In this blog post, I introduce a way to use entropy to detect anomalies in network communications patterns.