The easiest method of conducting a security compromise
is to look for a vulnerability in widely used software and exploit
that. The problem today is that vulnerabilities rarely become
public, writes Ari Takanen, CTO atCodenomicon.
There is very little motivation to disclose security findings.
Unfortunately this makes reactive tools such as intrusion detection
systems, security scanners and vulnerability scanners useless. They
are all based on public vulnerability knowledge, and today they
just do not have the data to work on. More and more zero-day
attacks emerge with no protection available. It is time to be
proactive.
Fortunately a set of proactive security assessment tools has
emerged to fill the gap. These tools can be divided in three
categories: static code analysis tools, reverse-engineering tools,
and fuzzers. But which of these tools are useful for your everyday
security engineer trying to defend his or her enterprise network?
Maybe to you, they all look like quality assurance tools rather
than enterprise tools?
Code auditing tools require access to source code to be useful.
Reverse-engineering is powerful, but often illegal means of finding
vulnerabilities. That leaves fuzzing as the only proactive means
for protecting your system.
Recently, fuzzing tools have been adapted in standard
penetration testing practices and certification processes. For
example in SCADA (industrial automation) fuzzing has become a
critical part of the security test. Such tests have also been
adapted as the procurement criteria in telecoms. Also if you look
at the recent
marketing materials for Google Chrome you can see that major
software companies have taken fuzzing as part of their quality
assurance process.
Without knowing, you might already be using a product that has
been fuzzed during its lifecycle. I definitely hope it has been.
The only way to ensure that is to fuzz it yourself. This was the
beginning of enterprise fuzzing market, and more and more end-user
organizations are adapting and integrating fuzzing into their
standard auditing, acceptance and procurement processes.
What is Fuzzing?
Fuzzing is nothing new. For years already, software testers,
developers and auditors have used fuzzing in their proactive
security assessments. It is used to easily find defects that can be
triggered by malformed inputs via external interfaces, This means
that fuzzing is able to cover the most exposed and critical attack
surfaces in a system relatively well, and identify many common
errors and potential vulnerabilities quickly and cost-effectively.
There are no false positives with fuzz testing. A crash is a crash,
you cannot argue against that.
Although today most widely used fuzzers are all commercial, much
of the notoriety of fuzzers has arisen from the success of open
source projects. The best-known fuzzing comes from
testing Unix
command-line tools with fuzzed parameters in 1989 by Miller et
al. Their research indicated that 20-40% of all tested software
failed (crashed) when random inputs were provided. Back then
fuzzing was dumb but still powerful. During the last 10-15 years,
fuzzing has gradually developed towards a full testing discipline
with support from both the security research and traditional QA
testing communities, although some people still suffer from
misconceptions regarding its capabilities, effectiveness and
practical implementation. Fuzzing today is extremely
intelligent!
Fuzzing value
Fuzzing is especially useful in analyzing proprietary and
commercial systems, as it does not require any access to source
code. The system under test can be viewed as a black-box, with one
or more external interfaces available for injecting tests, but
without any other information available on the internals of the
tested system. A practical example of fuzzing would be to send
malformed HTTP requests to a web server, or create malformed Word
document files for viewing on a word processing application.
The purpose of fuzzing is to find flaws in software, and it does
that extremely efficiently. In
tests conducted by
Codenomicon Labs the researchers found out that none of the
available WLAN access points used by consumers could withstand any
fuzzing. Elimination of such flaws with automated black-box tools
reduces the cost of software in both R&D, as well as
maintenance costs by the end-users of the communication
products.
Potentially in the world of tomorrow, you will not need any
security devices, because the networks themselves will have been
thoroughly tested, with fuzzing, to tolerate any surprises coming
from the network.
Codenomicon is exhibiting atInfosecurity Europe
2009on 28-30 April 2009 at Earls Court,
London.
Read more articles from Infosec 2009 >>