Malware Paradox - CIA (AAVAR 2010)

13th Symposium of Association of Anti Virus Asia Researchers (AAVAR 2010) conference

View more presentations from Aditya K Sood.

Binding SpyEye (1.0.x) with BSQL Injection

This is true that "vulnerabilities die hard". Recently during the process of testing, it has been detected that some of the released versions of SpyEye starting from 1.0.x has shown an interesting weakness in the "frm_cards_edit.php" module. This PHP module is present in the main admin panel and used to manage the credentials. The "id" parameter is used with "GET" request to fetch credit card details thereby updating the database after-wards.This module is vulnerable to blind SQL injection.


$data= '"id" : "1 AND [Union SQL Poisoning Code]));-- /*"'
$encode_data= apply encoding module on $data
$http_request("GET", path + "frm_cards_edit.php?" + $encode_data )

Some of the traces of the vulnerable PHP module is presented below.

<?php
require_once 'mod_dbase.php';
require_once 'mod_time.php';
require_once 'mod_crypt.php';
require_once 'mod_file.php';
$id_card = $_GET['id']; if (!@$id_card) exit;
$dbase = db_open();if (!$dbase) exit;

$sql = ' SELECT cards.num, cards.csc, cards.exp_date, cards.name, cards.surname, cards.address, cards.city, cards.state, cards.post_code, country_t.name_country, cards.phone_num, email_t.value_email '
. ' FROM cards, country_t, email_t'
. ' WHERE cards.fk_email = email_t.id_email'
. ' AND cards.fk_country = country_t.id_country'
. " AND cards.id_card = $id_card"
. ' LIMIT 0, 1';
$res = mysqli_query ($dbase, $sql);
if ((!(@($res))) || !mysqli_num_rows($res)) {
writelog ("error.log", $sql);
db_close($dbase);
exit();
}

$res = mysqli_fetch_row($res);
list($num_card, $csc, $exp_date, $name, $surname, $address, $city, $state, $post_code, $country, $phone_num, $email) = $res;

db_close($dbase);

list($year, $month) = split('[\/.-]', $exp_date);
$res[2] = $exp_date = gmdate("m/y", gmmktime(0, 0, 0, $month, 1, $year));
$res[0] = $num = encode(base64_decode($num_card), $csc);

// labels & names
$reslb['num'] = 'Card number';
$reslb['csc'] = 'CSC';
$reslb['exp_date'] = 'Exp. date';
$reslb['name'] = 'Name';
$reslb['surname'] = 'Surname';
$reslb['address'] = 'Address';
$reslb['city'] = 'City';
$reslb['state'] = 'State';
$reslb['post_code'] = 'ZIP';
$reslb['country'] = 'Country';
$reslb['phone'] = 'Phone';
$reslb['email'] = 'E-Mail';

// lengths
$lnexp = 7;
$resln[0] = $numln = strlen($num) + $lnexp;
$resln[1] = $cscln = strlen($csc) + $lnexp;
$resln[2] = $exp_dateln = strlen($exp_date) + $lnexp;
$resln[3] = $nameln = strlen($name) + $lnexp;
$resln[4] = $surnameln = strlen($surname) + $lnexp;
$resln[5] = $addressln = strlen($address) + $lnexp;
$resln[6] = $cityln = strlen($city) + $lnexp;
$resln[7] = $stateln = strlen($state) + $lnexp;
$resln[8] = $post_codeln = strlen($post_code) + $lnexp;
$resln[9] = $countryln = strlen($country) + $lnexp;
$resln[10] = $phone_numln = strlen($phone_num) + $lnexp;
$resln[11] = $emailln = strlen($email) + $lnexp;
?>

It works efficiently in number of cases. Thanks to my team.

SpyEye's Analysis Derived from Weak Base

Recently, there has been a post at Fortinet's blog "SpyEye Exposes Mule" which reflects an example of analysis based on a weak base. It is always good to share analysis using differential information but it should have sound base. Understanding, the critical nature of SpyEye, it requires a complete understanding of malware framework. This type of analysis results in unclear information from technical perspective thereby raising complexity in real time environment. The purpose of this post is to raise a point about half flooded analysis of malware. There are lot of misleading points in this analysis as follows

"the most current version of SpyEye we could get our hands on (W32/SpyEye.C!tr.spy).

Which version of SpyEye has been analyzed? No information! Are they talking about signatures ((W32/SpyEye.C!tr.spy).)? That is complete different aspect of version information of malware.

"SpyEye connects to a “log server” that is different than the server where it fetches updates from, where fraudulent transactions done by the Trojan are logged"

Well, this is not new in the version. Further, the details of this process has been released in our previous post "SpyEye Backend Collector" This is a claim which is completely out of the analytical point of view because it requires an understanding of complete chronology of SpyEye development framework This feature was actually introduced in SpyEye version 1.0.75

The snapshots provided of the logs do not explain the real technical details of the actual nature of the attack and the outcome presented. In order to deliver information, We can explain a detailed post on it. Later on.

Further, down the blog post, it has been stated about "SpyEye Upper Limit". In general , there is no such upper limit of SpyEye. It depends on botmaster itself how he wants to design the stealer plugin considering the inherent SDK. Primarily, it is more of banking terms used in money laundering attacks. Most of the banking Trojans use same set of fake transaction strategy (mules and drops). In general, it is an uncompressed LZO log of successful infection.

It could have been better if technical details based on strong base is considered. We would like to see some more technical details as stated at the end of blog post.

Phoenix Exploit Kit (2.4) - Infection Analysis

Phoenix exploit kit is one of the best Browser Exploit Pack (BEP) in the market nowadays. Looking at the pace of development, it seems like we are going to see plethora of advancements in this BEP. In this post , we are aiming to disclose some of the findings and reviews about the latest Phoenix BEP version 2.4. Primarily, we will be talking about the following metrics in detail to discuss the impact of this BEP.

1. Exploitation Success Rate (ESR).
2. Loader Infection Success Rate (LISR).

The most critical part of testing BEP's is to determine the success rate of loading a bot or executable once the target is exploited in real time environment. This metric is quite important because number of browser exploit packs suffer from huge loss in loading activity even after the exploitation. However, many times it has been noticed that most of the statistics provided by BEP's claiming the fact that infection rate based on ESR to be thousands of machines. But the installation rate is very less. Based on our analysis, we are raising a point on the effectiveness of BEP. If the exploitation rate is high it means the BEP has to be robust enough to perform the successful installs.

A generic experiment was conducted on some of the samples of Phoenix Exploit Kit 2.x - 2.4 in a controlled environment to detect the possible rates of infection. The output is presented as follows

[1] Browser Exploitation Rate (BER)
Microsoft Internet Explorer (IE6+IE7+IE8) - 25%
Firefox (All Versions) - 17% - 22%

[2] Operating Systems Exploitation Rate (OSER)
Windows XP : 25% - 30%
Windows Vista : 18% - 22%
Windows 7 : 5% - 8%

[3] Traffic Infection Rate (TIR)
Mixed Traffic Rate (Hard+Generic) = 70% - 80%

[4] Loader Infection Success Rate (LISR)
Loader Installation Rate after exploitation - 90%

This gives us an indication about the exploitation ratios of browsers and operating systems. Windows 7 shows less vulnerable because of the protection mechanisms developed in it. Phoenix BEP converts 70%-80% of traffic to be infected. As it has been discussed above, the loader installation loss is quite less as compared to other BEP's. We can consider the fact of firewalls and other possible scenarios where security mechanisms can reduce the loader installation rate to 10%-15%.However, considering the stats the rate is still high.

Note: The infection rate varies depending on the rate of traffic but the overall stats remain the same.

With the release of version 2.4 we will be encountering following exploits and codes

Added JAVA TC (privilege escalation) which works instead of JAVA DE-SERIALIZE and JAVA GSB exploits.It breaks JRE/JDK 1.5.0-1.5.0_23 and 1.6.0-1.6.0_18 on Win XP/VISTA/7.

Added QUICKTIME exploit for QUICKTIME PLAYER v. 7.6.6-7.6.7 on Win XP for IE 6/7/8.

Added PDF FONT exploit for ADOBE READER 9.3.1-9.3.4 on Win XP/VISTA/7. Vulnerability is not patched yet!

(Hitting Anti Viruses Hard) Random file-names of BEP structure.

(Stealth Technique) Link Encryption in JAVA exploit.

Phoenix 2.4 has shown good advancements. So overall this exploit pack is building really good codes to dismantle the web.

SpyEye Backend Collector - Victim Databases

SpyEye is a fast growing platform that is used for bot infection. SpyEye uses a definitive back end engine for collecting information from the bots. The SpyEye collector is not a part of the admin interface which is used to manage certain specific controls. The collector is an independent component of SpyEye infection platform. This method is used by SpyEye in order to make this component completely unique from the perspective of collecting information from various infected systems all around the world. It means the admin interface has no relation and impact on the working of backend collector because this component works inadvertently even if the admin is disabled or not working. Well, this is quite impressive in its functioning. It means that in a botnet, the main admin that starts infection does not have a much relation with the component that collects information from the bots.

Basically, SpyEye uses a daemon for Linux. It listens on a specific port, collect logs and store information in database. The logs use special compression library termed as LZO for real time data compression. Actually, the LZO is primarily known for its speed over compression ratio. The compression in itself is really fast in LZO and it does not require any memory for decompression. LZO use algorithms that are thread safe, lossless and portable. This provides a glimpse of high compression used for log transmission over the internet from the bots to the backend collector daemon. This simply sets the traffic control in a strict manner thereby economize traffic to transfer logs directly without much interference.

The SpyEye collector looks like as follows


SpyEye has its own SDK and development platform which is designed for generating plugins for infecting victims and stealing specific information. Through plugins, data can be easily transferred to collector. SpyEye provides relative function as a part of its API as follows
void TakeGateToCollector(LPVOID lpGateFunc);

This function is used in the SpyEye plug-in development as follows



The page is dumped as



The collector is configured in the builder part of SpyEye as follows



The collected logs provide statistics as follows



SpyEye uses a good technique and provision of storing information irrespective of user centric access.

SpyEye 1.2.22 - Art of Web Fakes - Malware

SpyEye is one of the latest infection platform on the web which includes a satisfactory browser exploit pack and bot generating system. With the latest SpyEye version starting from 1.2.2X (1.2.4) on the run, we have noticed a state of web fakes which is generated in an artistic manner by the SpyEye. If we look at the profitable nature of SpyEye, it is named as banking Trojan, which comprises of efficient techniques to infect bank websites. In this post, we are going to talk about the technique used by SpyEye to infect banks website with Web Fakes.

SpyEye uses a well defined SDK for its development and infection among websites. It uses the same DLL injection technique. According to definition "DLL injection is a technique used to run code within the address space of another process by forcing it to load a dynamic-link library. DLL injection is often used by third-party developers to influence the behavior of a program in a way its authors did not anticipate or intend." In general it works as follows

1. At first, SpyEye infect the processes by DLL Injection in most of standard DLL's used by HTTP and socket generation functions in the system. It uses DLL hooking to take control of certain functions such as HTTP requests GET/POST to monitor the functioning of process.

2. SpyEye extensibility depends a lot on plug-in designing. The plug-ins have additional infection code which is to be injected into the process for variety of infections. This is done to ensure that initial process of infection remains intact. Plug-ins are used to increase the level of infection at later stage looking at the capability of infected targets.

3. SpyEye uses named pipes, as the same window concept, to read data from plugins and infecting HTTP processes directly.

SpyEye SDK uses following functions as follows

[1] DLLEXPORT bool IsGlobal() { return true; }

This function is called by plug-in itself at the start. It provides a full access to plug-in to communicate all the infected processes so that it is possible for plug-in to take control of all the infected interfaces directly from the source.

[2] DLLEXPORT void Callback_OnBeforeLoadPage(IN PCHAR szUrl, IN PCHAR szVerb, IN PCHAR szPostVars, OUT PCHAR * lpszContent, OUT PDWORD lpdwSize) {}

This function is called by plug-ins to set a hook on the HTTP/HTTPS request, so that contents of the page can be reported back to centralized repository for analyzing the type of information is going out of the network. Let's see the layout



[3] DLLEXPORT void Callback_ProcessContentOfPage(IN PCHAR szUrl, IN PCHAR szVerb, IN PCHAR szPageContent, OUT PCHAR * szOut, IN OUT PDWORD lpdwSize) {}

This function is used to infect the web page dynamically. It again performs a hook exactly before the page is about to render in the browser. It provides an edge to update page contents and inject additional Web Fakes in banking websites. Let's see



[4]DLLEXPORT void FreeMem(LPVOID lpMem) {}

At last, this function is used to set the allocated resource free. A good memory allocation and management benchmark :)

SpyEye mainly infects following DLL's



The payload to be injected or data to be used for infection is applied as follows

#include "data.cpp" /*
unsigned char data[] = {
0x48, 0x54, 0x54, 0x50, 0x2F, 0x31, 0x2E, 0x31, 0x20, 0x32, 0x30, 0x30, 0x20, 0x4F, 0x4B, 0x0D,
0x0A, 0x43, 0x6F, 0x6E, 0x74, 0x65, 0x6E, 0x74, 0x2D, 0x54, 0x79, 0x70, 0x65, 0x3A, 0x20, 0x74,
0x65, 0x78, 0x74, 0x2F, 0x68, 0x74, 0x6D, 0x6C, 0x3B, 0x20, 0x63, 0x68, 0x61, 0x72, 0x73, 0x65,
0x74, 0x3D, 0x55, 0x54, 0x46, 0x2D, 0x38, 0x0D, 0x0A, 0x53, 0x65, 0x72, 0x76, 0x65, 0x72, 0x3A,
0x20, 0x73, 0x72, 0x76, 0x0D, 0x0A, 0x0D, 0x0A, 0x3C, 0x68, 0x31, 0x3E, 0x57, 0x65, 0x62, 0x66,
0x61, 0x6B, 0x65, 0x73, 0x20, 0x69, 0x73, 0x20, 0x6E, 0x6F, 0x77, 0x3C, 0x2F, 0x68, 0x31, 0x3E,
0x3C, 0x62, 0x72, 0x3E, 0x3C, 0x62, 0x3E, 0x74, 0x61, 0x64, 0x61, 0x21, 0x3C, 0x2F, 0x62, 0x3E }; */

Let;s see the SpyEye Plug-ins infection at world level



So the Web Fakes look like as follows





This is really disastrous from security point of view as well as looking at the scenario of stealing information from victim machines by fooling them completely. This type of Malware is getting deadly day by day.

But that's true.