Rooting a VMC2040 security camera part 7: Conclusion and summary
Brief
In this part we are going to give some thoughts about the security of the camera and what to do to prevent this kind of attack.
The other parts of the series are:
Lets talk a bit about security
Often when I talk with my clients about security of their products, I urge them to analyze what threat they want to protect against. The security solution is different if you intend to protect against a script kiddie or a guy with a soldering gun. Somewhere you have to draw the line where you say "ok", this is the level of security we want to achieve and this is the level of effort we are willing to put in to achieve it. "Secure" is not a binary term.
Security cost. It characterizes the product in many ways, everything form key management in production, complexity in software development and testing, hardware and so on.
Secure enough?
Is the camera secure enough? I would say so.
There was no obvious vulnerability that could be exploited remotely. The attack required physical access to the device and soldering wires to the flash chip. The private keys were secretly stored and protected by the hardware. No exposed services and all communiction from the device were using HTTPS. The RX line on the UART was disabled. Most of the firmware were signed and verified during boot.
All the low-hanging fruit has been picked and the remaining attack surface is quite small.
How to make it even more secure
To make it even more secure, the following measures could be taken
Encrypted squashfs
The rootfs could be encrypted and decrypted on the fly during boot. This would make it much harder to analyze the firmware and find vulnerabilities in it.
Not put executable on writeable area
Putting executable files on a writeable area (UBIFS) is just not a good idea, can we agree on that? I'm pretty sure that the SigmaStar SDK let you provide an alternative path for the config tool, so why not put it on a read-only area?
AppArmor
Lets pretend that you really have to put the config tool on a writeable area, then at least use AppArmor [1] or some other sandboxing solution to restrict what it can do. For example, with AppArmor you could setup rules for which applications startSPARROW can execute, which files it can read and write, etc. This would make it much harder for an attacker to use the config tool to gain root access to the system.
Summary
It has been an interresting journey, not much more to say about it. Now it's time to give the camera back to my friend and let him enjoy it.
References
| [1] | https://apparmor.net |