DNS Hijacking by Cox

Mailman List Mirror (Read Only)
1

It looks like cox is hijacking dns for irc servers.

bash2-2.05b$ nslookup

server 68.6.16.30

Default server: 68.6.16.30
Address: 68.6.16.30#53

irc.vel.net

Server: 68.6.16.30
Address: 68.6.16.30#53

Name: irc.vel.net
Address: 70.168.71.144

server ns1.vel.net

Default server: ns1.vel.net
Address: 207.182.224.10#53

irc.vel.net

Server: ns1.vel.net
Address: 207.182.224.10#53

Name: irc.vel.net
Address: 64.161.255.2

it looks like they are using it to clean drones, when you connect to
their fake irc server you get forced joined into a channel.

#martian_
  [INFO] Channel view for "#martian_" opened.
  -->| YOU (andrew.m) have joined #martian_
  =-= Mode #martian_ +nt by localhost.localdomain
  =-= Topic for #martian_ is ".bot.remove"
  =-= Topic for #martian_ was set by Marvin_ on Sunday, July 22, 2007 2:55:02 PM
  =-= Topic for #martian_ is ".remove"
  =-= Topic for #martian_ was set by Marvin_ on Sunday, July 22, 2007 2:55:02 PM
  =-= Topic for #martian_ is ".uninstall"
  =-= Topic for #martian_ was set by Marvin_ on Sunday, July 22, 2007 2:55:02 PM
  =-= Topic for #martian_ is "!bot.remove"
  =-= Topic for #martian_ was set by Marvin_ on Sunday, July 22, 2007 2:55:02 PM
  =-= Topic for #martian_ is "!remove"
  =-= Topic for #martian_ was set by Marvin_ on Sunday, July 22, 2007 2:55:02 PM
  =-= Topic for #martian_ is "!uninstall"
  =-= Topic for #martian_ was set by Marvin_ on Sunday, July 22, 2007 2:55:02 PM
  <Marvin_> .bot.remove
  <Marvin_> .remove
  <Marvin_> .uninstall
  <Marvin_> !bot.remove
  <Marvin_> !remove

isn't there a law against hijacking dns? What can i do to persue this?

2

Hey

Well I suppose that would get rid of some of the script kiddies bots off of their network...

http://www.dslreports.com/forum/remark,12922412
http://www.gossamer-threads.com/lists/fulldisc/full-disclosure/55016

Though...I cannot think of another means to achieve their goal. However I wonder how they generated what records to point to their servers. Is it simply anything with irc.* ? I suppose it would stop the script kiddies if they didn’t use their own unique DNS and specified a different port in the config before compiling. Typically zombies are set to listen to the topic commands in order to either continue a DDoS attack or like scan for other hosts to infect. This would prevent the bots from getting a valid command to start scanning or DDoS, or in this case .remove would remove the bot from their customers computer (unless the default command character was changed), so I suppose it gets what they want, DDoS's to not originate in their network + XDCC Bots being created from zombies etc etc, credit card, zombie bots can be set to listen for paypal information and credit card information etc...but at the same time causing problems for their customers who legitimately use IRC. If weighed, I believe their problems with DDoS bots is weighted more heavily then the few who legitimately use IRC. I suppose they can always use like psyBNC to connect to IRC.

I agree with their goal but not really the means they are using reach their goal. If they are going to manipulate DNS to do this...how far will they go with other problems?

Raymond Corbin
Support Analyst
HostMySite.com

(sorry if it this posted twice...outlook froze on me :frowning: )

3

DNS is just another application protocol that runs over IP. You don't have to use those DNS servers to resolve names.

4

It looks like cox is hijacking dns for irc servers.

<snip>

isn't there a law against hijacking dns? What can i do to persue this?

no, its their network and they play by their rules.. the law would prevent them from inserting data into 3rd party servers or from masquerading as someone they are not or other marketing unfairness (such as serving their site in place of their competitors).

if you are a cox customer you might want to have a reasoned discussion with them and find out more details and whether you can reach a resolution. if they dont play ball tho you ultimately would have to vote with your $$ and switch..

Steve

5

* steve.wilcox@packetrade.com (Stephen Wilcox) [Mon 23 Jul 2007, 01:21 CEST]:

It looks like cox is hijacking dns for irc servers.

<snip>

isn't there a law against hijacking dns? What can i do to persue this?

no, its their network and they play by their rules.. the law would prevent them from inserting data into 3rd party servers or from masquerading as someone they are not or other marketing unfairness (such as serving their site in place of their competitors).

You mean, like, sending you to their own machine instead of the actual irc.vel.net (a legit EFnet server) when you ask for it?

if you are a cox customer you might want to have a reasoned discussion with them and find out more details and whether you can reach a resolution. if they dont play ball tho you ultimately would have to vote with your $$ and switch..

This is a ridiculous argument as in many places there is only one game in town for affordable high speed internet for end users.

  -- Niels.

6

Agreed. If you’re savvy enough to have a problem because of this, you’re savvy enough to a) Use another set of DNS servers or b) Use your own local resolver.

-brandon

7

Brandon Galbraith wrote (on Sun, Jul 22, 2007 at 06:28:55PM -0500):

Agreed. If you're savvy enough to have a problem because of this, you're
savvy enough to a) Use another set of DNS servers or b) Use your own local
resolver.

-brandon

Oh. And when they implement Plan B (inspecting each DNS packet for
IRC.* and substituting their own answer as a reply), then what?

8

Brandon Galbraith wrote:

    DNS is just another application protocol that runs over IP. You don't
    have to use those DNS servers to resolve names.

Possibly, you do (based on experience).

Agreed. If you're savvy enough to have a problem because of this, you're savvy enough to a) Use another set of DNS servers or b) Use your own local resolver.

For awhile, Comcast blocked/redirected all DNS queries, sending them to
their own servers. Then, their servers didn't work properly....

Comcast still blocks port 25. And last week, a locally well-known person
was blocked from sending outgoing port 25 email to their servers from her
home Comcast service.

It took some days to find out that Comcast had (without any notice) turned
off her outgoing email (Monday), due to spam complaints! Needless to say,
her MacBook isn't sending spam -- but many thousands of folks have her
email address in their (presumably infected M$) address books.

The official response: We don't support Thunderbird. You could use web
email instead.

When you pull stunts like that, you shouldn't complain about legislation.

9

Hi!

Agreed. If you're savvy enough to have a problem because of this, you're
savvy enough to a) Use another set of DNS servers or b) Use your own local
resolver.

Oh. And when they implement Plan B (inspecting each DNS packet for
IRC.* and substituting their own answer as a reply), then what?

Whats next, will they also start proxy'ing your favorite bank on DNS so they can track cc info?

OTOH, lets do the same with spamvertized sites ... :wink:

Bye,
Raymond.

10

MSA port 587 is only 9 years old. I guess it takes some people longer than others to update their practices. Based on what I know how comcast's abuse systems implement their port 25 restrictions, I think it is extremely unlikely it was based on other people having her e-mail address in their Outlook programs.

Some people complain ISPs refuse to take action about abuse and compromised computers on their networks. On the other hand, people complain when ISPs take action about abuse and compromised computers on their networks. ISPs are pretty much damned if they do, and damned if
they don't.

Several ISPs have been redirecting malware using IRC to "cleaning" servers for a couple of years trying to respond to the massive number
of bots. On occasion they pick up C&C server which also contains some "legitimate" uses. Trying to come up with a good cleaning message for
each protocol can be a challenge.

Yes, false positives and false negatives are always an issue. People running sevaral famous block lists for spam and other abuse also made mistakes on occasion.

11

And people wonder why I support DNSsec....

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

12

Steve,

One of us is confused. It might be me, but right now I think it's you.

To be clear, here is the situation as I understand it: Cox has configured their recursive name servers such that when an end user queries the recursive server for a specific host name (names?), the recursive server responds with an IP address the host's owner did not configure.

How exactly is DNSSEC going to stop them from doing this?

13

If my host expects the response to be signed and it isn't, my host can
scream bloody murder. The whole point of DNSSEC is to prevent random
changes to DNS replies, whether by hackers or by ISPs.

Yes, they can change it, but they can't change it without being caught.

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

14

Quoting Sean Donelan <sean@donelan.com>:

Comcast still blocks port 25. And last week, a locally well-known person
was blocked from sending outgoing port 25 email to their servers from her
home Comcast service.

MSA port 587 is only 9 years old. I guess it takes some people longer
than others to update their practices. Based on what I know how
comcast's abuse systems implement their port 25 restrictions, I think
it is extremely unlikely it was based on other people having her e-mail
address in their Outlook programs.

Indeed. There's just not enough info to make anything but wild guesses about this.

Some people complain ISPs refuse to take action about abuse and
compromised computers on their networks. On the other hand, people
complain when ISPs take action about abuse and compromised computers on
their networks. ISPs are pretty much damned if they do, and damned if
they don't.

Gotta love the techie world :slight_smile:

Several ISPs have been redirecting malware using IRC to "cleaning"
servers for a couple of years trying to respond to the massive number
of bots. On occasion they pick up C&C server which also contains some
"legitimate" uses. Trying to come up with a good cleaning message for
each protocol can be a challenge.

I'm still unsure that this is either a good idea or a bad idea... changing the DNS can only help until the bots start connecting directly to IP addresses. Then where do we go? NAT those connections to elsewhere? It's one of those lovely arms races where things just get more and more invasive.

In the short term, it's a good thing - the amount of spam I get from their network has halved - which is great - however in the long term, the writers of this crudware will find another way to do business (web? ftp?).

Yes, false positives and false negatives are always an issue. People
running sevaral famous block lists for spam and other abuse also made
mistakes on occasion.

And these people have been flamed senseless. I like to think of it as a case of the work the blocklists do is excellent and saves many a network from being overrun by spam - however there is always collateral damage from things like this. The good far outweighs the bad however.

15

DNSSEC provides source authenticity and data integrity. You may get a bogus
answer, but with DNSSEC in place at least you have a way of verifying the
bogosity (is that a word?) of the reply.

I agree with Steve, DNSSEC won't stop these tricks but it makes them
detectable.

I'm a Cox user at home but I have my Linksys home router configured to use
DNS servers of my own choosing rather than Cox' choice. I also tunnel my
email through SSH to a mail server I control so that I'm not blocked by
their port 25 filters.

Marc

16

Is there any indication that they've done anything other than make
themselves authoritative for those DNS names and simply sent you to
their IRC server instead? If so, what they have done is pretty much
legal (mostly because I'm quite sure there is something in their ToS
which you implicitly accepted which allows them to do this). Under
net neutrality, it might be a different story.

Let's be honest, it's a band-aid lowtech fix for lowtech script
kiddies who right code like a bunch of apes with keyboards. However,
for anyone with a remote amount of clue, they could get around this
problem in approximately 1.6 seconds with their malware.

But to get straight to the point, Cox sucks, always has. Maybe it's
time for a real ISP?

j

17

I'm still unsure that this is either a good idea or a bad idea...
changing the DNS can only help until the bots start connecting directly

to >IP addresses. Then where do we go? NAT those connections to
elsewhere? It's >one of those lovely arms races where things just get
more and more >invasive.

I don't foresee the programming of IP addresses instead of IP addresses.
Because if/when they are found and their exploited server is shut down,
their dedicated server turned off for AUP violations etc they will loose
access to all of the bots set to that IP address. This happens a lot and
when it does they simply change the DNS.

And these people have been flamed senseless. I like to think of it as
a case of the work the blocklists do is excellent and saves many a
network from being overrun by spam - however there is always
collateral damage from things like this. The good far outweighs the
bad however.

I agree. They are at least trying to clean up their network. If they are
having a lot of problems with zombie bots that DDoS / Spam then this is
a good way to stop it, for now. The small group of users can either use
other nameservers or something like psybnc to connect if they want to
get on IRC.

Raymond Corbin
Support Analyst
HostMySite.com

18

Several people have email me privately to disagree with my statement
about DNSSEC, on various grounds. I stand by my statement, but I am
making a fair number of assumptions, some perhaps invalid. Let me be
less terse.

I'm assuming fairly universal deployment. In other words, the root
zone is signed, as is most or all of .com/.net/.org are signed and
the .ccTLDs of your choice. I don't assume that domains under,
say, .com are signed, but of course unsigned zones aren't protected.

I assume that user machines have a configuration file with the root
keys. (I'm carefully not saying anything here about how root key
rollover is done.) I'm assuming that ISPs are *not* changing that
configuration file; this may be a dubious assumption. One
correspondent felt that it was; I stand by my statement, because if the
ISP plays games there and the user falls to a pharming attack that
DNSSEC may have prevented, the ISP may be liable. Besides, there's an
easier attack for the ISP...

DNSSEC can be end-to-end, or it can be terminated by a full-service
caching server which has a security association with user resolver
(typically via TSIG, which uses shared secrets). In that case, the
caching server would verify the digital signatures and set a bit in the
response to the user saying "all is cool". This is the most likely way
an ISP would spoof a response, since it doesn't strip protection from
other zones, doesn't require them to do massive resigning, etc.

The way this is signaled by the end-user's resolver and handled by the
caching name server is complex (see Section 3.2 of RFC 4035); briefly,
though, it's ultimately under the control of the end system. I have no
idea what the Windows default will be or if it will let the user's
machine do its own validation. My guess, though, is that it will prefer
ISP validation but be able to do it itself. Note that 4035 requires a
secure channel (i.e., a shared secret) for upstream validation; since
that won't exist out of the box, the PC would have to be able to do its
own. For obvious reasons, I'm focusing on Windows here. It's 99%
certain that Linux and *BSD machines can do their own checking, if they
wish; I'll leave to others to speculate what MacOS will do. The net,
though, under my assumptions, is that ISP-supplied user configurations
will likely have the user's machine trust them, but sophisticated users
will be able to override that -- and DNSSEC is very much something for
sophisticated users.

The ISP can always ignore the RFC and strip out the signature RRs.
That's detectable by an end-system that has requested that they be sent
along. After all, that's no different than a monkey-in-the-middle
attacker doing the same thing -- DNSSEC doesn't distinguish between
offensive ISP and other enemies...

So -- I think that DNSSEC, if deployed, will protect users who care,
even against their ISP. It won't protect the clueless; I'm not sure
what will. (See
http://didierstevens.wordpress.com/2007/05/07/is-your-pc-virus-free-get-it-infected-here/
for an example of people you can't protect with technology...) But it
is, as the tube of toothpaste almost says, an effective
attack-prevention mechanism if used as part of a program of good
Internet hygiene and regular professional care.

19

It doesn't seem to be rogue Cox engineers. Several major ISPs have all taken action against these particular IRC servers (not! IRC in general).
They either re-direct the traffic to a cleaning server, or are blackholing the traffic completely.

Yes, it could have been some type of false positive; but when multiple ISPs all start re-acting to something, I think there might be more to the story. Especially when those ISPs are noted for not responding to incidents. One ISP, it might be the ISP. Multiple ISPs, gotta start looking at what has them disturbed.

Its hard to wake those dragons.

20

Sean Donelan wrote:

I agree. They are at least trying to clean up their network. If they are
having a lot of problems with zombie bots that DDoS / Spam then this is
a good way to stop it, for now. The small group of users can either use
other nameservers or something like psybnc to connect if they want to
get on IRC.

It doesn't seem to be rogue Cox engineers. Several major ISPs have all taken action against these particular IRC servers (not! IRC in general).
They either re-direct the traffic to a cleaning server, or are blackholing the traffic completely.

Yes, it could have been some type of false positive; but when multiple ISPs all start re-acting to something, I think there might be more to the story. Especially when those ISPs are noted for not responding to incidents. One ISP, it might be the ISP. Multiple ISPs, gotta start looking at what has them disturbed.

Legit or not, well that's for each individual, because of the problem of Bots I'm happy that they are doing it, when my ISP stops me connecting to my IRC server I'll probably not be happy (actually I'd be *very* unhappy because I IPSec all traffic with the network it's on, but that's another story).

Cox know they have a problem, they have taken steps which have been thought out to correct it. How many legitimate users use irc.vel.net from *.cox.net against how many bots use IRC from *.cox.net ... all a matter of numbers and risk. Not saying it's right or wrong, but am saying look at the numbers before making a personal call, and use your own server(s) for recursion if you can't accept what they have done to *their* DNS servers. of course if Cox is blocking DNS traffic from home users then I can see a reason to complain loudly.

My $0.02...

Regards,

Mat