Security researcher Wladimir Palant has disclosed extensive security issues in VStarcam IP cameras, revealing that hundreds of firmware versions contain mechanisms that leak administrator passwords.
The findings show that these are not isolated bugs but long‑standing design choices that allow credentials to be exposed to unauthenticated attackers and, in several cases, directly to VStarcam-operated servers.
Palant’s research is based on reverse engineering and automated analysis of 367 different firmware versions. He did not use physical devices; instead, he unpacked firmware updates and examined the code with Ghidra and custom scripts. While this approach has limitations, Palant notes that the patterns he identified are consistent across firmware families and hardware platforms.
VStarcam is a major vendor of consumer IP cameras, often marketed explicitly as security cameras. Its products are sold globally under many brand names, including Besder, MVPower, AOMG, and OUSKI, and are typically managed through mobile apps such as Eye4, EyeCloud, and O‑KAM Pro. The cameras rely on the PPPP peer‑to‑peer protocol, which keeps them reachable from the internet even when installed behind a NAT firewall.
Password exposure
Palant identified several distinct ways in which VStarcam firmware leaks credentials.
One common issue is unauthenticated access to device logs via the get_online_log.cgi endpoint. An attacker can enable live log streaming without logging in, then wait for the legitimate owner to connect. When that happens, the camera logs incoming requests, including plaintext usernames and passwords, and sends them to the attacker.
In other firmware versions, the problem is even more direct. During a failed login attempt, the firmware may log the correct administrator password in a debug message. If log streaming or log upload is enabled, the attacker immediately receives valid credentials without waiting for the user.
Palant also found functionality that uploads logs to VStarcam servers over unencrypted TCP connections. In several firmware builds, the upload is triggered on the first failed login attempt and includes both the failed request and the correct password, effectively sending credentials back to the vendor.
Most concerning is a hidden backdoor added in newer firmware versions. A second version of the get_online_log.cgi API returns an obfuscated string that, when decoded, reveals the device password. The obfuscation is trivial and appears designed to conceal the behavior rather than secure it. Palant concludes that this backdoor cannot reasonably be explained as a debugging mistake.
VStarcam advertises “AES financial‑grade encryption” and a “dual authentication mechanism.” Palant found no evidence of AES encryption in the firmware and confirmed that authentication relies on plaintext passwords. The “dual authentication” system largely checks a second password stored in the cloud, but in many firmware versions, the cloud verification always returns success, making it meaningless.
Leaking since 2020
By comparing logging behavior across all firmware versions, Palant reconstructed a rough timeline. Password leaks via logging appeared as early as 2020, log uploads to VStarcam servers in 2021, unauthenticated log access around 2022, and the covert backdoor around 2024. The newest firmware branch, the one still actively developed, often contains all of these issues at once.
Once an attacker knows a camera’s password, they can access live audio and video and, in some models, enable Telnet with known credentials. VStarcam cameras have a history of command‑execution flaws, making them suitable for botnets or as entry points into local networks.
Palant attempted to contact VStarcam but received no response, despite the company advertising ISO 27001 compliance. Given the apparent intent behind the backdoors, he published the findings without waiting for remediation.
Palant advises treating all VStarcam cameras as inherently untrusted. The safest option is to block their internet access at the router, use them only on a local network, or replace them entirely. No firmware version can currently be considered secure.
Leave a Reply