On Fri, Jun 14, 2013 at 8:47 AM, Rich Kulawiec <rsk@gsp.org> wrote:
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.
This is feasible, but frankly unlikely because AFAIK no one disputes that backdoors (intentional or not) are in most if not all gear. Having said that, it would still be pretty obvious in mass and over time to have packets going to a predesignated host. Its not really possible for a box to know whether its in a "real" network or a lab with Spirent or other traffic generator hooked to it.
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?
It really depends on what someone wants to accomplish. There are lots of things that are possible, but not feasible simply because there are cheaper/faster/better ways of accomplishing the same thing. Shutting down a network is pretty easy so if you have a kill switch and a backdoor (both likely and easy) then why do you care about the passwords of the devices near by? You can knock out a core router in other ways.
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.
How? There is truly not that much room in the IP packet to play games and if you're modifying all your traffic this would again be pretty easy to spot. Again, the easiest/cheapest method is that there is a backdoor there already.
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.
Not really, things that are far fetched can become reality but only in cases where something underlying changes.
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?
I could certainly and as I've pointed out, I wouldn't even consider routers outside of disruptive attacks. If you want to steal information you want to be as close to the end user target as you can be so your signal to noise ratio is better. If I wanted to do this and had the resources of the Chinese government then I'd be much more focused on Lenovo than Huawei. The parts that are most interesting in Huawei aren't the core pieces but rather the consumer and office gear.
---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.
There are a couple of places you could stick something, but it would stick out like a sore thumb in Wireshark.