I just wanted to try and pick some experienced brains regarding my ZOOM 5751 X4 and a security issue (???), with it. ITEM: [http://www.zoomtel.com/products/5751.html]
On and off for the last couple of weeks I've been getting minor outages with it. I'm with IDNET, so I don't really tend to get any outages as such - but just recently there has been a little occasional downtime where things have died at their gateway. This has all been sorted out by their tech support chap, Brian, who was fantastic.
A few days ago my ADSL just stopped working at about 5.30pm - I couldn't even ping/traceroute past my little ZOOM, it just kept firing back ICMP 'Destination unreachables'. Initially I suspected a return of this switch issue at IDNET. The problem appeared to clear a little later and a status update came in from IDNET saying they had changed a switch at Telehouse. With things working fine, I blundered along until the following evening, when at about the same time it did it again. A look at the router stats was giving me indications that PPP had failed to authenticate. I checked the credentials and they were all fine and dandy so I was somewhat perplexed.
A quick call to IDNET and I was told there were no problems, so I started to look a little closer to home. For about half an hour it appeared to refuse to connect, each time complaining about PPP authentication. This then changed but I noted I was unable to ping the usual 184.108.40.206 google name server I use to test. I also could not ping other known to-be-up IP addresses. After a while this cleared too. In the back of my mind I was thinking 'This looks like an ISP type of outage' but I could not connect to anything online, despite being able to ping stuff. It was then that I had noticed a couple of weird things:
1: Name resolution had stopped working - but only UDP. If I performed dig +tcp @220.127.116.11 google.com I instantly got a bunch of IP's back.
2: Trying to connect to port 80 by IP address in a browser resulted in the web gui of the Zoom trying to load.
I quickly established that I could connect to stuff in the wild on any port other than 80 (443/https for example) without issue.
I took a closer look in the syslog of the ZOOM router, and the reason for this strangeness was scarily clear:
1st day 00:01:06 user debug syslog: iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j DNAT --to <own.ip.address>
1st day 00:01:06 user debug syslog: iptables -t nat -I PREROUTING -i br0 -p udp --dport 53 -j DNAT --to <own.ip.address>
1st day 00:01:06 user debug syslog: /bin/dnsspoof <own.ip.address> &
1st day 00:01:08 user debug syslog: ethctl vport query 2>/var/vcfgerr
1st day 00:01:08 user debug syslog: rm /var/vcfgerr
Something appeared to be creating IPTABLES rules to redirect udp port 53 and tcp port 80. More worryingly it seemed to then launch this: /bin/dnsspoof <own.ip.address> &
Telnetting into the zoom and deleting the rules allowed traffic to flow normally, but I suspect the device - which runs busybox v1.0, may have been compromised somehow.
One other train of thought came to me. Preceding the iptables rules was the line:
1st day 00:01:05 daemon err pppd: User name and password authentication failed
I wondered if the unit intercepted all traffic and names for set-up purposes so it would display the gui if a user typed in something like http://setupzoom - I know some Netgear routers do something similar. This theory was all but extinguished when I checked the manual and quickstart guide and it clearly instructs users to point their browser to its IP address. Ummm.
So either this thing had just developed a deliberate fault where it intercepts all udp DNS and port 80 TCP traffic, or it's been compromised.
Now I come to the 'how did they do that?' Remote access was off. TRO-69 was disabled. The default password for Admin (zoomadsl) was changed, long and complicated. I did discover that the unit has two additional accounts other than Admin and they have default passwords. user/user and support/support. These are enabled by default and like a twonk I'd missed them. I wonder how many other Zoom devices are out there with these open and waiting? That said, there was no remote access to it - only LAN access and nobody else was around or running. I can't rule out some kind of CSRF attack, but in mittigation I only opened and logged into the GUI of the Zoom after the connection had failed.
I've had a sniff around the zoom with it offline in a sandboxed environment, but it seems to have a very limited and stripped down Busybox on it. There is no ls command to make life bearable. I suspect that there is something that init brings in, possibly only after the PPP is up but finding your way around it when you can't list any files, or tab them out makes it nearly impossible.
Whilst I don't suspect I'll find out what was done - or how - I'd like to share my long, winding tale here in the hope that someone else may have had something similar and weird happen.
Also - if you own a Zoom device, check that you too don't have those extra 'support/support' and 'user/user' accounts. You can't disable them on my 5751 - you have to change the passwords and live with them being there.
I contacted Zoom's technical folk a while ago but I've not heard back which is sad because - I'd love to do some forensics on this thing with them. If anyone has any ideas how to get more info out of the unit with the command set shown below I'd love to hear from you!
-c busybox sh
BusyBox v1.00 (2010.03.12-04:37+0000) multi-call binary
Usage: busybox ....
BusyBox is a multi-call binary that combines many common Unix
utilities into a single executable. Most people will create a
link to busybox for each function they wish to use, and BusyBox
will act like whatever it was invoked as.
Currently defined functions:
busybox, cat, chmod, cp, date, df, dmesg, echo, expr, false,
ftpget, ifconfig, init, insmod, kill, killall, klogd, linuxrc,
ln, logger, logread, mkdir, mount, msh, ping, ping6, ps, pwd,
reboot, rm, rmmod, route, sendarp, sh, sleep, sysinfo, syslogd,
test, tftp, tftpd, top, true, tty, umount, vconfig
Thanks for reading, and apologies if anyone is now asleep.
Edited by sam_jones (Thu 17-Nov-11 13:55:30)