IoT Hardening

Hacker team Flashback won the Pwn2Own Tokyo 2020 competition. Around Jan 6, 2021 they pwned a popular TP-Link router in another Pwn2Own. The video they released of their techniques was extremely clear an informative and gives a glimpse of some of the techniques they used. Congrats on the wins and great video Flashback! If you haven't see it, check it out here:

We'll briefly cover some mitigations that could have helped or thwarted their efforts. In security, you can never completely secure anything. The best you can do is direct a security budget to:

1. Understand the most likely threats.
2. Mitigate those threats as much as possible in budget.
3. Plan for and expect compromise. Build playbooks for those scenarios.

Context is everything when it comes time to mitigate risks. The following suggestions may or may not be applicable or make sense in any given scenario due to complications related to manufacturing, platform management, etc. But these give ideas for the sorts of things that can be considered. You'll notice that the compromises listed make a vulnerability chain that leads to the eventual single script defeat. Blocking any of these will slow down an attacker. Since attackers are human and have finite motivation, either attention or budget, simply making things much more difficult is a useful strategy!

1. Serial Port Access

They immediately found and got serial port access. Some potential mitigations:

• Completely disable serial access on MFG boards. If not practical:
• Use per device serial enablement with per device keys.
• Do not enable serial output until serial is unlocked.
• Require a hidden/random pin to be shorted before serial is enabled. This is a combination of physical + security by obscurity. Physical because it may be hard to enable without a custom jig to connect to. You'll notice they mentioned they were limited by lack of hardware interface tools and had to improvise. Imagine how much worse it would be with a small obscure pin on opposite side of the serial contacts. Many professionals consider "security by obscurity" an antipattern. I think it is just a tool that can slide in to a layered approach.

2. System Config

• If you can some dedicated sysadmin/sysconfig cycles for role for this, pay for the extra hours. You don't need to be an embedded guru to achieve excellence here.
• don't mount all partitions with write by default - Make it harder to write to the system.
• don't run all processes as root - Have a few processes run as root as possible. Sandbox as much as possible. Utilize chroot, fs perms, separate users as much as you have budget for.

3. Software Config

• Reduce Your Attack Surfaces - It looked a mesh-network daemon was running by default. Perhaps defaulting to mesh networking enabled is not necessary and can be done by user setup. Don't run any service until you know it is necessary. Yes this adds complication. Improved security is not free.

4. App + Security Considerations

• Don't use hardcoded crypto keys. I'm not sure if this mesh protocol used is proprietary or some part of a more standard one with the key exchange removed. Use TLS with some form of key exchange, perhaps via OpenSSL. Again, this is more work.
• Don't allow unsanitized snprintf inputs. snprintf has a number of risks. Find the best strategy for you to avoid the various known pitfalls. There are various static analysistools that can help you find things like this.
• fuzzing - protocol/graybox fuzzing to the server side would have likely shown the lua escape vuln. A couple ways this could be done. One is at the function level on the server side with unit-test type fuzzing. The other is on the client side for each of the interfaces the client uses. Just blasting random bytes for the encrypted data might show problems. But it's not going to show the problem with the decrypted malformed client mac.

5. System Monitors

These are more speculative ideas as I've not encountered active responses in low cost embedded systems. But I think this may be more common in the future.

• The incremental building of the exploit script provided some unique system and network calls. Could an instrumented system track unexpected or strange calls to wget, lua and other system tools/binaries? Actions for unexpected calls include:

Rebooting or partially disable the system to frustrate attacks

Contacting home base with logs and other info about the potential threat.

• netstat was unavailable and the attackers downloaded busybox. Might this have been a target for a dummy or instrumented netstat that called home to notify tplink that the system had been compromised

I really enjoyed the video and hope that you found some of my descriptions of potential mitigations for these vulnerabilities interesting.