5

First: This is not one of those "How do I start hacking?" questions, but more of a "How do I begin testing a specific device?".

It is a part of my Bachelor Thesis to perform a Vulnerability analysis/assessment of an IoT device that was Implemented during another BSc Thesis with a security focus in mind, and provide possible solutions or improvements. Applying Kerckhoffs principle, I have full access to the documentation, source code and have even been provided with a test client, leaving it to me to set up the webserver according to documentation.

How do I proceed?
According to this we have various steps for a full assessment.

  • Discovery
  • Vulnerability Scan
  • Vulnerability Assessment
  • Security Assessment
  • Penetration test

System
The three major thematic components are already identified:

  1. RFID Reader/tags
  2. Microcontroller Client, (Arduino /w Ethernet Shield)
  3. Backend system

Additional info to provide a better picture:
1) only uses ID of rfid tag (authorisation without authentication), tag cloning/spoofing possible. Considering if it is possible to integrate this with the proprietary door locking system, as the same rfid tags are used, so the system has user authentication.

2) Arduino Uno as interface to serial port and reading rfid tags, uses crypto library to ChaCha20-Poly1305 encrypt/authenticate trafic to backend, pre-shared key, generates new session key periodically, I will implement a small programm that emulates the communication via serial port.

3) Backend with Webserver(Apache), application server (django) and database (sqlite, as its still a test system). Provides Webinterface as administrative tool, uses state of the art TLS.

Current Status

I am currently stuck on how to tackle this in a methodical and structured way/process.
I don't really have that much hope in attacking (1) as I can't really see that many attack vectors, apart from cloning/spoofing
In (2), as it is an Arduino, using 99% of its capacity for its tasks. I already used flawfinder on the source code, but it showed only a few errors (check array size if copy etc), which were all handled in the code. No dynamic memory allocation is happening, reading from arrays is strictly defined by size of arrays etc. Assuming that the ChaCha20 Library, which brings their own secure RNG is properly implemented, I don't really see anything here.
Finally (3) where I see the most potential. Apache Webserver running on Debian 9. Webserver are quite often configured incorrectly/not up to date which opens up attack vectors. Application server? Not sure about that one. Webclient, depending on the implementation, build with Django, could also be one of the more vulnerable components.

TL;DR: I have an IoT device, consisting of multiple components (Microcontroller, backend webserver with webinterface), and I am stuck in how to do a methodically correct and thorough vulnerability assessment.

Questions

  • What is the proper methodical approach to this Problem? Are there standards/ frameworks?
  • How can I thoroughly test (1) and (2) for vulnerabilities? As there are guides for pentesting (3)

EDIT

I leave the background information as it is. Main question is:

What is a correct methodical approach to Vulnerability assessment of a multi-component IoT device?

k0s1nsky
  • 53
  • 5

2 Answers2

3

TL;DR:

  1. RFID Handling (your main input to the system)
  2. Debugging interfaces (combine this with all the other steps)
  3. Web app
  4. Crypto stuff
  5. Source code auditing
  6. Side channel & fault injection (that's a kinda harder one)

1. RFID

I'd start with the RFID part (check out proxmark3). How does the arduino handle a 1KB ID? It should blow up. it might even throw up some of its memory somewhere.

2. Debugging interfaces

DEBUGGING INTERFACES. Can’t stress that enough. Check out One-Wire debugging protocol for example and my other interface it utilizes. Try to get a memory dump.

3. Web Application

Fire up wire shark or burpsuite and see what goes on. Mis-configuration is often not your biggest problem on custom web apps.

4. Crypto stuff

Keep in mind that the arduino is a low power device with horse power almost identical to carrying out calculations with pen & paper - these two with cryptography do NOT play well. Especially the RNG part. If it’s not hardware (like a white noise generator with reverse biased transistors for example) its most probably trash. Check out how every crypto that takes place is implemented, I'm sure you'll find something.

5. Source code auditing

This goes without saying, you'll have to check the source code. I leave it down there, because by the time you start checking the source code, you'll already have a very good idea on what's going on, when and why. I think that you'd already checked various bits on previous phases, but in this phase try to be much more thorough

6. Side channel & fault injection

Last but not least, I’d try faulty injection & side channel attacks. Voltage & clock glitching on such simple architectures, as well as power analysis is very easy (compared to an ARM A series processor for example). ChipWhisperer will be of much use! I think you even have two step pipeline so you can skip whole instructions :P

NOTE: Try to take a lot of notes during the assessment (how you did stuff, or how the system works) as well as pictures and screenshots on interesting/weird stuff. There's no such thing as "too many notes"!

dzervas
  • 332
  • 2
  • 11
-1

Depends on what the device does. It must communicate in some way. Does it have a network interface? Try a port scan.

An "IoT device" is like a mini PC. Your attack vectors must be the same. It must receive some kind of input. Manipulate the inputs.

schroeder
  • 123,438
  • 55
  • 284
  • 319
rom3ocrash
  • 25
  • 1
  • this is a little too generic to be useful - can you expand your answer? – schroeder Mar 07 '18 at 19:45
  • He needs not to port scan, he already has the code. The attack vectors are actually a bit different than a PC (debug points, etc.). Also input manipulation is (as said) a bit vague. He asked for methodology. – dzervas Mar 09 '18 at 09:46