Re: Comcast storing WiFi passwords in cleartext?

["K. Scott Helms" <kscott.helms () gmail com>]

James,

By the DOCSIS standard and every North American MSO's ToS I've seen (I've
worked with or for about 200 different cable operators over the last 20
years) your cable modem is always managed and the cable operator _always_
has access to its configuration and settings via SNMP.  The configuration
file for a DOCSIS cable modem is nothing more than a list of SNMP OIDs with
their values set the way the operator wants them.  This has been true since
DOCSIS 1.0 (which doesn't make it correct, just common).  Now, DOCSIS is
primarily deployed with SNMP version 2c though more and more operators,
especially the larger ones, are moving or have to SNMPv3.  I mention this
because every cable modem on a given CMTS that's deployed in SNMPv2c mode
will (should for proper functioning) have the same SNMP READ and WRITE
strings.  SNMPv2c traffic is clear text UDP with no standardized methods of
encryption available to the industry.  To mitigate this to an extent part
of the cable modem's configuration will (best practice anyway) have
filtering rules to only accept SNMP traffic from a given IP address or
subnet and traffic between the CMTS and the modem should be encrypted via
BPI+ for some minimal security.  (A minor note, the router interface for a
combo unit by CableLabs OSS standards will not respond to SNMP traffic on
its public address by default and almost all of the SNMP traffic will be to
the modem's RFC1918 address.)  What I'm getting at is that the for DOCSIS
(and FTTH and most DSL flavors as well) the service provider has and has
had access to all the settings for a very long time.  What's changed is
that customers wanted to WiFi to be provided by the operator and
importantly supported by the operator.

" I have yet to hear any discussion of the business value of access to WiFi
network password, especially as compared to billing and identity data.
Also, remote management of local networks by definition requires
credentials stored off site from the customer. To the typical customer,
loss of connectivity is much worse than a small chance of sharing the WiFi."

Let me provide something in this regard.  The most common support call
category, by a large number, is the WiFi category.  In excess of 55% of all
support calls (regardless of how the customer describes them) end up being
WiFi issues.  The most common specific call in that category is some
variation of, "I've forgotten my WiFi password and I need to get my new
iPad online."  As a service provider your choices are to say I can reset
your WiFi PSK, which allows the new device to come online but breaks
everything else that was connected, or to allow the support rep and/or
customer to recover the passphrase.  In short, the ability to recover the
passphrase is strongly preferred by end users over resetting it and frankly
is much less expensive for the operator.

I've helped supply this functionality to a large number of operators and in
general the implementations _should_ at a minimum be able to capture the
agent who recovered the passphrase, the time/date, who the agent was on the
phone with, whether the agent correctly verified the identity of the
caller, and if the agent followed all other procedures laid by the service
provider.

Scott Helms



On Thu, Apr 25, 2019 at 8:38 AM James R Cutler <james.cutler () consultant com>
wrote:

> On Apr 25, 2019, at 8:26 AM, K. Scott Helms <kscott.helms () gmail com>
> wrote:
>
> People are missing the point here.  This is _not_ a Comcast "issue" this
> same data is available to every single cable operator in the US who deploys
> bundled modem/router/APs that follow the CableLabs standard.  They may or
> may not expose the data to their end customers, but it's stored in their
> systems and is often available to their support teams.
>
> http://mibs.cablelabs.com/MIBs/wireless/CLAB-WIFI-MIB-2017-09-07.txt
>
> The same thing applies to most FTTH and xDSL deployments.  They use TR-069
> to collect the data instead of SNMP but the object model is the same.  The
> WiFi MIB above is explicitly built to mimic TR-181 functionality.
>
> Scott Helms
>
>
>
> On Wed, Apr 24, 2019 at 5:48 PM Rich Kulawiec <rsk () gsp org> wrote:
>
> > On Wed, Apr 24, 2019 at 03:13:33PM +0000, Benjamin Sisco wrote:
> > > The bigger concern should be the cleartext portion of the subject.
> >
> > Yes, and the availability of all this to anyone who hacks Comcast
> > customer support.
> >
> > —rsk
>
>
> I have yet to hear any discussion of the business value of access to WiFi
> network password, especially as compared to billing and identity data.
> Also, remote management of local networks by definition requires
> credentials stored off site from the customer. To the typical customer,
> loss of connectivity is much worse than a small chance of sharing the WiFi.
>
> Narrowing the discussion back to Comcast, credentials for “guest” WiFi
> seem to be more used than purloined SNMP MIB data.