If high-tech gadgets are on your holiday shopping list, it’s worth taking a moment to think about the specific risks they can pose. Under the wrong circumstances, even a harmless gift can introduce unexpected vulnerabilities. In this blog series, VERT will take a look at some of the best-selling holiday gifts on the web in view of their possible security implications. Some of the risks discussed in this series may be exaggerated and even comical, while others can highlight realistic issues that you may not have thought of.
Looking at a WIFI microscope kit
In this first part of the series I will be discussing a WiFi microscope kit. There are, without exaggeration, dozens of listings for these devices on Amazon, and most appear to be the same or very similar hardware with different brands and different accessories. Being the science nerds that we are, our team quickly bought one of these devices when we saw it as a bestseller in Amazon’s Christmas gift guide.
The microscope itself is compact with a wheel to adjust the lens and a few buttons for power, digital zoom and to activate image capture. To view and save images, it is necessary to connect a computer or smartphone. From the quick start guide, Android and iOS devices can get a viewer app called “Max See” in their respective stores, macOS users can connect via USB and launch Photo Booth, but Windows users are prompted to download a program to access to get to the camera via USB or IP.
Review the security implications
The question of whether additional software must be installed to operate a device is an important question from a security point of view. Installing software on a system generally increases the attack surface and, from a purely security point of view, should be avoided where possible.
In this statistic, the fact that macOS can access the camera without additional software is preferable. However, for a Windows user, there is a risk even before the software is installed, as the instructions do not specify to use an HTTPS connection when downloading the camera software, making it possible for an attacker on the network to use it. downloaded program with malware. Assuming an authentic program is being downloaded, the risk of using this program to access the microscope via USB should be minimal.
In the Android and iOS use case, the attack surface is slightly different due to the WiFi connection. The microscope acts as a wireless access point without a password and allows the mobile device to connect to the supplier’s app. This could mean that the phone or tablet remains in an insecure configuration where it can automatically and unexpectedly connect to an attacker’s access point in the future. This also means that an attacker nearby could inject malicious messages or completely fake the microscope. An attacker who is nearby when the microscope is in use is unlikely to be able to authenticate the victim with the legitimate microscope and then produce a new entry point that mimics the camera, but sends malicious responses.
Multimedia and network protocol decoders have traditionally been a common source of memory corruption, but these risks can be largely minimized by using well-tested platform libraries. In this case, extracting the contents of the Android application will reveal a 7MB .so file which is responsible for handling device communication. A cursory static analysis of this binary reveals that it contains functionality for parsing RTP responses and MJPEG data. I haven’t spent time analyzing this file and finding concrete examples of vulnerability, but I have no doubt there is anything out there.
In the worst case scenario, an attacker could develop an exploit with one of these microscopes to run code on a nearby phone or tablet. By executing arbitrary code in the context of this Android application, the attacker can gain access to the victim’s photos and any other messages stored locally on the device.
Building gadgets with security in mind
The chances of someone caring enough to develop an exploit for this platform are slim, and the likelihood of yourself becoming the target of such an exploit is even less. My point with this post is not to argue that the sky is falling or to argue against buying fun gadgets, but to provide an example of how to evaluate some of the less obvious risks of a particular technology . This is an important perspective to maintain as we build and improve the systems we use every day.
As a developer or vulnerability researcher, an important consideration of this example is how the decision to create a custom parsing implementation instead of using system parsers can introduce vulnerabilities and create an inordinate amount of overhead to maintain.