TDL4 (TDSS family) Rootkit

TDL4 (TDSS family) Rootkit:

Q1 2011 was the most active first quarter in malware history. One of the dangerous one is TDL4, it's claimed to support all versions of Microsoft Windows, since XP including Windows 7 sp1, inclusive, and supports both x86 and AMD64 (EM64T).
TDL4 (Alurion ???) is the fourth generation of the TDSS Rootkit which hides itself on a system by infecting system files/drivers like atapi.sys, a common target because it loads early during the boot process and is difficult to detect. Newer variants, however, can target a number of other legitimate drivers in the Windows drivers folder and the Master Boot Record (MBR). Common symptoms/signs of this infection include:
• Google search results redirected as the malware modifies DNS query results.
• Infected (patched/forged) files in the Windows drivers folder.
• Infected Master Boot Record.
• Slowness of the computer and poor performance.
• Fake alerts indicating the computer is infected.
• Internet Explorer opening on its own.
• BSODs as described in this article.
The TDSS botnet, now in its 4th generation, is seriously sophisticated malware. The first response of the root kit’s authors to Microsoft's KB2506014 patch of a couple of weeks ago. This is a game of move and counter-move, and the latest development is not unexpected. The people who work on this root kit aren't going to give up, and they are technically extremely capable. This one will run and run ... and the rest of us just have to hope that TDL4 stays away from our system, because the only sure way to get rid of it is to take out your hard drive and drop it down a very deep hole. hmm.. As part of information security team I shouldn’t say this 

A brand new plug-in for TDL4 kad.dll (Win32/Olmarik.AVA) implements a particularly interesting network communication protocol. Kad.dll is intended to be injected into the 32-bit svchost.exe process. The main purpose of the module is to download and execute other malicious software on the infected system. Although there is nothing new in its functionality it differs drastically from cmd32.dll and cmd64.dll in the way it receives commands and additional modules. In contrast to other known plug-ins obtaining bot instructions from C&C servers listed in a configuration file, kad.dll relies on a P2P (Peer to Peer) network generated by other bots. It is the Kademilia Distributed Hash Table (DHT) P2P protocol which kad.dll implements in order to talk with peers over the network. In contrast to a Client-Server architecture where there is a list of dedicated C&C (Command and Control) servers that the bots should talk to, in a P2P network all the peers are equivalent: that is. each node is a C&C server and a bot at the same time. As there is no single point from which bots in a P2P bot network are coordinated , such botnets are much more resistant to takedowns than Client-Server botnets.
The Kad-protocol is a kind of DHT protocol where the information is stored as a (key, value) pair. The key is an MD4 hash of value which could be a file or a keyword (part of the file name) or a node ID. The resulting hash table is distributed between the peers. Communication between peers is performed over the TCP and UDP protocols. TCP is used to transmit a file from one node to another, while UDP is used to search files and other peers in the P2P network.
The plug-in stores the list of neighboring nodes in the nodes.dat file in TDL4’s hidden file system, which it also downloads from C&C.
McAfee Labs is now at the point where it claims to detect more than 110,000 new unique rootkits per quarter(Source: http://blogs.mcafee.com/mcafee-labs/the-new-reality-of-stealth-crimeware).
Countries with the Highest Zombie Populations in May 2011: (Source: http://blogs.mcafee.com/consumer/family-safety/dont-become-a-zombie-be-wary-of-unsolicited-emails-and-attachments-mcafee-warns)
1. India
2. Russia
3. Brazil
4. Indonesia
5. Belarus
There are some common symptoms of an infected device:
• The device is running sluggish
• Unusual activity at startup
• Internet security or virus detection software disabled
• You get e-mails from auto responders that the recipient is not online or on vacation, but you do not know the recipient
• Number of tasks running on the computer exceeds what should be running
• The device running at or near capacity

Tips to Avoid Becoming a Victim:

1. Never download or click anything from an unknown source. If you really think your friend is sending you a video clip or an electronic greeting card, double-check with the friend to be sure before you click on the link.
2. Before clicking on any links related to the news, check to see that the address is going to a well-established site. If it is a shortened URL, use a URL preview tool such as http://hugeurl.com/, to make sure it is safe to click on.
3. Buy consumer security software from a reputable, well known vendor, such as McAfee, and make sure the suite includes anti-virus, anti-spyware, anti-spam, anti-phishing, a two-way firewall, and a website safety advisor to stay protected against newly discovered malware and spam. Run the software EVERY DAY (not weekly or monthly) to make sure your machine is clear of malware.

Sources:

http://www.virus2remove.com/2011/06/tdl-tracking-peer-pressure/
http://www.virus2remove.com/2011/06/tdss-botnets-kademilia-and-collective-consciousness/
http://blogs.mcafee.com/consumer/family-safety/dont-become-a-zombie-be-wary-of-unsolicited-emails-and-attachments-mcafee-warns
http://blogs.mcafee.com/mcafee-labs/the-new-reality-of-stealth-crimeware
http://blogs.mcafee.com/mcafee-labs/memory-forging-attempt-by-a-rootkit
http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Win32%2fAlureon
http://www.dataprotectioncenter.com/antivirus/kaspersky/tdss-loader-now-got-legs/
http://www.dataprotectioncenter.com/antivirus/trendmicro/the-worm-the-rogue-dhcp-and-tdl4/
http://www.securelist.com/en/analysis/204792131/TDSS

Replay Attack & Its Countermeasures

Replay Attack:

A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and retransmits it, possibly as part of a masquerade attack by IP packet substitution. This attack uses a simple method of exploiting a captured packet or packets, and resends that traffic to cause unexpected results. If there is no mechanism implemented to detect such duplication of the packets/communications then the attack is successful.
The attack can be successful even if the communications channel uses encrypted channel and implements strong authentication, such as digital signing. The only thing is that in such a case the attacker doesn’t know the exact contents of the transmissions being replayed but can blindly perform the actions. Often these replay attacks will be carried out at a later time, but in some cases the replay has to be done when a legitimate client session is still valid. More sophisticated versions of this exploit may combine replay attacks with packet modification, source spoofing, or man-in-the-middle attacks. The success of this attack in any form relies on the ability of the attacker to initially capture valid transmissions to the target system, whether encryption is used or not. Common targets for the replay attack are encrypted communications channels such as IPSec tunnels or wireless encryption protocols, as well as web applications.
For example, assume that there is a web application with this vulnerability. A user called ‘Legitimate’ transferred 500 bucks to another account. If this transaction is captured by an ‘Attacker’ and he replayed the same packets again then what happens? Again 500 bucks from ‘Legitimate’ user’s account will get transferred to another account. Suppose, assume that these transactions are not protected with encryption then the ‘Attacker’ can modify the captured packets thus can transfer the amount to his account as well as can change the transfer amount. Even with or without encryption the attack is successful the only difference is if the communication/transaction is protected with encryption then the attacker can only replay the same action that the legitimate user did before.
The attacker can gain the access to a legitimate user’s session if he captures the initial requests (authentication related) of the legitimate user and replays the requests. For example, a legitimate user wants to establish a connection with the server. Server requests authentication information from legitimate user as proof of identity, which legitimate user dutifully provides; meanwhile, an attacker is eavesdropping this conversation and captures these requests made by the legitimate user. After the interchange is over, attacker connects to the server posing as legitimate user; when asked for a proof of identity, attacker replays the captured packets, which server accepts and gives access to attacker.
The combination of strong authentication and encryption defeats most spoofing and man-in-the-middle attacks when implemented correctly, but not replay attacks. For this reason, some sort of timestamp or pseudo sequence number (also known as ‘session token’) is needed in combination with the encryption and strong authentication. Commonly tools such as Tcpdump or Wireshark can be used to grab the traffic off the network, and a specialized tools such as Tcpreplay, or Aircrack in the case of wireless, can be used to test systems for this vulnerability. For web applications, another common method of testing for this weakness is to use a web proxy such as WebScarab or Fiddler to capture the HTTP requests and also to replay them to the server.

Countermeasures:

Session Tokens: A pseudo random token should be issued to the user when the request come from a legitimate user then this session token has to be submitted by the user whenever he sends the subsequent request thus the server can cross check this session token with the token stored at server side. These tokens should be chosen by a (pseudo-) random process and must be changed for every action performed by the user. For example, create a random token in page load, protect it with encryption/hash and send/store it at client (like in the form of acookie). So, whenever the client sends another request like submission of the data then cross check the token with the stored token at server side.
Timestamps: This is another way of preventing a replay attack, in this synchronization of the time should be achieved using a secure protocol. For example server periodically broadcasts the time on its clock together with a MAC. When user wants to send a request to the server, he includes his best estimate of the time on his clock in his request, which is also authenticated. Server only accepts requests for which the timestamp is within a reasonable tolerance. The advantage of this scheme is that server does not need to generate random numbers/ session tokens.
Limit the session time: Enforce session time limits to invalidate state information and session IDs after a certain period of inactivity (10 minutes, for example) or a set period of time (perhaps 30 minutes). This actually limits the interval time for attack.
Deny concurrent logins: Disallow users from having multiple, concurrent authenticated sessions to the application. This could prevent malicious users from hijacking or guessing valid session IDs.

References:

http://www.sans.org/resources/security_plus/replay_attack_sp08.php
http://www.reference.com/browse/wiki/Replay_attack