Comcast storing WiFi passwords in cleartext?

Thu Apr 25 17:53:05 UTC 2019

Doug,

I don't disagree, but things are pretty complicated, much more so than they
might seem from the outside.  First, if the configuration isn't stored
there's literally no way to have a backup for most of the CPE vendors so
there's definitely reason to have it duplicated in the service providers'
systems.  Very few allow for end users to download their router
configuration via the admin page and I know of none that encrypt that
configuration before it is delivered to the end user's computer.  (It's
also relevant that the usage for those vendors that do allow end users to
backup the config is vanishingly low.)  If we're looking at a TR-069 based
system for managing the WiFi and router components it's not really feasible
to do a real time grab of that data since that process can take up to ~5
minutes depending on your periodic inform settings in your ACS.  That's
because TR-069 is inherently a push technology (from the CPE to the ACS)
rather than a pull like SNMP.

The next piece is that a DOCSIS configuration file itself, which in some
cases contains these parameters, is by the standard required to be
delivered via insecure protocols, namely TFTP.  Newer devices have options
to allow for TLS secured HTTP, but that's very rare today in production
provisioning systems, and in case the secured protocols are all still
optional in the spec.  In general the config file itself is stored in it's
text format on the provisioning systems or if the file is dynamically
generated the user specific parameters are held in a database with the
general ones coming from a template for that class of service.

Again, I'm not disagreeing with your premise but the service providers
directly control a small piece of the overall process and we're still
working with standards from earlier times.  Most cable operators have
gotten rid of their DOCSIS 2.0 (1.0 and 1.1 as well) but it's not uncommon
to find a handful of users with (mostly customer owned) D2 devices that the
provisioning and OSS systems still have to deal with.  DOCSIS 3.0 devices
are the majority and 3.1 devices are just now being rolled out in large
numbers.

In short, not everything is quickly retrievable, much of the configuration
is in fact generated by the service provider and must be maintained because
the modem needs to download its configuration every time it reboots, and
the vendors and associations in the provisioning and OSS space have more
input than the operators themselves.

Scott Helms

On Thu, Apr 25, 2019 at 1:16 PM Doug Barton <dougb at dougbarton.us> wrote:

> On 4/25/19 8:04 AM, K. Scott Helms wrote:
> > Just so you know, if you have an embedded router from a service provider
> > all of that data is _already_ being transmitted and has been for a long
> > long time.
>
> Responding to a pseudo-random message ...
>
> If you are an average consumer and purchase a managed solution (in this
> case a WAP that comes as part of your package) I think it's perfectly
> reasonable for the vendor to manage it accordingly, even if said
> consumer doesn't fully understand the implications of that decision.
>
> In my mind, the problem here is not that the vendor has access to this
> data, it's that they are STORING it in the first place, and storing it
> in the clear to boot. In the hypothetical service call that we've
> speculated is the driver for this, the extra 15 or 20 seconds that it
> would take to pull the data via SNMP is in the noise.
>
> There are two mindsets that desperately need changing in the tech world:
>
> 1. Do not store data that you don't have a legitimate requirement to store
> 2. Do not store anything even remotely sensitive in the clear
>
> We live in a world of all breaches, all of the time. So we need to start
> thinking not in terms of just protecting said data from the outside, but
> rather in terms of limiting the attack surface to start with, and
> protecting the data at rest. So that WHEN there is a breach, whether
> from within or without, the damage will be minimal.
>
> As many have pointed out, this information is freely available via SNMP,
> so it's a classic example of something that didn't need to be stored in
> the first place.
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190425/8c8fadd4/attachment.html>