[please visit the HTML version athttps://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.htmlto see the image]

## Vulnerabilities Summary

The Wireless IP Camera (P2) WIFICAM is a camera overall badly designedwith 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 inbulk (OEM) andthe buyer companies resell them with custom software development andspecific branding. Wireless IP Camera (P2) WIFICAM is one of thebranded cameras.

So, cameras are sold under different names, brands and functions. The HTTPinterface is different for each vendor but shares the same vulnerabilities.

Because of code reusing, the vulnerabilities are present in a hugelist of cameras (especially the InfoLeak and the RCE),which allow to execute root commands against 1250+ camera models witha 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 GoAhead serverrunning on the camera affects at least 1250+ camera models. It can beused to execute the RCE as root.Thus, these cameras are likely affected by a pre-auth RCE as root:

This vulnerability allows an attacker to steal credentials, ftpaccounts and smtp accounts (email).

## Details - Authenticated RCE as root

A RCE exists in the ftp configuration CGI. This is well-documented asshown https://jumpespjump.blogspot.de/2015/09/how-i-hacked-my-ip-camera-and-found.htmland https://www.pentestpartners.com/blog/hacking-the-aldi-ip-cctv-camera-part-2/in several different camera models.

The partition `/` is mounted in Read-Only, so modifications are notpossible in this partition.

The command injection is located in in `set_ftp.cgi` (see `$(ftp x.com)`):

By combining the Pre-Auth Info Leak within the GoAhead http servervulnerability and then authenticated RCE as root, an attacker canachieve a pre-auth RCE as root on a LAN or on the Internet.

An exploit is provided and can be used to get a root RCE with connect-back.

The exploit will:

1. extract the valid credentials by connecting to the remote GoAheadHTTP server of the targeted camera2. plant a connect-back with `nc`3. execute the payload4. the attacker will receive a root shell with netcat on a second terminal5. clean the payload located in the configuration file

Other method: parse everything, find the "admin" string and extractthe associated password by adding 31bytes after the address of 'a'[dmin]. Works if the login is admin (seems to be this by default, but can bechanged by the user) */

[please visit the HTML version athttps://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.htmlto see the image]

Netcam 360 works too:

[please visit the HTML version athttps://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.htmlto see the image]

It appears, the network protocol is very weak:

1. the camera contacts a remote server using UDP,2. the application contacts a remote server using UDP,3. the application sends a request to the remote server, asking if thecamera with the specific serial-number is online,4. the server will reply by "camera doesn't exit", "camera is offline"or "camera is online",5. if the camera is online, a UDP tunnel is automaticaly establishedbetween the application and the camera, using the Cloud server as arelay.

### 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 thecredentials (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 thecredentials 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 HTTPrequests to .cgi files hosted by the camera by appending credentialsto the requests (`?loginuse=valid_user&loginpas=valid_pass`)

### Step 2 in detail:

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

[please visit the HTML version athttps://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.htmlto see the image]

Note: this trace was done with one of the application listed below, tobe sure applications are sharing the same "cloud" network (it appearsthe daemon running on the camera doesn't strictly respect the HTTPprotocol - 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.

[please visit the HTML version athttps://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.htmlto see the image]

### 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 byknowing a serial number. The UDP tunnel between the attacker and thecamera is established even if the attacker doesn't know thecredentials. It's useful to note the tunnel bypasses NAT and firewall,allowing the attacker to reach internal cameras (if they are connectedto 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:

The client indeed sends the `system.ini` request within the UDP tunnel:

[please visit the HTML version athttps://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.htmlto see the image]

The camera indeed receives this request within the UDP tunnel:

[please visit the HTML version athttps://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.htmlto see the image]

Complete trace is:

[please visit the HTML version athttps://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.htmlto see the image]

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 legitremote access protocol and has indeed weakness (everything inclear-text, i.e. an attacker can attack cameras within the cloud andleverage potential access to hack internal networks).

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

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

## Vendor Response

Due to difficulties in finding and contacting all the vendors,full-disclosure is applied.

I advise to IMMEDIATELY DISCONNECT cameras to the Internet. Hundredsof thousands cameras are affected by the 0day Info-Leak. Millions ofthem are using the insecure Cloud network.

## Report Timeline

* Feb 26, 2017: Vulnerabilities found by Pierre Kim.* Mar 08, 2017: A public advisory is sent to security mailing lists.

## Credits

These vulnerabilities were found by Pierre Kim (@PierreKimSec).

## References

https://pierrekim.github.io/advisories/2017-goahead-camera-0x00.txt

https://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html

## Disclaimer

This advisory is licensed under a Creative Commons Attribution Non-CommercialShare-Alike 3.0 License: http://creativecommons.org/licenses/by-nc-sa/3.0/