On-going Internet Emergency and Domain Names

Sun Apr 1 01:36:39 UTC 2007

On 3/30/07, Gadi Evron <ge at linuxbox.org> wrote:
>
> There is a current on-going Internet emergency: a critical 0day
> vulnerability currently exploited in the wild threatens numerous desktop
> systems which are being compromised and turned into bots, and the domain
> names hosting it are a significant part of the reason why this attack has
> not yet been mitigated.
>
> This incident is currenly being handled by several operational groups.
>
> This past February, I sent an email to the Reg-Ops (Registrar
> Operations) mailing list. The email, which is quoted below, states how DNS
> abuse (not the DNS infrastructure) is the biggest unmitigated current
> vulnerability in day-to-day Internet security operations, not to mention
> abuse.
>
> While we argue about this or that TLD, there are operational issues of the
> highest importance that are not being addressed.
>
> The following is my original email message, elaborating on these above
> statements. Please note this was indeed just an email message, sent among
> friends.
>
> ----- Begin quoted message -----
> Date: Fri, 16 Feb 2007 02:32:46 -0600 (CST)
> From: Gadi Evron
> To: reg-ops at ...
> Subject: [reg-ops] Internet security and domain names
>
> Hi all, this is a tiny bit long. Please have patience, this is important.
>
> On this list (which we maintain as low-traffic) you guys (the
> registrars) have shown a lot of care and have become, on our sister
> mitigation and research lists (those of you who are subscribed), an
> integral part of our community we now call "The Internet Security
> Operations Community".
>
> We face problems today though, that you can not help us solve under the
> current setting. But only you can help us coming up with new ideas.
>
> Day-to-day, we are able to report hundreds and thousands of completely
> bogus phishing and other bad domains, but both policy-wise and
> resources-wise, registrars can't handle this. I don't blame you.
>
> In emergencies, we can only mitigate threats if one of you or yours are in
> control.. Just a week ago we faced the problem of the Dolphins stadium
> being hacked and malicious code being put on it:
>
> 1. We tracked down all the IP addresses involved and mitigated them (by we
> I mean also people other than me. Many were involved).
> 2. We helped the Dolphins Stadium IT staff take care of the malicious code
> on their web page - Specifically Gary Warner).
> 3. We coordinated with law enforcement.
> 4. We coordinated that no one does a press release which will hurt law
> enforcement.
> 5. We did a lot more. Including actually convincing a Chinese registrar to
> pull one of the domains in question. A miracle. There was another domain
> to be mitigated, unsuccessfully.
>
> One thing though - at a second's notice, this could all be for nothing as
> the DNS records could be updated with new IP addresses. There were
> hundreds of other sites also infected.
>
> Even if we could find the name server admin, some of these domains have as
> many as 40 NSs. That doesn't make life easy. Then, these could change,
> too.
>
> This is the weakest link online today in Internet security, which we in
> most cases can't mitigate, and the only mitigation route is the domain
> name.
>
> 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.
>
> Now, if we have a domain which can be mitigated to solve such
> emergencies and one of you happen to run it, that's great...
> However, if we end up with a domain not under the care of you and
> yours.. we are simply.. fucked. Sorry for the language.
>
> ICANN has a lot of policy issues as well, and the good guys there can't
> help. ICANN has enough trouble taking care of all those who want money for
> .com, .net or .xxx.
>
> All that being said, the current situation can not go on. We can no longer
> ignore it nor are current measures sufficient. It is imperative that we
> find some solutions, as limited as they may be.
>
> We need to be able to get rid of domain names, at the very least during
> real emergencies. I am aware how it isn't always easy to distinguish what
> is good and what is bad. Still, we need to find a way.
>
> Members of reg-ops:
> What do you think can be conceivably done? How can we make a difference
> which is REALLY needed on today's Internet?
>
> Please participate and let me know what you think, we simply can no longer
> wait for some magical change to happen.
>
>        Gadi.
> ----- End of quoted message -----
>
> Thousands of malicious domain names and several weeks later, we face the
> current crisis. The 0day vulnerability is exploited in the wild, and
> mitigating the IP addresses is not enough. We need to be able to "get
> rid" of malicious domain names. We need to be able to mitigate attacks on
> the weakest link - DNS, which are not necessarily solved by DNS-SEC or
> Anycast.
>
> On Reg-Ops and other operational groups, we came up with some imperfect
> ideas on what we can make happen on our own in short term which will help
> us reach better mitigation, as security does not seem to be on the agenda
> of those running DNS:
>
> 1. A system by which registrars can acknowledge confirmed bad domains
> (under strict guidelines) and respond to the reports according to their
> AUP and ICANN policy, thus "getting rid" of them in a much quicker
> fashion, is being set up at the ISOTF.
> A black list for registrars, if you will. This is far from perfect and
> currently slow-going. Naturally, this can not be forced on all registrars,
> nor do the black hat ones, care.
>
> 2. A black list for resolvers (hopefully large service providers) is also
> being created at the ISOTF, so that the risk of visibility of bad domains,
> as will be defined, can be minimized. Naturally, no provider can be forced
> to use this list and there are millions of unaffiliated resolvers, etc.
>
> Other options that have been raised as technically possible, but
> considered unlikely and indeed, bad:
>
> 3. Setting up a black list of domain names for TLD servers, for them not
> to respond on.
>
> 4. Creating an alternate root which we could trust.
>
> Another suggestion which was raised:
>
> 5. Apply to change the ICANN policy.
>
> We need a solution. This operational issue needs to be added as a main
> agenda item today so that tomorrow we will be ready to mitigate it. I
> blame myself to some degree for not raising this with higher echelons 2
> and 3 years ago due to respect to those who have been working on DNS for
> many years, but what's done is done.
>
> The operational communities do not always know how to voice their needs or
> the difficulties they face. Nor will everyone agree on what the issues
> are. It is my strong belief (which is obviously my personal opinion),
> based on facts we see in daily security operations on the Internet that
> this issue is paramount, and I am sending here a call for help to the DNS
> experts of the world: what is our next step to be?
>
> What do we currently intend to do (not my personal opinion):
> We are formalizing a letter to ICANN's SSAC, as they are the top experts
> on DNS infrastructure security issues, coming from operational folks at
> the ISOTF dealing with daily usage of the DNS for abuse purposes (and
> specifically fastflux).
>
> Further, the ISOTF is moving forward with items #1 and #2 as mentioned
> above. #3 will have to remain as a contingency, #4 we have no influence to
> affect. #5 is currently being explored.
>
> Are we missing a possible solution? What does the larger community
> suggest?
>
>         Gadi Evron.
>

What really surprises the living crap out of me is that you're
attempting to find a technical solution to what is essentially a
social problem. If you really want to do something to fix this
problem, as you describe it, try suing microsoft for lost
time/man-hours/profits/whatever due to their lax security practices
instead of mucking about with DNS/ICANN/whatever else.

Social problems generally can only be solved by social solutions,
specifically because the moment your technical 'solution' is released,
someone will bypass it. If you'd like examples of technical solutions
for social problems not working, try DeCSS or any one of a number of
anti-drm solutions (social problems: piracy, copyright infringement;
technical solutions defeated recently within 1 week of release into
the wild).

If you need more examples: spam (email, blog, seo), phishing, 419
scams, DDoS 'ransoming.' All of these problems *continue* to work
because they continue to be profitable for the folks committing the
crimes, any technical solution the community *might* come up with will
be bypassed simply because it's in someone's best interest for them to
continue.

You'd do better by trying to study the sociological concepts at work
and attempting to address *THOSE.*

It's been said that if you build your software to be idiot proof, the
universe will simply invent a better idiot.

My 2/100th's of a monetary unit,
Allen Parker