Intentional Backdoor In Consumer Routers Found

New submitter janoc (699997) writes about a backdoor that was fixed (only not). "Eloi Vanderbeken from Synacktiv has identified an intentional backdoor in a module by Sercomm used by major router manufacturers (Cisco, Linksys, Netgear, etc.). The backdoor was ostensibly fixed — by obfuscating it and making it harder to access. The original report (PDF). And yeah, there is an exploit available ..." Rather than actually closing the backdoor, they just altered it so that the service was not enabled until you knocked the portal with a specially crafted Ethernet packet. Quoting Ars Technica: "The nature of the change, which leverages the same code as was used in the old firmware to provide administrative access over the concealed port, suggests that the backdoor is an intentional feature of the firmware ... Because of the format of the packets—raw Ethernet packets, not Internet Protocol packets—they would need to be sent from within the local wireless LAN, or from the Internet service provider’s equipment. But they could be sent out from an ISP as a broadcast, essentially re-opening the backdoor on any customer’s router that had been patched."

Meanwhile, in the Media...

[bengoerz]

...US tech firms blame Snowden for failing confidence in the safety of using US tech companies: The 'Snowden Effect' Is Crushing US Tech Firms In China [businessinsider.com]

Pot, meet Kettle.

Re:You say tomato?

[networkzombie]

That is all fine and I did purchase my Asus router (third one, among others) with Tomato or DD-WRT in mind, but free DDNS providers drop like flies and Asus' DDNS is free and reliable as long as I am using their firmware. My last DD-WRT lasted many years, but a worry-free DDNS is nice also.

Simple fix

[Anaerin]

Wouldn't it be a simple "Fix" to set up port forwarding to redirect traffic directed to port 32768 to a "dead" address. Then the port would already be allocated, and when the "Knock" arrives, the port is already in use, and data goes nowhere.

Nice. Caught red-handed...

[gweihir]

I predict we will see more of that. Congratulations to the finder! Maybe we should start to offer "public safety" bounties to people that find these acts of sabotage.

Re:Hardware backdoors in the actual CPUs ?

[gweihir]

You are either ignorant or a liar. (Maybe a paid-for liar?). Just read this: https://plus.google.com/+Theod... [google.com]

That is a few more people than "nobody". The flaw is that the whole design does not allow verification that it is non-compromised. The claim that including its bits in JTAG would be a security risk is completely bogus, as an attacker with access to the JTAG pins can do whatever they like already. With those bits in JTAG, it would be relatively easy to verify the analog-side is actually analog and is actually what feeds the whitener. That possibility was intentionally sabotaged, and the _only_ good reason for that is that they want to be able to compromise the CPRNG in select batches and make detection of that very hard. And no, there is no software access to those JTAG pins and yes, the hardware to query the internal CPRNG state and analog bit stream must be in place to test the CPU. That means they are switching this access explicitly off after they have verified the hardware works. So not only is this a compromised architecture and design, it is also more effort than doing it right. IT does not get more obvious than this.

Your link, BTW, is worthless. It does not go into the needed level of detail. The contrast with what you get for the VIA C3 generator (e.g.), is quite telling: http://www.cryptography.com/pu... [cryptography.com]. And VIA has a non-compromised design as they do not desperately try to hide what the analog random source spits out.