Archive for the ‘Exploit’ Category
Tuesday, January 19th, 2010
In an early-2009 literary flourish we condemned spammers to hell, discussed the Tedroo spambot’s increased momentum due to the shutdown of other botnets, posted screenshots of the Tedroo spewed pharmaceutical spam and related scam sites, and noted its distribution via malicious pdf files. Tedroo’s increased presence and its distribution is continuing into 2010. As a matter of fact, while the distributors are relying on users’ delays in updating their vulnerable pdf readers like Acrobat, the distributors are actively maintaining/modifying the bot itself — AV scanner results on the repacked binaries are very low as the modified variants are newly re-released.
Vulnerable systems with out-of-date Adobe Acrobat installs are the main focus of the attacks involving the Tedroo spambot. The spambot commonly is being distributed via a set of canned attacks using what appears to be a version of the Liberty Exploit kit. The Liberty pack maintains an effective set of Acrobat attacks, and considering the thousands of Acrobat attacks prevented on ThreatFire systems since the beginning of Jan, the attacks themselves are well chosen — vulnerable versions of Acrobat Reader continue to be readily available, even in this new decade.
Once the malformed pdf’s shellcode is passed control on a victim system, it attempts to download multiple components from another server. In our samples, a system hosted in China. There are several downloads to choose from on the server. The first of the files is a loader, carrying a packing stub somewhat similar to the recent Bredolab packed malware with an outer layer of encryption on top of a UPX packed inner layer. It drops a dll to an alternate data stream of a random file in the windows or system32 directory. It then registers that ADS in the AppInit_DLLs so that the dll is loaded at startup. The dll is loaded, and maintains a long list of paths and executables. Most are related to security solutions (examples are listed below) and system components. It terminates a group of them immediately. It then adds entries for security software to the Restricted Software Policy list in the registry, an AVKill method that we haven’t seen fully described as one elsewhere: HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Paths\<SID>
C:\Documents and Settings\All Users\Application Data\PC Tools
C:\Program Files\Common Files\PC Tools
C:\Program Files\Kaspersky Lab
C:\Documents and Settings\All Users\Application Data\Kaspersky Lab
C:\Documents and Settings\All Users\Application Data\Kaspersky Lab Setup Files
C:\Program Files\Panda Security
C:\Program Files\Norton AntiVirus
C:\Program Files\Alwil Software
With that undetected (on the day of discovery) component loaded and AV processes killed, the Tedroo spambot is loaded. In the latest loader variants associated with the bot, we observe an interesting entry point with anti-debug and anti-emulator tricks that can be vaguely described as an abuse of “Modern” CPU Instructions. In this case, the packer implements an unexpected x86 VMX instruction — VMLAUNCH. Versions of reverser-friendly Ollydbg decode it to “sgdt edx” and cannot handle the instruction at runtime, reporting to the user that it does not know how to step into it, while some vendor emulators also have a difficult time decoding it.
Windbg, on the other hand, decodes the vmlaunch command properly as specified by the Intel Reference material, seen below…
Following the malware entrypoint, a windbg deadlisting shows “mov ecx, 0×4fffh”, followed by the vmlaunch. On processors we observed, this setup thows an exception for an Illegal Instruction with ecx = 0×4fffh. The writers of this trick, however, took it upon themselves to force the code to trigger this exception 20,479 times (the decimal representation of 0×4fffh). It’s implemented by registering an SEH pointer to code that simply stores the counter, decrements it, and returns back into the ExcecuteHandler2 function within ntdll that’s within the standard flow of Windows exception handling. Each time, the exception “handler” code returns back into RtlDispatchException and eventually NtContinue, where CONTEXT.eip takes control directly back to the Illegal Instruction location, triggering yet another exception. When the counter finally is decremented to zero, the unpacking stub then modifies CONTEXT.eip on the stack so that flow passes out of this exception loop at ntdll.NtContinue and further into its unpacking stub. Tricky stuff indeed.
Decrement ecx value within the process CONTEXT struct
Continuing on its code path, the code first checks if it’s been run before on the victim system, looking for registry values it creates:
value: userini path: c:\windows\explorer.exe:userini.exe
It copies itself as an alternate data stream of explorer.exe
It sets this ADS to load at startup in the various autorun registry entries listed above, and then runs thru a series of sleeps/gettickcout to delay activity and cloak itself.
After a long wait, the spambot calls InternetConnectA and HttpOpenRequestA to contact its hardcoded server and retrieves more spam templates. The resulting spam recently has all led to www . pharm directbook .com, another ”Canadian Pharmacy #1 Internet Online Drugstore”. This behavior is similar to that noted in our past post. The sites have been run for years by a group otherwise known as “Glavmed“, selling knockoff, illegal pills with shifty names like “Viagra Professional”…
In spite of the significant shutdowns over the past year, spam like Tedroo’s continues to mess it all up on the net. Don John couldn’t have tried to mess up a good thing any better himself.
Tuesday, January 5th, 2010
There is an infinite number of ways to calculate 2010, here is a fairly fun list of some of them.
The past year showed massive numbers of malware being run on systems across the globe. Behind the malware was an active malware marketplace, often with forums full of services for hire, advice on distributing and maintaining crimeware, and devious ways to hire money-mules.
There is more than meets the eye to these services. Much of the activity was not being discussed in these public forums or was as front and center in the media as the Conficker circus. While bot activity is not new to the party, a recently published study “SBotMiner: Large Scale Search Bot Detection“ brings in the year with a fresh start on identifying and quantifying malicious search bot traffic. The activity is under-studied and significant: the “miner” identified that almost 4% of all query traffic is bot-related (which represents at least hundreds of millions of search queries every couple of months), and that seems to be only the tip of the iceberg. The traffic was collected in Feb and April 2009, the search engine is not specified (google, yahoo!, live, altavista, ask, etc.) and that selection may have impacted the studies’ volumes and results. It is suggested that Live search results were used, so results most likely are much larger when the other engines are considered. The study also includes more forms of bot-based attacker-related traffic, instead of exclusively examining click fraud related bot queries and activity.
The discussion and findings included:
“More importantly, detecting bot-generated search traffic has profound implications for the ongoing arms race of network security. While many bot queries from individual hosts may be legitimate (e.g., academic crawling of specific Web pages), a significant fraction of bot search traffic is associated with malicious attacks at different phases. In addition to the well known click-fraud attacks that can be commonly observed in query logs, attackers also use search engines to find Web sites with vulnerabilities, to harvest email addresses for spamming, or to search well-known blacklists.”
“Attackers are leveraging search engines for exploiting vulnerabilities of Web sites. SBotMiner Identifies 88K searchbot groups searching for various PHP scripts and ASP scripts.”
“Using the entire datasets, SBotMiner detects 8,678 groups searching for PHP scripts in Feb and 79,337 such groups in April; 64 groups searching for ASP scripts in Feb and 301 groups in April. These searches spread all over the world.”
“Initial evidence shows that many of them might be associated with various forms of malicious activities such as phishing attacks, searching for vulnerabilities and spamming targets, or checking blacklists. Interestingly, attacks from different countries and regions do exhibit distinct characteristics, and search bots from countries with high bandwidth Internet access are more likely to be aggressive in submitting more queries.”
“We used sampled query logs collected in two different months and identified 700K bot groups with more than 123 million pageviews involved. The percentage of bot traffic is non-trivial — accounting for 3.8% of total traffic”
So how might this effect you, dear reader? Well, 2010 already brings with it more publicly available information on the methods being used to harvest information about you, the blackhat Seo that these groups are increasingly relying on and the means in which these groups attempt to identify vulnerable servers to attack and use, in turn, to attack your system. It’s a fine read with some fresh information and an enjoyable way to settle into the New Year.
Monday, September 14th, 2009
ThreatFire continues to prevent high levels of activity from the Bredolab downloaders this week. The ongoing spam activity described several weeks ago is not abating. Our research then began to pry into the several kernel level hook overwrite attempts that Bredolab implements with the end goal of evading behavioral based security products. ThreatFire effectively prevents this malware, while other behavioral based products do not seem to perform quite so well, their kernel mode hooks duly overwritten and bypassed.
Two of the kernel hook overwrite attempts abuse straightforward Windows vulnerabilities, and they both have been patched. The other Bredolab hook overwrite attempt targets a mechanism that isn’t officially a vulnerability. When users are not logged in as admin, Bredolab is not effective. Here is the short list of the targeted vulnerabilities, in the order called by the Bredolab code:
1st Bredolab targeted vulnerability – MS07-017 – GDI Local Elevation of Privilege Vulnerability
2nd Bredolab targeted vulnerability- MS08-025 – Windows Kernel Usermode Callback Local Privilege Escalation Vulnerability
3rd Bredolab targeted vulnerability- Flaw allows local users with the SeDebugPrivilege privilege to execute arbitrary code as kernel
Just before exploiting the vulnerabilities to gain access to the kernel, Bredolab copies ntkrnlpa.exe from the drive to a location in virtual memory, examining the code for the addresses of nine kernel APIs that are frequently hooked by security solutions. It finds them and stores the virtual addresses for these api’s in its text section for use in the overwrites:
The first exploit attempt to overwrite security solutions’ hooks involves abusing Windows graphics functionality. After calling MapViewofFile and searching for the api’s listed above in the mapped copy of ntkrnlpa.exe, Bredolab maliciously initializes a Palette object:
Hook overwriting shellcode is delivered via a carefully crafted GetNearestPaletteIndex call:
cr0 manipulation in the shellcode to obtain write permissions on kernel memory here:
The first method will fail for Bredolab if the system is MS07-017 patched (patch your systems!). To account for that issue, Bredolab will check for the patch, and if present, deliver its next exploit.
First, it calls GetDesktopWindow to retrieve a handle to the desktop. Next, it sets up the first of two interrupt trampolines to NtUserMessageCall
After the two are setup, it then tricks ZwSetIntervalProfile to call user mode code from the kernel, passing a pointer to its hook overwrite function
Sometimes these first two exploits do not work on a system for the malware. But Bredolab arrives with a solution for that situation. When the first two are patched, Bredolab checks that its calling user has SeDebugPrivilege privilege
If SeDebugPrivilege is present, Bredolab calls ZwSystemDebugControl with two interesting parameters: Debug_Control_Code=9 and SysDbgCopyMemoryChunks_1. Providing that debug code to the call, Bredolab copies arbitrary code from user space to kernel space:
Using a bug in the read I/O sub-function of NtSystemDebugControl, not shown here, Bredolab writes to kernel memory. It modifies an IDT entry with a pointer to its malicious code, and provides control to the code by again calling ZwSetIntervalProfile.
While the bulk of the attacks appear in the U.S., outbreaks of this stuff occured the past year throughout Italy, England, Germany and Russia as well. Unfortunately, there remains large enough numbers of unpatched systems in these countries to gain these attackers’ attention.