How to Reverse Engineer Insecure IoT Cameras

TL;DR

Start an IoT camera assessment by obtaining its firmware, extracting files with Binwalk, scanning exposed ports with Nmap, and inspecting scripts and binaries for weak security choices. The demonstrated camera exposes Telnet and HTTP services, uses a shared discoverable password without attempt throttling, runs an old 2.6 kernel, and retains binary symbols that simplify reverse engineering and the search for persistent shell access or remote command execution.

Transcript

Um, so this was the first thing that we undertook in our IoT project, uh, which consisted of two items. Firstly, we needed a reliable analog, non-IoT mechanism of creating our coffee, just in case. Uh, so we found a large cold brew tower in Australia, uh, that takes eight hours to brew coffee. Um, and it's very, very strong. Uh, and then we found a... Read More

Key Insights

• Firmware acquisition is often the first step in an IoT security assessment because it exposes files, scripts, and binaries for offline inspection. In the demonstrated case, searching for the published firmware name and modifying a known download filename was enough to retrieve the camera's installed version.
• An Nmap scan is a simple way to identify an IoT device's exposed network services. The tested camera replied directly to probes without firewalling or stealth behavior, revealing Telnet and a standard HTTP web server operating on port 81 rather than the usual port.
• Moving an HTTP service to port 81 does not meaningfully conceal it from network discovery. The camera's service was still recognized during scanning, and the device could negotiate connectivity through UPnP, undermining any assumption that the altered port number provided substantial protection.
• Shared default credentials are especially weak when they are visible before purchase. The camera used the same administrator password across devices, and the password could be discovered on the box or by inspecting a product image displayed through an online shopping listing.
• Missing authentication throttling allows an attacker to make repeated password guesses without triggering a lockout. Although the camera's shared password was already easy to discover, the absence of attempt limits created an additional and independent weakness in its web interface.
• Binwalk can separate embedded firmware into components suitable for examination. The camera packages included web-interface files and the binaries running on the device, while a password-protected zip archive showed that the vendor distributed web-interface updates through an encrypted package targeting the www path.
• An old 2.6 kernel reduces the defensive protections available on the camera. The presenter says the platform lacks modern mitigations such as address space layout randomization and data execution prevention, possibly because the older, lightweight kernel supports cheaper hardware.
• Unstripped binaries make reverse engineering easier because meaningful function names remain visible. Instead of first reconstructing the program's structure from anonymous code, an analyst can inspect preserved symbols, identify functions that appear security-relevant, and focus debugging or disassembly work on promising areas.

Questions & Answers

Q: How do you begin reverse engineering an IoT camera?

Begin by obtaining the firmware so its files, scripts, web resources, and executable binaries can be inspected offline. In the demonstration, the researcher searched for the camera's firmware name, found a text file listing versions and MD5 hashes, copied a known filename, and changed its version number. The requested firmware then downloaded successfully, creating the basis for static analysis and comparison with the running device.

Q: How can exposed services on an IoT camera be identified?

Run a network scan against the connected camera and review the ports that answer. The demonstrated Nmap scan completed quickly because the device did not use firewalling or stealth behavior. It openly revealed Telnet and an HTTP service on port 81. Connecting through a browser then exposed the web administration interface, firmware information, and settings needed for further live assessment.

Q: Why does using port 81 not hide an IoT web server?

Changing an HTTP server from its usual port to port 81 only changes where the service listens. It does not prevent a port scanner from detecting the open endpoint or recognizing the underlying service. In the demonstration, Nmap found the camera's standard HTTP server immediately. The presenter also notes that the device uses UPnP negotiation, further weakening the idea that the unusual port provides concealment.

Q: Why are shared default IoT passwords dangerous?

A shared default password allows knowledge from one device or public source to unlock many devices using the same firmware or configuration. The demonstrated camera's administrator password was printed on its packaging and visible in an online product image, so a person could obtain it without buying the camera. Because the interface also lacked guess throttling, repeated login attempts remained another practical route to access.

Q: How does missing login throttling weaken an IoT device?

Missing throttling means the device continues accepting authentication attempts without introducing delays, temporary lockouts, or another stated limit. An attacker can therefore keep submitting password guesses until one works. On the demonstrated camera, this weakness existed alongside a shared administrator password that was already discoverable from packaging and online imagery, making the authentication design vulnerable through multiple independent paths.

Q: How is Binwalk used during IoT firmware analysis?

Binwalk is used to extract the contents embedded inside firmware packages so analysts can browse their structure and inspect individual artifacts. In the camera assessment, extraction produced one firmware set containing the web administration files and another containing binaries used by the device. The researcher then explored scripts, executables, model directories, and a password-protected zip archive associated with updates to the www path.

Q: Why does an old kernel make an IoT camera less secure?

The demonstrated camera runs a 2.6 kernel that the presenter describes as impressively old and comparable to an early Windows XP security model. According to the talk, it lacks mitigations such as address space layout randomization and data execution prevention. The suspected tradeoff is that an older, lightweight kernel can operate on cheaper hardware, but the resulting platform provides fewer barriers against exploitation.

Q: Why do unstripped binaries help reverse engineers?

Compiled binaries normally undergo stripping to remove symbols, including clear function names that reveal program structure and purpose. The camera's binaries were not stripped, so a reverse engineer could open them in debugging or disassembly tools and immediately see names that might identify interesting behavior. This shortens the search for security-relevant functions and makes focused investigation easier than working with anonymous code locations.

Summary & Key Takeaways

• The assessment begins by acquiring the camera firmware through a publicly accessible update location. A firmware index exposes version names and MD5 hashes, while changing the version number in a known filename produces a successful download. This gives the researcher files and binaries for static analysis without extracting firmware directly from the physical device.

• Live network assessment reveals exposed services without firewalling or stealth behavior. The camera openly answers an Nmap scan, provides Telnet, and runs a standard HTTP server on port 81. Its web interface accepts a shared administrator password that appears on packaging and product images, while missing attempt throttling permits repeated password guesses.

• Binwalk extracts separate firmware packages containing web files and device binaries. Inspection reveals a password-protected web-interface archive, an ARM system, a 2.6 kernel, and named functions preserved inside unstripped binaries. These design choices reduce modern exploit mitigations and make interesting code paths easier for a reverse engineer to identify and investigate.