Patent Application
20240169226
The present invention relates in general to fuzzing prevention, and more particularly to a system and method of impeding fuzzing by selecting responses that appear to be randomized to mislead a fuzzer.
Hackers often analyze a device (or a program) by interacting with the device or the like using any of the protocols that the device expects in an attempt to create a fault or exploit a bug in the code of the device being analyzed. Hackers may try to craft a malicious message that does not exactly follow the rules of a protocol. Before attacking the device, the hacker may attempt to understand how to craft a malicious message that can be used to exploit a bug in the code. Since the source code is rarely available, the hacker often uses “fuzzing” as an analysis technique to discover bugs in the implementation of the target device. Fuzzing is a well-known analysis technique that is used by a hacker or a test programmer to discover bugs in software or in hardware. A “fuzzer” is a hacker or other entity that performs a fuzzing analysis to discover any bugs in a device. Such bugs may represent vulnerabilities that compromise the integrity of the software or hardware and may thus be exploited by a hacker and used to attack the device.
The main idea behind fuzzing is to follow the expected protocol between the devices while introducing random mutations or modifications or the like. Examples of such modifications include random bit flips in messages or changes of the order of messages or parts of a message. If the device does not detect an error in the request message, then it might get into an incoherent situation such as deadlock or it might even crash. Incoherent states that can lead to the crash of the device may be exploited by a hacker. If such problems are not discovered during device manufacturing, they may be discovered by a hacker exposing any vulnerabilities of the device.
Embodiments of the present invention are illustrated by way of example and are not limited by the accompanying figures. Similar references in the figures may indicate similar elements. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale.
A fuzzing prevention technique as described herein can be used to counter a fuzzing campaign against a device or a program by selecting actions in response to fuzzing inputs to stagnate or impede the fuzzing campaign. A “fuzzing campaign” as used herein refers to analysis activities that are used to identify bugs in hardware or software of a device that render the device vulnerable to subsequent attack by a hacker. A person or other entity that conducts a fuzzing campaign, such as a hacker or attacker or the like, is referred to herein as a fuzzer. The fuzzing prevention technique fools the fuzzer into thinking that the fuzzing campaign is progressing when, instead, it has been detected and is, in fact, not actually succeeding. In this manner, fuzzing against a protected device becomes much more difficult and costly to execute potentially leading to fuzzing prevention. A fuzzing prevention technique as described herein concerns reacting to and impeding a fuzzing campaign that has been detected. After fuzzing has been detected using various fuzzing detection techniques, the response may include random-looking outputs that are selected from among a list of actions or responses, such as rebooting the device, requesting some user input, introducing delay after the query, sending a special response, etc. An advantage of a random-looking responses is that they are harder to automate the appropriate reaction for the fuzzer to continue the fuzzing analysis.
As further described herein, upon detecting fuzzing or a fuzzing campaign, a perceptual hash function is used to generate random-looking actions performed in response to fuzzing in order to mislead the fuzzer. The actions performed in response to fuzzing (which may include responses back to the fuzzer) are generated in such a manner that it is difficult to automate the fuzzing campaign and it is also difficult for the fuzzer to distinguish a real error from an intentional “fake” error that has been generated to mislead the fuzzer. A fuzzing prevention technique as described herein causes the fuzzer to spend as much time as possible analyzing fake actions or responses to fuzzing without actually discovering anything that may be used to harm the protected device.
The configuration shown in
The service provider 102 includes a fuzzing controller 104 which further includes a fuzzing detector 106 and the fuzzing responder 108. The fuzzing detector 106 incorporates a fuzzing detection mechanism that monitors inputs, which may include one or more of the queries Q1-QN, to detect fuzzing according to any one or more fuzzing detection techniques that are not further described herein. When the fuzzing detector 106 detects fuzzing, it asserts a fuzzing detection signal FD to the fuzzing responder 108. The fuzzing responder 108 responds by setting the service provider 102 into a “fuzzed” mode at least with respect to the fuzzing device 110 and its user (or any of its users). Once in the fuzzed mode, the fuzzing responder 108 takes control of interactions with the fuzzing device 110 and generates “random-looking” but consistent responses for the fuzzer to make them think that one or more errors have been found or are being found. The term “random-looking” means that the response appears to be random to the fuzzer but is in fact selected from a predetermined list of actions based on the fuzzing input as further described herein.
There are libraries implementing PHFs that can be used by the P-HASH generator 204, or a special PHF can be generated and used. PHF may be done in several ways including the use of self-supervised machine learning algorithms. This tailored approach helps to create a PHF better suited for a specific given system with a particular protocol, file format, message structure, etc.
In one configuration, the fuzzing response controller 202 controls a multiplexer (MUX) 205 to select the P-HASH value as the perceptual hash value PHSH provided to an action selector 206. The action selector 206 stores or otherwise points to or accesses a list of possible actions to choose from in response to the PHSH value for providing a selected action at its output. In the fuzzed mode as indicated by the fuzzing response controller 202, the selected action is executed in response instead of the normal response to the input or query. In other words, the input from the fuzzing device 110 is redirected to the fuzzing responder 108, and the selected action generated by the fuzzing responder 108 is performed the response to the input from the fuzzing device 110. The selected action may or may not include an actual response to the fuzzing device 110.
Examples of possible actions in the action selector 206 include rebooting the device; logging out the current user (of the fuzzing device 110); deleting some parts of the device's configuration, such as, for example, user data code, resetting to default settings, deleting keys or passwords, etc.; appearing to be stuck such as by not responding to any subsequent inputs or queries until reboot or the like; sending one of multiple standard error message selected as a parameter that can be sent during the normal execution of the protocol such as an error message that is specified by the specified by the format or the standard that the protocol implements; sending a special error message that is not specified by the standard, e.g., “Unexpected error” or “Unexpected error at address XXXX” in which XXXX is a selected parameter; sending a normal (appearing to be random) message of a protocol (such as one specified in the standard), in which the random message is selected as a parameter; and sending a random looking garbage-message instead of a normal response, in which the content of the message is selected as a parameter. This list of actions performed in response to fuzzing is not exhaustive by any means but provides an exemplary number of different actions that can be chosen with different probabilities based on the P-HASH value.
As noted by the possible actions of the action selector 206, some actions need a parameter to complete. The action selector 206 detects that a selected action requires a parameter and prompts a parameter generator 208 to generate and provide one or more parameters to the action selector 206 to formulate the complete action as the response. As described further herein, the PHSH value is also provided to the parameter generator 208 for generating one or more parameters to be used by the selected actions.
Generally, the PHF is used on the input that was received from a fuzzer to generate the P-HASH value, which is the same for identical inputs and is likely the same for similar inputs. The P-HASH value is used to choose the action that the service provider 102 produces to react to the input of the fuzzer as well as to produce parameters for this reaction (if parameters are required). This use of PHF to generate the P-HASH value ensures the same behavior observed by a fuzzer on different devices and on the same device across many trials for the same input. Thus, the fuzzer is duped into thinking that they are finding real errors that might be used to formulate an attack. In fact, however, the fuzzing campaign being conducted by the fuzzing device 110 has been detected and the fuzzing responder 108 essentially “fakes” the responses so that the fuzzer has not discovered any real errors.
The service provider 102 may be updated with new software or new hardware. In either or in both cases, while some of the errors of the older system may have been discovered and fixed in the newer versions, new errors or bugs may also be introduced. A new or updated system likely reacts differently to the same fuzzing inputs from the fuzzer as compared to the old system. A savvy fuzzer may detect fuzzing responses to a fuzzing campaign, which is not desired. The fuzzing responder 108 is configured to minimize detection by a fuzzer when new hardware or software is being used by the service provider 102.
A hardware version number (HW_VNUM) 210, a software version number (SW_VNUM) 212, a secret shared key (SH_KEY) 214, and the P-HASH value may be provided to respective inputs of a concatenator 216, which provides a concatenated value CVAL to an input of a non-perceptual (NP) hash generator 218, which outputs a revised hash value P-HASH-REV. It is noted that each concatenator described herein, including the concatenator 216 and another concatenator 502 (
In case the use of such system is known to the fuzzer, their goal may be to distinguish real errors or reactions from the fake ones (the ones computed using PHFs). To prevent the fuzzer from doing this, the SH_KEY may be incorporated into the computation. The secret key should be shared across the devices including all devices, or at least those devices that have the same hardware or software version, to ensure different behavior with different versioned devices and identical behavior with the same versioned devices.
Referring back to block 708, if the fuzzing detector 106 has instead asserted the FD signal indicating that a fuzzing campaign has been detected from the entity, such as, for example, from the fuzzing device 110, operation instead proceeds to block 710 in which the service provider 102 enters the fuzzed mode for that entity, which is now referred to as a fuzzer. It is noted that the service provider 102 may be providing data or services to other entities in which the fuzzed mode may be entered only for those entities for which fuzzing has been detected. Operation then advances to block 712 in which inputs from the fuzzer are redirected to the fuzzing responder 108. Operation then advances to block 714 in which the service provider 102 performs the action selected by the fuzzing responder 108. Depending upon the action performed, operation may loop back to block 702 for receiving the next input from the fuzzer. If and when a subsequent input is received from the fuzzer, then at block 704 operation instead proceeds to block 712 in which each subsequent input is redirected to the fuzzing responder 108. Operation may stay at block 702 indefinitely while waiting for the next fuzzing input, or may loop between blocks 702, 704, 712, and 714 for fuzzing operation in response to the fuzzer.
Although the present invention has been described in connection with several embodiments, the invention is not intended to be limited to the specific forms set forth herein. On the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the invention as defined by the appended claims. For example, variations of positive circuitry or negative circuitry may be used in various embodiments in which the present invention is not limited to specific circuitry polarities, device types or voltage or error levels or the like. For example, circuitry states, such as circuitry low and circuitry high may be reversed depending upon whether the pin or signal is implemented in positive or negative circuitry or the like. In some cases, the circuitry state may be programmable in which the circuitry state may be reversed for a given circuitry function.
The terms “a” or “an,” as used herein, are defined as one or more than one. Also, the use of introductory phrases such as “at least one” and “one or more” in the claims should not be construed to imply that the introduction of another claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an.” The same holds true for the use of definite articles. Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements.
