I.T. by Fire: 2015

(Note to the evil among us: I have, of course, changed the authorization and authentication details below. So don't bother. Or do, waste your time, see if I care. :) )

We recently moved about a mile down the road, which meant we needed a new Xfinity setup, and of course they've revamped their hardware. This time, we got a new Xfinity Gateway with 802.11ac support. In fact, the latest gateway we just got apparently has something called beamforming, which is totally worth reading about because it's a really awesome hack.

Unfortunately, we discovered that Xfinity Home Security no longer uses a discrete "security router" for the wireless touchscreen and cameras. They appear to have integrated this functionality directly into the Xfinity internet gateway, so my camera recording solution couldn't be set up with the new installation. While this is no doubt cheaper and better for them, I wasn't happy losing access to the cameras for no good reason.

Thanks to Chad Sturgill, however, I'd been thinking about sniffing the packets of a camera provisioning to determine the hidden wifi network and other details. Now I had a reason. So after the Xfinity tech left, I went to work. Chad was right, and this is probably not for the faint of heart, and it took me a few tries to get something useful. I set up my Linux firewall with 3 NICs to treat two of them in a bridged configuration, connected one to the camera, one to port 4 of the Xfinity gateway, and then ran tshark to capture the traffic. I did have to run dhclient on the bridged interface to get it online, and then ran tshark thusly:

# ifdown eth0
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth1
# dhclient br0
# tshark -i br0 -w capture.tcp src net 172.16.12.0/24 and dst net 172.16.12.0/24

(My firewall was getting traffic on non-bridged interfaces and trying to route it out the bridged interface, so I used the filter expression above to limit the captured traffic to only the "security" network.)
And voila, I see packets:

GET /device.xml HTTP/1.1
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130:6789
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
CONTENT-TYPE: text/xml
CONTENT-LENGTH: 998
LAST_MODIFIED: Tue, 27 Oct 2015 10:04:34 GMT
DATE: Tue, 27 Oct 2015 10:04:38 GMT
SERVER: Linux/2.6.18_SC-DM365 UPNP/1.0 Intel UPnP
CONNECTION: close

<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
    <major>1</major>
    <minor>0</minor>
</specVersion>
<URLBase>http://172.16.12.130:6789</URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:Wireless Network Camera:1</deviceType>
<friendlyName>iCamera-iCameraDFCD9E</friendlyName>
<manufacturer>iControl</manufacturer>
<manufacturerURL>http://www.icontrol.com</manufacturerURL>
<modelDescription>Wireless Network Camera </modelDescription>
<modelName>Wireless Network Camera</modelName>
<modelNumber>iCamera</modelNumber>
<UDN>uuid:4d751d74-694d-6564-6961-000e8fdfcd9e</UDN>
<serviceList><service>    <serviceType>urn:upnp:service:BasicService:1</serviceType>    <serviceId>urn:upnp:serviceId:BasicServiceId</serviceId>        <controlURL>/upnp/control/BasicServiceId</controlURL>        <eventSubURL>/upnp/control/BasicServiceId</eventSubURL>        <SCPDURL>/scpd_basic.xml</SCPDURL>    </service>
</serviceList>
<presentationURL>http://172.16.12.130</presentationURL></device>
</root>

There is some SSL traffic that I can't decrypt, but then things switch back to HTTP:

GET /adm/sysinfo.cgi HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Pragma: no-cache
Expires: Mon, 06 Jan 1990 00:00:01 GMT
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:04:38 GMT
Server: ip-camera

Firmware Version: V1.0.02R19
Serial Number:1307ZZ9063892

Note that the Authorization header here decodes to a username of "administrator" with an empty password. This seems like it's just getting the firmware version of the camera, checking to see if a firmware upgrade is required.

GET /adm/set_group.cgi?group=NETWORK&dns_server1=172.16.12.1&dns_type=1 HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:04:43 GMT
Server: ip-camera

OK

Using the same Authorization header, this appears to set the DNS (probably so that the next step can use DNS).

GET /adm/auto_upgrade.cgi?new_fw_url=http://edge.xfinity-home.top.comcast.net/firmware/DYW9HZ-308-1002R22.bin HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Status: 200
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:04:43 GMT
Server: ip-camera

OK

So it looks like this camera had firmware version 1.0.02R19, and the touchscreen wants it to get version 1.0.02R22. The request to perform the upgrade was sent 10 seconds in, and the touchscreen looks like it just waits 2 minutes. Then, at 129 seconds in, it tries to connect to the camera again. This fails, and the touchscreen starts periodically ARPing the camera.

At 383 seconds in, the camera appears to have finished whatever it was doing as it requests a DHCP from the Gateway router, does a bunch of IGD/UPNP negotiation with the Gateway router. Finally, at 402 seconds in, the touchscreen reconnects to the camera.

GET /adm/sysinfo.cgi HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Pragma: no-cache
Expires: Mon, 06 Jan 1990 00:00:01 GMT
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:11:17 GMT
Server: ip-camera

Firmware Version: V1.0.02R22
Serial Number:1307ZZ9063892

And it appears the upgrade succeeded, since the camera reports v1.0.02R22 now. The touchscreen then makes the same request again. That's weird.

GET /adm/sysinfo.cgi HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Pragma: no-cache
Expires: Mon, 06 Jan 1990 00:00:01 GMT
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:11:17 GMT
Server: ip-camera

Firmware Version: V1.0.02R22
Serial Number:1307ZZ9063892

And just for good measure, it checks a third time ("How many times did you do it?" "Three, you told me to always do it three times.")

GET /adm/sysinfo.cgi HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Pragma: no-cache
Expires: Mon, 06 Jan 1990 00:00:01 GMT
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:11:17 GMT
Server: ip-camera

Firmware Version: V1.0.02R22
Serial Number:1307ZZ9063892

And then things get interesting. Note that I'm breaking these requests up for clarity but they are actually being sent over a single HTTP connection in some cases. The first thing that happens is that the touchscreen tries to set the http and https mode. This fails because now authentication is required (is the username/password in the firmware that was just updated? or does it come from somewhere else?).

GET /adm/set_group.cgi?group=HTTP&https_mode=1&http_mode=1 HTTP/1.1
Host: 172.16.12.130
Connection: Keep-Alive

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Authorization"
Content-Type: text/html
Content-Length: 351
Date: Tue, 27 Oct 2015 10:11:17 GMT
Server: ip-camera

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
  <title>401 - Unauthorized</title>
 </head>
 <body>
  <h1>401 - Unauthorized</h1>
 </body>
</html>

Denied! But then the touchscreen immediately tries again with username administrator and an empty password:

GET /adm/set_group.cgi?group=HTTP&https_mode=1&http_mode=1 HTTP/1.1
Host: 172.16.12.130
Connection: Keep-Alive
Authorization: Basic YWRtaW5pc3RyYXRvcjo=

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 10:11:21 GMT
Server: ip-camera

OK

And this succeeds. I'm not sure whether this enables both an http and https server, or sets some other kind of mode. The touchscreen proceeds to get the firmware version again (but I'm not going to show that yet again). And then, at last, things get interesting!

GET /adm/set_group.cgi?group=USER&admin_name=root&admin_password=dvRxPrwv&login_check=1&user1=icn0Pnl2%2CV53xEm4 HTTP/1.1
Authorization: Basic YWRtaW5pc3RyYXRvcjo=
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:11:32 GMT
Server: ip-camera

OK

Looks like it wants to set a username of root and a password of dvRxPrwv, and a set of "viewer" credentials of username icn0Pnl2 and a password of tV53xEm4 (the %2C there is of course the URL-encoded value for the colon ":", which is used in the HTTP authentication scheme to separate the username from the password).

GET /adm/set_group.cgi?group=SYSTEM&led_mode=1&daylight_saving=1&pir_mode=0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 10:11:32 GMT
Server: ip-camera

OK

This is probably not really important, blinking lights and time zones, etc.

GET /adm/set_group.cgi?group=WIRELESS&wlan_type=1&wlan_essid=XHS-8C1EB62D&wlan_security=2&wlan_domain=12&wpa_ascii=D765494564A6621854 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 10:11:36 GMT
Server: ip-camera

OK

More meat! The wireless network settings we should use! The rest, frankly, seems like administrivia.

GET /adm/set_group.cgi?group=AUDIO&audio_in=0&in_audio_type=1 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 11:11:41 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=HTTP_EVENT&http_post_url=&http_event_en=1 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 11:11:43 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=VIDEO&contrast=4&sharpness=2&exposure=4&text_overlay=0&default_channel=1&saturation=4&color=0&hue=4&dn_sch=0&time_stamp=0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 11:11:49 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=MOTION&md_mode=0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 11:11:49 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=UPNP&upnp_mode=0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 11:11:50 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=MPEG4&gov_length=20&quality_type=0&mode3=0&quality_level=3&resolution=3&mode2=0&frame_rate=15&bit_rate=6&mode=1 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 11:11:54 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=H264&mode3=0&quality_level2=3&gov_length2=10&resolution=3&resolution2=3&mode=1&gov_length=15&quality_type=0&quality_type2=0&bit_rate2=512&frame_rate2=5&mode2=1&frame_rate=15&bit_rate=768&profile=77 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 11:11:57 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=JPEG&frame_rate3=10&mode2=0&resolution3=3&mode3=1&quality_level3=5&mode=0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 11:12:02 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=EVENT&event_trigger=1&event_interval=0&event_attach=mp4%2C1%2C5%2C10&event_httpc=email%3A0%3Bftpu%3A0%3Bhttpn%3A0%3Bhttppost%3A1&event_pir=email%3A0%3Bftpu%3A0%3Bhttpn%3A0%3Bhttppost%3A0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Date: Tue, 27 Oct 2015 11:12:06 GMT
Server: ip-camera

OK

GET /adm/set_group.cgi?group=NETWORK&dns_type=1&dhcp=0&ip_addr=172.16.12.163&dns_server1=172.16.12.1&gateway=172.16.12.1 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.130
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 11:12:09 GMT
Server: ip-camera

OK

But note this -- interestingly, it's moving the camera to a new IP address. Not sure why but okay. There's a little bit of ARPing before the next connection can be made, since the camera switches IP addresses immediately.

GET /adm/set_group.cgi?group=JPEG&frame_rate3=15&mode2=0&resolution3=2&mode3=1&quality_level3=3&mode=0 HTTP/1.1
Authorization: Basic cm9vdDpkdkR4cnJ3dg==
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; TCA203 Build/R10.3.3-r1)
Host: 172.16.12.163
Connection: Keep-Alive
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 4
Date: Tue, 27 Oct 2015 11:13:04 GMT
Server: ip-camera

OK

And that's it, all done.

Apparently, not news to anyone, this camera is an OEMed camera made by an overseas company called Sercomm, and many models exist (branded for each vendor). But they all (mostly) share (mostly) the same API. I found a pretty good reference at github, but there are others. IMHO the one at github does the best job listing all of the options available over the API.

A few interesting notes, thanks to the others who have investigated this:

The camera has a microphone, and if you turn it on you can hear it on the RTSP stream, at least. But it's a very bad microphone and you can barely hear it.
The camera might have a speaker. I can't tell about mine, but apparently some of them do. Maybe I'll try to do something with this at some point.
There is some kind of built-in motion detection that can be used to issue alerts to an HTTP server, and possibly other functionality. I haven't tried this either, but it seems like maybe having each camera notify a recording system of events rather than having the recorder streaming video from all of the cameras all of the time could be a much more efficient system.
There is a dynamic DNS update client. Not that these aren't a dime a dozen, and as the API reference notes that many of the DDNS providers are no longer working, this isn't a big deal, but it could be useful.
There is a Windows software package for managing the cameras. I haven't found it yet, but I haven't really looked either.

A few other notes:

The admin credentials for this camera are NOT the same as for the other cameras on my network, so there are apparently different credentials for each camera. Good Job, Comcast.
There are functions in the camera that seems like they could be abused -- the ability to do a wifi site survey and retrieve information about all of the wireless networks that the camera sees. I'm just not sure what purpose this could serve, and I worry (just a little bit) about that information leaking on such a massive scale since these cameras are quite popular.
In the same vein, you can do an SMB survey of the local network (which given it's an isolated hidden wifi network won't include your own machines). This could also potentially be abused, but I think the risk is mitigated by the network topology that Comcast enforces.

In conclusion, my thanks to Chad for pioneering this, and hopefully the protocol captures I've shown above might help someone figure out something about their camera.

I.T. by Fire

Tuesday, October 27, 2015

Hacking Xfinity's Home Security Cameras, part 2