IoT Recap (April 2020)
Welcome to the April 2020 issue of the yet to be officially named Internet of Things monthly recap. Join me as I take you through some of the interesting things I've seen in the world of IoT this month.
Brian Lough takes us through using an ESP-prog and PlatformIO to debug embedded code on the fly. The ESP-prog connects to the JTAG pins on espressif boards and allow you to perform such actions as:
- Creating Breakpoint
- Breakpoint Navigation
- Variable viewing and editing
Brian's tutorial is especially handy as it describes the process of debugging using PlatformIO as well.
When performing security testing on all things technology it's useful to have a high level guide for common things to check for. OWASP has always been the go to for fantastic resources for Web & App vulnerability testing however their IoT sections focused more on higher level software issues / network exploitation
This month we saw the release of the OWASP Firmware Security Testing Methodology which outlines a list of stages taken when performing security audits on firmware.
The stages covered are highly detailed but an overview of them can be seen below:
- Information gathering and reconnaissance
- Obtaining firmware
- Analyzing firmware
- Extracting the filesystem
- Analyzing filesystem contents
- Emulating firmware
- Dynamic analysis
- Runtime analysis
- Binary Exploitation
Off the back of the OWASP Firmware Security Testing Methodology release, we were also lucky enough to get the IoTGoat Project, a deliberately insecure firmware based on OpenWrt and maintained by OWASP.
Not only does the challenges involved in breaking into this firmware align well with the OWASP Top 10 IoT risks but it goes hand in hand with the OWASP Firmware Security Testing Methodology release this month also.
Included goals include:
- Weak, Guessable, or Hardcoded Passwords
- Insecure Network Services
- Insecure Ecosystem Interfaces
- Lack of Secure Update Mechanism
- Use of Insecure or Outdated Components
- Insufficient Privacy Protection
- Insecure Data Transfer and Storage
- Lack of Device Management
- Insecure Default Settings
- Lack of Physical Hardening
Google's Local Home SDK left beta this month opening up a lot more opportunities for smart things in our houses to better integrate with Google Assistant.
If you've read through my post on Alexa Gadgets Introduction - Voice Controlled Cat Feeder then you might already be aware of how powerful local triggers for voice assistants are; and Google's Local Home SDK is no exception
When a user invokes a voice intent, rather then the request needing to go up to the Cloud; the request can be passed off to a local device on the users home network to perform the action. I'm personally really excited about how this SDK will help shape a safer; ironically less internet connected world.
ADLINK has had their ROScude-X device listed as an officially supported device in the AWS Partner Device Catalog.
Currently the listed Greengrass supported version is 1.9.3 (where 1.10.1 is the latest version at the time of writing), so be aware that features like Docker application deployments via Greengrass connectors might not work out of the box.
Note: I'm sure there is nothing stopping you from updating to a newer Greengrass version using OTA though.
We've finally had a new small release to Greengrass since version 1.10.0 was released late last year. Not much information was released around what changed; however it's fair to assume you should update to the lastest version as soon as possible.
On-top of this we also got an update to the Docker Application Deployment Connector to version 3. There is mention this release fixes issues with environment variables.
The last thing worth noting from the AWS IoT Greengrass space is there is now an official Security section in the AWS IoT Greengrass guide.
The security section is really detailed, and it's a nice addition given prior to release it was very difficult to find information around Greengrass IAM policy actions.
An interesting overview of situations where you might need to scale out authorization policies for IoT devices. Surprisingly one of the bottlenecks you might run into when using a 1 to many relationships is IAM policy size; where 1 person might have many devices that all could have a different IAM policy.
Scaling up to where limits is something you usually won't notice until it's too late, so I found this post to be particularly insightful myself.
Part 2 of the series was released this month and it's excellent! If you didn't catch Part 1 I highly recommend reading it over before this one.
The use of a gateway authorizer, and the overall complete solution makes for a really nice reference architecture (even if its just for hobby projects). You can find the code repository for the project at aws-samples/aws-serverless-telepresence-robot