IT Security Research by Pierre

TL;DR: by analysing the security of a camera, I found a pre-auth RCE as root against 1250 camera models. Shodan lists 185 000 vulnerable cameras. The "Cloud" protocol establishes clear-text UDP tunnels (in order to bypass NAT and firewalls) between an attacker and cameras by using only the serial number of the targeted camera. Then, the attacker can automaticaly bruteforce the credentials of cameras.

Product Description

The Wireless IP Camera (P2P) WIFICAM is a Chinese web camera which allows to stream remotely.

Vulnerabilities Summary

The Wireless IP Camera (P2) WIFICAM is a camera overall badly designed with a lot of vulnerabilities.
This camera is very similar to a lot of other Chinese cameras.

It seems that a generic camera is being sold by a Chinese company in bulk (OEM) and
the buyer companies resell them with custom software development and specific branding. Wireless IP Camera (P2) WIFICAM is one of the branded cameras.

So, cameras are sold under different names, brands and functions. The HTTP
interface is different for each vendor but shares the same vulnerabilities.
The OEM vendors used a custom version of GoAhead and added vulnerable code inside.

GoAhead stated that GoAhead itself is not affected by the vulnerabilities but the OEM vendor who did the custom and
specific development around GoAhead is responsible for the cause of vulnerabilities.

Because of code reusing, the vulnerabilities are present in a huge list of cameras (especially the InfoLeak and the RCE),
which allow to execute root commands against 1250+ camera models with a pre-auth vulnerability.

The vulnerabilities in the Cloud management affect a lot of P2P or "Cloud" cameras.

My tests have shown that the InfoLeak affecting the custom http server running on the camera affects at least 1250+ camera models. It can be used to execute the RCE as root.
Thus, these cameras are likely affected by a pre-auth RCE as root:

Update (Mar 16, 2017): Following the strong requests from a specific vendor,
the complete list of 1250 affected camera models has been removed.

The HTTP interface is provided by a custom http server. This HTTP server is in fact based on GoAhead and
was modified by the OEM vendor of the cameras (which resulted in the listed vulnerabilities).
It allows 2 kinds of authentication:

htdigest authentication OR

authentication using credentials in URI (?loginuse=LOGIN&?loginpas=PASS).

the application sends a request to the remote server, asking if the camera with the specific serial-number is online,

the server will reply by "camera doesn't exit", "camera is offline" or "camera is online",

if the camera is online, a UDP tunnel is automaticaly established between the application and the camera, using the Cloud server as a relay.

UDP tunnel:

[Android Application] <===UDP===> Cloud server <===UDP===> [Camera]

Then, the UDP tunnel is used by the application to reach the camera:

1/ the client will send a HTTP request to the camera with the credentials (still in clear-text)

GET check_user.cgi?&loginuse=admin&loginpas=admin&user=admin&pwd=admin&

or

GET /check_user.cgi?&loginuse=admin&loginpas=admin&user=admin&pwd=admin&

2/ the camera will reply by using HTTP over UDP whenever the credentials are valid or invalid.

If the credentials are valid, the camera will reply:

result= 0;

If the credentials are not valid, the camera will reply:

result=-1

3/ if the credentials are valid, then the application will send HTTP requests to .cgi files hosted by the camera by appending credentials to the requests (?loginuse=valid_user&loginpas=valid_pass)

Step 2 in detail:

If the authentication is OK, so it is alright to dump all the configuration in cleartext!

Note: this trace was done with one of the application listed below, to be sure applications are sharing the same "cloud" network (it appears the daemon running on the camera doesn't strictly respect the HTTP protocol - note the lack of / - but it works !).

If the authentication is not OK. The cameras answers:

result=-1;

Due to the absence of checking, an attacker can simply bruteforce credentials.

Step 3 in detail:

The application sends:

GET get_params.cgi?&loginuse=admin&loginpas=admin&user=admin&pwd=admin&

OR

GET /get_params.cgi?&loginuse=admin&loginpas=admin&user=admin&pwd=admin&

This is interesting because an attacker can reach a camera only by knowing a serial number. The UDP tunnel between the attacker and the camera is established even if the attacker doesn't know the credentials. It's useful to note the tunnel bypasses NAT and firewall, allowing the attacker to reach internal cameras (if they are connected to the Internet) and to bruteforce credentials.
Then, the attacker can just try to bruteforce credentials of the camera:

GET /get_params.cgi?&loginuse=admin&loginpas=TEST&user=admin&pwd=TEST&

This protocol appears to be common to a lot of Android applications, ie:

It appears the pre-auth is not easily reachable within the cloud network.

This "cloud" protocol seems to be more a botnet protocol than a legit remote access protocol and has indeed weakness (everything in clear-text, i.e. an attacker can attack cameras within the cloud and leverage potential access to hack internal networks).

A lot of P2P ('Cloud') cameras are in fact using the same botnet protocols and the same infrastructure seemingly to be managed by a single entity.

Writing a PoC which bruteforces credentials of the remote camera is left as an exercise for the reader.