New attack vector in DDoS observed

[+] Post Title :

New attack vector in DDoS observed

[+] Date : Rabu, 25 Januari 2012
[+] Author : Dr. Cruzz
[+] Link : https://xcruzz.blogspot.com/2012/01/new-attack-vector-in-ddos-observed.html
[+] Type : Tutorial

This arti­cle is a result of the com­mon research of Jakub Alimov from the Sez​nam​.cz and minor from Zone​-​h​.org. If you have any­thing to say about this, write to com­ments [a} zone-h{dot]org. The topic was pre­sented at the SPI con­fer­ence in Brno/​CZ.

While pro­tect­ing the users from receiv­ing a huge amount of the unso­licited bulk mail, a new attack­ing sce­nario against the DNS servers was observed. The sce­nario involves send­ing the spam mes­sages to the SMTP ser­vices with a big band­width. Since such ser­vices are mostly the free email ser­vices such as Google, Yahoo, Hot­mail, etc, they are the main can­di­dates to be a “white horse”. But because of the SMTP def­i­n­i­tion, all the SMTP ser­vices have to behave on the same way, there­fore they are also poten­tial candidates.

The prob­lem of the mis­use of the email sys­tem for send­ing the unso­licited bulk mes­sages (spam) is in the focus for more than 20 years. As the pro­tec­tive coun­ter­mea­sures are devel­oped, the tech­niques of the spam­mers are being more and more sophis­ti­cated. Nowa­days the pro­tec­tive meth­ods involve:

• IP/​Host blacklist
• Sender/sender’s domain checking
• SMTP compliance
• Con­tent checking
• Attach­ment checking
• Bayesian filters
• Triplet check­ing (IP address, sender, receiver)
• Other methods

These meth­ods are imple­mented on the var­i­ous stages of the e-​mail han­dling. Although the deci­sion process is not sim­ple, the most impor­tant is to deliver all the “ham” mes­sages. Spam­mers are using nowa­days much more pre­cise ways to ensure their spam mes­sages will be accepted. As from our obser­va­tion, the spam­mers are focused on the qual­ity of the spam mes­sage. We will shortly focus on the method, where the sender’s domain is checked. This is described in the sec­tion 3.6 of the RFC2821 ^[6] that is deal­ing with the SMTP.

When SMTP con­nec­tion is made, the sender has to spec­ify it’s domain at least in the MAIL FROM com­mand that is made. Accord­ing to the RFC 2821: “Only resolv­able, fully-​qualified, domain names (FQDNs) are per­mit­ted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as dis­cussed in sec­tion 5) are per­mit­ted, as are CNAME RRs whose tar­gets can be resolved, in turn, to MX or A RRs. Local nick­names or unqual­i­fied names MUST NOT be used.”

Also Denial of ser­vice attacks on the DNS servers are noth­ing new, we would like to remind on some of the well known attacks on the root servers; first big attack hap­pened on Octo­ber 21^st 2002 ^[1], where all 13 root servers were simul­ta­ne­ously attacked by means of a dis­trib­uted denial of ser­vice attack, par­tic­u­larly by send­ing exces­sive amount of the traf­fic con­tain­ing the ICMP data, TCP SYN, frag­mented TCP data and UDP data. The sec­ond big attack hap­pened in Feb­ru­ary 2007 ^[2], as reported by the ICANN, at least 6 root servers were the sub­ject of the Denial of ser­vice attack, and the attack­ing force was a bot­net. More insight into this attack was brought by John Kristoff ^[3], who tried to explain real facts, as he wrote in his pre­sen­ta­tion: “Even the ICANN ‘fact sheet’ was impre­cise on: Who exactly got hit, the attack dura­tion and start/​stop times, the packet-​level detail”. One of the most impor­tant infor­ma­tion in his pre­sen­ta­tion is the num­ber of the attack­ing bots. Kristoff claims, the attack was per­formed with 4000 – 5000 bots cre­ated from infected com­put­ers run­ning Microsoft Windows.

Yet another inter­est­ing Denial of ser­vice attack against the DNS servers hap­pened in the Feb­ru­ary 2006 ^[4], accord­ing to the offi­cial release from the ICANN SSAC, this was the case of the DNS ampli­fi­ca­tion attack with spoofed source IP addresses.

The attack we observed and analysed com­bines the fea­tures of pre­vi­ously known Denial of ser­vice attacks with the mis­use of the pro­tec­tive means and spam­ming tech­nique. We have to men­tion also the lack of will­ing­ness and very slow approach from the Inter­net reg­is­tra­tion author­i­ties when fight­ing with a cyber crime and other process related prob­lems that make this kind of attack possible.

1. Denial of Ser­vice attacks against DNS servers using the white horses

The Denial of Ser­vice attacks in years 2002, 2006 and 2007 that we men­tioned in the intro­duc­tion were per­formed on a large scale. Fol­low­ing sce­nario con­sid­ers that a sin­gle pre-​registered domain is used. To per­form the Denial of Ser­vice attack using white horse sys­tems fol­low­ing means are necessary:

• Spam bot­net – dur­ing our obser­va­tion we recorded about 14.000 unique IP addresses appar­ently belong­ing to a sin­gle botnet.
• Pre-​registered domain – it is nec­es­sary to have a pos­si­bil­ity to man­age the domain records, but this fea­ture is often offered by the providers/​resellers.

The attack phases are as follows:

1. The attacker obtains the IP address /​host­name of the tar­get DNS server.
2. The attacker updates the NS records of the pre-​registered domain foo​-domain​.com with the IP address /​host­name of the tar­get DNS server. Some reg­is­trars or host­ing providers do not pro­vide this func­tion­al­ity, many other do. There are known host­ing com­pa­nies and ISP that are sup­port­ing the spam ^[5]. After the NS records update the attacker waits at least 24 hours until the new records are prop­a­gated all over the Internet.
3. Now the attacker pre­pares a spam cam­paign. There are few aspects to note: as first, the sender mail address for the MAIL FROM can con­tain the same user name, but the sub­do­main — 3^rd level domain must vary per each spam mes­sage (for exam­ple first spam mes­sage has the sender james@​subdom1​.​foo-​domain.​com but the sec­ond sender has to be james@​subdom2​.​foo-​domain.​com).
4. The sec­ond impor­tant aspect is the selec­tion of the white horse sys­tems. White horse sys­tems are the SMTP incom­ing mail servers with a high bandwidth.
5. Once the spam cam­paign has been started to the white horse sys­tems using the spam bot­net, these sys­tems check on the back­ground 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 tar­get DNS server, the DNS requests will be per­formed to the tar­get DNS server.
6. Tar­get DNS server receives mul­ti­ple reg­u­lar DNS requests for the bogus sub­do­main records(note that in the pre­vi­ous Denial of Ser­vice attacks against the DNS servers received either mal­formed, frag­mented, ICMP mes­sages or TCP SYN, with invalid length, or over­sized and some of these can be fil­tered by the fire­walls or secu­rity appli­ances). Since the DNS server does not have the records for the foo​-domain​.com, it has to respond neg­a­tively to the request. If the spam cam­paign is suc­cess­ful, the white horse sys­tems flood the DNS server with mul­ti­ple valid DNS requests. The attack schemat­ics are shown in the Fig­ure 1.
   
   
   
   Fig­ure 1: Exam­ple of a figure.
   As we already wrote in this paper, the num­ber of recorded bots dur­ing the attack obser­va­tion was about 14.000 with more than 100.000 spam mes­sages. The tar­get was just one DNS server and only one pre-​registered domain was used. The white horse sys­tems were able to dis­rupt the DNS server oper­a­tion for more than one day and the effi­ciency of such attack was very high. It is not pos­si­ble to use the IP spoof­ing in this kind of the attack because the bot­net has to make a proper SMTP com­mu­ni­ca­tion to the white horse systems.
   This kind of the Denial of ser­vice attack has many advan­tages from the attacker point of view. Tra­di­tional meth­ods of the flood­ing can be fil­tered by the fire­walls, UTM boxes or even at ISP level, mak­ing the attack weaker. But fire­walls and other secu­rity appli­ances can­not block a valid DNS requests even for a bogus domain and sub­do­main. Among other advan­tages, these are of a sig­nif­i­cant meaning:
7. The bot­net is not attack­ing directly and attack might look like a “com­mon” spam cam­paign. Real inten­tions might be hid­den unless a proper analy­sis of the spam cam­paign and its impact will be evaluated.
8. Because of the SMTP nature all SMTP servers might become the white horses.
9. This attack can be ampli­fied by using more than one pre-​registered domain. If all the pre-​registered domains will have the same NS record con­fig­ured, this will extend the attack dura­tion time or its strength.
10. The attack source on the tar­get will bring the con­fu­sion – white horse sys­tem in this attack method are con­sid­ered as the servers with a high reputation.
11. Not only a bot­net must be involved – any sys­tem that is able to send spam mes­sages (for exam­ple, vul­ner­a­ble webap­pli­ca­tion) can par­tic­i­pate on this attack.
12. If the spam cam­paign will be suc­cess­ful and the spam mes­sages arrive to the user mail­boxes, it can bring “dou­ble sat­is­fac­tion” to the attacker.

This attack has also some dis­ad­van­tages; we would like to men­tion a longer plan­ning and deep analy­sis of the white horse sys­tem before the attack is launched. There­fore this attack method is not suit­able for the small tar­gets. Also the pre-​registered domain can be soon black­listed, there­fore using one pre-​registered domain can bring only a short effect.

2. Com­bi­na­tion of the old and new attack methods

As described above, this attack method can be very effec­tive when using mul­ti­ple pre-​registered domains and com­bin­ing the spam mes­sage sender and orig­i­nat­ing sys­tem. Since the bot­net can be used to a var­i­ous tasks, the attacker has the pos­si­bil­ity to com­bine pre­vi­ously known attack meth­ods with the new approach. Attack­ing the big­ger tar­gets, for exam­ple the root servers, can require a high demand for the band­width. The bot­net itself must not be enough suf­fi­cient to dis­rupt the oper­a­tion, because it is lim­ited by the client con­nec­tiv­ity. The white horse sys­tems have a very good band­width because of their func­tion as the MX sys­tems. The Denial of Ser­vice attack per­formed with fol­low­ing sce­nario could be suc­cess­ful in attack­ing the root servers:

• The attacker will pre­pare many bogus domains and a mas­sive spam campaign
• Bot­net of more than 50.000 bots will send the spam mes­sages to more than 100 white horse sys­tems with good band­width and on the same time cause the DNS flood­ing by means of send­ing ICMP mes­sages, TCP SYN, or even per­form­ing a ran­dom DNS queries on the server to keep it busy. Num­ber of the spam mes­sages being sent for each domain can be sim­ply cal­cu­lated as [bot­net count]x[white horse sys­tems count], when con­sid­er­ing that each bot sends just one mes­sage per white horse system.
• By care­ful obser­va­tion what domains were already black­listed on which SMTP server, the attacker can change the sender’s domain in the spam cam­paign and con­tinue, the white horse sys­tems will again per­form queries for another domain and con­tinue the flood with the DNS requests. On the same time still the bot­net will per­form the DNS flood­ing. With each domain the tar­get sub­ject can be changed to affect as much tar­gets as possible.

3. Pos­si­ble countermeasures

While research­ing for any pro­tec­tive coun­ter­mea­sures against this attack method, we were suc­cess­ful to find a solu­tion block­ing the DNS flood­ing as it was per­formed in the year 2006 or 2007. Unfor­tu­nately there is no strat­egy avail­able to mit­i­gate the sole DoS attack via white horse systems.

We were con­sid­er­ing the mod­i­fi­ca­tion of the black­list­ing method but this could cause that a sin­gle domain is black­listed com­pletely. Another solu­tion could be the domain rep­u­ta­tion sys­tem, where only allowed domains could send e-​mail mes­sages. The process and the eval­u­a­tion would be very complicated.

The only viable solu­tions as we see it from our point of view are

• to tighten the rules when reg­is­ter­ing the domains. Cur­rent sit­u­a­tion allows var­i­ous crim­i­nal activ­i­ties where domains are mis­used: start­ing from the cyber squat­ting, huge vol­ume domain reselling, pre-​registering the domains for the spam pur­poses and other.
• to update the stan­dards for SMTP and DNS, as it has to reflect this kind of the attack.

As a pos­si­ble solu­tions we can con­sider the use of the faster imple­men­ta­tion of a DNS server or putting the DNS server into the cloud, but these solu­tions are not suit­able for every DNS server.

4. Con­clu­sions

We described above a new way of the Denial of Ser­vice attack. We do believe this method of the attack poses an increased risk to all the DNS servers as there are no pro­tec­tive coun­ter­mea­sures avail­able. The seri­ous­ness of the sit­u­a­tion is under­lined with the fact that this kind of attack was observed on the Inter­net 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 com­mu­nity of the secu­rity researchers is strong enough (even often filled with unhealthy com­pe­ti­tion) and proper solu­tion will be avail­able soon. Any­way, we would like to use this paper and issue a call to the emer­gency response teams around the world as well as their coor­di­nat­ing orga­ni­za­tion FIRST (as they will have to han­dle such kind of the attack) to cre­ate strong pres­sure on the Inter­net author­i­ties to finally stop the cyber crim­i­nal busi­ness with the domains. We all should have a com­mon tar­get – to make the Inter­net be a safer place.

At this time, we are estab­lish­ing the team of researchers will­ing to par­tic­i­pate in the pos­si­ble solu­tions. If you want to join us, write to minor[at}zone-h{dot]org .

Ref­er­ences

1. http://c.root-servers.org/october21.txt
2. http://​www​.icann​.org/​e​n​/​a​n​n​o​u​n​c​e​m​e​n​t​s​/​f​a​c​t​s​h​e​e​t​-​d​n​s​-​a​t​t​a​c​k​-​0​8​m​a​r​0​7​_​v​1​.​1.pdf
3. https://​www​.dns​-oarc​.net/​f​i​l​e​s​/​d​n​s​o​p​s​-​2​0​0​7​/​K​r​i​s​t​o​f​f​-​F​e​b​0​7​-​a​t​t​a​c​k​s.pdf
4. http://​www​.icann​.org/​e​n​/​c​o​m​m​i​t​t​e​e​s​/​s​e​c​u​r​i​t​y​/​d​n​s​-​d​d​o​s​-​a​d​v​i​s​o​r​y​-​3​1​m​a​r​0​6.pdf
5. http://​www​.spamhaus​.org/​s​t​a​t​i​s​t​i​c​s​/​n​e​t​w​o​r​k​s​.​lasso
6. http://​www​.apps​.ietf​.org/​r​f​c​/​r​f​c​2​8​2​1​.html