Who knew that paranoia could be so generous? Not only does it allow you to worry about a larger fraction of the world's hazards, it can even increase the number of potential hazards for you to worry about.

I read ads on the subway, so I know that you can't be too careful these days. There are no bounds, for example, to the treachery my dog might be perpetrating while I'm hard at work, and it is essential, therefore, to have a 7 day rolling video archive of so that, say, 5 days after the shredding of a particularly valuable chunk of styrofoam, I can confront Fido (not her real name) with irrefutable evidence.

Shameless commerce

So I bought me one of these Amcrest thingies:

(By the way, this is an Amazon affiliate link, and I really would appreciate it if you clicked through and bought the camera, notwithstanding the very good reasons not to.)

Then, I noticed this disturbing review, the gist of which is that, if you follow the standard instructions for setting up the camera with UPnP, you'll be exposing a totally unsecured CGI interface to the internet at large. "Not to worry, Fido," I said, "I'm an Information Technology professional, and I would never do anything that stupid. Your disgusting secrets are safe with me." Blinking quizzically, Fido batted herself in the face, dislodging a blackened clump of eye mucous, which she quickly slurped up. "True," I said, "but I have UPnP disabled, I've verified with nmap that incoming ports are all closed, and I access the camera only via web services, to which the camera makes outgoing connections... What? Wireshark, you say? Oh fine." Sometimes I wonder if dog ownership is worth the effort.

Puzzlement

(Another Amazon affiliate link, by the way. Whatever it is, it's previously used but supposedly in good condition. Give it a try.)

The more I say about Wireshark, the more likely I am to reveal my ignorance about something important, so, if you haven't had the pleasure yet, go read about it, and come back after a few weeks of the sort of thing you think is fun but probably disturbs a lot of people. Basically, we all now know, if you run Wireshark, it will scoop up all the TCP packets it sees and let you filter and search them in various ways. What I was looking for was traffic to and from the camera. I already knew, by looking at router logs, what IP address the camera went by and that it had made various connections into IP ranges owned by Amazon Web Services. Strangely, though, Wireshark couldn't see any of this. All I saw in the logs was the occasional message between my laptop and the camera's configuration web interface, which I'd already verified was invisible to the outside world.

Nervous little dogs

As an active (in the sense of this-very-minute) practitioner of internet scaremongering, I am brimming with sympathy for the authors of breathless Wireshark tutorials about the fun you can have in a coffee shop, but my dog doesn't live in a coffee shop. For a number of reasons that in retrospect were a bit obvious, it's not always easy to capture traffic to or from a machine other than the one on which you are running Wireshark. There are many long and intimidating articles about why this is so, but it all comes down to two common cases:

1. It's a wired network. In this case, all the traffic is flowing through an ethernet switch, which is meticulously routing to each device only the packets that are meant for it. Back when switches were really expensive, you could count on the ethernet hub to send all packets to all devices, which were supposed to avert their eyes from irrelevant ones. (You'll read a lot about setting your NIC card to "promiscuous mode," but that only affects what the card does with packets it receives. It doesn't induce the switch to send them in the first place.)
2. Alternatively, it's a wireless network. And, since we're all responsible adults - unlike those hippies in charge of America's coffee shops - it's likely using WPA2, which features session-level encryption, so, whether or not other people's business is physically reaching your NIC, you aren't going to be able to make sense of it. (Note that this encryption is independent of whether or not the contents of the TCP communication is encrypted.)

Of course, since we own the network, we have the ability to modify it, such that Wireshark is in the path of ungarbled packets. The most common advice is to stick an old-fashioned ethernet hub on the network, positioned so that the traffic you're interested in must pass through it, and then plug your laptop (or whatever you're using to run Wireshark) into the hub. Alternatively, you can endow your switch with hub-like capabilities (or deficiencies). Fancy switches have specific sniffer features for this, but not-so-fancy consumer routers are generally running linux and so have iptables. Looking at the DHCP leases on my router, I can see that the camera is roosting at 192.168.2.98, while my laptop is 192.168.2.87. Now, I want to take all traffic -destined for the camera or -sourced from it, and --tee a copy off to my laptop:

iptables -t mangle -A POSTROUTING -d 192.168.2.98 -j ROUTE --tee --gw 192.168.2.87
iptables -t mangle -A PREROUTING -s 192.168.2.98 -j ROUTE --tee --gw 192.168.2.87

Having done this, we can start up capture in Wireshark with a host 192.168.2.98 filter, and there's quite a bit more to see.

Ouch

In particular, we see something like this:

3054    19.206767   ec2-54-81-2-137.compute-1.amazonaws.com 192.168.2.98    FTP 86  Response: 220 (vsFTPd 2.2.2)
3056    19.209820   192.168.2.98    ec2-54-81-2-137.compute-1.amazonaws.com FTP 81  Request: USER cam12345
3059    19.236939   192.168.2.98    ec2-54-81-2-137.compute-1.amazonaws.com FTP 83  Request: PASS 1a23456b
3074    19.416028   192.168.2.98    ec2-54-81-2-137.compute-1.amazonaws.com FTP 101 Request: stor 2016-1-2-03-04-05-AmcFtp.mp4

In case this isn't clear, my "security" camera is transmitting video by ftp, in plaintext, along with a username and password. "Surely someone can explain this to me, Fido, but who?" Fido removed her snout from a delicate location and belched. "Worth a try," I admitted. Indeed, the packet stream contained thousands of bytes along the lines of

0000   a4 5e 60 d6 c9 69 bc ee 7b 7d 10 b8 08 00 45 00  .^`..i..{}....E.
00a0   67 31 0b 30 09 06 03 55 04 06 13 02 43 41 31 0b  g1.0...U....CA1.
00b0   30 09 06 03 55 04 08 13 02 4f 4e 31 0f 30 0d 06  0...U....ON1.0..
00c0   03 55 04 07 13 06 4f 74 74 61 77 61 31 11 30 0f  .U....Ottawa1.0.
00d0   06 03 55 04 0a 13 08 43 61 6d 63 6c 6f 75 64 31  ..U....Camcloud1
00e0   11 30 0f 06 03 55 04 0b 13 08 43 61 6d 63 6c 6f  .0...U....Camclo
00f0   75 64 31 14 30 12 06 03 55 04 03 13 0b 44 61 6e  ud1.0...U....Dan
0100   20 42 75 72 6b 65 74 74 00 69 30 67 31 0b 30 09   Burkett.i0g1.0.
0110   06 03 55 04 06 13 02 43 41 31 0b 30 09 06 03 55  ..U....CA1.0...U
0120   04 08 13 02 4f 4e 31 0f 30 0d 06 03 55 04 07 13  ....ON1.0...U...
0130   06 4f 74 74 61 77 61 31 11 30 0f 06 03 55 04 0a  .Ottawa1.0...U..
0140   13 08 43 61 6d 63 6c 6f 75 64 31 11 30 0f 06 03  ..Camcloud1.0...
0150   55 04 0b 13 08 43 61 6d 63 6c 6f 75 64 31 14 30  U....Camcloud1.0
0160   12 06 03 55 04 03 13 0b 44 61 6e 20 42 75 72 6b  ...U....Dan Burk
0170   65 74 74 0e 00 00 00                             ett....

so clearly at least one person wants my attention. Dan Burkett, you may have guessed, lives in Ottawa, and is affiliated with a company called Camcloud, to which Amcrest apparently outsources its web-based offerings.

I fired off a nice email to info@camcloud.com, inquiring about "the methods you use to protect the privacy and security of users." Surprisingly, they wrote back. Unsurprisingly, they don't really see an issue here:

Your packet analysis is correct that FTP is used for media transfer during media upload, which is very common for almost all IP cameras. It's important to point out that our FTP server implementation does not permit user access or any file retrieval (upload only) and every camera's FTP credentials are unique to that camera, and are destroyed when the camera is removed from the cloud.

The upload-only ftp drop is very slightly reassuring, in that spies would need to to capture and reassemble each file in real time, rather than perusing a library of mp4's at their leisure. On the other hand, it did occur to me that a careful burglar - less interested in spying on me than preventing me from spying on him - might think to overwrite incriminating uploads. Please don't tell Fido, but I verified that (1) I could indeed log into the ftp server manually, (2) I could not RETR the file that my camera had uploaded, but (3) I could indeed overwrite it with one containing only the string "Hello".

Also, for what meanings of "very common" and "almost all" is "very common for almost all" distinguishable from "very common" or "almost all" separately? I worry about these things.

What now?

In the grand scheme of IoT disaster scenarios, the Amcrest ProHD 1080P is probably not going to be our national undoing, but it's still kind of creepy. We're used to the idea that peril lurks in every email (so sorry, HotH00kup69), and there doesn't seem to be much percentage in wiring our refrigerator to the matrix, but security cameras sound like they ought to be sort of secure. Phrased as, "hey, let's take this mysterious little computer running software about which we know nothing, cram it with gigabytes of personal data and expose it to the internet," the idea is less appealing.

Worse, while it took a bit of effort to uncover the minor fiasco of plaintext ftp, increased sophistication on the part of the provider would have the primary effect of hiding the mechanism from users like me, and only secondarily and unverifiably the effect of increasing security. I don't own a NestCam, but I'd be surprised if the fine people at a wholly owned subsidiary of Google would at this point be making any mistakes crude enough for me to discover and blog about. On the other hand, Google may not be the most trustworthy guardian of your visual records.

Anyway, this is why you shouldn't have a dog.