The initial variants of the worm, Conficker A/B, focused on potentially utilizing a limited number of domain names to control the infected computers. The affected registrars have collaborated to block the control of this variant of the worm over the past two months. A new variant, Conficker C, has been identified. This variant is more complex and presents increased mitigation challenges. Among these challenges, Conficker C seeks to use a wider range of domain names across the DNS, involving many more names in across a greater number of registries. Analysis indicates the Conficker C code will become active on April 1st.

ICANN is working with the security, vendor and DNS communities in an effort to proactively inform those involved registries who might be affected with specific information that will enable them to block the use of the DNS to control the infected computers. Through the outreach, the registry community is now in close contact with the Conficker working group and taking actions appropriate to their particular situations. An important note regarding April 1st: While the Conficker C code may become active on this date, the DNS and the Internet will likely not see a sudden wave of disruption or activity from the infected computers. Lack of activity on April 1st does not mean the millions of infected computers have been cleaned up or that efforts to mitigate the control of these computers can stop.

The cooperation to stop the spread of the Conficker worm and block control of the infected computers has become a major effort involving well over 100 organizations. The collaborative has conducted shared technical analysis and passed information resulting in practical, proactive steps to limit control and stop the spread of the worm. ICANN will continue its efforts with the security and DNS communities and sees this effort as a model for effective global response to situations that challenge the security and stability of the Internet and the DNS. We also want to encourage individuals and organizations who are concerned about removing the malicious code and to contribute to disabling Conficker to visit http://confickerworkinggroup.org/wiki/ for information regarding what can be done.

As has been discussed a lot lately, the DNS does not have much in the way in inherent security mechanisms. DNSSEC is a newer technology designed to remedy that by adding a layer of cryptographic verification to the DNS. By using DNSSEC, DNS data can be checked and verified to make sure it has not been tampered with in transit over the unprotected Internet.

Key to deploying DNSSEC is deploying it at the root zone level. The root zone is the upper most level in the DNS hierarchy, and is managed under a complex arrangement involving not only ourselves, but also VeriSign and the US Government. Right now, consultations are being made on how best to secure the root zone using DNSSEC, and that discussion is expected to carry on for some time. It is a somewhat political debate, as well as a technical discussion on how to maintain the robustness of a service that is the cornerstone of Internet stability.

The community has recognised that discussion will undoubtedly carry on for some time, but that there is an immediate need to support nascent DNSSEC deployment efforts. To do this a trust anchor repository was proposed, with ICANN requested to operate the service. A trust anchor repository would be a place to hold the security information that would be in the root zone if it were signed. For example, the Swedish country code top-level domain .SE has already implemented DNSSEC, and their trust anchors can be found in the repository. This allows for early adopters who have suitably configured DNSSEC software to obtain that security information independent of the DNS, without waiting for the root zone to have DNSSEC implemented.

Today we have released the first public version of the trust anchor repository after some initial experimentation with some of the core DNSSEC engineering community. We have prepended the word “interim” to its name, just to emphasise that this isn’t permanent, and is only designed to be a stepping stone to the ultimate goal of a DNSSEC-signed root zone.

We do not recommend it for use other than by expert administrators. It is experimental and requires some understanding of DNSSEC to be helpful. We think it will be useful in giving everyone involved better operational experience with DNSSEC, as well as being a helpful nudge on the way toward more universal DNSSEC deployment on the Internet. As a temporary solution, it has its caveats, and we recommend not treating it as an ultimate solution. But with that in mind, we look forward to those who are feeling adventurous to give it a try and provide us with feedback on how we can improve the service.

The Conflicker/Downadup worm infects computers running Windows operating systems variants. The infected computers can be remotely controlled (i.e. forming a botnet) and the infection propagates through a number of different routes. The worm has been estimated as infecting as many as 10 million hosts and data from the security community indicates the number is at least 1.5 million. One mechanism the worm’s code uses to enable control is to download commands by accessing specific date-based domain names.

In mid-January, security community researchers began to understand which future domain names that the botnet would seek to utilize. These researchers sought cooperation from these registries to protect the names that would potentially be utilized. ICANN has worked with the registries, the security researcher community and Microsoft to share information, discuss specific mitigation steps and reach out globally across all involved parties to block the spread of the worm and formation of a massive botnet. This type of collaborative response is a model for dealing with distributed, evolving threats to the Internet’s security and resiliency.

We believe that malicious code using the DNS to enable propagation of worms and establishment of large botnets is likely to continue, even increase, in the short term. We are continuing our collaboration in response to the Conflicker/Downadup worm/botnet. DNS registries, the security community, and ICANN staff have agreed to initiate a working group to establish how ICANN can enable timely and effective responses to such worm/botnet situations that involve abuse of the DNS and threaten Internet security and resiliency.

Greg Rattray

ICANN Chief Internet Security Advisor

How does the DNS work?

The DNS can be considered to be a question-and-answer system. When you type in an address like “icann.org” into a web browser, your computer needs to turn that into a numeric address of the computer hosting that website. To do this, it sends a question over the Internet to a DNS server “Where is icann.org?” The DNS server sends back an answer, “The address is 192.0.2.0”.

How do you attack the DNS?

Let’s say I want to execute an attack on this question and answer exchange, in order to convince the computer to go to the wrong address. When the computer I wish to attack asks a question, my goal is to provide a fake response back to that computer quicker than the real server comes back with the response. By getting my forged answer back faster, the computer will proceed using my answer, rather than the official one.

So, if I send back a fake address to a computer, I can get that computer to go to a different address than the one intended. For example, on that address I might have set up a fake website intended to take someone’s sensitive data, like a replica of a bank’s website.

If I manage to attack one computer why is that a big deal?

A successful attack on one computer in isolation can be problematic for the user of that computer, but it is not that interesting to an attacker to succeed against only one person. Unlucky for us, just one successful attack can very easily have wider consequences. Let me explain.

The DNS is made much more efficient by the use of “caching” name servers. These name servers sit at ISPs, or on corporate networks, and perform DNS lookups on behalf of customers. It then stores the answers it receives in a cache, so for future lookups for the same domain it does not repeat the lookup – it just remembers the previous answer.

This means that if you execute an attack and it gets stored in a cache, it can actually impact many people over and over again, because that answer will be redistributed to everyone that uses that same caching server.

This is why this type of attack is usually called a “cache poisoning” attack, because by poisoning the cache with the wrong data, it creates a much more serious problem.

So I just send back an answer quicker, and that’s it?

It is not quite as simple as just sending a quicker answer back to a computer, you also have to guess certain attributes correctly on the answer that match the question. For example, your answer needs to go back to the same computer the question originated. You also need match the question that was being asked in your answer.

It is simple, however, to guess most of the attributes. As you know which computer you are trying to attack, you don’t need to guess that. As you know which domain you are trying to impersonate, that is also a given. Conventionally, there are only two variables. One variable is you need to guess which server the answer is coming from. The average domain on the Internet has around two or three name servers, only one of which will respond to any given query. Therefore you have about a one in three chance of guessing that correctly. The second variable is a unique reference number (formally, a “transaction ID”), that has about 65000 possibilities. Therefore you have about a 1 in 65000 chance of guessing that correctly.

Earlier this year, security researcher Dan Kaminsky found that it is devastatingly simple to exhaust all those possibilities in a very short amount of time by performing an attack in a certain way. How short? Well, British DNS researcher John Dickinson did some tests and found that on average he could successfully attack a server in just 1.3 seconds.

How do you fix the problem?

The sad news is there is no real solution as far as the regular DNS is concerned. It is not like a security hole in a piece of software that can be repaired with an update. This is an architectural flaw in the DNS protocol itself. There are patches for DNS software, but these only attempt to make executing an attack more difficult, they don’t solve the problem.

Some of the short term approaches to make attacks more difficult are as follows:

1. Randomise the “source port”. One of the attributes in the packet that an attacker needs to guess is called the port number. For architectural reasons, this needs to be port 53 on the way to the server — this is how the server realises it is a DNS query as opposed to a different type of query. However, the port number that a response is sent back to doesn’t need to be port 53. By randomising this, you make it harder for an attacker to guess. Much of the software updates to this problem in mid-2008 related to adding source port randomisation.
2. Block open recursive name service. If you provide access to a caching name server to the whole Internet, then it is very easy for the whole Internet to execute an attack against your server. If you limit access to just those who need it (i.e. your local network), then you reduce that risk.
3. Experimentation with capitalisation of domains. Domains in practice are not case sensitive – if you type ICANN.ORG or icann.org, it means the same thing. However, inside the DNS protocol itself, the encoded transmission between computers actually is case sensitive. This property can be used to add some more randomness to transmissions. If my computer sends off a question asking about “iCaNn.OrG” and gets back an answer for “icann.org”, it can throw it away as untrustworthy. This approach is still experimental and being discussed.

The net effect of these attempts to reduce the risk of attacks primarily involve adding more randomness for the attacker to guess. These approaches approximately double the number of “bits” of randomness. To be clear though, they only make an attack harder, but an attack is still viable. Furthermore, we know that both network speeds and computer speeds get faster and faster each year. These are the two things that slow down an attacker. Therefore, we know that successful attacks will just be easier and easier into the future.

If there is no short term solution, what is the long term solution?

While the DNS itself can’t be properly fixed for the security problem, a new protocol that overlays the DNS called DNSSEC does. DNSSEC uses a system of certification to show that a DNS answer has not been modified. If someone tries to execute an attack, the certificate won’t validate, and the incorrect answer will be thrown away.

DNSSEC is difficult to deploy. It requires upgrades in DNS servers, it changes the way domain name holders manage their name servers, and it adds extra complexity. However, with the knowledge that DNS attacks are so simple to execute without it, there is growing consensus that the pain it will take to deploy is less than the pain of a DNS that you can no longer trust.

More information

You can view the presentation slides used in Cairo.

Read Report [PDF, 1,372K]

If you want to know about cyber security for CEOs, we have the report you need.

This week the British North American Committee released “Cyber Attack: A Risk Management Primer for CEOs and Directors.” [PDF, 1,372K] ICANN CEO Paul Twomey was a key architect of the report.

One thing is clear — every business, every government, every organization that uses the Internet in its day-to-day operations is vulnerable. Simply put, cyber security is no longer “one for the IT department.” Just as CEOs and Directors are responsible for ensuring that their Chief Financial Officers manage funds properly, they must now satisfy themselves that the Chief Information Officer has taken steps to safeguard the organization’s resources.

The British North American Committee (BNAC) is made up of business, labor, and academia leaders in the UK, US, and Canada who are committed to harmonious, constructive relations among their countries and their citizens. It meets regularly to discuss common concerns with invited experts and senior policymakers in an off-the-record setting, and its regular research and publishing program seeks to discover and disseminate potential solutions.

Both BNAC and ICANN want to hear your thoughts on cyber security, especially in the business environment. Please share those thoughts on this blog, along with any ideas you think will help counter cyber warfare and cyber predation.