ripdog:

 

 <sigh>

 

I have already answered your question. Standard HTTPS download of a signed firmware update which allows the client to verify the signature of the update and reject any not provided by someone in possession of the private key. This is standard practice in EVERY OTHER MAJOR DEVICE UPDATE SYSTEM. You talk about Windows update? iOS updates? Android updates? They ALL verify signatures. But apparently routers don't have to? No, they just give the vendor unlimited read/write access to all data contained on the device. Great!

 

DNS, Windows Update, Apple Update, Facebook, Akamai CDNs, Accessing any web site, Ad Networks. These services allow direct access to your computer let alone a delivery method for malware. That's why you patch windows. That's why you patch routers. Using ACS.

 

You really don't see the difference between a client downloading untrusted content and parsing it in a (hopefully) secure manner/signed, trusted content, and giving the vendor unlimited, read/write access to the device?

 

Oh, and standards can and must be updated as security research and standards advance.

 

You seem to be thinking that routers accept any firmware that isn't signed by the hardware vendor. Incorrect, every router manufacturer I have worked with will verify the firmware before it loads it.

You seem to think that redirecting the ACS URL to a rogue URL is easy. That would require pwning the DNS. If that happens you have more serious problems on your hands.

You seem to think that the ACS server isn't monitored and compromising it is simple. This is a telco grade service run by a telco. To imply that it's running on a un-monitored server available to be hacked by any script kiddy is just utter nonsense.

Please, I really recommend you do some research on how Web/App/Database tier applications work and how is a safe and secure way to expose web services to the internet. There is no difference on how you deploy the ACS vs any other web service securely.

The Broadband Forum welcomes your input to making the standard better. Have you read TR-069, TR-098, TR-101, TR-104. I have and know them well and know what you're talking about is nonsense.

ripdog:

 

ubergeeknz:

 

ripdog:

 

 <sigh>

 

I have already answered your question. Standard HTTPS download of a signed firmware update which allows the client to verify the signature of the update and reject any not provided by someone in possession of the private key. This is standard practice in EVERY OTHER MAJOR DEVICE UPDATE SYSTEM. You talk about Windows update? iOS updates? Android updates? They ALL verify signatures. But apparently routers don't have to? No, they just give the vendor unlimited read/write access to all data contained on the device. Great!

 

 

In actual fact, most device firmware is signed by the vendor, and the router will not accept firmware with an invalid signature.  Why do you assert otherwise?

 

 

Because that's my experience. Googling around, TP-Link devices only started enforcing signature verification due to FCC requirements in 2016. I know my Asus router takes unsigned firmware, because I flashed unsigned firmware on it. Some are better, for instance the old Apple routers enforced signing (say what you want about Apple, but they typically do a better than average job around security).

 

Obviously I can't know for sure about all routers, and some manufacturers are better than others. But even if they do enforce signatures, that doesn't make it okay to offer unnecessary full read/write access to the ISP.

 

So glad you are admitting firstly you are using Google as your source of information and referring to end-customer purchased routers vs routers that ISPs issue.

And again you seem to think that getting full read/write access to the router other than going to the ACS is a "simple" thing to do. It's not. There are only two attack vectors that are possible IMHO and I have done this a fair bit is:

A) Compromise DNS to point the router to a rogue ACS. As I said above if that happens there are larger issues than the ACS.

B) Compromise of the ACS server itself. Sanitizing of the inbound XML then proper security testing and ongoing monitoring of the service provides a telco grade level of control over the ACS Server. I won't say that nothing is impossible but all practicable steps are taken to secure the ACS end point. That's how everyone else does it when they expose web services to the internet and the ACS is no different. For a nation actor to compromise the ACS without being noticed by the ISP would require a non-trivial amount of effort. There would have to be a high value target and Spear-phishing via a drive by URL infecting or a malicious email would have a far higher likelihood of working than compromising the ACS.

The Broadband Forum welcomes your feedback, and I would love an answer to my standard Telco Remote Management requirements above.

Yeah indeed. I'm calling this before I get grumpy.

Let me know if a real backdoor or vulnerability arrives with evidence and a CVE for TR-069 and I'll unlock this thread.

CVE-2014-9222 DOES NOT COUNT.