Protocols (in the loose sense of structured exchange of messages) are like russian dolls. Everything at some point is contained within everything else. The Nested TLV vulnerability pattern is probably more to do with binary protocols than ascii ones. You can think of each TLV as a rectangle from a bounds perspective.

More »

In the quest to provide complete Attack Surface Coverage, we strive to identify patterns of abuse in protocols that we can replicate across other protocols and applications. We call them Vulnerability Patterns, because it abstracts the problem away from the programming language, the protocol or the one-off vulnerability in a particular version of a given product. It’s a powerful concept, especially if you can capture this pattern and apply it to every single place you see it. It’s no different from Design Patterns used in software engineering.

More »

The concept of Attack Surface is a formal way for quantifying the exposure of a connected system. It’s a measure of exposure and not that of vulnerabilties. However, two aspects of Attack Surface, channels and protocols, are key in figuring out how to attack a system and where the failure points are. In the last blog about mutations, I wrote about how we can create reusable mutation objects that can be plugged into arbitrary protocols and how we can use code coverage as one metric for measuring the effectiveness of it. From a system level perspective, I want to introduce this new notion of Attack Surface Coverage.

More »

When you are attacking an xinetd-based process model, there’s no reliable way to know if the child process seg-faulted. The accept’ing socket is always alive and GDB’s follow-fork-mode doesn’t quite help us with this since child processes are being spawned and killed all the time.

More »

First the definition: Proxies are objects that masquerade as some other object that’s contained within them, effectively intercepting all messages to the contained object. Proxies are used in multiple places like debugging, tracing, intercepted delegation, benchmarking, etc. But those have already been solved. This post is not about that.

More »

When performing any type of protocol fuzzing, one must obtain three key pieces of information about the target protocol: structure, state and semantics. The structure of a network protocol is the format of the messages, which contains a series of fields which, at the simplest level, are integers and strings. When dealing with any protocol with public specifications, this information is easily obtained. However, what is one to do when the specs are not publicly available, say in the case of a proprietary industrial control and automation protocol?

More »

If you look at the glibc equivalent for converting #defines to strings for purposes of perror, it’s a massive array that, at compile-time, builds all the strings.

The biggest drawback with this approach is that the #define and the corresponding friendly strings are defined and reconciled in two different places. If someone updates the header file to add a new errno, then s/he has to remember to also update this other place so perror works as expected. I’m using errno as an example, but this is a common problem when writing code in C or C++. The problem is exacerbated when certain enums are conditional (based on the operating system, cpu type and so on). Then these checks now need to be in multiple places. Ugliness.

More »

Object Oriented Mutations for Protocol Hardening.

Seriously though, I want to write about the process through which we create mutations and how ultimately it gets linked up in an assorted set of seemingly unrelated protocols. The take aways (for the impatient) are that mutations are really unit-tests, but have their origins in the following:

• Protocol specification
• Code reviews
• Known vulnerabilities that other people have found
• Expertise
• Structure
• Semantics
• State

More »

The Mu Security Research Team released advisory “MU-200611-01″ today. Details: http://labs.musecurity.com/advisories/MU-200611-01.txt

The Mu advisory “MU-200610-01″ was released today by the Mu Security Research Team. Details: http://labs.musecurity.com/advisories/MU-200610-01.txt