Fixed Rechtschreibfehler and added bibliography again
parent
3cddde823b
commit
a7355d8459
16
paper.tex
16
paper.tex
|
@ -193,9 +193,9 @@ In this section, we are going to create an overview of different IoT fuzzers, li
|
||||||
\subsection{Mutational fuzzing}
|
\subsection{Mutational fuzzing}
|
||||||
Mutation based fuzzing is a method of input generation\cite{tfuzz}. Mutational fuzzing requires predefined messages to start the mutation on. These mutation can include e.g.\ bit flipping, checking for out of bound bugs, sending empty data or substituting parts of the message with random data\cite{snipuzz} to explore new program states or trigger unexpected behavior.
|
Mutation based fuzzing is a method of input generation\cite{tfuzz}. Mutational fuzzing requires predefined messages to start the mutation on. These mutation can include e.g.\ bit flipping, checking for out of bound bugs, sending empty data or substituting parts of the message with random data\cite{snipuzz} to explore new program states or trigger unexpected behavior.
|
||||||
\subsection{Generational fuzzer}
|
\subsection{Generational fuzzer}
|
||||||
Generation based fuzzers create messages from scratch while being provided with the format specifications for the input. Creating such a format specification requires manual effort and may even be infeasable, especially if a format is not available\cite{tfuzz}.
|
Generation based fuzzers create messages from scratch while being provided with the format specifications for the input. Creating such a format specification requires manual effort and may even be infeasible, especially if a format is not available\cite{tfuzz}.
|
||||||
\subsection{Snippet-based mutation}
|
\subsection{Snippet-based mutation}
|
||||||
Snipped-based mutation is a novel approach to input generation of Snipuzz\cite{snipuzz}. Snippet-based mutation is the application of the mutation-based fuzzing approach on snippets. Snippets are parts of messages, determined by a heuristic algorithm and hierarchical clustering. Those snippets are categorized by the response they trigger from the IoT device. Snippets are then used to build new messages to trigger new program states. This method of mutation and message generation creates messages, which more likly follow message or protocol constaints of IoT devices, which leads to more effictive fuzzing. Since this mutation method is guided by the response of the tested device, detailed responses are required to accuratly categorize snippets\cite{snipuzz}.
|
Snipped-based mutation is a novel approach to input generation of Snipuzz\cite{snipuzz}. Snippet-based mutation is the application of the mutation-based fuzzing approach on snippets. Snippets are parts of messages, determined by a heuristic algorithm and hierarchical clustering. Those snippets are categorized by the response they trigger from the IoT device. Snippets are then used to build new messages to trigger new program states. This method of mutation and message generation creates messages, which more likely follow message or protocol constraints of IoT devices, which leads to more effective fuzzing. Since this mutation method is guided by the response of the tested device, detailed responses are required to accurately categorize snippets\cite{snipuzz}.
|
||||||
\subsection{Message Structure Tree}
|
\subsection{Message Structure Tree}
|
||||||
Message Structure Tree is a mutational fuzzing technique where the valid input is analyzed to create a tree structure based on heuristics to mutate single fields of the input\cite{hfuzz}. This way the grammar of the protocol can be derived without explicitly providing the input format.
|
Message Structure Tree is a mutational fuzzing technique where the valid input is analyzed to create a tree structure based on heuristics to mutate single fields of the input\cite{hfuzz}. This way the grammar of the protocol can be derived without explicitly providing the input format.
|
||||||
\subsection{Binary Rewriting/Instrumentation}
|
\subsection{Binary Rewriting/Instrumentation}
|
||||||
|
@ -213,7 +213,7 @@ This technique used by Firmcorn\cite{firmcorn} executes firmware instructions in
|
||||||
\subsection{Symbolic Execution}
|
\subsection{Symbolic Execution}
|
||||||
A technique used to increase code coverage by using symbols as input and tracking manipulations and comparisons of them during runtime\cite{avatar}. The usage of the input is then backtracked to solve the constraints of specific code branches if a desired state is reached. Symbolic execution has the problem of path explosions and constraint solving, which poses as an obstacle to scalability\cite{angora}. Path explosions is the exponential increase of code branches the larger the program is. A part of this problem are possible infinite loops. Constraint solving can pose another challenge, since depending on ``how deep'' the programs tracking goes, the calculation of the constraints of a specific branch can be complex.%\textbf{citation needed}.
|
A technique used to increase code coverage by using symbols as input and tracking manipulations and comparisons of them during runtime\cite{avatar}. The usage of the input is then backtracked to solve the constraints of specific code branches if a desired state is reached. Symbolic execution has the problem of path explosions and constraint solving, which poses as an obstacle to scalability\cite{angora}. Path explosions is the exponential increase of code branches the larger the program is. A part of this problem are possible infinite loops. Constraint solving can pose another challenge, since depending on ``how deep'' the programs tracking goes, the calculation of the constraints of a specific branch can be complex.%\textbf{citation needed}.
|
||||||
\subsection{Liveness Check}
|
\subsection{Liveness Check}
|
||||||
By checking for liveness a fuzzer can determine the state of an IoT device. This is done activly by sending regular heartbeat messages to the device or passivly by checking for expected responses of the IoT device.
|
By checking for liveness a fuzzer can determine the state of an IoT device. This is done actively by sending regular heartbeat messages to the device or passively by checking for expected responses of the IoT device.
|
||||||
%
|
%
|
||||||
Liveness checks may cause timeouts to be detected as crashes, which slows down fuzzing. Omitting active liveness check improves performance, since probing packages aren't sent, which make up a certain percentage of traffic that do not contribute to the detection of vulnerabilities during the fuzzing process.
|
Liveness checks may cause timeouts to be detected as crashes, which slows down fuzzing. Omitting active liveness check improves performance, since probing packages aren't sent, which make up a certain percentage of traffic that do not contribute to the detection of vulnerabilities during the fuzzing process.
|
||||||
\subsection{Taint analysis}
|
\subsection{Taint analysis}
|
||||||
|
@ -221,19 +221,19 @@ Taint analysis is used to track data of interest during execution. The data that
|
||||||
\subsection{Stateful Message Generation}
|
\subsection{Stateful Message Generation}
|
||||||
This technique was introduced by SIoTFuzzer\cite{siotfuzzer} which fuzzes web interfaces of IoT devices. Stateful Message Generation (SMG) is divided into three parts: front-end analysis, state analysis and seed generation.
|
This technique was introduced by SIoTFuzzer\cite{siotfuzzer} which fuzzes web interfaces of IoT devices. Stateful Message Generation (SMG) is divided into three parts: front-end analysis, state analysis and seed generation.
|
||||||
%
|
%
|
||||||
SMG considers that communication depends on certain states and therefore groups together messages as a test case to fuzz the target system. So far SMG is only used to fuzz web interfacesin SIoTFuzzer\cite{siotfuzzer}.
|
SMG considers that communication depends on certain states and therefore groups together messages as a test case to fuzz the target system. So far SMG is only used to fuzz web interfaces in SIoTFuzzer\cite{siotfuzzer}.
|
||||||
\subsection{Vulnerability-oriented fuzzing}
|
\subsection{Vulnerability-oriented fuzzing}
|
||||||
Vulnerability-oriented fuzzing is used in Firmcorn\cite{firmcorn}. For this method, static analysis is used to find vulnerable code. Vulnerable code is determined by multiple factors like, complexity, number of memory operations and call to sensitive functions.
|
Vulnerability-oriented fuzzing is used in Firmcorn\cite{firmcorn}. For this method, static analysis is used to find vulnerable code. Vulnerable code is determined by multiple factors like, complexity, number of memory operations and call to sensitive functions.
|
||||||
\subsection{Coverage-oriented fuzzing}
|
\subsection{Coverage-oriented fuzzing}
|
||||||
Coverage-oriented fuzzing generates input with the traversion of different execution paths in mind. This is done to maximize code coverage to reach paths which may be vulnerable. This is done by taking the ability of an input to trigger new paths into account\cite{vuzzer}. While coverage guided fuzzing tries to maximize code coverage, usually most of an softwares code is not vulnerable, therefore a lot of resources are spent on exploring paths, which are not vulnerable.
|
Coverage-oriented fuzzing generates input with the traversion of different execution paths in mind. This is done to maximize code coverage to reach paths which may be vulnerable. This is done by taking the ability of an input to trigger new paths into account\cite{vuzzer}. While coverage guided fuzzing tries to maximize code coverage, usually most of a softwares code is not vulnerable, therefore a lot of resources are spent on exploring paths, which are not vulnerable.
|
||||||
\subsection{Directed fuzzing}
|
\subsection{Directed fuzzing}
|
||||||
Direct fuzzing is the process of generating input with the goal of traversing specific execution paths\cite{vuzzer}.
|
Direct fuzzing is the process of generating input with the goal of traversing specific execution paths\cite{vuzzer}.
|
||||||
Since only a fraction of firmware code has vulnerabilities the graybox approach to fuzzing by increasing code coverage leads to test cases, which end up not finding vulnerabilities\cite{firmcorn}.
|
Since only a fraction of firmware code has vulnerabilities the graybox approach to fuzzing by increasing code coverage leads to test cases, which end up not finding vulnerabilities\cite{firmcorn}.
|
||||||
|
|
||||||
\section{Conclusion}
|
\section{Conclusion}
|
||||||
In this paper we created an overview of the different IoT fuzzing techniques used by state of the art IoT fuzzing tools and compared their approaches in regards of input generation, crash detection heuristics and their device scopes.
|
In this paper we created an overview of the different IoT fuzzing techniques used by state of the art IoT fuzzing tools and compared their approaches in regards to input generation, crash detection heuristics and their device scopes.
|
||||||
%
|
%
|
||||||
The IoT fuzzer we looked at utilized many different techniques to make use of many attack surfaces and even used software outside of the IoT devices themselves to gain information about the device, like IoTFuzzer\cite{iotfuzzer} which used the devices companion app to send fuzzing messages to the tested device.
|
The IoT fuzzer we looked at, utilized many techniques to make use of many attack surfaces and even used software outside the IoT devices themselves to gain information about the device, like IoTFuzzer\cite{iotfuzzer} which used the devices companion app to send fuzzing messages to the tested device.
|
||||||
%\printbibliography{}
|
\printbibliography{}
|
||||||
|
|
||||||
\end{document}
|
\end{document}
|
Loading…
Reference in New Issue