Archive for Fuzzing

How to win in the age of cyber war

While the bad news is that experts are declaring that we have entered the age of cyber war, the worse news as we enter 2012 is that security systems and professionals are just not able to keep up. Security attacks are increasing in their complexity and intensity every day. These range from inter-state attacks (like the one on Raytheon this year and the ones from China that are being investigated by the U.S. government) to cyber-crime (that includes countless malware and DDOS attacks against businesses and consumers).

                            

Full Post »

Bookmark and Share

blitz.io: Benchmarking view performance in CouchDB

If you are running CouchDB on an EC2 node with an EBS volume (or otherwise), it’s kinda hard to predict how the view performance will be affected by disk seeks and other criteria. Add complex reduce functions to this mix and you are flying blind. Just in my last blog, we talked about adding parameterization to blitz.io so you can easily test location-aware iPhone and Android apps. What if we could use CouchDB itself to generate fully parameterized tests so you can blitz it?

Full Post »

Bookmark and Share

MuSL – Interactive Application Protocol Fuzzing Playground

MuSL stands for Mu Scenario Language, a canonical canonical Domain Specific Language that we use in Mu Studio to represent complex transactions between multiple hosts using multiple transports and layers. The language itself borrows constructs from numerous languages and was designed to be protocol friendly. We just published an interactive application protocol playground that shows off MuSL and how to use it for various types of testing including LTE, NoSQL, Databases, Layer2 and DPI.

Full Post »

Bookmark and Share

MuSL for Application Protocol Fuzzing and Scale Testing – Introduction

So we’ve had this thing called MuSL (Mu Scenario Language) for more than a year now in the Mu Studio product. It’s the format of choice at Mu for modeling everything from layer 2 through 7 across a wide range of applications, everything from LTE (Long Term Evolution), Databases, SCADA, Web applications, NoSQL to FCoE (Fiber Channel over Ethernet). Our customers use this for Functional Testing, Fuzzing and most recently Scale Testing. This is the first of a series of blogs describing what MuSL is and how you can use a single description of a multi-host, multi-protocol, multi-transport transaction for Application Fuzzing to Scale Testing.

Full Post »

Bookmark and Share

Testing HTML5 Applications

There are two kinds of test tool vendors in the world. Those that count in binary and those that don’t. Okay, stale joke aside there are those that test applications (like Mercury, now part of HP, IBM, etc) and those that test the infrastructure (like IXIA, Spirent, etc). Mu was founded on the premise that this boundary is blurring rapidly and there needs to be a new kind of testing solution that spans the layers between applications and infrastructures and looks at the service as a whole. As we look into the imminent future of HTML5 and the innovation in mobile and cloud apps, you can see this in play right now. And yet all these test tool vendors are lagging behind this brave new world.

Full Post »

Bookmark and Share

Application Fuzzing with Mu Studio

Fuzzing has in the past mostly been relegated to protocols and file formats. With the huge surge in mobile apps, cloud applications, virtualization and social gaming, not to mention a RESTful API for everything these days, the challenge becomes generating fuzz tests rapidly for these applications. This is not just for the actual services, but also for the application-aware systems that are getting smarter by the day. We now have Deep Packet Inspection, Application Identification and a host of new technologies that allow firewalls and UTM’s to inspect application flows for compliance, QoS and access control.

Full Post »

Bookmark and Share

Functional and Fuzz Testing Proxies and Load-Balancers

Using Mu Studio, we recently enabled one of our customers to do both functional and fuzz testing of their proxy/load-balancer (P/LB). This P/LB supports SSL termination, IPv6, Caching, Compression, WAN Acceleration & Optimization and a plethora of really cool features that enable high-volume cloud apps and web sites. What I want to talk about is our approach to testing complex products/deployments like these from both a functional and fuzz/security/resiliency testing perspective.

Full Post »

Bookmark and Share

Wireshark, dissectors and fuzzers

Just saw someone tweet about Python dissectors in Wireshark. Personally, I would’ve preferred a Ruby DSL that maps back to the internal libwireshark API in a way that makes writing dissectors incredibly easy. A couple of years ago, I presented “I see dead protocols” at CanSecWest and talked quite a bit about laziness, impatience and virtue. In the context of dissectors, I dug out some code that I wrote a while back that essentially converts a parser into a fuzzer. Let me explain.

Full Post »

Bookmark and Share

Charlie and the Fuzzing Factory

It’s cool that Charlie Miller fuzzed the iPhone and broke it, but the catch phrase for me was (paraphrased) “When I start the fuzzer, I want to get some sleep and when I wake up find tons of 0-days“. I remember watching the movie with my kids and it wasn’t that the factory made awesome chocolates, but the whole thing was automated with elves and such.

Full Post »

Bookmark and Share

Fuzzing SCADA Programmable Logic Controllers

PLC’s for short, are used extensively in SCADA networks for meter readings and equipment status reports, which are then sent over an IP network (using IEC61850, DNP3, MODBUS, etc) to the Supervisory Station. PLC’s run both a piece of software to report back up to the station while simultaneously controlling physical entities like electric motors, pneumatic or hydraulic cylinders, magnetic relays, etc. You can see where I’m going with this: There are two alternate universes here and they should not affect each other. On the measurement/controlling side, responses have to be sent back within certain time bounds or things will break leading to physical and collateral damage. On the IP side, the inherent unreliability of IP networks has to be handled. This is very similar to how routing vendors [try and] isolate the control and forwarding planes, except the forwarding plane here controls and measures physical entities.

Full Post »

Bookmark and Share