[163635] in North American Network Operators' Group
Re: huawei
daemon@ATHENA.MIT.EDU (Mark Seiden)
Thu Jun 13 14:06:02 2013
From: Mark Seiden <mis@seiden.com>
In-Reply-To: <BC3048D9-F11D-4A06-B57A-5829C5696A5D@ianai.net>
Date: Thu, 13 Jun 2013 10:59:22 -0700
To: "Patrick W. Gilmore" <patrick@ianai.net>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
there are lots of other attack scenarios besides the simple one you =
suggest,
as people who try to analyze malware payloads by their outbound network =
activity
have figured out.
an attack could be time-driven, or driven by some very hard to interpret =
network=20
signalling (such as a response to something the router would have a =
perfectly legitimate
reason to ask an attacker about). which means you need to watch for an =
indefinite length of
time (possibly forever) to see behavior. (in the malware world, the =
question is: how long do you
run this in your sandbox to find the command and control?)
covert channels have been known for many years, and outbound data could =
be encoded in a covert
channel by timing (which is much more difficult to notice than content =
modification such as steganography as there
are no specs and few expectations about timing). see=20
http://www.crypto.com/papers/jbug-Usenix06-final.pdf
for an wonderful example of a keyboard specially modified to leak =
passwords by modulating the timing in an ssh channel
snooped between the admin and the router.
the volume of data need not be huge. a login and password, for example, =
can be leaked out in a covert channel without
the likelihood of anyone noticing, and would provide subsequent access =
to the router in case of need, which is good enough
for many military purposes.
finally, denial of service on a network component could be implemented =
by watching for a sequence of out of spec packets of death. =20
only someone doing impossibly exhaustive fuzzing might see the result, =
and it would be indistinguishable from a bug.
On Jun 13, 2013, at 9:35 AM, "Patrick W. Gilmore" <patrick@ianai.net> =
wrote:
> On Jun 13, 2013, at 12:28 , "Avi Freedman" <avi@freedman.net> wrote:
>=20
>> I disagree.
>>=20
>> There have already been lab demos of sfps that could inject frames =
and APTs are pretty advanced, sinister, and can be hard to detect now.
>>=20
>> I'm not suggesting Huawei is or isn't enabling badness globally but I =
think it would be technically feasible.
>=20
> I am assuming a not-Hauwei-only network.
>=20
> The idea that a router could send things through other routers without =
someone who is looking for it noticing is ludicrous.
>=20
> Of course, most people aren't paying attention, a few extra frames =
wouldn't be noticed most likely. But if you are worried about it, you =
should be looking.
>=20
> Also, I find it difficult to believe Hauwei has the ability to do DPI =
or something inside their box and still route at reasonable speeds is a =
bit silly. Perhaps they only duplicate packets based on source/dest IP =
address or something that is magically messaged from the mother ship, =
but I am dubious.
>=20
> It should be trivial to prove to yourself the box is, or is not, doing =
something evil if you actually try.
>=20
> --=20
> TTFN,
> patrick
>=20
>=20
>> ------Original Message------
>> From: Patrick W. Gilmore
>> To: NANOG list
>> Subject: Re: huawei
>> Sent: Jun 13, 2013 12:22 PM
>>=20
>> On Jun 13, 2013, at 12:18 , Nick Khamis <symack@gmail.com> wrote:
>>=20
>>> A local clec here in Canada just teamed up with this company to
>>> provide cell service to the north:
>>>=20
>>> =
http://cwta.ca/blog/2012/09/24/ice-wireless-iristel-and-huawei-partner-for=
-3g-wireless-network-in-northern-canada/
>>>=20
>>> Scary....
>>=20
>> Why?
>>=20
>> Do you think Huawei has a magic ability to transmit data without you =
noticing?
>>=20
>> If you don't want to use Hauwei because they stole code or did other =
nasty things, I'm right there with you. If you believe a router can =
somehow magically duplicate info and transport it back to China =
(ignoring CT/CU's inability to have congestion free links), I think you =
are confused.
>>=20
>> --=20
>> TTFN,
>> patrick
>>=20
>>=20
>>=20
>=20
>=20
