Finished Background, added (IoT-)Fuzzing techniques (wip), added IoT fuzzing intricacies (wip)
TuDatTr
parent
2b0a7e10fd
commit
ecbeb6e79d
279
bibliography.bib
279
bibliography.bib
|
|
@ -1,3 +1,41 @@
|
||||||
|
@inproceedings{grammarinator,
|
||||||
|
author = {Ren{\'{a}}ta Hodov{\'{a}}n and
|
||||||
|
{\'{A}}kos Kiss and
|
||||||
|
Tibor Gyim{\'{o}}thy},
|
||||||
|
editor = {Wishnu Prasetya and
|
||||||
|
Tanja E. J. Vos and
|
||||||
|
Sinem Getir},
|
||||||
|
title = {Grammarinator: a grammar-based open source fuzzer},
|
||||||
|
booktitle = {Proceedings of the 9th {ACM} {SIGSOFT} International Workshop on Automating
|
||||||
|
{TEST} Case Design, Selection, and Evaluation, A-TEST@ESEC/SIGSOFT
|
||||||
|
{FSE} 2018, Lake Buena Vista, FL, USA, November 05, 2018},
|
||||||
|
pages = {45--48},
|
||||||
|
publisher = {{ACM}},
|
||||||
|
year = {2018},
|
||||||
|
url = {https://doi.org/10.1145/3278186.3278193},
|
||||||
|
doi = {10.1145/3278186.3278193},
|
||||||
|
timestamp = {Wed, 09 Jan 2019 17:56:06 +0100},
|
||||||
|
biburl = {https://dblp.org/rec/conf/sigsoft/Hodovan0G18.bib},
|
||||||
|
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{modelfuzz,
|
||||||
|
author = {Pham, Van-Thuan and B\"{o}hme, Marcel and Roychoudhury, Abhik},
|
||||||
|
title = {Model-Based Whitebox Fuzzing for Program Binaries},
|
||||||
|
year = {2016},
|
||||||
|
isbn = {9781450338455},
|
||||||
|
publisher = {Association for Computing Machinery},
|
||||||
|
address = {New York, NY, USA},
|
||||||
|
url = {https://doi.org/10.1145/2970276.2970316},
|
||||||
|
doi = {10.1145/2970276.2970316},
|
||||||
|
booktitle = {Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering},
|
||||||
|
pages = {543–553},
|
||||||
|
numpages = {11},
|
||||||
|
keywords = {Program Binaries, Symbolic Execution},
|
||||||
|
location = {Singapore, Singapore},
|
||||||
|
series = {ASE 2016}
|
||||||
|
}
|
||||||
|
|
||||||
@article{hung2017leading,
|
@article{hung2017leading,
|
||||||
title={Leading the IoT Gartner Insight on How to Lead in a Cnnected World},
|
title={Leading the IoT Gartner Insight on How to Lead in a Cnnected World},
|
||||||
author={Hung, Mark},
|
author={Hung, Mark},
|
||||||
|
|
@ -23,6 +61,14 @@
|
||||||
urldate = {2021-05-20}
|
urldate = {2021-05-20}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@online{xss,
|
||||||
|
author = {The OWASP Foundation},
|
||||||
|
title = {Cross Site Scripting (XSS) Software Attack | OWASP},
|
||||||
|
year = 2021,
|
||||||
|
url = {https://web.archive.org/web/20210615012447/https://owasp.org/www-community/attacks/xss/},
|
||||||
|
urldate = {2021-06-15}
|
||||||
|
}
|
||||||
|
|
||||||
@online{OWASP2021Fuzzing,
|
@online{OWASP2021Fuzzing,
|
||||||
author = {The OWASP Foundation},
|
author = {The OWASP Foundation},
|
||||||
title = {Fuzzing | OWASP},
|
title = {Fuzzing | OWASP},
|
||||||
|
|
@ -31,6 +77,110 @@
|
||||||
urldate = {2021-04-14}
|
urldate = {2021-04-14}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@inproceedings{iothunter,
|
||||||
|
author = {Bo Yu and
|
||||||
|
Pengfei Wang and
|
||||||
|
Tai Yue and
|
||||||
|
Yong Tang},
|
||||||
|
editor = {Lorenzo Cavallaro and
|
||||||
|
Johannes Kinder and
|
||||||
|
XiaoFeng Wang and
|
||||||
|
Jonathan Katz},
|
||||||
|
title = {Poster: Fuzzing IoT Firmware via Multi-stage Message Generation},
|
||||||
|
booktitle = {Proceedings of the 2019 {ACM} {SIGSAC} Conference on Computer and
|
||||||
|
Communications Security, {CCS} 2019, London, UK, November 11-15, 2019},
|
||||||
|
pages = {2525--2527},
|
||||||
|
publisher = {{ACM}},
|
||||||
|
year = {2019},
|
||||||
|
url = {https://doi.org/10.1145/3319535.3363247},
|
||||||
|
doi = {10.1145/3319535.3363247},
|
||||||
|
timestamp = {Tue, 10 Nov 2020 20:00:54 +0100},
|
||||||
|
biburl = {https://dblp.org/rec/conf/ccs/YuWYT19.bib},
|
||||||
|
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{hfuzz,
|
||||||
|
author = {Xinyao Liu and
|
||||||
|
Baojiang Cui and
|
||||||
|
Junsong Fu and
|
||||||
|
Jinxin Ma},
|
||||||
|
title = {HFuzz: Towards automatic fuzzing testing of NB-IoT core network protocols
|
||||||
|
implementations},
|
||||||
|
journal = {Future Gener. Comput. Syst.},
|
||||||
|
volume = {108},
|
||||||
|
pages = {390--400},
|
||||||
|
year = {2020},
|
||||||
|
url = {https://doi.org/10.1016/j.future.2019.12.032},
|
||||||
|
doi = {10.1016/j.future.2019.12.032},
|
||||||
|
timestamp = {Mon, 18 May 2020 17:42:49 +0200},
|
||||||
|
biburl = {https://dblp.org/rec/journals/fgcs/LiuCFM20.bib},
|
||||||
|
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{siotfuzzer,
|
||||||
|
title={SIoTFuzzer: Fuzzing Web Interface in IoT Firmware via Stateful Message Generation},
|
||||||
|
author={Zhang, Hangwei and Lu, Kai and Zhou, Xu and Yin, Qidi and Wang, Pengfei and Yue, Tai},
|
||||||
|
journal={Applied Sciences},
|
||||||
|
volume={11},
|
||||||
|
number={7},
|
||||||
|
pages={3120},
|
||||||
|
year={2021},
|
||||||
|
publisher={Multidisciplinary Digital Publishing Institute}
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{diane,
|
||||||
|
title={DIANE: Identifying Fuzzing Triggers in Apps to Generate Under-constrained Inputs for IoT Devices},
|
||||||
|
author={Redini, Nilo and Continella, Andrea and Das, Dipanjan and De Pasquale, Giulio and Spahn, Noah and Machiry, Aravind and Bianchi, Antonio and Kruegel, Christopher and Vigna, Giovanni},
|
||||||
|
booktitle={42nd IEEE Symposium on Security and Privacy 2021},
|
||||||
|
year={2021}
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{firmfuzz,
|
||||||
|
author = {Prashast Srivastava and
|
||||||
|
Hui Peng and
|
||||||
|
Jiahao Li and
|
||||||
|
Hamed Okhravi and
|
||||||
|
Howard E. Shrobe and
|
||||||
|
Mathias Payer},
|
||||||
|
editor = {Peng Liu and
|
||||||
|
Yuqing Zhang},
|
||||||
|
title = {FirmFuzz: Automated IoT Firmware Introspection and Analysis},
|
||||||
|
booktitle = {Proceedings of the 2nd International {ACM} Workshop on Security and
|
||||||
|
Privacy for the Internet-of-Things, IoT S{\&}P@CCS 2019, London,
|
||||||
|
UK, November 15, 2019},
|
||||||
|
pages = {15--21},
|
||||||
|
publisher = {{ACM}},
|
||||||
|
year = {2019},
|
||||||
|
url = {https://doi.org/10.1145/3338507.3358616},
|
||||||
|
doi = {10.1145/3338507.3358616},
|
||||||
|
timestamp = {Tue, 10 Nov 2020 16:06:16 +0100},
|
||||||
|
biburl = {https://dblp.org/rec/conf/ccs/SrivastavaPLOSP19.bib},
|
||||||
|
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{mulbin,
|
||||||
|
author = {Nilo Redini and
|
||||||
|
Aravind Machiry and
|
||||||
|
Ruoyu Wang and
|
||||||
|
Chad Spensky and
|
||||||
|
Andrea Continella and
|
||||||
|
Yan Shoshitaishvili and
|
||||||
|
Christopher Kruegel and
|
||||||
|
Giovanni Vigna},
|
||||||
|
title = {Karonte: Detecting Insecure Multi-binary Interactions in Embedded
|
||||||
|
Firmware},
|
||||||
|
booktitle = {2020 {IEEE} Symposium on Security and Privacy, {SP} 2020, San Francisco,
|
||||||
|
CA, USA, May 18-21, 2020},
|
||||||
|
pages = {1544--1561},
|
||||||
|
publisher = {{IEEE}},
|
||||||
|
year = {2020},
|
||||||
|
url = {https://doi.org/10.1109/SP40000.2020.00036},
|
||||||
|
doi = {10.1109/SP40000.2020.00036},
|
||||||
|
timestamp = {Thu, 20 Aug 2020 17:04:50 +0200},
|
||||||
|
biburl = {https://dblp.org/rec/conf/sp/RediniM0SCSKV20.bib},
|
||||||
|
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||||
|
}
|
||||||
|
|
||||||
@article{lowendos,
|
@article{lowendos,
|
||||||
author = {Oliver Hahm and
|
author = {Oliver Hahm and
|
||||||
Emmanuel Baccelli and
|
Emmanuel Baccelli and
|
||||||
|
|
@ -209,11 +359,56 @@
|
||||||
bibsource = {dblp computer science bibliography, https://dblp.org}
|
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@Misc{aflpp,
|
||||||
|
title = {American Fuzzy Lop plus plus},
|
||||||
|
howpublished = {\url{https://github.com/AFLplusplus/AFLplusplus}},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Misc{panda,
|
||||||
|
title = {Panda},
|
||||||
|
howpublished = {\url{https://github.com/panda-re/panda}},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Misc{afl,
|
||||||
|
title = {american fuzzy lob},
|
||||||
|
howpublished = {\url{https://github.com/google/AFL}},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Misc{xsstrike,
|
||||||
|
title = {XSStrike},
|
||||||
|
howpublished = {\url{https://github.com/s0md3v/XSStrike}},
|
||||||
|
}
|
||||||
|
|
||||||
@Misc{binwalk,
|
@Misc{binwalk,
|
||||||
title = {Binwalk},
|
title = {Binwalk},
|
||||||
howpublished = {\url{https://github.com/ReFirmLabs/binwalk}},
|
howpublished = {\url{https://github.com/ReFirmLabs/binwalk}},
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@Misc{valgrind,
|
||||||
|
title = {Valgrind},
|
||||||
|
howpublished = {\url{https://www.valgrind.org/}},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Misc{triforceafl,
|
||||||
|
title = {TriforceAFL},
|
||||||
|
howpublished = {\url{https://github.com/nccgroup/TriforceAFL}},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Misc{fuzzdb,
|
||||||
|
title = {FuzzDB},
|
||||||
|
howpublished = {\url{https://github.com/fuzzdb-project/fuzzdb}},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Misc{blons,
|
||||||
|
title = {Big List of Naughty Strings},
|
||||||
|
howpublished = {\url{https://github.com/minimaxir/big-list-of-naughty-strings}},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Misc{radamsa,
|
||||||
|
title = {radamsa},
|
||||||
|
howpublished = {\url{https://gitlab.com/akihe/radamsa}},
|
||||||
|
}
|
||||||
|
|
||||||
@Misc{IDA,
|
@Misc{IDA,
|
||||||
title = {IDA Pro},
|
title = {IDA Pro},
|
||||||
howpublished = {\url{https://hex-rays.com/ida-pro/}},
|
howpublished = {\url{https://hex-rays.com/ida-pro/}},
|
||||||
|
|
@ -263,3 +458,87 @@ howpublished = {\url{https://github.com/jtpereyda/boofuzz}},
|
||||||
biburl = {https://dblp.org/rec/conf/ndss/MuenchSKFB18.bib},
|
biburl = {https://dblp.org/rec/conf/ndss/MuenchSKFB18.bib},
|
||||||
bibsource = {dblp computer science bibliography, https://dblp.org}
|
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@inproceedings{tfuzz,
|
||||||
|
author = {Hui Peng and
|
||||||
|
Yan Shoshitaishvili and
|
||||||
|
Mathias Payer},
|
||||||
|
title = {T-Fuzz: Fuzzing by Program Transformation},
|
||||||
|
booktitle = {2018 {IEEE} Symposium on Security and Privacy, {SP} 2018, Proceedings,
|
||||||
|
21-23 May 2018, San Francisco, California, {USA}},
|
||||||
|
pages = {697--710},
|
||||||
|
publisher = {{IEEE} Computer Society},
|
||||||
|
year = {2018},
|
||||||
|
url = {https://doi.org/10.1109/SP.2018.00056},
|
||||||
|
doi = {10.1109/SP.2018.00056},
|
||||||
|
timestamp = {Wed, 16 Oct 2019 14:14:51 +0200},
|
||||||
|
biburl = {https://dblp.org/rec/conf/sp/PengSP18.bib},
|
||||||
|
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{angora,
|
||||||
|
author = {Peng Chen and
|
||||||
|
Hao Chen},
|
||||||
|
title = {Angora: Efficient Fuzzing by Principled Search},
|
||||||
|
booktitle = {2018 {IEEE} Symposium on Security and Privacy, {SP} 2018, Proceedings,
|
||||||
|
21-23 May 2018, San Francisco, California, {USA}},
|
||||||
|
pages = {711--725},
|
||||||
|
publisher = {{IEEE} Computer Society},
|
||||||
|
year = {2018},
|
||||||
|
url = {https://doi.org/10.1109/SP.2018.00046},
|
||||||
|
doi = {10.1109/SP.2018.00046},
|
||||||
|
timestamp = {Wed, 16 Oct 2019 14:14:51 +0200},
|
||||||
|
biburl = {https://dblp.org/rec/conf/sp/ChenC18.bib},
|
||||||
|
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{karonte,
|
||||||
|
author = {Nilo Redini and
|
||||||
|
Aravind Machiry and
|
||||||
|
Ruoyu Wang and
|
||||||
|
Chad Spensky and
|
||||||
|
Andrea Continella and
|
||||||
|
Yan Shoshitaishvili and
|
||||||
|
Christopher Kruegel and
|
||||||
|
Giovanni Vigna},
|
||||||
|
title = {Karonte: Detecting Insecure Multi-binary Interactions in Embedded
|
||||||
|
Firmware},
|
||||||
|
booktitle = {2020 {IEEE} Symposium on Security and Privacy, {SP} 2020, San Francisco,
|
||||||
|
CA, USA, May 18-21, 2020},
|
||||||
|
pages = {1544--1561},
|
||||||
|
publisher = {{IEEE}},
|
||||||
|
year = {2020},
|
||||||
|
url = {https://doi.org/10.1109/SP40000.2020.00036},
|
||||||
|
doi = {10.1109/SP40000.2020.00036},
|
||||||
|
timestamp = {Thu, 20 Aug 2020 17:04:50 +0200},
|
||||||
|
biburl = {https://dblp.org/rec/conf/sp/RediniM0SCSKV20.bib},
|
||||||
|
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{vuzzer,
|
||||||
|
author = {Sanjay Rawat and
|
||||||
|
Vivek Jain and
|
||||||
|
Ashish Kumar and
|
||||||
|
Lucian Cojocar and
|
||||||
|
Cristiano Giuffrida and
|
||||||
|
Herbert Bos},
|
||||||
|
title = {VUzzer: Application-aware Evolutionary Fuzzing},
|
||||||
|
booktitle = {24th Annual Network and Distributed System Security Symposium, {NDSS}
|
||||||
|
2017, San Diego, California, USA, February 26 - March 1, 2017},
|
||||||
|
publisher = {The Internet Society},
|
||||||
|
year = {2017},
|
||||||
|
url = {https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/vuzzer-application-aware-evolutionary-fuzzing/},
|
||||||
|
timestamp = {Mon, 01 Feb 2021 08:42:22 +0100},
|
||||||
|
biburl = {https://dblp.org/rec/conf/ndss/0001JKCGB17.bib},
|
||||||
|
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{compwbgbox,
|
||||||
|
title={A comparative study of white box, black box and grey box testing techniques},
|
||||||
|
author={Khan, Mohd Ehmer and Khan, Farmeena and others},
|
||||||
|
journal={Int. J. Adv. Comput. Sci. Appl},
|
||||||
|
volume={3},
|
||||||
|
number={6},
|
||||||
|
year={2012},
|
||||||
|
publisher={Citeseer}
|
||||||
|
}
|
||||||
|
|
|
||||||
Binary file not shown.
|
|
@ -0,0 +1,74 @@
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{4}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{4}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{5}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{5}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{5}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{5}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{6}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{6}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{6}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{6}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{8}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{8}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{8}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{8}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{8}
|
||||||
|
|
@ -0,0 +1,74 @@
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{1}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{2}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{3}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{4}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{4}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{5}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{5}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{5}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{5}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{6}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{6}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{6}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{6}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{7}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{8}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{8}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{8}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{8}
|
||||||
|
\glossaryentry{IoT?\glossentry{IoT}|setentrycounter[]{page}\glsnumberformat}{8}
|
||||||
|
|
@ -0,0 +1,31 @@
|
||||||
|
% makeindex style file created by the glossaries package
|
||||||
|
% for document 'paper' on 2021-6-19
|
||||||
|
actual '?'
|
||||||
|
encap '|'
|
||||||
|
level '!'
|
||||||
|
quote '"'
|
||||||
|
keyword "\\glossaryentry"
|
||||||
|
preamble "\\glossarysection[\\glossarytoctitle]{\\glossarytitle}\\glossarypreamble\n\\begin{theglossary}\\glossaryheader\n"
|
||||||
|
postamble "\%\n\\end{theglossary}\\glossarypostamble\n"
|
||||||
|
group_skip "\\glsgroupskip\n"
|
||||||
|
item_0 "\%\n"
|
||||||
|
item_1 "\%\n"
|
||||||
|
item_2 "\%\n"
|
||||||
|
item_01 "\%\n"
|
||||||
|
item_x1 "\\relax \\glsresetentrylist\n"
|
||||||
|
item_12 "\%\n"
|
||||||
|
item_x2 "\\relax \\glsresetentrylist\n"
|
||||||
|
delim_0 "\{\\glossaryentrynumbers\{\\relax "
|
||||||
|
delim_1 "\{\\glossaryentrynumbers\{\\relax "
|
||||||
|
delim_2 "\{\\glossaryentrynumbers\{\\relax "
|
||||||
|
delim_t "\}\}"
|
||||||
|
delim_n "\\delimN "
|
||||||
|
delim_r "\\delimR "
|
||||||
|
headings_flag 1
|
||||||
|
heading_prefix "\\glsgroupheading\{"
|
||||||
|
heading_suffix "\}\\relax \\glsresetentrylist "
|
||||||
|
symhead_positive "glssymbols"
|
||||||
|
numhead_positive "glsnumbers"
|
||||||
|
page_compositor "."
|
||||||
|
suffix_2p ""
|
||||||
|
suffix_3p ""
|
||||||
169
paper.tex
169
paper.tex
|
|
@ -33,10 +33,12 @@
|
||||||
% \usepackage[parfill]{parskip}
|
% \usepackage[parfill]{parskip}
|
||||||
\addbibresource{bibliography.bib}
|
\addbibresource{bibliography.bib}
|
||||||
|
|
||||||
|
|
||||||
\usepackage{blindtext}
|
\usepackage{blindtext}
|
||||||
\newcommand\blindsection{{\color{gray}\subsection{Some bindtext}\blindtext}}
|
\newcommand\blindsection{{\color{gray}\subsection{Some bindtext}\blindtext}}
|
||||||
|
|
||||||
\begin{document} \title{Overview of IoT Fuzzing Techniques}
|
\begin{document}
|
||||||
|
\title{Overview of IoT Fuzzing Techniques}
|
||||||
\author{\IEEEauthorblockN{Tuan-Dat
|
\author{\IEEEauthorblockN{Tuan-Dat
|
||||||
Tran\\\small(3012345)}\\\IEEEauthorblockA{University of
|
Tran\\\small(3012345)}\\\IEEEauthorblockA{University of
|
||||||
Duisburg-Essen\\tuan-dat.tran@stud.uni-due.de}}
|
Duisburg-Essen\\tuan-dat.tran@stud.uni-due.de}}
|
||||||
|
|
@ -44,7 +46,7 @@
|
||||||
\maketitle
|
\maketitle
|
||||||
|
|
||||||
\begin{abstract}
|
\begin{abstract}
|
||||||
Due to the rising popularity of IoT devices and embedded systems and their usage in, not only in the business sector, but also at home, the view has been shifting on the security of those devices. To address this issue, there have been many approaches in detecting, analyzing and mitigation of security flaws in IoT devices. One of the ideas to detect vulnerabilities in an automated manner is IoT Fuzzing. Contrary to regular fuzzing it comes with its own constraints and techniques to optimize performance and coverage of attack surfaces.
|
Due to the rising popularity of IoT devices and embedded systems and their usage in, not only in the business sector, but also at home, the focus has been shifting on the security of those devices. To address this issue, there have been many approaches in detecting, analyzing and mitigating security flaws in IoT devices. One of the ideas to detect vulnerabilities in an automated manner is IoT Fuzzing. Contrary to regular fuzzing it comes with its own constraints and techniques to optimize performance and coverage of attack surfaces.
|
||||||
|
|
||||||
In this paper we are comparing techniques used by IoT fuzzers to circumvent the adversities presented by IoT devices like app-based approaches by IoTFuzzer and Snipuzz or emulation approaches used by Firm-Afl.
|
In this paper we are comparing techniques used by IoT fuzzers to circumvent the adversities presented by IoT devices like app-based approaches by IoTFuzzer and Snipuzz or emulation approaches used by Firm-Afl.
|
||||||
|
|
||||||
|
|
@ -62,77 +64,172 @@ Fuzzing is a method to test software for flaws by automatically generating and s
|
||||||
|
|
||||||
Due to fuzzing being an automated process, fuzzing became a common tool for software testing in software development. Conventional fuzzing of software can be easily done concurrently, since software can, in most cases, be easily executed concurrently\cite{crash}. This increases the throughput of the fuzzer and thus the amount of test cases the software is tested against. This is one of the issues, which IoT fuzzers have to deal with, since the fuzzing IoT devices usually include fuzzing the physical device itself if there is no emulation solution available, while emulation enables another class of issues and complexity to the fuzzing process. An example for an arising problem due to emulation is the acquisition of the firmware. The process of firmware acquisition is different for every device, since it is dependant on the willingness of the manufacturer to publicly release the firmware. If the manufacturer does not release the firmeware for his device the firmware needs to be extracted directly from the device, which can vary in difficulty depending on the device\cite{crash}.
|
Due to fuzzing being an automated process, fuzzing became a common tool for software testing in software development. Conventional fuzzing of software can be easily done concurrently, since software can, in most cases, be easily executed concurrently\cite{crash}. This increases the throughput of the fuzzer and thus the amount of test cases the software is tested against. This is one of the issues, which IoT fuzzers have to deal with, since the fuzzing IoT devices usually include fuzzing the physical device itself if there is no emulation solution available, while emulation enables another class of issues and complexity to the fuzzing process. An example for an arising problem due to emulation is the acquisition of the firmware. The process of firmware acquisition is different for every device, since it is dependant on the willingness of the manufacturer to publicly release the firmware. If the manufacturer does not release the firmeware for his device the firmware needs to be extracted directly from the device, which can vary in difficulty depending on the device\cite{crash}.
|
||||||
|
|
||||||
Alternativly to fuzzing there are other ways to test software for vulnerabilities like static and dynamic firmware analysis. Static firmware analysis is the analysis of firmware without executing it by using tools like binwalk\cite{binwalk} to unpack the firmware and reverse engineering it with an reverse engineering tool like IDA\cite{IDA}\cite{firmup}. For dynamic analysis the firmware is executed to be investigated. This can be done in a multitude of ways, for example running the firmware on the original device or emulating the device to have the firmware run in the emulated environment. The running firmwares behavior is then analyzed\cite{autodyn}. The advantage of static analysis is the possibility to automate and scaling the processes of analyzing the firmware\cite{largeanal}, since the testing does not depend on a physical device. On the other hand, static analysis also yields a high amount of false positives and may not find completly new vulnerabilities, with the usage of its heuristics\cite{firmafl}. Another challenge during static analysis is the handling of packed or obfuscated code. This can be overcome with dynamic analysis\cite{avatar} by emulating the physical device, which increases scalability and eliminates the need to acquire the physical device to test it\cite{autodyn}.
|
Alternativly to fuzzing there are other ways to test software for vulnerabilities like static and dynamic firmware analysis. Static firmware analysis is the analysis of firmware without executing it by using tools like binwalk\cite{binwalk} to unpack the firmware and reverse engineering it with a reverse engineering tool like IDA\cite{IDA}\cite{firmup}. For dynamic analysis the firmware is executed to be investigated. This can be done in a multitude of ways, for example running the firmware on the original device or emulating the device to have the firmware run in the emulated environment. The running firmwares behavior is then analyzed\cite{autodyn}. The advantage of static analysis is the possibility to automate and scaling the processes of analyzing the firmware\cite{largeanal}, since the testing does not depend on a physical device. On the other hand, static analysis also yields a high amount of false positives and may not find completly new vulnerabilities, with the usage of its heuristics\cite{firmafl}. Another challenge during static analysis is the handling of packed or obfuscated code. This can be overcome with dynamic analysis\cite{avatar} by emulating the physical device, which increases scalability and eliminates the need to acquire the physical device to test it\cite{autodyn}.
|
||||||
|
|
||||||
Since IoT devices offer a large surface area regarding communication e.g.\ network protocols, their companion app or their web interface\cite{iotfuzzer}\cite{boofuzz}\cite{wmifuzzer}. For this reason fuzzers, which were not originally designed to fuzz IoT devices can still be utilized for IoT fuzzing, like in the case of boofuzz, which was developed with the intent to fuzz network protocols\cite{boofuzz}. IoT fuzzers can also make use of techniques used by dynamic analysis, since both approaches require execution of the firmware. This makes emulation a feasable way of testing IoT devices to increase scalability\cite{firmcorn}. In this work we will focus mainly on fuzzers, which were primarily developed for IoT fuzzing, but since techniques used by non-IoT focused fuzzers are also used by fuzzers, that focus on IoT devices, non-IoT focused fuzzers will be considered in the overview.
|
Since IoT devices offer a large surface area regarding communication e.g.\ network protocols, their companion app or their web interface\cite{iotfuzzer}\cite{boofuzz}\cite{wmifuzzer}. For this reason fuzzers, which were not originally designed to fuzz IoT devices can still be utilized for IoT fuzzing, like in the case of boofuzz, which was developed with the intent to fuzz network protocols\cite{boofuzz}. IoT fuzzers can also make use of techniques used by dynamic analysis, since both approaches require execution of the firmware. This makes emulation a feasable way of testing IoT devices to increase scalability\cite{firmcorn}. In this work we will focus mainly on fuzzers, which were primarily developed for IoT fuzzing, but since techniques used by non-IoT focused fuzzers are also used by fuzzers, that focus on IoT devices, non-IoT focused fuzzers will be considered in the overview.
|
||||||
|
|
||||||
Even though IoT fuzzers are used for finding security vulnerabilities in devices and fixing those errors or learning from them and mitigating them is the next logical step we will not discuss mitigation techniques in this paper, since this is outside of our scope. We will also not dive deep into specific techniques and how they work in detail or are implemented.
|
Even though IoT fuzzers are used for finding security vulnerabilities in devices and fixing those errors or learning from them and mitigating them is the next logical step we will not discuss mitigation techniques in this paper, since this is outside of our scope. We will also not dive deep into the implementations of specific techniques.
|
||||||
|
|
||||||
By creating an overview of different IoT fuzzing techniques we hope to archive a comprehensive list of IoT fuzzing tools and their properties to help developers and researchers to find the right tool for their job and weight in the positive on negative aspects of existing approaches to improve upon them.
|
By creating an overview of different IoT fuzzing techniques we hope to archive a comprehensive list of IoT fuzzing tools and their properties to help developers and researchers to find the right tool for their job and weight in the positive on negative aspects of existing approaches to improve upon them.
|
||||||
\section{Background}
|
\section{Background}
|
||||||
\subsection{IoT devices and embedded systems}
|
\subsection{IoT devices and embedded systems}
|
||||||
|
|
||||||
The terms IoT devices and embedded systems describe a great amount of devices. Embedded systems are devices, interact with their surroundings via sensors and regulators and are built to serve a specific purpose\cite{crash}. IoT devices on the other hand are broadly described as devices, which extend regular devices with an internet connection and enable them to communicate over it\cite{posey2021iot}. The term embedded devices can describe many devices such as cameras or industrial control systems (ICS), which makes it hard to make general statements about embedded devices. The same is the case for IoT devices, which includes the definition of internet capable embedded systems. Ongoing, when we describe IoT devices, the description also fits embedded systems if not explicitly mentioned.
|
The terms IoT devices and embedded systems describe a great amount of devices. Embedded systems are devices, which interact with their surroundings via sensors and regulators and are built to serve a specific purpose\cite{crash}. IoT devices on the other hand are broadly described as devices, which extend regular devices with an internet connection and enable them to communicate over it\cite{posey2021iot}. The term embedded devices can describe many devices such as cameras or industrial control systems (ICS), which makes it hard to generalize embedded devices. This also applies to IoT devices, which includes the definition of internet capable embedded systems. Ongoing, when we describe IoT devices, the description also fits embedded systems if not explicitly mentioned.
|
||||||
|
|
||||||
IoT devices, due to being built for specific purposes, don't need as much processing power as a general computer does. This leads to them having an hardware platform specifically tailored to their use case. For this reason the amount of different hardware and software architectures used in IoT devices is diverse and unlistable.
|
The wide applicability of IoT devices in the context of business, manufacturing and home-use increases the surface area for vulnerabilities to be found. IoT devices being so diverse regarding their functionalities and ways to offer their services further increases the possible ways to accumulate vulnerabilities\textbf{citation neeeded}.
|
||||||
%
|
|
||||||
The works of Hahm et al.\cite{lowendos} proposes a classification into low-end and high-end IoT devices and deviding those two classificatoins into three subcategories for low-end devices. Those classes represent the complexity and computing capability of those devices with ``Class 0'' having the least resources and ``Class 2'' devices having the most resources.
|
|
||||||
%
|
|
||||||
In the works of Muench et al.\cite{crash} a similar classification is done. They are classified in ``Type-0'' to ``Type-III'' systems. T0 (Type-0) systems represent multi-purpose systems, which don't fall under the classification of embedded systems or IoT devices. T1 (Type-1) devices are devices, which use a general purpose operating system like Linux. The OS (operating system) is often modified to be more lightweight and offer a lightweight user environment like busybox. T2 (Type-2) devices run on customized operating systems, which are tailored to the devices use case. In order to save space and computational power typical OS functions like a Memory Management Unit may be omited. T3 (Type-3) devices run on a single control loop. On these devices the firmware and the software, which runs the devices functionalities, are a single instance. This leads to a so called ``monolithic firmware'', consisting of the application and system code compiled together.
|
|
||||||
|
|
||||||
We will later use these classes, and especially those proposed by Muench et al.\cite{crash} to classify IoT devices when comparing IoT fuzzing techniques, since different types of IoT devices require different approaches to fuzzing.
|
IoT devices, due to being built for specific purposes, don't need as much processing power as a general computer does. This leads to them having an hardware platform specifically tailored to their use case. And due to the heterogenic nature of IoT devices in terms of e.g. OS, instruction sets or memory layouts, analysis of the firmware proves difficult\cite{largeanal}. Reasons for this are the different requirements a manufacturer has for the device like the energy efficiency, real-time capabilty or memory footprint\cite{lowendos}.
|
||||||
|
|
||||||
Due to the heterogenic nature of IoT devices in terms of e.g. OS, instruction sets or memory layouts, analysis of the firmware proves difficult\cite{largeanal}. Reasons for this are the different requirements a manufacturer has for his device like the energy efficiency, real-time capabilty or memory footprint\cite{lowendos}.
|
|
||||||
|
|
||||||
\begin{figure}
|
\begin{figure}
|
||||||
\begin{center}
|
\begin{center}
|
||||||
\includegraphics[width=\linewidth]{iotnetwork}
|
\includegraphics[width=\linewidth]{iotnetwork}
|
||||||
\end{center}
|
\end{center}
|
||||||
\caption{Example of IoT home network.}\label{fig:iotnetwork}
|
\caption{Example of IoT home network (inspred by Wang et al.\cite{wmifuzzer}).}\label{fig:iotnetwork}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
Like mentioned earlier IoT devices, and especially home-based ones, use a multiple ways to connect to the internet. Either directly through WiFi or via a intermediary device like a smartphone and connecting to it with Bluetooth\cite{wmifuzzer}. Another way is having an IoT hub, which acts as proxy between other IoT devices and either another intermediary via Bluetooth or directly WiFi. This leads to many ways an IoT network can be structured, depending on the kind and number of IoT devices (\Cref{fig:iotnetwork}).
|
Like mentioned earlier IoT devices, and especially home-based ones, use multiple ways to connect to the internet. Either directly through WiFi or via a intermediary device like a smartphone and connecting to it with Bluetooth\cite{wmifuzzer}. Another way is having an IoT hub, which acts as proxy between other IoT devices and either another intermediary via Bluetooth or directly WiFi. This leads to many ways an IoT network can be structured, depending on the kind and number of IoT devices (\Cref{fig:iotnetwork}).
|
||||||
|
|
||||||
|
IoT firmware is the bridge between the hardware of the device and the software running on it. Firmware expects presence of certain hardware at boot- and/or runtime and may log the error or keeps trying to find it and goes into a busy loop\cite{firmfuzz}. Sometimtes IoT firmware can be acquired through the vendors website. Alternative methods for acquiring the firmware are extraction from the physical device, even though this way can be challenging due to debugging ports (e.g. JTAG interface) to dump the firmware from the device may not be available\cite{iotfuzzer}\cite{mulbin}.
|
||||||
|
%
|
||||||
|
Additionally firmware is often packed or even encrypted, which poses as an obstacle for firmware analysis. In some cases proprietary compression algorithms or encryption without knowledge of the secret key makes firmware analysis infeasable or even impossible.
|
||||||
|
|
||||||
|
The works of Hahm et al.\cite{lowendos} proposes a classification into low-end and high-end IoT devices and deviding those two classificatoins into three subcategories for low-end devices. Those classes represent the complexity and computing capability of those devices with ``Class 0'' having the least resources and ``Class 2'' devices having the most resources.
|
||||||
|
%
|
||||||
|
In the works of Muench et al.\cite{crash} a similar classification is done. They are classified in ``Type-0'' to ``Type-III'' systems. T0 (Type-0) systems represent multi-purpose systems, which don't fall under the classification of embedded systems or IoT devices. T1 (Type-1) devices are devices, which use a general purpose operating system like Linux. The OS (operating system) is often modified to be more lightweight and offer a lightweight user environment like busybox. T2 (Type-2) devices run on customized operating systems, which are tailored to the devices use case. In order to save space and computational power typical OS functions like a Memory Management Unit may be omited. T3 (Type-3) devices run on a single control loop. On these devices the firmware and the software, which runs the devices functionalities, are a single instance. This leads to a so called ``blob firmware''\cite{karonte}, consisting of the application and system code compiled together. Muench et al.\cite{crash} add, that the classification of the device merely indicates about the kind of available security mechanisms, while the usage of them varies from device to device.
|
||||||
|
|
||||||
|
We will later use these classes, and especially those proposed by Muench et al.\cite{crash}, to classify IoT devices when comparing IoT fuzzing techniques, since different types of IoT devices require different approaches to fuzzing, while also posing different challenges.
|
||||||
|
|
||||||
|
Multi-purpose systems (i.e.\ smartphones and computers) deploy many mechanisms to detect faults like segmentation faults and report them through core dumps. IoT devices may not have such functionalities due to their more minimalistic designs to only perform the tasks they were built for. Therefore functionalities like heap hardening may not be present due to the IoT devices limited computing power and constrained costs\cite{crash}.
|
||||||
|
|
||||||
\subsection{Fuzzing}
|
\subsection{Fuzzing}
|
||||||
|
Fuzzing describes the process of testing a software for faulty and unexpcted behavior by sending malformed messages as input for the software\cite{OWASP2021Fuzzing}. The basic fuzzing process can be divided into three steps: (1) input generation (2) sending messages as input to software and (3) monitor software behavior in reaction to the given input (\Cref{fig:fuzzing}). Due to the need to have the tested software running, fuzzing is considered a dynamic technique.
|
||||||
\begin{figure}
|
\begin{figure}
|
||||||
\begin{center}
|
\begin{center}
|
||||||
\includegraphics[width=\linewidth]{fuzzing}
|
\includegraphics[width=\linewidth]{fuzzing}
|
||||||
\end{center}
|
\end{center}
|
||||||
\caption{Generalization of fuzzing process.}\label{fig:fuzzing}
|
\caption{Generalization of fuzzing process.}\label{fig:fuzzing}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
\section{IoT Fuzzing}
|
Advantages of fuzzing are the automation and scalability of the process. This enables fuzzing to be run many test cases in a short amount of time, which makes throughput of the fuzzer an important metric in evaluating fuzzers\cite{angora}. This is achieved by easily being able to run software concurrently on multiple processors. An alternative way is running the software in a virtual environment\cite{crash}.
|
||||||
\textbf{Mutation based fuzzing}
|
|
||||||
\textbf{Taint}
|
There are multipe types of fuzzing techniques based on the amount of known information about the software. Whitebox, blackbox and greybox fuzzing. Whitebox fuzzing has complete information about the softwares source code. Blackbox fuzzing on the other hand has no such information, while greybox fuzzing lies inbetween regarding the available information. Blackbox fuzzing relies purly on the binary of a program or the program in it's already executed state\cite{hfuzz}. This leads to blackbox fuzzers generally creating many unnecessary test cases due to the lack of knowledge about the target\cite{firmcorn}. Greybox fuzzers may use the additional information to improve the monitoring by injecting instrumentation to the binary at compile time\cite{angora}. Whitebox fuzzers can utilize the full source code to increase efficiency by using techniques like symbolic execution or dynamic taint analysis\cite{vuzzer}. Comparing blackbox fuzzers with greybox fuzzers or even whitebox fuzzers is therefore not worthwhile, due to the different starting conditions\cite{snipuzz}.
|
||||||
\textbf{Emulation}
|
|
||||||
\textbf{Message}
|
During the input generation step the fuzzer generates and prepares messages according to its generation strategy. Choosing which generation strategy is used depends on the given information or constraints of the system that is fuzzed. The fuzzer radamsa\cite{radamsa}, a general purpose blackbox fuzzer, for example creates messages derived from a possibly valid input and changes parts of it to generate new test cases. Which classifies him as a mutation based fuzzer, since radamsa modifies existing input to create test cases. The operations on the given input can be substitution of characters, bit flips or other operations, based on the tools internal heuristics (\Cref{lst:radamsa}). There are lists, which contain strings, that have a high propability to cause issues when used as input\cite{blons}\cite{fuzzdb}. These lists may be used by fuzzers as well to generate input, but the generated input can also be random. The goal is to find a input, which makes the software crash or display otherwise unexpected behavior.
|
||||||
\subsection{Adversaries}
|
|
||||||
\subsection{Whitebox Fuzzing}
|
\begin{figure}[t]
|
||||||
\subsection{Blackbox Fuzzing}
|
\begin{lstlisting}[language=sh,firstnumber=0,breaklines=true]
|
||||||
\subsection{Greybox Fuzzing}
|
> echo "rm -rf / --no-preserve-root" | radamsa -n 5
|
||||||
|
rm -rf / --no-presef / --no-preserve-root
|
||||||
|
rm -rf / --no-preserve-root
|
||||||
|
rm -rf --no-preserve-roo
|
||||||
|
rm -rf!!;xcalc\0\u0000�\n\340282366920938463463374607431768211457!xcalc$'%d\0$!!%d\x00 / --no-preserve-root
|
||||||
|
rm -rf / --no-preserve-r'xcalc%#x'xcalcaaaa%d%n\0\x0aNaN%#x%p%d;xcalc+infoot
|
||||||
|
\end{lstlisting}
|
||||||
|
\caption{Example output of radamsa on ``rm -rf / --no-preserve-root'' (omitted non-printable characters)}\label{lst:radamsa}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
The message sending step depends on the target of the message. Software offers many ways to interact with it, from simple things like user input via textfields in desktop applications to packages sent by the users through web browsers to web servers. Those points of contacts are possible targets for fuzzing. And dependant on the target, different techniques for message generation may be used. If a network protocol is fuzzed, like with the tools boofuzz\cite{boofuzz}, the fuzzer needs to have an understanding of the network protocol which is fuzzed. While other fuzzers like XSStrike\cite{xsstrike}, which was built to find XSS (cross site scripting) bugs, target web applications. While XSS bugs will not crash the software, they are a serious security threat, which enable an attacker to inject code to websites\cite{xss}.
|
||||||
|
|
||||||
|
Monitoring the softwares behavior upon receiving a malformed message as input is the last step of a typical fuzzing loop. The behavior monitored depends on the earlier steps, but after every loop the original programs state should be restored to have an equal ground for all test cases. When the fuzzer looks for XSS bugs or SQL injections, the program will not crash, when such a bug is triggered. This has to be taken into consideration while monitoring the software and therefore other methods of detecting those bugs will have to be used than methods, which are used to detect crashes due to memory errors like buffer overflows. Fuzzers who don't try to trigger crashes usually use the applications answer to the input message to determine whether the test case triggered the event, which was tested for\cite{boofuzz}. To monitor a softwares crash the fuzzer can provide instrumentation, with which the tested software is compiled\cite{afl}, if greybox fuzzing is used. A blackbox approach could be monitoring for specific output of the software after a malformed input has been sent or monitoring the status of the network connection for networking capable software. A fuzzers goal is to cover as many parts of the software as possible. Evaluating the coverage of the software is only possible for greybox or whitebox fuzzers, since they can instrument the code. This metric can be used to guide the fuzzing process of generating input like in the state-of-art mutational fuzzer AFL\cite{afl} and its fork afl++\cite{aflpp}.
|
||||||
|
|
||||||
|
Another property of fuzzers is their adjustments to the input after a fuzzing loop is done. They are categorized into smart and ``dumb'' fuzzers. Dumb fuzzers aren't aware of the input structure and therefore only try random input, substitutions based on heuristics, delete parts of the input or add parts to the input. This can lead to a lot of test cases, which don't lead anywhere. Another disadvantage is that input generated by a dumb fuzzer may easily be dismissed if a specific input structure is expected. Looking at smart fuzzers, which try to generate valid input based on the softwares protocol\cite{boofuzz}, grammar\cite{grammarinator} or model\cite{modelfuzz} \textbf{describe grammar, protocol, model}. To perform smart fuzzing the input model must be provided to the fuzzer, which may not be as easily accessable on proprietary devices, although there are ways to derive an input model from a large sample of valid and invalid input.
|
||||||
|
|
||||||
|
\section{Intricacies of IoT Fuzzing}
|
||||||
|
IoT Fuzzing is the application of fuzzers on IoT devices, which poses new challenges, since fuzzing hardware and their firmware and fuzzing software work on different domains, each with their own challenges.
|
||||||
|
|
||||||
|
The works of Muench et al.\cite{crash} offers insight into the challenges of fuzzing embedded devices. They mention three main challanges.
|
||||||
|
%
|
||||||
|
The first challenge being fault detection. Regular fuzzing assumes, that crashes are generally observable. Due to an IoT devices limited computational capability fault detection functionalities, usually present in multi-purpose devices, are rarely present in embedded systems.
|
||||||
|
%
|
||||||
|
Even when crash causing fault detection mechanisms are available, they would be logged on multi-purpose systems, whileembedded devices usually do not provide feedback like multi-purpose systems do due to the lack the necessary I/O capabilities.
|
||||||
|
%
|
||||||
|
A liveness check, also called probing, can be performed to check the status of the device while fuzzing it. Probing can be either active and passive. During active probing the fuzzer sends regular known to be valid messageses to the target system and evaluates the response. The messages sent by the fuzzer may cause a state change in the tested device, which has to be accounted for. Passive probing uses the devices responses to the test message to determine liveness or observes visible crashes.
|
||||||
|
|
||||||
|
Muench et al.\cite{crash} expands on this by classifying system crashes by their observability. An observable crash is therefore the most visible and managable kind of crash, where the tested device stops running and provides an error message or another 6 that is easily visible. It is added, that this also includes crashes, which don't provide additional information about the crash. Observable crashes are the optimal case regarding crashes, since they are visible and enable the fuzzer or tester to react without delay.
|
||||||
|
%
|
||||||
|
Reboots are another kind of crash. Crashes on T3 devices automatically lead to a reboot, since the crashed software and firmware on the device are part of the same ``blob firmware''. On other kinds of devices, a service may crash, while the rest of the system continues to run without problems.
|
||||||
|
%
|
||||||
|
In reaction to malformed input a device may hang. That means, that it halts execution and doesn't react to any more input. This may be due to being stuck in an infinite loop. This leads to a slowdown in throughput and the device needs to be restarted if such behavior is found.
|
||||||
|
%
|
||||||
|
Late Crashes pose a challenge for testing the device. This behavior is described as the device crashing after a non-negligible amount of time after the cause of the crash, like a malformed message, is sent, which makes correlation between the cause and the crash challenging.
|
||||||
|
%
|
||||||
|
At last there are cases where neither the device nor the software crash, while still being in an unexpected state. This can lead to wrong data and incorrect results. This malfunctioning of the device is hard to detect, since the fuzzer needs information about the expected response to determine whether an its an output caused by a malfunction or not. This is further complicated due to the diverse message formats in use\cite{snipuzz}
|
||||||
|
%
|
||||||
|
There are also cases of malformed input not causing any visible effects, even when errors occured. These errors may cause crashes or malfunctioning at a later time, which makes detecting them during fuzzing almost impossible without instrumentation\cite{snipuzz}.
|
||||||
|
|
||||||
|
The second challenge is performance and scalability. While regular fuzzers can execute and test software concurrently to increase the throughput and therefore find more possible faults in the software over time. Fuzz testing on an IoT device is not possible in the same manner, since a physical device is being fuzzed. Even though multiple copies of the same device could be purchased, to scale up the test cases, it would become infeasable due to financial limitations and infrastructure requrements like power and space. Emulation can help with the problem of scalability by emulating the test device, but this approach faces the challenge of IoT devices being dependant on the hardware components of the device\cite{firmafl}.
|
||||||
|
%
|
||||||
|
After a fuzzing loop the original state of the tested device has to be established to start every fuzzing attempt with the same starting conditions. This is not a challenge with regular software, since the softwares original state is reestablished after rerunning it and changes on the filesystem can be reverted with a e.g.\ snapshot of the virtual VM (virtual machine). Restarting an IoT device can take up to a minute, since the device needs to be completly rebooted to get it to a neutral state.
|
||||||
|
|
||||||
|
The third challgenge Muench et al.\cite{crash} mentions is the instrumentation. Instrumentation on desktop systems is used to obtain coverage information about the software that is being fuzzed and detect memory corruptions by adding them during compile time or run time.
|
||||||
|
%
|
||||||
|
Instrumentation being added during compile time therefore requires the firmware beforehand. This is already an issue on IoT devices, since acquireing the firmware is not always possible. Additionally the variety of operating systems and processor architectures, makes instrumentation on IoT devices a challenging task. Obtaining the manufacturers toolchain to re-compile the firmware is rarely possible. This could be solved by utilizing binary dynamic instrumentation frameworks like valgrind\cite{valgrind} or using QEMUs instrumentation\cite{triforceafl}, but these methods heavily depend on the OS and CPU architecture.
|
||||||
|
|
||||||
|
Furthermore, IoT fuzzing suffers from the similar or the same problems as regular fuzzing based on the fuzzing approach. Therefore an IoT fuzzer which utilizes network protocol fuzzing will face the same challenges as the used network protocol fuzzer, like generating valid input\cite{diane}, on top of the challanges of fuzzing an IoT device.
|
||||||
|
|
||||||
\section{Overview of IoT Tools and Techniques}
|
\section{Overview of IoT Tools and Techniques}
|
||||||
In this section we are going to look the overview of different IoT Fuzzing devices\Cref{tab:toollist}.
|
In this section we are going to create an overview of different IoT fuzzers, list the techniques they utilize and look at the techniques advantages and disadvantages (\Cref{tab:toollist}).
|
||||||
\begin{table*}
|
\begin{table*}
|
||||||
\begin{center}
|
\begin{center}
|
||||||
\begin{tabular}{rclll}
|
\begin{tabular}{rclll}
|
||||||
Tool & Year & Fuzzing approach & Techniques & Scope \\
|
Tool & Year & Fuzzing approach & Techniques & Scope \\ % novelty
|
||||||
\toprule
|
\toprule
|
||||||
SIoTFuzzer & 2021 & Blackbox & & \\
|
SIoTFuzzer\cite{siotfuzzer} & 2021 & Blackbox & & \\
|
||||||
IoTFuzzer & 2018 & Blackbox & & \\
|
IoTFuzzer\cite{iotfuzzer} & 2018 & Blackbox & & \\
|
||||||
Firm-AFL\cite{firmafl} & 2019 & Greybox & & \\
|
Firm-AFL\cite{firmafl} & 2019 & Greybox & & \\
|
||||||
Snipuzz & 2021 & Blackbox & & \\
|
Snipuzz\cite{snipuzz} & 2021 & Blackbox & & \\
|
||||||
Firmcorn & 2020 & & & \\
|
Firmcorn\cite{firmcorn} & 2020 & & & \\
|
||||||
FirmFuzz & 2019 & & & \\
|
FirmFuzz\cite{firmfuzz} & 2019 & Greybox & Static analysis, Emulation (QEMU) & Linux based MIPS \& LE ARM firmware\\
|
||||||
Diane & 2021 & Blackbox & & \\
|
Diane\cite{diane} & 2021 & Blackbox & & \\
|
||||||
HFuzz & 2019 & & & \\
|
HFuzz\cite{hfuzz} & 2019 & & & \\
|
||||||
IoTHunter & 2019 & & & \\
|
IoTHunter\cite{iothunter} & 2019 & & & \\
|
||||||
WMIFuzzer & 2019 & Blackbox & & \\
|
WMIFuzzer\cite{wmifuzzer} & 2019 & Blackbox & Mutation & Web Management Interface in IoT devices \\
|
||||||
\bottomrule
|
\bottomrule
|
||||||
\end{tabular}
|
\end{tabular}
|
||||||
\end{center}
|
\end{center}
|
||||||
\caption{An overview of different IoT fuzzing tools.}\label{tab:toollist}
|
\caption{An overview of different IoT fuzzing tools.}\label{tab:toollist}
|
||||||
\end{table*}
|
\end{table*}
|
||||||
As we can see the fuzzers requireing firmware, i.e.\ whitebox fuzzers, are mostly designed to fuzz IoT devices, built on top of linux devices. This is due to.
|
As we can see the fuzzers requiring firmware, i.e.\ white-/greybox fuzzers, are mostly designed to fuzz IoT devices, built on top of linux based firmware. This is due to them usually utilizing emulation to speed up the fuzzing process, which fuzzing usually excells at, but where IoT fuzzing esspecially is a bottleneck. Emulation of Linux based devices covers the most available devices\textbf{citation needed}, so going for those makes most sense instead of building a custom emulator for every IoT device there is.
|
||||||
\subsection{Techniques}
|
\subsection{Techniques}
|
||||||
|
\subsubsection{Static Instrumentation}
|
||||||
|
\subsubsection{Binary Rewriting}
|
||||||
|
\subsubsection{Physical Re-Hosting}
|
||||||
|
\subsubsection{Full Emulation}
|
||||||
|
Emulation tackes the problems of throughput and scalability in IoT fuzzing. This is done by improving the performance, successrate and hardware-indipendance of fuzzers\cite{snipuzz}. Full emulation of the firmware with the help of heuristics mitigates the lack of fault detection and increases accuracy of found vulnerabilities to a level of desktop system application fuzzers. Additionally emulation based fuzzing provides the possibility to repeat test cases and their executions to further analyze specific test runs\cite{panda}.
|
||||||
|
|
||||||
|
Often third party developers lack details of the device to implement good emulator. This makes building emulator requiring huge amounts of manual effort\cite{crash}. This is due to IoT devices being heavily dependant on their hardware\cite{firmafl}.
|
||||||
|
|
||||||
|
\subsubsection{Partial Emulation}
|
||||||
|
Can lead to accurate vulnerability detection with decreased performance in comparison to full emulation, but possibly better performance than fuzzing the physical device, since it makes the fuzzing process more scalable\cite{crash}.
|
||||||
|
\subsubsection{Segment Tracking}
|
||||||
|
\subsubsection{Format Specifier Tracking}
|
||||||
|
\subsubsection{Heap Object Tracking}
|
||||||
|
\subsubsection{Call Stack Tracking}
|
||||||
|
\subsubsection{Call Frame Tracking}
|
||||||
|
\subsubsection{Stack Object Tracking}
|
||||||
|
\subsubsection{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}.
|
||||||
|
\subsubsection{Liveness Check}
|
||||||
|
May cause timeouts to be detected as crashes. Slows down fuzzing. Omitting 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.
|
||||||
|
\subsubsection{Generational fuzzer}
|
||||||
|
Does not require a protocol template
|
||||||
|
Generational fuzzers, such as PROTOS, SPIKE, and PEACH, construct inputs according to some providedformat specification. Generational fuzzing requires an input format specification,which imposes significant manual effort to create (especiallywhen attempting to fuzz software on a large scale) or maybe infeasible if the format is not available. Thus, most recentwork in the field of fuzzing, including this paper, focuses on mutational fuzzing\cite{tfuzz}.
|
||||||
|
\subsubsection{Mutation based fuzzing}
|
||||||
|
Requires protocol template
|
||||||
|
By contrast, mutational fuzzers, includingAFL, honggfuzz, and zzuf, create inputs by ran-domly mutating analyst-provided or randomly-generated seeds\cite{tfuzz}.
|
||||||
|
\subsubsection{Taint-based fuzzing}
|
||||||
|
\cite{angora}\cite{iotfuzzer}
|
||||||
|
\subsubsection{genetic algorithm}
|
||||||
|
\cite{angora}
|
||||||
|
\subsubsection{evolutionary fuzzing}
|
||||||
|
\cite{vuzzer}
|
||||||
|
\subsubsection{vulnerability-oriented fuzzing}
|
||||||
|
\cite{firmcorn}
|
||||||
|
\subsubsection{Stateful Message Generation}
|
||||||
|
\cite{siotfuzzer}
|
||||||
|
\subsubsection{Coverage-oriented fuzzing}
|
||||||
|
|
||||||
|
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}.
|
||||||
|
|
||||||
\subsection{Classification}
|
\subsection{Classification}
|
||||||
|
|
||||||
\section{Conclusion}
|
\section{Conclusion}
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue