Category: Tools

In my last post, I presented how to create a YAF application label signature rule that corresponds to a text-based Snort-type rule. In this post, I discuss methods for using Analysis Pipeline to provide context to those signatures.

The context for signatures can take many forms. Some context can be derived from the individual flows that match the signatures. This information is easy to obtain from either SiLK or another traffic analysis tool--just look at the traffic that matched the signature. Analysis Pipeline lets you easily do more. I will discuss three simple options, but Analysis Pipeline can be used for more complex analyses.

Ever want to use a Snort-like rule with SiLK or Analysis Pipeline to find text within packets? Timur Snoke and I were recently discussing how we could do this and realized that while neither SiLK nor Analysis Pipeline themselves do packet inspection, YAF can be used to create an application label that can be used in analyses in both SiLK and Pipeline (field 29, application). This post outlines the steps required and provides an example.

Hi. This is Angela Horneman of the SEI's Situational Awareness team. I've generated service specific network flows to use as baseline examples for network analysis and am sharing them since others may find them helpful.

We have been looking at implementing Network Profiling in Analysis Pipeline to automatically generate lists of active servers and to alert when new IPs start acting as servers. As part of this initiative, we started looking at alternatives to using flags in the identification process, since not all collection methods capture TCP flag data. In this process, I looked for example network flows for verified services.

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 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.

Hacking the CERT FOE

By on in

Hey folks, it's Will. Every now and then I encounter an app that doesn't play well with FOE. You don't have to throw your hands up in defeat, though. Because FOE (and BFF) are written in Python, it's pretty easy to modify them to do what you like.

Hi folks, Allen Householder here. As Will Dormann's earlier post mentioned, we have recently released the CERT Basic Fuzzing Framework (BFF) v2.7 and the CERT Failure Observation Engine (FOE) v2.1. To me, one of the most interesting additions was the crash recycling feature. In this post, I will take a closer look at this feature and explain why I think it's so interesting.

Hi, this is Allen Householder of the CERT Vulnerability Analysis team. If you've been following this blog for a while, you are probably familiar with our fuzzing tools: Dranzer, the CERT Basic Fuzzing Framework (BFF), and the CERT Failure Observation Engine (FOE). While creating tools that can find and analyze vulnerabilities makes up a significant portion of our work in the CERT Vulnerability Analysis team, our focus is on developing and communicating the knowledge we've built into those systems.

Hi everybody. Allen Householder from the CERT Vulnerability Analysis team here, back with another installment of "What's new in CERT's fuzzing frameworks?" Today we're announcing the release of updates of both our fuzzing tools, the CERT Basic Fuzzing Framework (BFF) version 2.6 and the CERT Failure Observation Engine (FOE) version 2.0.1. The remainder of this post describes the changes in more detail.

Hi folks, Allen Householder from the CERT Vulnerability Analysis team here. Back in April, we released version 1.0 of the CERT Failure Observation Engine (FOE), our fuzzing framework for Windows. Today we're announcing the release of FOE version 2.0. (Here's the download.) Although it has only been a few months since we announced FOE 1.0, our development cycle is such that FOE 2.0 actually reflects nearly a year of additional improvements over the 1.0 release.

In May 2010, CERT released the Basic Fuzzing Framework, a Linux-based file fuzzer. We released BFF with the intent to increase awareness and adoption of automated, negative software testing. An often-requested feature is that BFF support the Microsoft Windows platform. To this end, we have worked to create a Windows analog to the BFF: the Failure Observation Engine (FOE). Through our internal testing, we've been able to help identify, coordinate, and fix exploitable vulnerabilities in Adobe, Microsoft, Google, Oracle, Autonomy, and Apple software, as well as many others. Our office shootout post is a good example of this testing.

Version 2.0 of the CERT Basic Fuzzing Framework (BFF) made its debut on Valentine's Day at the 2011 CERT Vendor Meeting in San Francisco. This new edition has a lot of cool features that we'll be describing in more detail in future posts, but we wanted to let you know that it's available so that you can download and try it.

Hi folks. I've been involved in a fuzzing effort at CERT. One of the ways that I've been able to discover vulnerabilities is through "dumb" or mutational fuzzing. We have developed a framework for performing automated dumb fuzzing. Today we are releasing a simplified version of automated dumb fuzzing, called the Basic Fuzzing Framework (BFF).

Hi, it's Will. As previously mentioned, we have been investigating and discovering ActiveX vulnerabilities over the past few years. Today we released the Dranzer tool that we have developed to test ActiveX controls.

We've been using the Dranzer ActiveX fuzz testing tool for over three years, and we've found a large number of vulnerabilities with it. I've tagged a few of the US-CERT Vulnerability notes with the "Dranzer" keyword to show the sort of vulnerabilities we've been discovering with the tool.