$30 off During Our Annual Pro Sale. View Details »

Night of the living vulnerabilities: forever-days of IoT

Night of the living vulnerabilities: forever-days of IoT

Video: https://www.youtube.com/watch?v=OIYoe32biNk

In a tribute to Romero's masterpiece, we examined 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 looked 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.

Roberto (Rob) Clapis

November 17, 2017
Tweet

More Decks by Roberto (Rob) Clapis

Other Decks in Technology

Transcript

  1. NIGHT OF THE LIVING VULNS
    Roberto Clapis, Stefano Zanero
    CODEMOTION MILAN - SPECIAL EDITION
    10 – 11 NOVEMBER 2017

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  7. WHAT ARE WE EXACTLY TALKING ABOUT?

    View Slide

  8. FORMAT STRING IN THERMOSTAT

    View Slide

  9. BUFFER OVERFLOW IN POS DEVICES

    View Slide

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

    View Slide

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

    View Slide

  12. DEFAULT PASSWORDS NEVER DIE

    View Slide

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

    View Slide

  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!

    View Slide

  15. COPY-PASTA THAT SPAGHETTI CODE

    View Slide

  16. 1980 CALLED, THEY WANT THEIR VULNS BACK

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  20. ▪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

    View Slide

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

    View Slide

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

    View Slide

  23. ▪"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"

    View Slide

  24. ▪ 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

    View Slide

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

    View Slide

  26. 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

    View Slide

  27. ▪ 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

    View Slide

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

    View Slide