The problem of the misuse of the email system for sending the unsolicited bulk messages (spam) is in the focus for more than 20 years. As the protective countermeasures are developed, the techniques of the spammers are being more and more sophisticated. Nowadays the protective methods involve:
IP/Host blacklist
Sender/sender’s domain checking
SMTP compliance
Content checking
Attachment checking
Bayesian filters
Triplet checking (IP address, sender, receiver)
Other methods
These methods are implemented on the various stages of the e-mail handling. Although the decision process is not simple, the most important is to deliver all the “ham” messages. Spammers are using nowadays much more precise ways to ensure their spam messages will be accepted. As from our observation, the spammers are focused on the quality of the spam message. We will shortly focus on the method, where the sender’s domain is checked. This is described in the section 3.6 of the RFC2821 [6] that is dealing with the SMTP.
When SMTP connection is made, the sender has to specify it’s domain at least in the MAIL FROM command that is made. According to the RFC 2821: “Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs. Local nicknames or unqualified names MUST NOT be used.”
Also Denial of service attacks on the DNS servers are nothing new, we would like to remind on some of the well known attacks on the root servers; first big attack happened on October 21st 2002 [1], where all 13 root servers were simultaneously attacked by means of a distributed denial of service attack, particularly by sending excessive amount of the traffic containing the ICMP data, TCP SYN, fragmented TCP data and UDP data. The second big attack happened in February 2007 [2], as reported by the ICANN, at least 6 root servers were the subject of the Denial of service attack, and the attacking force was a botnet. More insight into this attack was brought by John Kristoff [3], who tried to explain real facts, as he wrote in his presentation: “Even the ICANN ‘fact sheet’ was imprecise on: Who exactly got hit, the attack duration and start/stop times, the packet-level detail”. One of the most important information in his presentation is the number of the attacking bots. Kristoff claims, the attack was performed with 4000 – 5000 bots created from infected computers running Microsoft Windows.
Yet another interesting Denial of service attack against the DNS servers happened in the February 2006 [4], according to the official release from the ICANN SSAC, this was the case of the DNS amplification attack with spoofed source IP addresses.
The attack we observed and analysed combines the features of previously known Denial of service attacks with the misuse of the protective means and spamming technique. We have to mention also the lack of willingness and very slow approach from the Internet registration authorities when fighting with a cyber crime and other process related problems that make this kind of attack possible.
Denial of Service attacks against DNS servers using the white horses
The Denial of Service attacks in years 2002, 2006 and 2007 that we mentioned in the introduction were performed on a large scale. Following scenario considers that a single pre-registered domain is used. To perform the Denial of Service attack using white horse systems following means are necessary:
Spam botnet – during our observation we recorded about 14.000 unique IP addresses apparently belonging to a single botnet.
Pre-registered domain – it is necessary to have a possibility to manage the domain records, but this feature is often offered by the providers/resellers.
The attack phases are as follows:
The attacker obtains the IP address /hostname of the target DNS server.
The attacker updates the NS records of the pre-registered domain foo-domain.com with the IP address /hostname of the target DNS server. Some registrars or hosting providers do not provide this functionality, many other do. There are known hosting companies and ISP that are supporting the spam [5]. After the NS records update the attacker waits at least 24 hours until the new records are propagated all over the Internet.
Now the attacker prepares a spam campaign. There are few aspects to note: as first, the sender mail address for the MAIL FROM can contain the same user name, but the subdomain — 3rd level domain must vary per each spam message (for example first spam message has the sender james@subdom1.foo-domain.com but the second sender has to be james@subdom2.foo-domain.com).
The second important aspect is the selection of the white horse systems. White horse systems are the SMTP incoming mail servers with a high bandwidth.
Once the spam campaign has been started to the white horse systems using the spam botnet, these systems check on the background whether the sender’s domain resolves to the domain MX or at least to an A record. Since the NS record is set to the target DNS server, the DNS requests will be performed to the target DNS server.
Target DNS server receives multiple regular DNS requests for the bogus subdomain records(note that in the previous Denial of Service attacks against the DNS servers received either malformed, fragmented, ICMP messages or TCP SYN, with invalid length, or oversized and some of these can be filtered by the firewalls or security appliances). Since the DNS server does not have the records for the foo-domain.com, it has to respond negatively to the request. If the spam campaign is successful, the white horse systems flood the DNS server with multiple valid DNS requests. The attack schematics are shown in the Figure 1.
Figure 1: Example of a figure.
As we already wrote in this paper, the number of recorded bots during the attack observation was about 14.000 with more than 100.000 spam messages. The target was just one DNS server and only one pre-registered domain was used. The white horse systems were able to disrupt the DNS server operation for more than one day and the efficiency of such attack was very high. It is not possible to use the IP spoofing in this kind of the attack because the botnet has to make a proper SMTP communication to the white horse systems.
This kind of the Denial of service attack has many advantages from the attacker point of view. Traditional methods of the flooding can be filtered by the firewalls, UTM boxes or even at ISP level, making the attack weaker. But firewalls and other security appliances cannot block a valid DNS requests even for a bogus domain and subdomain. Among other advantages, these are of a significant meaning:
The botnet is not attacking directly and attack might look like a “common” spam campaign. Real intentions might be hidden unless a proper analysis of the spam campaign and its impact will be evaluated.
Because of the SMTP nature all SMTP servers might become the white horses.
This attack can be amplified by using more than one pre-registered domain. If all the pre-registered domains will have the same NS record configured, this will extend the attack duration time or its strength.
The attack source on the target will bring the confusion – white horse system in this attack method are considered as the servers with a high reputation.
Not only a botnet must be involved – any system that is able to send spam messages (for example, vulnerable webapplication) can participate on this attack.
If the spam campaign will be successful and the spam messages arrive to the user mailboxes, it can bring “double satisfaction” to the attacker.
This attack has also some disadvantages; we would like to mention a longer planning and deep analysis of the white horse system before the attack is launched. Therefore this attack method is not suitable for the small targets. Also the pre-registered domain can be soon blacklisted, therefore using one pre-registered domain can bring only a short effect.
Combination of the old and new attack methods
As described above, this attack method can be very effective when using multiple pre-registered domains and combining the spam message sender and originating system. Since the botnet can be used to a various tasks, the attacker has the possibility to combine previously known attack methods with the new approach. Attacking the bigger targets, for example the root servers, can require a high demand for the bandwidth. The botnet itself must not be enough sufficient to disrupt the operation, because it is limited by the client connectivity. The white horse systems have a very good bandwidth because of their function as the MX systems. The Denial of Service attack performed with following scenario could be successful in attacking the root servers:
The attacker will prepare many bogus domains and a massive spam campaign
Botnet of more than 50.000 bots will send the spam messages to more than 100 white horse systems with good bandwidth and on the same time cause the DNS flooding by means of sending ICMP messages, TCP SYN, or even performing a random DNS queries on the server to keep it busy. Number of the spam messages being sent for each domain can be simply calculated as [botnet count]x[white horse systems count], when considering that each bot sends just one message per white horse system.
By careful observation what domains were already blacklisted on which SMTP server, the attacker can change the sender’s domain in the spam campaign and continue, the white horse systems will again perform queries for another domain and continue the flood with the DNS requests. On the same time still the botnet will perform the DNS flooding. With each domain the target subject can be changed to affect as much targets as possible.
Possible countermeasures
While researching for any protective countermeasures against this attack method, we were successful to find a solution blocking the DNS flooding as it was performed in the year 2006 or 2007. Unfortunately there is no strategy available to mitigate the sole DoS attack via white horse systems.
We were considering the modification of the blacklisting method but this could cause that a single domain is blacklisted completely. Another solution could be the domain reputation system, where only allowed domains could send e-mail messages. The process and the evaluation would be very complicated.
The only viable solutions as we see it from our point of view are
to tighten the rules when registering the domains. Current situation allows various criminal activities where domains are misused: starting from the cyber squatting, huge volume domain reselling, pre-registering the domains for the spam purposes and other.
to update the standards for SMTP and DNS, as it has to reflect this kind of the attack.
As a possible solutions we can consider the use of the faster implementation of a DNS server or putting the DNS server into the cloud, but these solutions are not suitable for every DNS server.
Conclusions
We described above a new way of the Denial of Service attack. We do believe this method of the attack poses an increased risk to all the DNS servers as there are no protective countermeasures available. The seriousness of the situation is underlined with the fact that this kind of attack was observed on the Internet as fully working.
There is also a place to overview the RFC2821 as it does not reflect this kind of the attack. We do hope, that the community of the security researchers is strong enough (even often filled with unhealthy competition) and proper solution will be available soon. Anyway, we would like to use this paper and issue a call to the emergency response teams around the world as well as their coordinating organization FIRST (as they will have to handle such kind of the attack) to create strong pressure on the Internet authorities to finally stop the cyber criminal business with the domains. We all should have a common target – to make the Internet be a safer place.
At this time, we are establishing the team of researchers willing to participate in the possible solutions. If you want to join us, write to minor[at}zone-h{dot]org .
No comments:
Post a Comment