ðòïåëôù 


  áòèé÷ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  óôáôøé 


  ðåòóïîáìøîïå 


  ðòïçòáííù 



ðéûéôå
ðéóøíá














     áòèé÷ :: Security-alerts
Security-Alerts mailing list archive (security-alerts@yandex-team.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[security-alerts] On-going Internet Emergency and Domain Names



 

________________________________

ïÔ: full-disclosure-bounces@xxxxxxxxxxxxxxxxx ÏÔ ÉÍÅÎÉ Gadi Evron
ïÔÐÒÁ×ÌÅÎÏ: óÂ, 31.03.2007 6:22
ëÏÍÕ: bugtraq@xxxxxxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxxx
ôÅÍÁ: [Full-disclosure] On-going Internet Emergency and Domain Names



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@...
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.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/





 




Copyright © Lexa Software, 1996-2009.