Malicious firmware found on SPA3102

[pipeline]

Just a heads up that I have found some malicious firmware on a SPA3102 which is sending out multicast packets and trying to connect to ports 1500 and ports 1501. 

The multicast packets will screw up some netgear switches according to the CVE they released.

The packets can be captured using wireshark and look like this:

192.168.0.1 224.0.0.252 LLMNR protocol mpfblwmrypiyr
Identification 0x0579 (hex)
Header checksum 0x1293 (validation disabled)
Source Port: 49817 (decimal)

192.168.0.1 224.0.0.252 LLMNR protocol javwbhucmkoxhea
Identification 0x057b
Header checksum 0x128f

192.168.0.1 224.0.0.252 LLMNR protocol yemxafqj
Identification:0x057a
Header Checksum 0x1297
Source Port: 53438

192.168.0.1 224.0.0.252 LLMNR protocol mpfblwmrypiyr
Identification: 0x057c
Header Checksum: 0x1290
Source Port: 57907

192.168.0.1 224.0.0.252 LLMNR protocol yemxafqj
Identification:0x057e
Header checksum 0x1293 
Source Port: 61557

192.168.0.1 224.0.0.252 LLMNR protocol javwbhucmkoxhea
Identification: 0x057d
Header checksum: 0x128d
Source Port: 54186

192.168.0.1 224.0.0.252 LLMNR protocol yemxafqj
Identification:0x0580
Header Checksum: 0x1291
Source Port: 61557

192.168.0.1 224.0.0.252 LLMNR protocol mpfblwmrypiyr
Identification:0x0581
Header Checksum: 0x128b
Source Port: 57907

192.168.0.1 224.0.0.252 LLMNR protocol javwbhucmkoxhea
Identification: 0x057f
Header Checksum:0x128b
Source Port: 54186

The fact it also tries to connect to port 1500 and 1501 which has been cited as a Trojan suggests the international phone system standard for sending telephone callers identification is being used to control the device, as this data sends name, number and other details using an old dial up modem protocol, namely v23. Its also possible the device also acts as a dial up modem with this malicious firmware considering the device is able to take the v23 protocol data which is just like old dial up modem data protocols and then send it over the network to syslog servers using syslog messages. 

It certainly explains why my netgate devices running pfsense and netgear switches were being hijacked and misconfigured, giving whoever carte blanche access into my systems.

Pity the British police are not interested and reports I have made with actionfraud.co.uk have disappeared when I have gone back to add more details to them. Perhaps that action is telling!

[pipeline]

Also forgot to add how else you can find out you might have malicious firmware on your SPA3102 device.

Firmware version 5.2.13 also comes with a program which enables the user to recover the firmware, despite being logged into the device's web gui as well as getting constant syslog messages from it, the device never recovers the firmware its throws the following error message:

Recovery Failed: cannot find the specified device!

The wireshark packet capture at the time the software attempts to recover the firmware is:

192.168.0.2 234.4.8.10  UDP 4811-4811 Len=160
I've taken the mac id's out for privacy reasons, but the hex for the rest of the packet is below start from the version 4.
                                                                      45 00
00 bc 05 9d 00 00 01 11  00 dc c0 a8 00 02 ea 04
08 0a 12 cb 12 ca 00 a8   b3 72 00 cc cc cc 52 45
43 4d 43 46 36 30 30 4d  43 31 33 38 34 36 00 00
00 00 00 00 00 00 cc cc   cc cc cc cc cc cc cc cc 
the remaining 8 lines are cc.

The identification and header checksum in the packet changes, but it appears to just broadcast the serial number of the device across the network before any communication can be initiated.

I'll be hooking into this program using APImonitor from Rohitab to find out what else this program does, but does anyone know if its worth taking the device to pieces and hook up a SOIC clip to one of the chips or other device to download the firmware manually in order to take the code to pieces? 

I wonder if the SPA8800 has any firmware recovery facility or will it be a firmware update only which could hide the existence of any malicious firmware from further scrutiny.

I'm going to hang back from flashing this device with new firmware for now, but its interesting that a device from one seemingly unconnected manufacturer is able to compromise the firmware of a completely different manufacturer.

TIA 

[Leo Laohoo]

I'd recommend you create a TAC Case and submit your findings that way.

[pipeline]

Does this cost money?

For the record, this is the advisory for the Netgear switch I have that was being hacked by the device.

https://kb.netgear.com/000038519/Security-Advisory-for-Authentication-Bypass-and-Remote-Command-Execution-on-Some-Smart-and-Managed-Switches-PSV-2017-0857

[pipeline]

Well this gets weirder by the minute. The latest wireshark captures have them coming from the pc, ie 192.168.0.2 but it only shows these when I am using Google Chrome, 51.0.2704.103m and I unplug the Ethernet cable from the device and plug it back in again. 

With wireshark just running, no other browser, plugging in the Ethernet cable to either the wan interface or the Ethernet interface doesn't show those packets.

Running Internet Explorer 8, doesn't show those packets, either left on the about:blank start page or logged into the SPA3102 web gui.

If I load Google Chrome, 51.0.2704.103m so it opens on its standard blank web page,

I see different multicast packets to one's posted above, namely coming from 192.168.0.2 (pc ip address) to the non routeable 224.0.0.252 address. Cant find any reason online why these packets would be coming sent out when the browser is loaded for the first time, only something else is expecting these packets.

Now the above was done with pc plugged into a tplink hub, and the SPA3102 plugged into the hub. If I unplug the cable from the SPA3102 swapping between the wan and lan port, I don't see those multicast packets any more, I just see them once.

If I plug the SPA3102 into the PC removing the hub, this is where it gets fun.

With IE loaded, I don't see those packets, but with Chrome loaded I see those multicast packets but different ones. Unplugging the cable and plugging it back I keep seeing the multicast packets, so it seems Google Chrome is monitoring the network connection and sending out a different batch of multi cast messages everytime the network cable is plugged into a port. I'll have to ask on the Google forum somewhere what these multicast packets are for, because I wonder if this is some sort of multicast network between other Google programs or devices, and then communicate with the mothership perhaps? I'll need to setup two pc's with chrome on and watch the communication to see what happens there. The thing with search engines & AI is they need to know lots about you to work well which is where website API's do their job at identifying people. There is a distinct pattern to these packets though, so cracking that might throw more insight at least.

This also doesn't necessarily mean anything, because well written malware could observe the browser being used most often through and link certain network activities to when the most commonly used web browser is used.

Still doesn't solve whats hijacking the network though, or why the firmware cant be recovered, and still trying to decrypt the debug and audio dump when no calls were being made by me is puzzling.