Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica
http://arstechnica.com/security/2014/03/hackers-hijack-300000-plus-wireless-... Is there any valid reason not to black hole those /32s on the back bone? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth <jra@baylink.com> wrote:
http://arstechnica.com/security/2014/03/hackers-hijack-300000-plus-wireless-...
Is there any valid reason not to black hole those /32s on the back bone?
The telltale sign a router has been compromised is DNS settings that have been changed to 5.45.75.11 and 5.45.76.36. Team Cymru researchers contacted the provider that hosts those two IP addresses but have yet to receive a response.
you wanted to say "blackhole those 5.45.72.0/22 and 5.45.76.0/22", aren't you? Cheers
On Tue, Mar 4, 2014 at 5:46 AM, fmm <vovan@fakmoymozg.ru> wrote:
On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth <jra@baylink.com> wrote:
http://arstechnica.com/security/2014/03/hackers-hijack-300000-plus-wireless-...
Is there any valid reason not to black hole those /32s on the back bone?
The telltale sign a router has been compromised is DNS settings that have been changed to 5.45.75.11 and 5.45.76.36. Team Cymru researchers contacted the provider that hosts those two IP addresses but have yet to receive a response.
you wanted to say "blackhole those 5.45.72.0/22 and 5.45.76.0/22", aren't you?
Cheers
Jay is right, it is just the /32s at the moment... Dropping the /22s could cause other sites to be blocked. inetnum: 5.45.72.0 - 5.45.75.255 netname: INFERNO-NL-DE descr: ******************************************************** descr: * We provide virtual and dedicated servers on this Subnet. descr: * descr: * Those services are self managed by our customers descr: * therefore, we are not using this IP space ourselves descr: * and it could be assigned to various end customers. descr: * descr: * In case of issues related with SPAM, Fraud, descr: * Phishing, DDoS, portscans or others, descr: * feel free to contact us with relevant info descr: * and we will shut down this server: abuse@3nt.com descr: ******************************************************** country: NL admin-c: TNTS-RIPE tech-c: TNTS-RIPE status: ASSIGNED PA mnt-by: MNT-3NT mnt-routes: serverius-mnt source: RIPE # Filtered -- ~ Andrew "lathama" Latham lathama@gmail.com http://lathama.net ~
Andrew Latham wrote:
On Tue, Mar 4, 2014 at 5:46 AM, fmm <vovan@fakmoymozg.ru> wrote:
On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth <jra@baylink.com> wrote:
http://arstechnica.com/security/2014/03/hackers-hijack-300000-plus-wireless-...
Is there any valid reason not to black hole those /32s on the back bone?
The telltale sign a router has been compromised is DNS settings that have been changed to 5.45.75.11 and 5.45.76.36. Team Cymru researchers contacted the provider that hosts those two IP addresses but have yet to receive a response.
you wanted to say "blackhole those 5.45.72.0/22 and 5.45.76.0/22", aren't you?
Jay is right, it is just the /32s at the moment... Dropping the /22s could cause other sites to be blocked.
inetnum: 5.45.72.0 - 5.45.75.255 netname: INFERNO-NL-DE
I'm guessing that was said under the assumption the provider wouldn't intervene, because if it does intervene there is no point in blackholig anything.
On Tue, Mar 4, 2014 at 7:27 AM, Davide Davini <diotonante@gmail.com> wrote:
Andrew Latham wrote:
On Tue, Mar 4, 2014 at 5:46 AM, fmm <vovan@fakmoymozg.ru> wrote:
On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth <jra@baylink.com> wrote:
http://arstechnica.com/security/2014/03/hackers-hijack-300000-plus-wireless-...
Is there any valid reason not to black hole those /32s on the back bone?
The telltale sign a router has been compromised is DNS settings that have been changed to 5.45.75.11 and 5.45.76.36. Team Cymru researchers contacted the provider that hosts those two IP addresses but have yet to receive a response.
you wanted to say "blackhole those 5.45.72.0/22 and 5.45.76.0/22", aren't you?
Jay is right, it is just the /32s at the moment... Dropping the /22s could cause other sites to be blocked.
inetnum: 5.45.72.0 - 5.45.75.255 netname: INFERNO-NL-DE
I'm guessing that was said under the assumption the provider wouldn't intervene, because if it does intervene there is no point in blackholig anything.
Davide, you are correct, some people are assuming that the provider is doing nothing. That has yet to be determined. -- ~ Andrew "lathama" Latham lathama@gmail.com http://lathama.net ~
Why want to swing such a big hammer. Even blocking those 2 IP's will isolate your users, and fill your support queue's. Set up a DNS server locally to reply to those IP's Your customers stay up and running and blissfully unaware. Log the IP's hitting your DNS servers on those IP and have your support reach out to them in a controlled way, or reply to any request via DNS with an internal host that has a web page explaining what is broken and how they can fix it avoiding at least some of the calls to your helpdesk. -jim On Tue, Mar 4, 2014 at 7:54 AM, Andrew Latham <lathama@gmail.com> wrote:
On Tue, Mar 4, 2014 at 5:46 AM, fmm <vovan@fakmoymozg.ru> wrote:
On Tue, 04 Mar 2014 09:00:18 +0100, Jay Ashworth <jra@baylink.com> wrote:
http://arstechnica.com/security/2014/03/hackers-hijack-300000-plus-wireless-...
Is there any valid reason not to black hole those /32s on the back bone?
The telltale sign a router has been compromised is DNS settings that have been changed to 5.45.75.11 and 5.45.76.36. Team Cymru researchers contacted the provider that hosts those two IP addresses but have yet to receive a response.
you wanted to say "blackhole those 5.45.72.0/22 and 5.45.76.0/22", aren't you?
Cheers
Jay is right, it is just the /32s at the moment... Dropping the /22s could cause other sites to be blocked.
inetnum: 5.45.72.0 - 5.45.75.255 netname: INFERNO-NL-DE descr: ******************************************************** descr: * We provide virtual and dedicated servers on this Subnet. descr: * descr: * Those services are self managed by our customers descr: * therefore, we are not using this IP space ourselves descr: * and it could be assigned to various end customers. descr: * descr: * In case of issues related with SPAM, Fraud, descr: * Phishing, DDoS, portscans or others, descr: * feel free to contact us with relevant info descr: * and we will shut down this server: abuse@3nt.com descr: ******************************************************** country: NL admin-c: TNTS-RIPE tech-c: TNTS-RIPE status: ASSIGNED PA mnt-by: MNT-3NT mnt-routes: serverius-mnt source: RIPE # Filtered
-- ~ Andrew "lathama" Latham lathama@gmail.com http://lathama.net ~
On Tue, 04 Mar 2014 09:28:01 -0400, jim deleskie said:
Why want to swing such a big hammer. Even blocking those 2 IP's will isolate your users, and fill your support queue's.
Set up a DNS server locally to reply to those IP's Your customers stay up and running and blissfully unaware.
Log the IP's hitting your DNS servers on those IP and have your support reach out to them in a controlled way, or reply to any request via DNS with an internal host that has a web page explaining what is broken and how they can fix it avoiding at least some of the calls to your helpdesk.
Two words: "DNS Changer". What did we learn from that?
On Mar 4, 2014, at 6:54 AM, Valdis.Kletnieks@vt.edu wrote:
On Tue, 04 Mar 2014 09:28:01 -0400, jim deleskie said:
Why want to swing such a big hammer. Even blocking those 2 IP's will isolate your users, and fill your support queue's.
Set up a DNS server locally to reply to those IP's Your customers stay up and running and blissfully unaware.
Log the IP's hitting your DNS servers on those IP and have your support reach out to them in a controlled way, or reply to any request via DNS with an internal host that has a web page explaining what is broken and how they can fix it avoiding at least some of the calls to your helpdesk.
Two words: "DNS Changer". What did we learn from that?
My thoughts exactly. Some walled gardens set up in those instances. And don't blindly follow someone's advice without looking at impacts to your networks. CPE devices are just a huge cesspool. Any device that already doesn't let you change username 'admin' is off to a bad start. We have to get these supposedly 'plug it in and never touch it' devices to be better at firmware upgrades. - merike
I don¹t know that they have a lot of motivation to support ³legacy² access points. The home brew guys tend to magically ³find² ways to install software on these POS CPE AP/Router combos, which I don¹t think is a coincidence. The linksys types of the world want to sell more routers, not make routers that suddenly have an amazing 8 year shelf life. Most people get tired of that POS box that gives them internet not working, and buy a new LESS POS with whatever 802.xxx of the week/month/year/shopping season. The margins probably really suck if you support a piece of plastic longer than __ months, so I doubt you¹ll see anyone supporting their cheap box any time soon. I bet if you offered them a way to do it for free, they¹d look at it ;) On 3/4/14, 11:52 AM, "Merike Kaeo" <kaeo@merike.com> wrote:
On Mar 4, 2014, at 6:54 AM, Valdis.Kletnieks@vt.edu wrote:
On Tue, 04 Mar 2014 09:28:01 -0400, jim deleskie said:
Why want to swing such a big hammer. Even blocking those 2 IP's will isolate your users, and fill your support queue's.
Set up a DNS server locally to reply to those IP's Your customers stay up and running and blissfully unaware.
Log the IP's hitting your DNS servers on those IP and have your support reach out to them in a controlled way, or reply to any request via DNS with an internal host that has a web page explaining what is broken and how they can fix it avoiding at least some of the calls to your helpdesk.
Two words: "DNS Changer". What did we learn from that?
My thoughts exactly. Some walled gardens set up in those instances.
And don't blindly follow someone's advice without looking at impacts to your networks.
CPE devices are just a huge cesspool. Any device that already doesn't let you change username 'admin' is off to a bad start. We have to get these supposedly 'plug it in and never touch it' devices to be better at firmware upgrades.
- merike
On 3/4/14, 11:52 AM, "Merike Kaeo" <kaeo@merike.com> wrote:
CPE devices are just a huge cesspool. Any device that already doesn't let you change username 'admin' is off to a bad start. We have to get these supposedly 'plug it in and never touch it' devices to be better at firmware upgrades.
* wbailey@satelliteintelligencegroup.com (Warren Bailey) [Tue 04 Mar 2014, 21:00 CET]:
I don't know that they have a lot of motivation to support "legacy" access points. The home brew guys tend to magically "find" ways to install software on these POS CPE AP/Router combos, which I don't think is a coincidence. The linksys types of the world want to sell more routers, not make routers that suddenly have an amazing 8 year shelf life. Most people get tired of that POS box that gives them internet not working, and buy a new LESS POS with whatever 802.xxx of the week/month/year/shopping season. The margins probably really suck if you support a piece of plastic longer than __ months, so I doubt you¹ll see anyone supporting their cheap box any time soon. I bet if you offered them a way to do it for free, they'd look at it ;)
Cisco tried doing this while they still owned Linksys and got huge blowback from the community, who felt that they'd lost control over their own devices and the data passing through them. https://www.techdirt.com/articles/20120629/15451719541/you-dont-own-what-you... http://arstechnica.com/civis/viewtopic.php?f=2&t=1177772 (whole thread) http://blogs.cisco.com/home/update-answering-our-customers-questions-about-c... (I fixed your quotes, by the way. You may want to engage with your postmaster to unfuck your mail client's character set.) -- Niels.
----- Original Message -----
From: "jim deleskie" <deleskie@gmail.com>
Why swing such a big hammer. Even blocking those 2 IP's will isolate your users, and fill your support queue's.
Set up a DNS server locally to reply to those IP's Your customers stay up and running and blissfully unaware.
Log the IP's hitting your DNS servers on those IP and have your support reach out to them in a controlled way, or reply to any request via DNS with an internal host that has a web page explaining what is broken and how they can fix it avoiding at least some of the calls to your helpdesk.
Jim's right, of course. In my defense, it *was* 9 am, and I hadn't had any caffeine yet. ;-} Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On 03/04/2014 05:28 AM, jim deleskie wrote:
Why want to swing such a big hammer. Even blocking those 2 IP's will isolate your users, and fill your support queue's.
When the malicious DNS services get shutdown you will still have your support queue's filled, anyway. Doing it now will let you identify those affected. Blockage doesn't have to be all-or-nothing. It can be incremental, selective or all-or-nothing on some time windows. Better now than later.
Until the average user's cpe is only permitted to use the resolvers one has provided as the provider (or otherwise decided are OK), this is going to be a game of whackamole. So long as there's an 'I have a clue' opt out, it appears to be the way forward to resolve this issue. Shutting down one set of 'bad resolvers' will simply cause a new set to be spawned, and a reinfection run round the still-unpatched cpe's of the world. Thanks -- ian Sent from my phone, please excuse brevity and misspelling. ________________________________ From: Octavio Alvarez<mailto:alvarezp@alvarezp.ods.org> Sent: 04/03/2014 18:09 To: jim deleskie<mailto:deleskie@gmail.com>; Andrew Latham<mailto:lathama@gmail.com> Cc: nanog@nanog.org<mailto:nanog@nanog.org> Subject: Re: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica On 03/04/2014 05:28 AM, jim deleskie wrote:
Why want to swing such a big hammer. Even blocking those 2 IP's will isolate your users, and fill your support queue's.
When the malicious DNS services get shutdown you will still have your support queue's filled, anyway. Doing it now will let you identify those affected. Blockage doesn't have to be all-or-nothing. It can be incremental, selective or all-or-nothing on some time windows. Better now than later.
On Tue, Mar 4, 2014 at 12:33 PM, Ian McDonald <iam@st-andrews.ac.uk> wrote:
Until the average user's cpe is only permitted to use the resolvers one has provided as the provider (or otherwise decided are OK), this is going to be a game of whackamole. So long as there's an 'I have a clue' opt out, it appears to be the way forward to resolve this issue. Shutting down one set of 'bad resolvers' will simply cause a new set to be spawned, and a reinfection run round the still-unpatched cpe's of the world.
+1. Local network resolvers/trusted providers (Google 8.8., OpenDNS), "Clue Opt Out" switch available if needed.
On Tue, Mar 4, 2014 at 12:33 PM, Ian McDonald <iam@st-andrews.ac.uk> wrote:
Until the average user's cpe is only permitted to use the resolvers one has provided as the provider (or otherwise decided are OK), this is going to be a game of whackamole.
No. That is still just treating symptoms, and not the disease. This also creates an unacceptable annoyance for the most slightly technical user who needs to troubleshoot any DNS problems with their domains. When the ISP's nameservers are blocked, the script kiddies will set up a tunnel, or configure the DNS client to use a different UDP port number for DNS resolution, or adjust the router firmware to run tcpdump and upload session data to/from interesting web destinations, to a hostname on port 80. -- -JH
On 04/03/14 10:33, Ian McDonald wrote:
Until the average user's cpe is only permitted to use the resolvers one has provided as the provider (or otherwise decided are OK), this is going to be a game of whackamole. So long as there's an 'I have a clue' opt out, it appears to be the way forward to resolve this issue. Shutting down one set of 'bad resolvers' will simply cause a new set to be spawned, and a reinfection run round the still-unpatched cpe's of the world.
Hi. That's a method for just temporarily managing the situation, not fixing it. If a techie opts-out, it doesn't mean other non tech-savvy users behind the same CPE won't go to a bad website and infect the vulnerable CPE. Once in this situation, it is *very* difficult The clueful user to find out. Most operators don't have an opt-out for SOHO services or it's a pain in the $BODYPART because of the dynamic nature of the SOHO services and the proper static identification of each user among the mass of not tech-savvy users. I've been through that as a user. The root of the problem is an unpatched CPE, that's right. The ISP is responsible for fixing that in pretty much all its own SOHO networks. It all boils down to finding the affected users and patching the CPEs. That has the additional benefit of involving the upstream CPE vendor. Best regards.
participants (13)
-
Andrew Latham -
Brandon Galbraith -
Davide Davini -
fmm -
Ian McDonald -
Jay Ashworth -
jim deleskie -
Jimmy Hess -
Merike Kaeo -
Niels Bakker -
Octavio Alvarez -
Valdis.Kletnieks＠vt.edu -
Warren Bailey