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.