1 2 3 4 next »

Daniel Bachfeld

Taking an axe to bugs

Introduction to fuzzing tools

Fuzzing is a means of searching for errors in applications automatically. The process can be assisted by tools for specific applications and protocols. We take a look at three of these tools.

Fuzzing as a means of searching for vulnerabilities is, certainly since the "month of the browser bug" (MoBB), a familiar term to security specialists. In just 30 days, H. D. Moore published details of 25 vulnerabilities in Internet Explorer. The majority of these were in faulty Active-X control functions, which Moore discovered using a self-coded fuzzing tool.

AxMan

AxMan essentially consists of two parts: the first is the Windows tool - axman.exe, which records and analyses all Com objects, including Active-X controls, on Windows PCs and writes a JavaScript script for each one, with an array of all methods in a log folder [1]. This is complemented by scripts that, in the second step, control the actual fuzzing process using a webserver. Depending on the number of controls present on the PC, the AxMan analysis may take several hours. The tool, which is launched from the command line, calls a series of ActiveX modules on the computer. This results in Office programs and many other applications, opening and closing, as if by magic.

The log folder must then be saved in the root folder of a web server, along with the AxMan collection of scripts. All files required are found in the downloadable AxMan file. The next step involves calling the index.html page in the root folder of the webserver, using Internet Explorer. The user is now presented with an interface that shows how many controls are available for testing. In our test 3,733 objects were available. The GUI also has options to allow the user to determine which parts of the properties and methods are to be subjected to fuzzing.

A local or external Web server is required for the fuzzing procedure.

If no further specifications are entered, the tool will test all objects. It is also possible, however, to fuzz single objects, as long as you know their CLS ID. Whilst the process is running, the GUI shows the ID of the current object being dealt with and the properties and methods tested. All sorts of things can then occur in Internet Explorer, up to and including the browser crashing. In combination with a debugger and information on the bad methods, it is possible to obtain information for further manual analysis and to determine whether the vulnerability allows the infiltration of code. In order to prevent the fuzzing process from becoming stuck on the same object and to allow it to proceed to investigate further objects, the CLS ID of the problem control must be entered in the blacklist.js file.

In tests we quickly found a vulnerability in a Microsoft Data Access Components (MDAC) object in the msado15.dll library, which crashed Internet Explorer. AxMan gives quick initial results, but can only hint at where a developer needs to put in some extra work.

1 2 3 4 next »