Feb 28 2011

Android Threats Getting Steamy

As seen in recent blog postings, Android malware is on the rise. Android.Pjapps is another example of a Trojan with back door capabilities that targets Android devices. As seen with previous Android threats, it is spreading through compromised versions of legitimate applications, available on unregulated third-party Android marketplaces.

We have detected a few applications carrying Android.Pjapps code. One of these applications is Steamy Window. Similar to other compromised Android applications, it is difficult to differentiate the legitimate version from the malicious one once it is installed. However, during installation it is possible to identify the malicious version by the excessive permissions it requests. The images below show the installation process of a clean Steam Window application and a malicious one.

When run, both the legitimate and malicious version of the application mimic a steam effect on your Android device’s screen. It even lets you wipe it off with your finger as seen in the image below:

However, the malicious version has added additional functionality. The screenshot below shows how the original application’s manifest has been changed:

The aim of Android.Pjapps is to build a botnet controlled by a number of different Command and Control (C&C) servers. Among other things, it is able to install applications, navigate to websites, add bookmarks to your browser, send text messages, and optionally block text message responses.
The threat registers its own service to operate in the background without the user noticing. The service will be started whenever the signal strength of the infected mobile changes and it tries to connect to the following C&C server to register the infection:

http://mobile.meego91.com/mm.do?..{parameters}

Along with this request, it sends sensitive information obtained from the device, including:

It then awaits for a response, and if commanded it will send a message with the infected device’s IMEI number to a mobile number obtained from the following URL:

http://log.meego91.com:9033/android.log?{parameters}

This mobile number is meant to be controlled by the attacker. By using this technique the attacker hides his identity within the “cloud”.

The malicious service also periodically checks the C&C server using the URL below to pull down commands:

http://xml.meego91.com:8118/push/newandroidxml/...

Android.Pjapps uses an XML-based protocol which basically defines tasks (or commands) to be performed at certain times, it supports the following commands:

note
This command is most probably meant to be used to send text messages to premium-rate numbers. A mobile number and content have to be specified, and two additional actions can be performed:

  • blacklisting—If specified, the mobile’s number will be sent to a remote server to check whether it has been blacklisted, in which case the message won’t be sent. The URL of the service has to be sent as a parameter to the command and the blacklist check will be performed issuing a request with the following format:

    ($blacklist_url) + "/?tel=" + mobilenumber
     

  • response blocking—Android.Pjapps also listens for incoming messages, this allows the note command to specify rules to drop inbound messages if certain conditions are met, so the user doesn’t read them. Beginning and end-of-message strings are among the supported filters.

push
This command performs SMS-spamming and requires the following parameters:

  • <smscontent>—Content of the text message
  • <smsurl>—A URL to add at the end of the message contents
  • <tel>—Mobile numbers to send the text to, separated by '#'

It also supports a check for blacklisted devices. In this case the action is performed issuing the following request:

($blacklist_url) + "/sim?=" + imei

soft
This command is used to install packages on to the compromised device. The packages are downloaded from a remote URL that has to be sent along with the command as a parameter.

window
This command makes the mobile navigate to a given website. Android.Pjapps has a preference of which browser to use, checking for the presence of the following browsers:

  • com.uc.browser
  • com.tencent.mtt
  • com.opera.mini.android
  • mobi.mgeek.TunnyBrowser
  • com.skyfire.browser
  • com.kolbysoft.steel
  • com.android.browser

mark
The mark command is used to add bookmarks to the compromised device. When the service is first launched, Android.Pjapps may also, by default, add the following bookmarks to the device:

  • android.paojiao.cn
  • ct2.paojiao.cn
  • g3g3.cn

xbox
This command has been found in Android.Pjapps parsing code but it seems to be unimplemented.

None of the domains listed above seem to be active at the moment, so we haven’t had the chance to inspect the traffic between Android.Pjapps and its C&C servers. However, looking at the threat’s capabilities we believe it has been designed to push advertisement campaigns and to reap the benefits from compromised devices using third-party, premium-rate services.

To avoid becoming a victim of such malicious Android applications, we recommend that you only use regulated Android marketplaces for downloading and installing Android applications. Also, in the Android OS application settings there is an option to stop the installation of non-market applications, which can help to prevent against this type of attack. Checking user comments on the marketplace can also assist in determining if the application is safe. Lastly, always check the access permissions being requested during the installation of any Android applications. If they seem excessive for what the application is designed to do, it would be wise to stop installing the application.

Feb 25 2011

Mass Phishing on Credit Card Services Brand Using Fake SSL

In February, Symantec observed a mass phishing attack on a popular credit card services brand. There were a large number of phishing URLs in the attack, which were all secured using Secure Socket Layer (SSL).

So what makes this phishing attack stand out from the rest?
Phishing websites that use SSL are uncommon and are typically seen in very small numbers. To create a phishing site that uses SSL, the phisher would either have to create a fake SSL certificate or attack a legitimate certificate to attain an encryption for the site. In both cases, Symantec has observed that phishing sites using SSL are less frequent. In this particular attack, there were over a hundred phishing URLs that used a fake SSL certificate. This was achieved by hosting the phishing site on one single IP address which resolved to several domain names. That is, although there were abundant URLs in the attack, they all resolved to a single IP address and contained the same webpage. The SSL certificate was an expired one, with its issue date of the year 2006 and an expiration date of 2007. The phisher’s primary motive behind creating an encrypted phishing site is to help the site appear authentic and to convince users that the site is safe.

 

The phishing site spoofed a credit card services brand, which targeted customers of Switzerland and its phishing pages were in French. End-users were also asked to provide login credentials of a popular e-commerce brand. Hence, phishers attempted to harvest confidential information of two brands with the same phishing attack. The phishing site was hosted on servers based in California, USA.

The phishing site asks for the confidential information in a two step process. The first step is an identity verification of the user. Here, the user is asked to enter name, date of birth, address, email with password of the e-commerce brand, and mother’s maiden name. The second step asks for banking data including bank name, bank ID, name of card holder, card type, card number, personal code, card expiration date, and CVV number. Upon entering the requested information, the phishing site redirects to a blank webpage. If users fell victim to the phishing site, phishers would have stolen their information for financial gain.

Internet users are advised to follow best practices to avoid phishing attacks, such as:

  • Do not click on suspicious links in email messages.   
  • Avoid providing any personal information when answering an email.
  • Never enter personal information in a pop-up screen.
  • Frequently update your security software, such as Norton Internet Security 2011, which protects you from online phishing.
  • Look for the  green address bar in the browser, which denotes that the transaction is secured and the site has been authenticated.

Note: Thanks to Rohan Shah for contributing to the research for this blog.

Feb 24 2011

I got accidental code execution via glibc?!

The story of Chromium security bug 48733, with guest Cris Neckar, part I

It has been a long time now, but the story of Chromium security bug 48733 deserves to be told. It involves intrigue in glibc and even gcc; and notably I accidentally executed arbitrary code whilst playing with this bug!

The bug was reported in July 2010, and there were instantly some WTF aspects. It caused a full browser crash on Linux, and the trigger seemed to be a long string. Such a case would tend to suggest a buffer overflow; but these are very unusual in Chromium code. Upon further investigation, the crash was occurring in the glibc function fnmatch():

int fnmatch(const char *pattern, const char *string, int flags);

And what was very strange was the trigger was not the pattern (which is a complicated string format), but simply the string itself. Further investigation narrowed the problem down to any long-ish (few megabytes+) string, if the locale was set to UTF8. A simple C test program is included at the end of the post. And here comes the killer: I was playing around and ran the program like this on my 32-bit Ubuntu 9.04 machine:

./a.out 1073741796

And accidentally achieved arbitrary code execution! The "A" characters making up the large input string actually correspond to the instruction inc %ecx so I wound up executing a bunch of those.

So what was going on?
Probably best to tackle the list of interesting points in bullet form:

  • glibc had a bug where it would use alloca() for the length of a user-supplied UTF8 string, times four (with additional integer overflow in the times four). This is good for at least a crash, because alloca() extends the stack, which is typically limited to a few MB.

  • It seems uncommon for Linux distributions to compile packages with gcc flags that defend against stack extension attacks -- more about that in part II.

  • 32-bit Ubuntu releases used to lack DEP. Perhaps they still do? This permits the execution of code contained within heap chunks, and is key to the accidental code execution achieved.

  • But how did EIP get redirected? The number passed to a.out above is a bit magic; glibc multiplies it by 4 (sizeof(wchar_t)) before passing it to alloca(), which ends up with the value 2^32 - 112. This wraps the stack pointer, causing an effective decrease in the stack of 112 bytes.

  • The decrease in stack size leads to all sorts of havoc; we're not sure, but most likely a local variable (in a subfunction of the function that called alloca()), pointing to the incoming heap string -- got plonked on top a saved EIP. I no longer have the old version of Ubuntu to test with, and more recent glibcs are fixed, so I can't confirm.

  • Note that stack extension bugs like this often sidestep a lot of system defenses, such as stack canaries (which are left undamaged) and ASLR (a valid address is automatically filled in). It's another case where Ubuntu could really have used DEP; see my older Firefox exploit for further proof!


How does part I end?
Of course, we reported the bug upstream to glibc: http://sourceware.org/bugzilla/show_bug.cgi?id=11883. The somewhat terse response notes that the issue was fixed but not in which version. Because of this, no glibc security advisories were released; so apologies if your older but still supported Linux distribution might still have vulnerabilities in this area.

Although certainly not a bug in Chromium, we still paid the bug finder $1337 under the Chromium Security Reward program. We did this partly just because we can, and we love encouraging all security research. But also, we were able to work around this glibc bug in Chromium fairly trivially -- so we did so in short order. As can be seen from the Chromium bug, we had all users protected in under 20 days from the original report, despite it not being our fault!


#include <err.h>
#include <fnmatch.h>
#include <locale.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, const char* argv[]) {
size_t num_as;
char* p;
setlocale(LC_ALL, "en_US.UTF8");
if (argc < 2) {
errx(1, "Missing argument.");
}
num_as = atoi(argv[1]);
if (num_as < 5) {
errx(1, "Need 5.");
}
p = malloc(num_as);
if (!p) {
errx(1, "malloc() failed.");
}
memset(p, 'A', num_as);
p[num_as - 1] = '\0';
p[0] = 'f';
p[1] = 'o';
p[2] = 'o';
p[3] = '.';
fnmatch("*.anim[1-9j]", p, 0);
return 0;
}
Feb 24 2011

Android.Geinimi Branching Out to Japanese Applications

In some recent blog postings by Irfan Asrar, we discussed how a number of legitimate Android applications have been “Trojanized” in order to include “backdoor” functionality and are then published on unregulated Android marketplaces. In the past, we have seen a number of English and Chinese language Android applications being Trojanized and placed on unregulated Android marketplaces. Up until now, however, we have not seen any Japanese language Android applications being manipulated in this manner. This is no longer the case, since we have found a Trojanized Japanese language Android application on an unregulated Android marketplace. Symantec detects this malicious Android application as Android.Geinimi. The following image is the start picture of the application:
 

The legitimate version of the application is sold at 525 yen (approx. $6 US) on the proper regulated Android marketplace. It allows you to do "push-up", "sit-up", and "squat" exercises with an anime character. The legitimate and Trojanized versions of the Android application may appear identical, but the “Trojanized” version has Android.Geinimi running in the background and is transmitting information from the device to a remote location. The access permissions required during installation also differ. The following images show the access permissions required by the Trojanized version of the application during installation:
 

Whereas the proper access permissions required by the legitimate Android application (according to the regulated Android marketplace) are shown in the following image:
 

The presence of Trojanized versions of legitimate Android applications on unregulated Android marketplaces is a growing problem. Increasing demand for content, along with the absence of official marketplace outlets in certain regions, is fueling the growth of unregulated marketplaces. In turn, these marketplaces are becoming the perfect incubator and propagation engine for threats such as Android.Geinimi. To avoid becoming a victim of such Trojanized Android applications, Symantec recommends that you only use regulated Android marketplaces for downloading and installing Android applications. Also, in the Android OS application settings there is an option to stop the installation of non-market applications, which can help to prevent against this type of attack. Checking user comments on the marketplace can also assist in determining if the application is safe. Lastly, during the installation of any Android applications, always check the access permissions being requested for installation. If they seem excessive for what the application is designed to do, it would be wise to stop installing the application.