It appears that some of my subscribers DSL modems (which are acting as nat routers) have had their dns settings hijacked and presumably for serving ads or some such nonsense. The dns server addresses are statically programmed in and of the onces I have seen, they are not currently responsive, leading to slow page loads or 404 errors and hence tech support calls to my support desk. I have set up a resolver that will answer dns queries and have done some routing magic to re-direct queries sent from my customer CPE's to these hijacked dns addresses. This is working for the time being and affected clients don't know about the problem (yet).
I realise it's highly likely there are more than just the 2 addresses I have identified so far in the realm of dns hijackers, and so I am
I am wondering if anyone has a line on dns server addresses that have been used or are currently in use for dns redirecting malware. I would like to maybe script something so that addresses on such a list would automatically get dropped into a routing table pointing at my special dns resolver. In the future I would also likely set up some sort of web redirect so that any client that queries the special resolver would get a web page explaining they have been hijacked and how to handle it. For now however I just want to stem the tide and make sure clients continue to work and to catch as many of these as I can. Anyone ?
How do you think this was accomplished? Via some kind of Web exploit customized for those devices and targeting your user population via email or social media, which tricked users into clicking on something that accessed the Web admin interface via default admin credentials or somsesuch; or via some direct attack on the CPE devices themselves; or via some other method?
Basically two cases... (1) XSS attack on the router using default (or
dictionary) credentials to set the DNS server on the router, or (2) DHCP
hijacking daemon installed on the client, supplying the hijacker's DNS
servers on a DHCP renewal. Have seen both, the latter being more
common, and the latter will expand across the entire home subnet in time
(based on your lease interval)
I'd (perhaps wrongly) assumed that this probably wasn't the case, as the OP referred to the CPE devices themselves as being malconfigured; it would be helpful to know if the OP can supply more information, and whether or not he'd a chance to examine the affected CPE/end-customer setups.
Date: Tue, 12 Nov 2013 06:35:51 +0000
From: "Dobbins, Roland" <rdobbins@arbor.net>
To: NANOG list <nanog@nanog.org>
Subject: Re: CPE dns hijacking malware
> (2) DHCP hijacking daemon installed on the client, supplying the hijacker's DNS servers on a DHCP renewal. Have seen both, the latter being more
> common, and the latter will expand across the entire home subnet in time (based on your lease interval)
I'd (perhaps wrongly) assumed that this probably wasn't the case, as the OP referred to the CPE devices themselves as being malconfigured; it would be helpful to know if the OP can supply more information, and whether or not he'd a chance to examine the affected CPE/end-customer setups.
I have encountered a family members provider supplied CPE that had the
web server exposed on the public interface with default credentials still
in place. It's probably more common than one would expect.
EXTREMELY common. Almost all Comcast Cable CPE has this same login,
cusadmin / highspeed
At least on AT&T U-Verse gear, there's a sticker on the modem with the
password which is a hash of the serial number or something equally unique.
Almost all home routers also tend to have the default credentials.
I'm actually surprised it was this long before XSS exploits and similar
garbage started hitting them.
Personally I have fond memories of going into my neighbor's router,
flashing it with dd-wrt which allowed manual channel setting, and moving it
off of the same wifi channel mine was on.... That was probably not a great
idea, but you do what you have to sometimes.
"Personally I have fond memories of going into my neighbor's router, flashing it with dd-wrt which allowed manual channel setting, and moving it off of the same wifi channel mine was on.... That was probably not a great idea, but you do what you have to sometimes."
Props on that, but wouldn't it have been easier to simply change your channel setting?
-James
The on-line chat to Linksys was subsatisfying, but for want of something to do I dropped the "s" IN "https" and go on the router just fine. Makes you wonder if I understand "certificates".
But I do not see anything that looks like I can affect DNS beyond which servers I use.
As I recall, the unit in question had a severely flawed "auto" channel
selection algorithm that always, without fail, landed on the first OCCUPIED
channel. It was pretty terrible.
Someone has to move. The defaults are really bad in dense deployments of 1,6,11. Always fun when we went to Japan in the early days and our equipment could not see channel 13
