Almost every higher class DSLR on the market today features multiple and complex access technologies. To name a few, canons new flagship features IP connectivity wired via 802.3 as well as wireless via 802.11. All the big vendors are pushing these features to the market and advertise them with real time image transfer to the cloud. We have taken a look at the layer 2 and 3 implementations in the CamOS and the services running upon those, so here is what we found while examine the EOS 1D X:
Layer 2/3:
Nothing surprising here, all the classic attacks, like ARP spoofing or TCP RST attacks are working like a charm. Maybe one thing noted, if you send more than ~100 packets per second to the camera, you can easily DoS the network stack (we tested this with broadcasted ARP packages), which also isn’t much of a surprise, as its a real time operating system running on the cam, made for taking a lot photos fast, not for processing a lot of packets fast.
The Services:
There are four different networking modes, the camera can be driven at. First you got the option to upload photos directly to a configured FTP server. Not the most challenging service as FTP is complete clear text. So if an attacker is able to get into the packet stream (which he can get easily via ARP spoofing, if he’s in the same broadcast domain) it’s easy to extract the credentials used to loggon the FTP server. If the packet stream is recorded, its even possible to extract all uploaded photos from that stream.
The second network mode is called DLNA (Digital Living Network Alliance), which in fact is a communication standard for exchanging audio, photo and video between compatible devices. The standard relies on UPNP for discovery of other DLNA compatible devices. Afterwards XML over HTTP is used for information (read: directory listing) exchange and finally the photos are directly accessible via HTTP. No authentication at all. That said it should be obvious, that an attacker with some connectivity to the cam can enumerate and download all the images, if he is in the same broadcast domain, he even sees the cam announcing its presence.
OK, pretty boring so far and not secure at all, but wait, we got two more network modes to go. The next mode is called WFT (Wireless File Transmitter) server. What it does is simply firing up a web server on the camera [by the way, I really like the idea of getting a webserver to every embedded device, this makes a lot of things so much more easy 😉 ]. Once visited with a web browser an AJAX application starts running and one can control the major functions of the camera, as downloading pictures, taking pictures, getting a preview picture a few times per second. But this time there actually is some authentication. On the first visit the web server asks for the credentials configured on the camera via HTTP Basic Auth. The Basic Auth is only performed once and a session id is used afterwards. Now one could complain about not using HTTPS and the authentication being HTTP Basic and not Digest, so a Man-in-the-Middle can sniff either the credentials or the used session id. But in reality its worse, you don’t need to be in the data stream, as the session id is just 4 bytes long and containing hex chacarters. Meaning there are only 16^4 = 65536 different ids, so if a user is authenticated and a valid session id was issued, an attacker can brute force that session id in a matter of minutes.
Now for the last network mode. This one is called EOS Utility mode and that’s exactly what is does, it connects the camera to a Canon proprietary software, the EOS Utility. The utility grants access to every non-manual control of the camera. Once again, MDNS is used to discover the camera and once found, PTP/IP (Picture Transfer Protocol over Internet Protocol – ISO 15740) is used to set up a connection. In this mode the camera and the software needs an initial pairing step to bundle the camera and the software instance running that one PC, in other words to exchange credentials. At least that’s what the pairing process is supposed to do ;).
Long story short, we also managed to bypass this authentication and were able to speak standard PTP with the camera, as well as using all Canons proprietary PTP extensions. This is as far root as one can get without injecting shell code. I won’t discuss the technical details yet (that will be a whole future post on its own) but if you are interested in that topic, leave a comment, drop an email or come see our talk at Shmoocon, Troopers or HITB-AMS and lets have a nice chat afterwards.
cheers
/daniel
Really handy, this new awesome features added by the vendors. One doesn’t even has to buy a camera anymore – a hack is enough!
😛
Great work guys! Just one quick question. Wouldn’t it be just 2 bytes for sessionID? afaik, each byte represent 2 hexadecimal characters.
Yes, you are absolutely right. We tried to sell better than it actually is. must have happened some were between CCC and new years eve (-;
Hi Daniel, really interesting stuff! I am working on a project where I want to control my camera over ptp/ip. Any chance you would share the python script in the last example in your talks?
Thanks,
Einar