Patent Application
20230306091
This disclosure generally relates to electronic circuits, and more particularly, to a method for detecting a fuzzing analysis on an electronic circuit.
There are many protocols that facilitate communication between electronic devices. Example communication protocols include USB, Bluetooth, Wifi, and near field communication (NFC). The protocol in one device interacts with a counterpart program in another device to facilitate communications. Application programs also often interact with each other using protocols as well as Application Programming Interfaces (APIs). The protocols and other programs interact using a set of structured messages such as commands and instructions that can be exchanged between two devices to obtain information or access services. An attacker can also try to interact with a device (or a program) using any of the protocols that the device expects. An attacker may try to craft a malicious message that does not exactly follow the rules of a protocol using a technique called fuzzing. Using information gained from a fuzzing analysis, the attacker may try to create a fault or exploit a bug or error in the program code of the attacked device to gain control or access to the device.
Therefore, what is needed is a method for detecting a fuzzing analysis performed by an attacker on a device.
The present invention is illustrated by way of example and is not limited by the accompanying figures, in which like references indicate similar elements. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale.
Generally, there is provided, a mechanism to detect a fuzzing analysis on a first electronic device or a program operating in the first electronic device. In the method, a new message having a message type is received from a second electronic device. The message type of the new message is predicted from previously received messages. In one embodiment, the prediction is performed using a machine learning model. Also, the message type of the new message is determined by analyzing bits of the new message using circuitry available in a processor of the device for fetching, decoding, parsing, and executing instructions. Then, a likelihood that the predicted message type of the new message compares favorably to the determined message type of the new message is computed. If it is determined that the predicted message type does not compare favorably to a threshold likelihood value, an indication of an ongoing fuzzing analysis is indicated, and appropriate action may be taken. If it is determined that the predicted message type does compare favorably to the threshold likelihood value, normal operations may be continued including responding to the new message. In another embodiment, a lookup table of likely subsequent messages based on previously received messages is precomputed and stored in the first electronic device.
Detecting a fuzzing analysis by an attacker that is underway allows a reaction to the attack that can undermine the efforts of the attacker. For example, steps may be taken to slow down the fuzzing attack or disable some parts of the protocol in the device under attack. Additional checks and countermeasures may be enabled. For example, a server may be alerted of the attack, the device may be rebooted, the device’s firmware may be erased, or some other actions may be performed to discourage and slow down the attacker.
In accordance with an embodiment, there is provided, a method for detecting a fuzzing analysis in a first device, the method including: receiving a new message of a message type from a second device; predicting the message type of the new message from previously received messages; determining the message type of the new message by analyzing the new message; determining a likelihood that the predicted message type compares favorably to the determined message type of the new message; determining that the predicted message type does not compare favorably to a threshold likelihood value; and providing an indication of the fuzzing attack. The method may further include adding the determined message type of the new message to a stored list of previous messages in a memory of the first device. Predicting the message type of the new message may be performed using a machine learning model in the first device. The machine learning model may include a long short-term memory (LSTM) neural network. The indication of the fuzzing attack may be provided only after a plurality of unfavorable comparisons to the threshold likelihood value. The method may be implemented in a program including instructions stored in a non-transient storage medium and executed by a processor in the first device. The method may be capable of being disabled during software development in the first device. The message type of the new message may be a request for data. The new message may be a malformed request for data, and wherein the malformed request for data may have a relatively low likelihood value. Fuzzing analysis detection may be enabled or disabled using a control bit stored in a memory.
In another embodiment, there is provided, a method for detecting a fuzzing analysis in a first device, the method including: receiving a new message having a message type from a second device; predicting the message type of the new message from previously received messages; determining the message type of the new message by analyzing the new message; determining a likelihood that the predicted message type compares favorably to the determined message type of the new message; adding the determined message type of the new message to a stored list of previous messages in a memory of the first device; determining that the predicted message type does not compare favorably to a threshold likelihood value; and providing an indication of the fuzzing attack. Predicting the message type of the new message may be performed using a machine learning model in the first device. The machine learning model may include a long short-term memory (LSTM) neural network. The indication of the fuzzing analysis may be provided only after a plurality of unfavorable comparisons to the threshold likelihood value. The method may be implemented in a program including instructions stored in a non-transient storage medium and executed by a processor in the first device. The method may be capable of being disabled during software development in the first device. The message type of the new message may be a request for data. The new message may be a malformed request for data, and wherein the malformed request for data has a relatively low likelihood value. Fuzzing analysis detection may be enabled or disabled using a control bit stored in a memory. Determining the message type of the new message by analyzing the new message may further include using instruction execution circuitry of a processor to decode the new message to determine the message type.
In the example of
Before attacking a device, a hacker needs to know how to craft a malicious message that can be used to exploit a bug in the code. If the source code of the implementation is available to the attacker, the attacker may analyze the source code to find a bug that can be used for an attack. However, the source code of the implementation of many protocols (for a given specific device) is rarely available for commercial products. In such case the attacker may use fuzzing, or fuzz-testing, to discover bugs in the implementation of the target device. A fuzzing analysis performed by an attacker can be successful even without having details of the implementation such as hardware schematics or the source code. Sometimes even a tested piece of code will have some uncaught errors.
Fuzzing analysis detection can be applied to a variety of different use cases and scenarios. For example, fuzzing analysis detection can be applied to most devices that include programs that communicate with other devices such as smartphones, smartcards, card readers, servers, internet of things (IoT) devices, household appliances, automobiles, etc. In terms of ways of communicating, fuzzing detection can be applied to files being used as inputs, messages of a protocol being parsed by a program, a request sent using an API, etc.
Continuing with the above example, from the point of view of the device receiving the requests, in the case of a detected malformed request the device B will answer with an error message. In case of a bug in the program that may make the device miss the error in the malformed request, the device receiving the request may crash or go to an incoherent state. The order in which these messages arrive in a normal scenario for a legitimate device is not completely random. In other words, it is more likely to get a specific type of a request subsequent to certain previously received types of requests. It is expected that at least some of the malformed requests from a fuzzing analysis by an attacker can be detected by the code, and that the implementation of the device is not so bad that the device crashes immediately once any small error is present in a request.
A model that can predict the type of the next request can be built in a lab by observing normal device communication conditions and can also be updated on the fly after a period of data collection from all devices. For example, all devices would send data about types of requests that they received to a server, the server would build the model based on data from all devices and then it can ship it back for use by the devices to predict the message types.
Once the fuzzing analysis is detected the device under analysis can react to undermine the efforts of the attacker and slow down the fuzzing analysis. For example, some types of queries may be forbidden, or some parts of the protocol may be disabled. Also, additional checks and countermeasures may be enabled. For example, a dedicated countermeasure server or part of a server may be alerted. The device may be rebooted or reset, firmware in the device may be erased, or some other action may be performed that is designed to discourage and slow down the attacker. The device can reset to factory settings. The device can erase its memory. Either some of the device configuration, or the entire firmware or even the cryptographic materials embedded in the device may be erased. The device can send a fake response message instead of following the standard expected protocol. The device can also send a message to a special dedicated server and alert it that one of the devices might be under attack or under investigation by a hacker. The device can also ask the user to perform some additional tasks to prove that the user is legitimate, e.g., the user may be asked to authenticate, solve a CAPTCHA or ask the user to prove that he is not a bot in any other way. Such actions that can only be done by humans will seriously slow down any attempt at fuzzing the device. This way an attacker who tries to use fuzzing against a device will have to spend much more effort to discover a bug that can be exploited, and the attacker may be discouraged from continuing the attack.
Instead of taking actions immediately, the device may be set to react to alerts only if a predetermined number of alert raising events occur within a relatively short time frame. This technique can reduce undesirable reactions to false alerts. Note, that the fuzzing detection mechanism, or at least actions taken upon detection should have a mechanism for being disabled because legitimate software developers and testers can use fuzzing during the development phase of a device. One way to disable the fuzzing mechanism may be to assign a bit in a register that can be controlled to enable or disable fuzzing detection. The register may be a secure register or memory location.
Memory 126 may be any kind of memory, such as for example, L1, L2, or L3 cache or system memory. Memory 126 may include volatile memory such as static random-access memory (SRAM) or dynamic RAM (DRAM), or may include non-volatile memory such as flash memory, read only memory (ROM), or other volatile or non-volatile memory. Also, memory 126 may be implemented in a secure hardware element or other type of secure storage. Alternately, memory 126 may be a hard drive implemented externally to data processing system 120 or a register file. In one embodiment, memory 126 may be used to store a look up table for message type prediction and likelihood, or data useful for computing message type predictions.
User interface 128 may be connected to one or more devices for enabling communication with a user such as an administrator. For example, user interface 128 may be enabled for coupling to a display, a mouse, a keyboard, or other input/output device. Network interface 132 may include one or more devices for enabling communication with other hardware devices. For example, network interface 132 may include, or be coupled to, a network interface card (NIC) configured to communicate according to the Ethernet protocol. Also, network interface 132 may implement a TCP/IP stack for communication according to the TCP/IP protocols. Data samples for classification may be input via network interface 132, or similar interface. Various other hardware or configurations for communicating are available.
Instruction memory 130 may include one or more non-transient machine-readable storage media for storing instructions for execution by processor cores 124. In other embodiments, both memories 126 and 130 may store data upon which processor cores 124 may operate. Memories 126 and 130 may also store, for example, encryption, decryption, and verification applications. Memories 126 and 130 may be implemented in a secure hardware element and be tamper resistant.
Machine learning model 134 may be implemented in hardware, software, or a combination of hardware and software. Machine learning model 134 computes predictions for message types of newly received messages using previously received messages, responses to the previously received messages, or other information regarding communication between devices. In one embodiment, machine learning model 134 may be a Long Short-Term Memory (LSTM) network. Long short-term memory networks are a type of recurrent neural network capable of learning order dependence in sequence prediction problems. This is a behavior required in complex problem domains like machine translation, speech recognition, and more.
Various embodiments, or portions of the embodiments, may be implemented in hardware or as instructions on a non-transitory machine-readable storage medium including any mechanism for storing information in a form readable by a machine, such as a personal computer, laptop computer, file server, smart phone, or other computing device. The non-transitory machine-readable storage medium may include volatile and non-volatile memories such as read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage medium, flash memory, and the like. The non-transitory machine-readable storage medium excludes transitory signals.
Although the invention is described herein with reference to specific embodiments, various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention. Any benefits, advantages, or solutions to problems that are described herein with regard to specific embodiments are not intended to be construed as a critical, required, or essential feature or element of any or all the claims.
Furthermore, 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. The term “coupled,” as used herein, is not intended to be limited to a direct coupling or a mechanical coupling.
