On Thu, Jun 13, 2013 at 09:11:35PM -0400, Scott Helms wrote:
I challenge your imagination to come up with a common scenario where a non targeted "I'm/they're here" that's useful to either the company or the Chinese government keeping in mind that you have no fore knowledge of where these devices might be deployed.
How about "code that watches for password changes on the device, captures them, quietly and slowly leaks them a bit at a time"? And I do mean "slowly": passwords don't change all that often, so if it takes a week to transmit one, that's not a concern. Passwords also get reused, so knowledge of the pair (Device1, Password1) is often useful when considering (Device2, Device3, ... DeviceN). You're right: nobody would know a priori where the devices are going. But why would [some of the] attackers care? And it's not strictly necessary to have the devices transmit the info to a pre-designated listener: it could be inserted in ALL traffic [1] so that the device is always (slowly) broadcasting its own password. Yes, this is very inefficient; yes, that might mean that transmission of the password back to the attackers isn't guaranteed; yes that might mean that it takes a much longer time to harvest passwords. But if the attackers' goal is to harvest as many passwords as possible, then efficiency and speed aren't important. (After all, many of the devices might sit in boxes for a long time. Or be installed on networks that are air-gapped. Or otherwise might never report anything useful.) What's much more important is undetectability, and given that almost all the detection mechanisms in play look for something like "lots of traffic to/from an unexpected location" the best way to avoid that is to be very slow, very quiet and very undirected. Yeah, yeah, yeah, I know: far-fetched. But yesterday's "far-fetched" keeps turning out to be today's reality with monotonous regularity. And: suppose *you* were an attacker with a multi-billion dollar budget, thousands of people, and years to work: don't you think you could pull this off, too? ---rsk [1] Perhaps disused packet header fields. Or perhaps, more cleverly, buried in the packet itself. Or otherwise concealed in other ways that make it very hard to pick out unless you know, a priori, what you're looking for.