Calix GigaSpire router and unexpected TR-069 listening port

Last Modified: Mon, 16 Sep 2024 04:19:31 +0000 ; Created: Sat, 14 Sep 2024 03:59:21 +0000

An ISP controlled Calix GigaSpire BLAST Model: u6.1 GS4220E router (firmware version 23.3.0.3.57). Running an Nmap scan I found a single open high-number port with an HTTP web server (no TLS) listening. 
curl --include http://the-ip-here:60002/
  
HTTP/1.1 404 Not Found
Server: gSoap 2.8.30 / Dimark client v.4.8 [9347]
Content—Length: 0
Connection: close

Doing some digging into the headers I found this was a TR-069 service. I tried sending a few TR payloads to it via curl but nothing changed the 404.

A search on Shodan.io did turn up a number of other devices on the public Internet with this device present.

I did get an interesting result from downloading https://github.com/bitfu/sricam-gsoap2.8-dos-exploit/blob/master/Sricam_gSOAP_PoC_exploit.sh for CVE-2019-6973. 

bash Sricam_gSOAP_PoC_exploit.sh the-ip-here 60002 10000

After running the service on port 60002 was still open but no longer responded. Another Nmap scan from inside the LAN (i.e. behind the router) indicated the port was open, but there were also other ports open on the device. 

nmap the-ip-here -p 60000-60100
Starting Nmap 7.80 ( https://nmap.org ) at 2024-09-13 22:50 CDT
Nmap scan report for the-ip-here (the-ip-here)
Host is up (0.88s latency).
rDNS record for the-ip-here: the-ip-here.block0.example.com
Not shown: 98 closed ports
PORT      STATE SERVICE
60002/tcp open  unknown
60004/tcp open  unknown
60016/tcp open  unknown

Connecting to one of the other ports (from the LAN, Internet was blocked) returned an HTTP server response as below. The response corralated with a TR-069 CPE starting a session to the remote ACS. 

curl -i http://the-ip-here:60004/
HTTP/1.1 503 Service Unavailable
Server: gSoap 2.8.30 / Dimark client v.4.8 [9347]
Content-Length: 0
Connection: close

curl -i http://the-ip-here:60016
HTTP/1.1 503 Service Unavailable
Server: gSoap 2.8.30 / Dimark client v.4.8 [9347]
Content-Length: 0
Connection: close

At no time did the Internet service incur an interruption.

Performing a TCP Nmap scan from the LAN showed some interesting services: 

Not shown: 65522 closed ports
PORT      STATE    SERVICE
53/tcp    open     domain
80/tcp    open     http
111/tcp   open     rpcbind
443/tcp   open     https
2049/tcp  open     nfs
5201/tcp  open     targus-getdata1
30007/tcp filtered unknown
32777/tcp open     sometimes-rpc17
32778/tcp open     sometimes-rpc19
32780/tcp open     sometimes-rpc23
60002/tcp open     unknown
60004/tcp open     unknown
60016/tcp open     unknown

Nmap done: 1 IP address (1 host up) scanned in 12410.41 seconds
  • 5201 was an actual iperf3 server that LAN clients could connect to for speed testing
    • Interesting was that .\iperf3.exe --client 192.168.0.1 -t 3 --udp -b 0 --reverse
    • The router can only send UDP at a rate of ~385 Mbits/sec (upload to router was at gigabit speed)
    • TCP iperf3 traffic was gigabit in both directions
    • Guess would be some firewall or NAT table speed limitation
  • 32777/tcp open nlockmgr 1-4 (RPC #100021)
  • 32778/tcp open status 1 (RPC #100024)
  • 32780/tcp open mountd 1-3 (RPC #100005)

The NFS share results 

sudo showmount -e 192.168.0.1
Export list for 192.168.0.1:
/ponsfp_usr  169.254.1.1
/tmp/log/pon 169.254.1.1

An Nmap scan from the LAN side (nmap -sn -oA privnet-scan --stats-every 10 169.254.0.0/16) turned up 169.254.2.1 which was another IP address for the router itself.

Attempting to mount the NFS shares 

sudo mount 169.254.2.1:/ponsfp_usr /mnt/
mount.nfs: access denied by server while mounting 169.254.2.1:/ponsfp_usr'

sudo mount 169.254.2.1:/tmp/log/pon /mnt/
mount.nfs: access denied by server while mounting 169.254.2.1:/tmp/log/pon

sudo ip address add 169.254.1.1/16 dev eth0

sudo mount 169.254.2.1:/tmp/log/pon /mnt/

sudo mount 169.254.2.1:/ponsfp_usr /mnt2/

The mounts never completed successfully but no access denied error was observed.

This Reddit thread talked about support user credentials with 12345!5upporT, but I could not get it to work with a provisioned device.

Setting up a bridge and tcpdump of the router WAN port to the ONT uplink revealed a few interesting traffic patterns: 

Traffic from an AWS EC2 instance IP range (34.210.116.13) to the router on port 60002.

Hypertext Transfer Protocol
    GET /3xFyb0AI HTTP/1.1\r\n
    User-Agent: Calix Consumer Connect\r\n
    Host: IP-ADDR-OF-ROUTER-WAS-HERE:60002\r\n
    Accept: */*\r\n
    \r\n

The response from the router back:
    HTTP/1.1 401 Unauthorized\r\n
    WWW-Authenticate: Digest realm="Dimark", qop="auth", nonce="7065d4b300001f2f66e7abbb"\r\n
    Server: gSoap 2.8.30 / Dimark client v.4.8 [9347]\r\n
    Content-Type: text/xml; charset=utf-8\r\n
    Content-Length: 0\r\n
    Connection: keep-alive\r\n
    \r\n

The remote EC2 instance sent a follow-up request:
    GET /3xFyb0AI HTTP/1.1\r\n
    Authorization: Digest username="admin", realm="Dimark", nonce="7065d4b300001f2f66e7abbb", uri="/3xFyb0AI", response="REDACTED", qop=auth, nc=00000001, cnonce="55d856d1432701ff", algorithm=MD5\r\n
    User-Agent: Calix Consumer Connect\r\n
    Host: IP-ADDR-OF-ROUTER-WAS-HERE:60002\r\n
    Accept: */*\r\n
    \r\n

The response:
    HTTP/1.1 200 OK\r\n
    Server: gSoap 2.8.30 / Dimark client v.4.8 [9347]\r\n
    Content-Length: 0\r\n
    Connection: close\r\n
    \r\n

No further traffic on that clear-text port was observed. This likely only triggers the router to then reach out to the ACS for a config update.