Category Archives: security

fuzzing, security, tools, XML

Use of Fuzzers Helps Discover XML Security Threats

I posted about fuzzing a few days ago, and I think the tools are neat, and in the hands of good testers can be powerful. They are a nice way to augment existing security testing, to test data transfers or messaging, or to simply generate test data. However, some of my readers basically said:

Big deal. It’s a neat toy for you, or some of your clients who have the time for that sort of thing, but why would I want to use one?

The Register has posted an interesting article where fuzzers were used to discover potential security holes in XML libraries. Check it out here: XML flaws threaten ‘enormous’ array of apps. If my babblings about fuzzing don’t get your attention, maybe this article will. The potential to use fuzzers (in conjunction with other security tools and techniques) to help people catch problems that bad guys will exploit is enormous.

Codemonicon, the company cited in the article, have a lot of interesting information and expertise in this area. They have a nice introduction to fuzzing on their website. This paper by Rauli Kaksonen has a lot of technical detail on fuzzing if you’d like to learn more.

fuzzing, security

Fuzzing Through the Side Door

I’ve been looking into testing with fuzzers lately, and finally got the chance to do this on a live project. While there are a good deal of black-box fuzzing tools out there, if you want to go beyond that you are often on your own. At the other end of the spectrum, MSDN has a nice article on white box fuzzing.

What I needed to do was somewhere in the middle. I needed to test a data transport layer in a large, complicated system, and fuzz the data that was sent in messages from internal systems as well as from 3rd parties. This required some knowledge of the code internals, the protocol, and messaging APIs used, the architecture, etc. Some people call this gray box testing, and I like to call it “testing through the side door”, a term I got from Jennitta Andrea. (The front door is the UI, the back door is the database, the side door are other testable interfaces in-between like messaging APIs, etc.)

I couldn’t find any tools (open source or proprietary) that did what I needed, so I started a search for a Java fuzzing library. (I was doing the work in a Java shop, so Java-based tools were my first choice.) I couldn’t find anything, so I contacted the people on the JBroFuzz project and told them what I wanted to do. I like OWASP, and I liked what I saw in the JBroFuzz product. Thankfully, it is pretty easy to use JBroFuzz as a library, in addition to the already-powerful HTTP(S) fuzzing the tool provides through its UI.

Yiannis Pavlosoglou bent over backwards to help me. Yiannis sent me examples to try out, explained how to create my own fuzzers, and even helped me fix a silly iterator error I had in my own code. Thanks Yiannis!

In relatively short order, I integrated JBroFuzz into the existing test framework for messaging, and the first afternoon I had it running, it helped us uncover problems.
If you’re looking for a fuzzing library for Java, here are directions for using JBroFuzz as a fuzzing library.

Thanks to Yiannis Pavlosoglou for all the help, and the JBroFuzz team for a great tool. If you haven’t started looking at fuzzers and fault injection tools on your project, give them a try. Happy fuzzing.

reliability, security

Simplicity and Reliability

From the National Post:

Systems crash inevitable report: Networks for banks, hospitals, power lines at risk within the next five years

Michael Friscolanti
National Post

June 8, 2004

Computer networks that support Canada’s critical services — from hospitals to banks to power lines — will undoubtedly crash in the next five years, warns a government-commissioned report that says even immediate action cannot stop the inevitable.

Shoddy software has left the Internet and other parts of our telecommunications systems vulnerable to a massive meltdown, the report concludes. No corrective action can avert “a major failure,” but the authors say both the government and the private sector must act quickly if they are to prevent subsequent collapses.

[….]

With respect to software that has evolved to a high level of complexity, there may exist no single individual who grasps the entire program, let alone one who can keep track of all those who have contributed to its various components,” the report reads. ” [emphasis added]

I’m reminded of Ralph Johnson speaking on security last week. He noted that secure systems are usually known by one person; they have a simple enough design to be understood by one person (usually the designer). To be secure, a system must be reliable.