Assessing IOT pt. 1 - Preparing for the assessment

"How you climb a mountain is more important than reaching the top." -Yvon Chouinard

Perhaps one of the largest issues in IoT isn't the fact that you can hack it, rather, the lack of a formal process for evaluating it and lack of how to begin assessing/evaluating IoT.

In this post (part 1), we will take the perspective of a consultant hired to perform an assessment on an IoT device. What questions should I ask? Do I need to buy additional hardware or software? I hope to address these questions and many more via this post.

Go get some coffee (or tea), sit back, and enjoy the ride; it's just another quick post.


Who This Post Is For

This post is for those looking to begin evaluating IoT systems mainly as a consultant or some other person hired/contracted to do so. It is important to understand that this post is not designed specifically for researchers. Researchers generally have more time/money than consultants.

Why consultants? I am one, and I have seen a large amount of consulting companies trying to either break into the IoT space or have had consulting companies ask me if I want a job doing this for them. My goal is to help people. I hope this post helps in some way.

This post could also be potentially leveraged by sales...maybe. If it helps sales, then even better.

Questions To Consider

I'm a strong believer in being as prepared as possible before an assessment. The more you know and can plan, the stronger the assessment. As for you, ensure you know if you are to evaluate hardware controls, firmware, and/or running services.

Cool ProToxin, you plan. So do we...get on with it!

Some questions to consider (no specific order):

  • What does the product do? (a bit obvious, however, essential)
  • Is the product currently in production and/or out to public?
  • What communication protocols are in use?
  • What communication protocols should be considered out of scope?
  • Are there any web management interfaces?
  • Is there an api for control or gathering data?
  • Who manages the device?
    • Consumer?
    • The Client?
    • Another third party?
  • Are communications over SSL/TLS?
  • How are firmware updates performed? (answer can be obtained via assessment if needed)
    • If over http, is SSL/TLS being used?
  • Is the development team leveraging rapid development?
  • What was the primary push for the assessment?
    • Internal concern?
    • Request of third party?
  • What primary attacks vectors are you concerned with?
  • What data is considered high value?
  • Who is the intended audience of the product?
    • Standard consumers?
    • Enterprise?
    • Industrial?

Ensure that the company has a strong development environment that you can test in. Secondly, it is important for you to ensure that test data is populated so that you can ensure that all functions/operations are tested as if they were real world.

Schedule a Technical Walkthrough

Perhaps this seems a bit simple, however, this part is VERY important. Schedule a walkthrough with the company. This will allow you not only meet the client but also see exactly how their product works.

This may be one of the largest issues with IoT testing; not knowing the product. Schedule your walkthrough and ask questions. Remember those questions above? The technical walkthrough may be another place to ask them or ask new ones. In my experience, this can take anywhere from one hour to four hours depending on the product.

Understand the Client's Product and Philosophy

While understanding the product at a technical level helps, try to understand why the product is such a good thing and to understand the client's philosophy. For example, is the product designed to assist users or just an extension of technology to be used by consumers? What type of stance does the company have on user privacy and security? (that last one can greatly change how you write up issues).

A Word About Issues

While you are almost guaranteed to find at least one issue, it is in good practice to ensure that you write down all steps needed to discover said issue(s). Additionally, your client may request to see an estimated amount of effort required to discover each issue. I am not going to go too far into how to write up issues...if you've made it this far and you don't know how to write reports, you need to take a step back.

Be Ready for Headache

While assessing IoT can be fun, it is certainly filled with headaches. You will generally find a lack of community help as well as limited understanding of non-standard protocols/communication types. In my opinion, I think a lot of the lack of community support is because a large majority of the infosec industry only cares about rockstar status and protocols that are straightforward to exploit (/rant). Either way, there ARE people out there, I promise!

As I covered in my last IoT post, some things you may see are:

  • JTAG
  • UART/Serial
  • WiFi (802.11a/b/g/n/ac)
  • Zigbee/Zwave (802.15.4)
  • Bluetooth
  • Bluetooth Low Energy (BLE)
  • IPSec
  • HTTP(s)
  • DNS
  • NTP
  • SNMP
  • Telnet
  • SSH
  • MQTT
  • FTP

... and many, many, more.

Don't let the amount of things involved with IoT scare you away from testing. Honestly, assessing IoT has been one of my favorites.

Learn

Learn. Learn as much as you can about not only the product to test, but also IoT in general. It is becoming a more intimate (in some cases quite intimate ;) ) part of our lives. The more tech we have in our lives, the larger the potential damage that can happen.


See? that was not too bad. I am looking forward to sharing more IoT stuff soon :D.

Until next time,
ProToxin

And, if you've made it THIS far (no, this isn't a sponsor/endorsement...I just find it hilarious):

Join EFF!