What is Fuzzing in Cybersecurity?

Unlike most dynamic application security testing tools, black box fuzzers do not look for certain attack signatures or attempt to locate known vulnerabilities in products, but rather deliver the widest possible range of unexpected input in order to uncover new and unknown vulnerabilities in network products.

When you need more than vulnerability management and scanning assessment, fuzzing is used either during the development process (in the QA phase) to automatically discover the security holes that still remain in the product, allowing the developer to fix those vulnerabilities before the product is shipped, or as a product certification solution to test applications and devices before acceptance.

BeSTORM is an automated fuzzer tool, programmed to make an exhaustive search of all possible input combinations in order to test the product for weaknesses, subtle as they may be. Of course, attempting to cover all theoretical input combinations to the program is not practically possible for any non-trivial product. Therefore beSTORM is equipped with prioritization algorithms to enable complete coverage of all inputs that are likely to ‘trigger’ a security hole, all within a reasonable time frame.

These algorithms stem from BeSTORM’s experience and knowledge, accumulated during years of performing manual product audits in search of security holes.

How Does Fuzz Testing Work?

Fuzzing Step-by-step

Although it may seem that hackers spend a great deal of time studying different software or systems for security vulnerabilities, that isn’t always the case. They usually just poke around until they find a weakness to exploit. When this process of poking around is carefully recreated into a well defined testing process, it’s called fuzzing. Fuzz testing works by poking into software, firmware, networks and even hardware, in an effort to uncover bugs that can be exploited by hackers.

Specialized tools, called fuzzers, are used to detect these vulnerabilities as quickly as possible. While other application security (appsec) testing tools focus on detecting known vulnerabilities, which requires access to source code, fuzzers rely on using as many inputs as possible to uncover new and unknown bugs. Fuzzers can function with or without access to the software’s source code.

What are the Benefits of Fuzzing?

Supports Both Interactive and Non-Interactive Protocols

The beSTORM modules support both non-interactive protocols (such as HTTP, possibly the most common protocol in any Internet environment; used by web servers, communication products, and many others), and interactive protocols such as SMTP (used by mail servers, content filtering devices and anti-virus gateways).

Simplifies Testing

First, it simplifies the adjustments needed to test an off-the-shelf product, since the protocol standard enables building a beSTORM fuzzer module that will work for all HTTP-compatible products.

For example, most network devices use HTTP for configuration, to allow the customer to use a standard web browser to configure the device. Regardless of whether the network device uses a known web server for HTTP communication or if the programmers developed an HTTP-compatible application from scratch, the same beSTORM module can be used for testing. Note, however, that the fact that the HTTP protocol is used does not mean that the relevant beSTORM modules will not attempt attacks “outside” the HTTP protocol – many security holes appear when breaking the standard, and beSTORM will attempt to locate these holes. The definition of the protocol only means that beSTORM will focus on finding HTTP based holes first.

Quantifies Level of Security

Second, it facilitates quantification of the level of security of the product. By systematically checking the application, we can indicate how secure a certain product really is, by measuring the number of checks we have done compared with other products in the same category. This enables an actual security certification of products, based on an objective and automated scaling – as opposed to today’s manual and error-prone evaluation.

The typical beSTORM user will run beSTORM with a specific module, based on the application being checked.

The user will then set beSTORM to monitor the application that is being audited, and provide the necessary details for the attack: IP address and port (if the attack is on a remote machine), and the protocol used.

The attack can be started and stopped, as well as paused and resumed. A status bar indicates the current test that is being done, and the percentage of the attack that has been completed.

What is Smart Fuzzing?

While most fuzzers use strictly random inputs to probe software (i.e, dumb fuzzers), there is a new breed of fuzzers, smart fuzzers, that are programmed with some knowledge of inputs and file types required.

Rather than throw lots of random fuzz at software, smart fuzzers use algorithms to determine which attacks are most likely to succeed. Smart fuzzers can test all internet protocols, even complex ones such as SIP. And smart fuzzers test the binary application, and are therefore programming language independent. All of these capabilities mean smart fuzzers are more likely to find a vulnerability and in less time.

How to Defend Against Security Holes

From our research, we have concluded that although the number of possible inputs to any given application is almost infinite, it is usually possible to isolate certain inputs that are likely to lead to the exposure of a security hole. This is how most leading security researchers (including us) find security holes in products – by covering this application input-space. However, this is a very costly procedure, that requires expertise and large amounts of time. The main issue is that while a software development company may not want to spend the huge amount of time and effort needed to uncover such security holes, a smart 16 year-old kid with plenty of time on his hands and a freeware fuzzer tools will go through this procedure for the fame and glory that comes with finding such security holes.

By making this procedure automatic and removing the need for security expertise in running the tool, beSTORM fuzzer standardizes the security checking phase of product development.

Why Does My Organization Need Code Fuzzing?

There is an obvious need in the information security industry for security testing tools that will enable early detection of vulnerabilities in products that might allow unauthorized intrusion. There are plenty of use cases because of the reasons below.

Increase In Attacks

One of the most common problems in today’s software market is the numerous attempts by hackers to try and break the security protection of applications. Every single day, new vulnerabilities are discovered and published. The damage caused by these vulnerabilities is extensive and includes harm to the vendor’s image; financial loss due to labor being diverted from other tasks to cope with the problem; and third-party damage caused by privileged information stored in the applications used to hurt the interests of the organization. Direct damages can be in the hundred thousands of dollars and indirect damages can be in the millions of dollars, depending on the sensitivity of the information being exposed.

Lack of Knowledge

One cause of vulnerabilities is that application developers are not experts in writing secure code that is resilient to hackers and QA departments can’t maintain an array of often unsupported protocol fuzzers.

There are hundreds of fuzzers written by hackers whose purpose is to break applications. Developers have had to buy and deploy dozens of these unsupported tools to check whether their products can be attacked. This testing becomes labor intensive and time consuming as more lines are written into the application.

Lack of Resources

Let’s look at an application of medium size with about half a million lines of code. A security specialist scanning over eight hundred lines of code per day to detect vulnerabilities will spend five hundred days to perform a complete assessment of the code. This has an estimated street price of a quarter of a million dollars. The responsibilities of the security specialist not only include spotting known security vulnerabilities, but also to identify new security vulnerabilities that were previously unknown. In addition, this process needs to be repeated whenever a new version of the product comes out, which can be several times a year.

To save company resources that are allocated to the detection and subsequent repair of security vulnerabilities, there is a clear need for an enterprise fuzzer which will test every application’s level of protection against vulnerabilities before it is released to the market.

Legacy Vulnerabilities

Due to time constraints caused by the testing of security vulnerabilities in products, many vendors release their products prior to conducting a proper security audit, exposing their customers to potential vulnerabilities. This is becoming unacceptable to customers and they have stepped up their demand that vendors conduct at least some security testing of their products prior to purchase.

In those cases where a product was purchased by a customer and a security vulnerability is discovered, two major problems arise – the vendor has the responsibility to fix the problem and must also provide its customers with the appropriate means to protect themselves against the vulnerability. The customer will usually contact the vendor and demand that the vendor provide an appropriate solution to protect the customer from attack. As mentioned above, these types of vulnerabilities are discovered on a daily basis. As hackers get better at finding vulnerabilities, and the number of vulnerabilities steadily increase, the rise in awareness on the part of customers will inevitably cause them to demand higher standards of security from vendors’ products.

Automation Is Your Ally

To summarize, there is an obvious need for an automated audit tool, a fuzzer, that provides detailed information on different types of vulnerabilities that is currently unavailable to the average programmer. The tool will conduct product audits, discover known and previously unknown vulnerabilities by doing a thorough test of all possible combinations, and allow for prioritization. All this, without consuming excessive amounts of man-hours or any other accompanying resources.

This is where BeSTORM fuzzer enters the picture.

In order to interface with the application, beSTORM fuzzer will need to “speak” the “language” the application expects. This language is the network protocol.

BeSTORM provides over 200 special testing modules to do this. These modules are programmed according to known protocol standards (HTTP, FTP, SMTP, IMAP, POP3, DNS, DHCP, VOIP). More modules can be programmed on request to accommodate the specific needs of the product being tested.

See How BeSTORM Can Uncover Unknown Vulnerabilities

BESTORM DEMO

How to Choose a Fuzzing Tool

SPEED

When it comes to detecting vulnerabilities, time is everything. A reliable fuzzer should be able to support load tests of as many attacks as possible per second. Whether it’s dumb fuzzing that requires random inputs or smart fuzzing that utilizes intelligent inputs, getting a fuzzer that can run as many test cases as possible per second is crucial to discovering your application security (appsec) vulnerabilities.

CODE COVERAGE

Code coverage refers to how much of a software’s code has been executed by a fuzzer. The more code covered the more thorough the test. However, just testing a lot of code is not the answer. Unless you know which parts of the source code are executed, you don’t really know how thorough the test is. Ideally you have a fuzzer that lets you know which sections of the source code have been tested.

CRASH CATEGORIZATION

The role of fuzz testing does not end with discovering potential crashes. Once you find a crash, the next step will usually be to correct the code. However, with potentially hundreds of thousands of test cases being run per second, treating each crash on an individual basis is impossible. A fuzz tester that categorizes crashes will allow you to prioritize them and identify those with similar bugs for more efficient problem resolution.

Fuzzer Tool Performance

beSTORM is expected to find the majority of vulnerabilities that a manual test would reveal within the first 24 hours of automated testing. The full test is expected to take several days to several months – depending on the size and complexity of the application. Distributed capabilities enable to shorten this time considerably by sharing the task between multiple machines. In any event, the testing is completely automated and requires no manual intervention.

Fuzzer Case Studies

During the development of beSTORM, we made sure that the fuzzer met its expected goals by constantly taking vendor provided products, and running beSTORM against them. In this list of 13 products, each had at least one security vulnerability that prompted the vendor to release a patch to prevent their customers from being vulnerable to the discovered problem.

As wireless connectivity becomes more engrained in everyday technology, there is a rapidly growing need for fuzzing prior to product deployment. Key industries need it to keep customers safe and stay within compliance regulations.

Some of the crucial industry cases include:

Software Security Testing of IoT Devices
Fuzzing For Microsoft SDL
Software Security Testing and Certification of Medical Devices
Security Testing of Critical Infrastructures
Black Box Fuzzing for the Automotive Industry

Learn About Fuzzing for Key Industries

There are key industries that DAST and black box fuzzing are absolutely crucial to use during application development. The Importance of Black Box Fuzzing in Key Industries Guide can show you how fuzzing can keep you compliant and even help “future-proof” your company from new regulations.

GET THE GUIDE

Fuzzing in Cybersecurity Guide