In a tribute to Romero's masterpiece, we will examine the resurgence of vulnerabilities we all thought dead. As soon as a security expert looks at the firmware and code of IoT devices, 2017 may as well be 1997: format string bugs, basic stack overflows and hardcoded credentials arise. Zero-days are actually forever-days. We will look at a number of real world cases of industrial and consumer IoT devices we tested and broke, and besides analyzing the most common and most outstanding findings, we will wonder why we seem unable to kill these pests once and forever.

1. NIGHT OF THE LIVING VULNS
Roberto Clapis & Stefano Zanero
AMSTERDAM | MAY 8-9, 2018

2. A tale of
horror and hope
in the land of IoT
Starring:
Roberto Clapis
Security Engineer
Secure Network
Stefano Zanero
Associate Professor
Politecnico di Milano

3. ▪Smart hairbrush
▪Smart wine bottle
▪Smart egg tray
▪Smart salt shaker

4. ▪Smart Plugs
▪Smart Keychain
▪Smart Thermostat
▪Smart Irrigation Controllers

5. ▪Cooperative Robots
▪Insulin Pumps
▪Automotive
▪Surgical Robots

6. THREAT MODEL
▪Internet facing but not
designed for it
▪Contains PII
▪Safety critical

7. WHAT ARE WE EXACTLY TALKING ABOUT?

8. FORMAT STRING IN THERMOSTAT

9. BUFFER OVERFLOW IN POS DEVICES

10. BUFFER OVERFLOW IN POS DEVICES
This is an
fgets()

11. SOMETIMES IOT DEVICES
ARE NOT SMALL AND
CUTE...

12. DEFAULT PASSWORDS NEVER DIE

13. DID YOU SAY CODE SIGNING?
Any password works during boot
No code signing or verification (!)
What the... ?

14. ZOMBIE VULNERABILITY MATRIOSKA
FTP RETR /command/whatever read system info
FTP STOR /command/command execute“commands”
e.g., shell reboot
shell uas_disable
With no/hardcoded credentials!

15. COPY-PASTA THAT SPAGHETTI CODE

16. 1980 CALLED, THEY WANT THEIR VULNS BACK

17. • Why are these vulns still alive?
• What are the tools we can use?
• To find out,and go beyond our own opinion, we
brainstormed with tens of developers and openly twitter-
stormed with the security community

18. WHY ARE THEY STILL ALIVE
▪ Lack of awareness
▪ A senior developer was completely
puzzled by the potential security
risks of strcpy
▪ Perception that security
vulnerabilities happen only to "the
web guys"
▪ Out of memory is cool again but no
one knows it
▪ Old code and technical debt
▪ Time to market pressure
▪ The security community is not
providing viable solutions

19. ▪ Stack overflow vulnerabilities "as if in the 90s"
▪ Often no memory segment protection
▪ No ASLR
▪ No W^X
▪ Grsec missing in action and...
▪ The default was until very recently
--no_protect_stack (the opposite of all other
architectures) for no reason at all!!!
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.d
ui0491i/BCFGBAIC.html

20. CHECKSEC...

21. "RANDOM" CANARIES

22. ▪Lack of IDE tools
▪Lack of emulators for extensive testing
▪There are no "safe(r)" libraries
▪Most of the tools we (can) recommend
either do not exist in embedded or are
not usable by developers
▪Code samples in SDKs contain brittle
code and no security related
documentation

25. TU QUOQUE

26. JSON FORMATTING

27. ▪Fuzzing with AFL / libfuzzer
▪Compcert C
▪"Change language to..."
▪Address Sanitizer (no
Linux/ARM yet)
https://github.com/google/sanitiz
ers/wiki/AddressSanitizer

28. ▪Let people choose their
analysis tools
▪Advanced threat
modeling/secure coding
training for all developers
▪"Consider all inputs
(including sensors) hostile,
always"

29. ▪"Apply LangSec"
▪Look at the assembly output,
especially on sensitive or
crypto code. Unrealistic.
▪"Patch sbrk() to reboot rather
than allowing malloc() to
return 0"

30. ▪ Create or use some safe libraries, e.g. to handle type safety,
integer expansion/truncation, etc.
▪ https://github.com/mbedded-ninja/MFixedPoint/
▪ MISRA C and the JPL coding standard:
▪ https://yurichev.com/mirrors/C/JPL_Coding_Standard_C.pdf
▪ Simple cheat sheets and usable documentations:
▪ https://www.owasp.org/index.php/C-Based_Toolchain_Hardening_Cheat_Sheet
▪ https://github.com/intel/safestringlib/wiki/SDL-List-of-Banned-Functions
▪ https://scriptingxss.gitbooks.io/embedded-appsec-best-practices/
▪ Don't reinvent the wheel (updates, graphics libraries)
▪ https://mender.io
▪ https://ugfx.io

31. ▪ Flawfinder
▪ Cppcheck:
▪ http://cppcheck.sourceforge.net
▪ Scitools:
▪ https://scitools.com/features
▪ Frama-C
▪ Clang Analyzer
▪ Enable stack protector

32. What if you inherit a codebase?
▪ Get any and all documentation left behind, are there patterns in the kinds of bugs being
fixed?
▪ Check if there are good tests in place already
▪ Lint the code
▪ Start with static analysis tools
▪ Look for bad/incompletely commented sections and TODOs
▪ Seek for inputs and uses of untrusted data and follow the breadcrumbs
▪ Seek for custom crypto code and kill it with fire
▪ Don't be afraid of refactoring

33. ▪ For further information:
▪ https://www.amazon.com/Secure-Programming-Cookbook-
Cryptography-Authentication/dp/0596003943
▪ https://www.amazon.com/Secure-Coding-2nd-Software-
Engineering/dp/0321822137
▪ https://www.e-reading.club/bookreader.php/138815/Linden_-
_Expert_C_Programming:_Deep_C_Secrets.pdf
▪ https://www.amazon.com/Safer-McGraw-Hill-International-
Software-Engineering/dp/0077076400
▪ http://www.cse.psu.edu/~pdm12/cse597g-
f15/readings/cse597g-embedded_systems.pdf
▪ https://www.blackhat.com/presentations/bh-usa-04/bh-us-04-
grand/grand_embedded_security_US04.pdf

34. CONCLUSIONS:WHY CAN'T WE
HAVE NICE IOTHINGS
▪ Lack of Awareness
▪ Lack in Tools
▪ Lack in Processes
▪ We are not aiming for the head