On-going Internet Emergency and Domain Names

Mailman List Mirror (Read Only)
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I won't discount the assertion that there is some sort of emergency
occurring. I would however, like to see a bit of a reference to where
we can learn more about what is going on (I assume this is the
javascript exploit I heard about a couple days ago).

No -- it's a 0day in Internet Explorer involving animated cursors --
and it can be spread by visiting an infected web site or even by email.

Not that I like being in the position of correcting Steve :slight_smile: but the
real answer is "yes" and "no" -- or ctually just yes.

While the 0-day exploit is the ANI vulnerability, there are many,
many compromised websites (remember the MiamiDolhins.com embedded
javascript iframe redirect?) that are using similar embedded .js
redirects to malware hosted sites which fancy this exploit.

And some of them have vast audiences, increasing the potential
for a major "issue" -- TBD.

Track with the SANS ISC -- they're doing a good job of keeping the
community abreast.

Cheers,

- - ferg

2

>> I won't discount the assertion that there is some sort of emergency
>> occurring. I would however, like to see a bit of a reference to where
>> we can learn more about what is going on (I assume this is the
>> javascript exploit I heard about a couple days ago).
>
>No -- it's a 0day in Internet Explorer involving animated cursors --
>and it can be spread by visiting an infected web site or even by email.

Not that I like being in the position of correcting Steve :slight_smile: but the
real answer is "yes" and "no" -- or ctually just yes.

While the 0-day exploit is the ANI vulnerability, there are many,
many compromised websites (remember the MiamiDolhins.com embedded
javascript iframe redirect?) that are using similar embedded .js
redirects to malware hosted sites which fancy this exploit.

Also to expand on that, if someone embeds this exploit or an iframe onto a
high traffic site that's known to be "safe", via things like comment fields
where HTML is allowed there's no telling the number of infections, it could
possibly be in the hundreds of thousands of systems if an official patch
isn't released - I hope Microsoft intends to release a patch by Monday at the
latest.

And some of them have vast audiences, increasing the potential
for a major "issue" -- TBD.

Agreed.

3

whoa. this is like deja vu all over again. when barb@CERT asked me to
patch BIND gethostbyaddr() back in 1994 or so to disallow non-ascii host
names in order to protect sendmail from a /var/spool/mqueue/qf* formatting
vulnerability, i was fresh off the boat and did as i was asked. a dozen
years later i find that that bug in sendmail is long gone, but the pain
from BIND's "check-names" logic is still with us. i did the wrong thing
and i should have said "just fix sendmail, i don't care how much easier
it would be to patch libc, that's just wrong."

are we really going to stop malware by blackholing its domain names? if
so then i've got some phone calls to make.

4

That does seem to be the single point of failure for these malwares,
and for various other things besides [phish domains hosted on botnets,
and registered on ccTLDs where bureaucracy comes in the way of quick
takedowns]

srs

5

.. just wait until they start living on in P2P trackerless type setups
and not bothering with temporary domains - just use whatever resolves to the
end-client. You'll wish it were as easy to track as "accessing these websites
or servers." (That, and the IPv6 space doesn't seem to be a saving grace either -
it'll be easy to identify potential hosts to infect by infecting someone
participating in P2P and moving across to other machines as you see
P2P application connections to/from them.)

Scary stuff.

Adrian

6

p2p based botnets are already there, I'm afraid.

7

Shiny. Know any papers which have looked at it?

Adrian

8

The recent storm worm for example seems to have had at least some p2p
functionality. There's a bunch of papers, ISC SANS posts etc that can
be found by a quick google for p2p+botnet

9

whoa. this is like deja vu all over again. when barb@CERT asked me to
patch BIND gethostbyaddr() back in 1994 or so to disallow non-ascii host
names in order to protect sendmail from a /var/spool/mqueue/qf* formatting
vulnerability, i was fresh off the boat and did as i was asked. a dozen
years later i find that that bug in sendmail is long gone, but the pain
from BIND's "check-names" logic is still with us. i did the wrong thing
and i should have said "just fix sendmail, i don't care how much easier
it would be to patch libc, that's just wrong."

are we really going to stop malware by blackholing its domain names? if
so then i've got some phone calls to make.

are we really going to stop malware by blackholing its domain names? if
so then i've got some phone calls to make.

I don't know about bind, obviously your knowledge over-shadows
mine.
Changing bind for sendmail was likely silly but it showed some agaility we
seem to not have today.
If it could have been a temporary dynamic solution (rather than a
package change), it's an interesting concept.

Back to reality and 2007:
In this case, we speak of a problem with DNS, not sendmail, and not bind.

As to blacklisting, it's not my favorite solution but rather a limited
alternative I also saw you mention on occasion. What alternatives do
you offer which we can use today?

        Gadi.

10

The argument can be made that you're trying to solve a windows-problem by implementing blocking in DNS.

Next step would be to ask all access providers to block outgoing UDP/53 so people can't use open resolvers or machines set up to act as resolvers for certain DNS information that the botnets need, as per the same analysis that blocking TCP/25 stops spam.

So what you're trying to do is a pure stop-gap measure that won't scale in the long run. Fix the real problem instead of trying to bandaid the symptoms.

11

The real problem? Okay, I'd like your ideas than. :slight_smile:

What we are referring to here is not just malware, phishing, DDoS (rings a
bell, root servers?) and othr threats. It is about the DNS being
manipulated and abused and causing instability across the board, only not
in reachability and availability which is the infrastructure risk already
being looked after.

Hijacking may be resolved by DNS-SEC, this isn't.

If an A record with a low TTL can be changed every 10 minutes, that means
no matter what the problem is, we can't mitigate it. There are legitimate
reasons to do that, though.

The C&C for a botnet would not disapear, as it would be half way across
the world by the time we see it.
The only constant is the malicious domain name.

If the NS keeps skipping around, that's just plain silly. :slight_smile:

If we are able to take care of all the rest, and DNS becomes the one facet
which can rewind the wheel, DNS is the problem. It HAS become an
infrastructure for abuse, and it disturbs daily life on the Internet. We'd
like solutions and we raised some ideas - we are willing to accept they
are not good ones, please help us out with better ones?

Or we can look at it from a different perspective:
Should bad guys be able to register thousands of domains with "amazon" and
"paypal" in them every day? Should there be black hat malicious registrars
around? Shouldn't there be an abuse route for domain names?

One problem at a time, please.

  Gadi.

12

Paul Vixie wrote:

whoa. this is like deja vu all over again. when barb@CERT asked me to
patch BIND gethostbyaddr() back in 1994 or so to disallow non-ascii host
names in order to protect sendmail from a /var/spool/mqueue/qf* formatting
vulnerability, i was fresh off the boat and did as i was asked. a dozen
years later i find that that bug in sendmail is long gone, but the pain
from BIND's "check-names" logic is still with us. i did the wrong thing
and i should have said "just fix sendmail, i don't care how much easier
it would be to patch libc, that's just wrong."

are we really going to stop malware by blackholing its domain names? if
so then i've got some phone calls to make.

Okay, what I am about to suggest here is clearly going to be heretical, and I have to admit I thought about it before reading Paul's post... but I still want to put it out for thought.

Clearly, the bad guys are manipulating DNS as a means to hide. Quoting Gadi from earlier:
  "Every day we see two types of fast-flux attacks:
  1. Those that keep changing A records by using a very low TTL.
  2. Those that keep changing NS records, pretty much the same."

So, since they are manipulating DNS, how about trying to "fix" DNS as somewhat of a work-around here? After all, this is a DNS issue, and **MAYBE** a patch to BIND may be the easiest temporary work-around?

What I would suggest is as follows:
    Add an option to BIND that:
       a) Returns a lookup failure if the TTL for the NS or A record is "too low"
       b) Caches the failure record for the server's "negative lookup" TTL time period to slow the rate of future lookups
       c) Clearly flags the forced failure in the query log to allow for the identification of potentially infected hosts and to help evaluate the effectiveness of this kludge
There should probably be separate options for setting minimum acceptable NS and A TTLs. I would think that in most circumstances you would want to consider rejecting NS RRs with TTLs < 4hrs and A RRs with TTL < 1hr.

If my bit-herding skills were a little more up to date, I might have even tried to write such a patch myself.

I think we can all agree that this is a "BAD IDEA", but given the current circumstances, maybe this bad idea could be the lesser of several evils?

Maybe we could get an "unofficial" patch from someone outside the ISC to allow this idea to be tried, thus avoiding ISC's having to forever support another bad idea that in reality didn't fix much? I would posit that if we don't try it, we would never know how effective it would be.

Jon

13

Port 25 is bad. It has been blocked.
Port 53 is bad. Some ISPs are already going to block it.

How about port 80?

I think port 80 should have been the first and only port to block.

Let the other ports stay alive.

And maby a test for port 42 would be nice.

If port 42 is answered by an IEN 116 nameserver then everything is
fine. If it is windows nameservice - then shot the guy. Chance is
75% that it is a bot already. If you dont shot him chance is 75%
that he will get infected anyhow.

Can somebody tell me how to delay this post until midnight your time?
I have unlocked the "mettre en voyage" lever already and the kettle is
boiling. I am shure we built staem enough :slight_smile:

Cheers
Peter and Karin

Gadi Evron wrote:

14

Based on Lorenzen's data, domain tasting enables millions of domain
names to be in flux every day. Exchange lists this large to end users
is extremely costly. When small handguns became a weapon of choice for
holdups, a waiting period was imposed to allow enforcement agencies time
to block exchanges.

Even when bad actors can be identified, a reporting lag of 12 to 24
hours in the case of global registries ensures there can be no
preemptive response. If enforcement at this level is to prevent crime,
registries would need to help by providing some advanced notice.
Perhaps all registries should be required to report public details of
domain name additions 24 hours in advance of the same details being
published in the TLD zones.

-Doug

15

Gadi Evron wrote:

The real problem? Okay, I'd like your ideas than. :slight_smile:

Just because one doesn't have a solution to the real
problem doesn't invalidate them from objecting to an
idea presented by someone else, you know?

Trying to "fix" DNS this way is just the wrong thing
to do, even though the goal is honorable. We'll just
end up having them do something else instead and the
attempts we've made will be in vain and will likely
have ended up with limitations to ourselves rather
than to them.

They will adapt to any change like this we would try
to do. The only real way to attempt to stop this is
lobbying for legislation, nailing people for what we
see around us and the damage they cause us and to
make it risky business rather than the piece of cake
it is today. Anything else is just a minor setback
for them, and a HUGE deal of investment and money
for "us" on top of what we already spend handling
what we're exposed to.

16

The only constant is the malicious domain name.

If we are able to take care of all the rest, and DNS becomes
the one facet
which can rewind the wheel, DNS is the problem.

You have just explained how DNS is *NOT* the problem. The only constant
is the domain name. That is handled by domain name registries, not by
the DNS. Since domain name registries are not a technical issue, there
is no technical solution to the problem.

I suggest that you would get further by working with (or suing) the
domain name registries that allow these domain names to be so
"constant".

Or we can look at it from a different perspective:
Should bad guys be able to register thousands of domains with
"amazon" and
"paypal" in them every day?

In my opinion, yes. This gives the police something to subpoena from the
registries to track down these people. If they were registering random
words from the dictionary, the police would not know what records to
subpoena. And if the registries disallowed applications with amazon and
paypal in them, then the crooks would be using random words from the
dictionary.

Should there be black hat
malicious registrars
around?

Yes. Again it gives a target for the police. As the FBI learned in the
1950's, you get much further by chasing the money than by chasing the
men behaving badly.

--Michael Dillon

17

Close one, the will go to another, and another -- Nowadays, you'd have to
block all 65535 ports on both TCP and UDP to get anywhere, Port blocking
isn't the answer -- It ONLY postpones the attacks and such.

What needs to be done is the ISPs allowing botnets and malware to run rampid
on their networks to be held accountable for being negligent on their network
security, Service provider abuse mailboxes should be paid more heed to, and
reports should be acted upon,

But I will relitterate, you can block all the ports you want, they (The
origins of these attacks) will just ove to the next available one.

18

What about a worldwide clearing house where all registrars must submit their
domains for some basic verification?

Naming: For phishing reasons. I think detection of possible trademark
violations would be too contentious.
Contact info: It's fine to use a proxy to hide true ownership to the public,
but the clearing house would verify telephone numbers and addresses against
public and private databases, and for those countries that don't have that
well built-out, something that ties payment (whether that be credit card,
bank transfer, or check) to a piece of identification as strong as a
passport.
Funding of such a clearing house: a flat fee per domain
Maintenance: It can't be a one-time event, but I'm not sure how this would
look.

Of course, the above is only utopia and the problem has to get much worse
before we'll see international cooperation.

Frank

19

...
Back to reality and 2007:
In this case, we speak of a problem with DNS, not sendmail, and not bind.

As to blacklisting, it's not my favorite solution but rather a limited
alternative I also saw you mention on occasion. What alternatives do you
offer which we can use today?

on any given day, there's always something broken somewhere.

in dns, there's always something broken everywhere.

since malware isn't breaking dns, and since dns not a vector per se, the
idea of changing dns in any way to try to control malware strikes me as
a way to get dns to be broken in more places more often.

in practical terms, and i've said this to you before, you'll get as much
traction by getting people to switch from windows to linux as you'd get by
trying to poison dns. that is, neither solution would be anything close to
universal. that rules it out as an "alternative we can use today".

but, isp's responsible for large broadband populations could do this in their
recursion farms, and no doubt they will contact their dns vendors to find a
way. BIND9, sadly, does not make this easy. i'll make sure that poison at
scale makes the BIND10 feature list, since clustering is already coming.

at the other end, authority servers which means registries and registrars
ought, as you've oft said, be more responsible about ripping down domains
used by bad people. whether phish, malware, whatever. what we need is some
kind of public shaming mechanism, a registrar wall of sheep if you will, to
put some business pressure on the companies who enable this kind of evil.

fundamentally, this isn't a dns technical problem, and using dns technology
to solve it will either not work or set a dangerous precedent. and since
the data is authentic, some day, dnssec will make this kind of poison
impossible.

20

Some SPs are doing DNS manipulation/poisoning now for various reasons, with varying degrees of utility/annoyance. If those SPs choose to manipulate their own DNS in a way which affects their own users, that's fine; if the users don't like it, they can to elsewhere. Some enterprises are doing the same kinds of things, with the same options available to the user population (though not always quite as easy to 'go elsewhere', heh).

What SPs or enterprises choose to do for/to their own user bases is between them and their users. When we start talking about involving registries, etc., that's when we've clearly jumped the shark.

There is no 'emergency', any more than there was an 'emergency' last week or the week before or the month before that - after a while, a state of 'emergency' becomes the norm, and thus the bar is raised. It's merely business as usual, and no extraordinary measures are required. Yes, there are ongoing, long-term problems, but they need rationally-thought-out, long-term solutions.

'Think globally, act locally' seems a good principle to keep in mind, along with 'Be liberal in what you accept, and conservative in what you send'. Much unnecessary grief and gnashing of teeth would be avoided if folks worries about what was going on in their own networks vs. grandiose, 'fix-the-Internet'-type 'solutions' (the appeal of the latter is that it requires no actual useful effort or sacrifice on one's own part, merely heated rhetoric and a pointed finger, which appeals to some of the least attractive aspects of human nature).