Android.Bgserv Found on Fake Google Security Patch – Part II

Following our initial post on the discovery of Android.Bgserv, Symantec has found additional Trojanized samples in the wild. After analysis of these new samples, it appears that the applications contain multiple bugs. In the case of the Trojanized version of Google’s Security Tool, we have confirmed after testing (with no surprise) that it does not have the ability to clean a system infected with Android.Rootcager.

The Trojanized applications also contain code to change an infected device’s APN settings. The screenshot below belongs to the threat code responsible for changing them. However, in our research we have not been able to identify the code being called at any time.

Our research also shows that even if this APN change code was called, the application's permissions would not allow the requested changes to take place. This can be seen in the screenshot below, showing the Trojanized application's manifest:  

An application willing to change the APN settings is required to hold the “android.permission.WRITE_APN_SETTING” permission. We have also found some other pieces of interesting code within the threat that seem to be dormant. One example of this is seen in the screenshot below:

The purpose of this code seems to be to block incoming calls from specific telephone numbers. In this case, the telephone numbers in question seem to belong to a major Chinese telecom operator's customer care service.  

Below is an image showing the command-and-control (C&C) server that is being used by this threat and an example of the information that is posted to the C&C server. At the time of writing, the C&C server was live but not serving commands.

Our overall analysis of this threat has shown it to be a potentially worrying threat. However, the threat's perpetrators have failed to fully implement all of the functionality within the infected applications, thereby lessening its potential impact as a threat.    

Here are a few tips that may help to identify whether or not a device has been infected with Android.Bgserv. The legitimate Android Security tool was automatically pushed to infected users and did not require manual download.  Also, it does not show up within the application menu, as opposed to the malicious one:

We can see the malicious service that has been started by the Trojanized tool running in the background as “BgService”:

Finally, 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.

Note: Special thanks to Irfan Asrar for all his input into this blog.

Persistent XSS Vulnerability in Facebook

There is a Javascript spam trick on Facebook resulting in spam messages being posted on many user accounts. First mentioned yesterday by our colleagues at GFI Software, the persistent cross-site scripting vulnerability still remains unpatched as of this writing. So, what happened? Some attacker has discovered a new method to inject Javascript through specially crafted Facebook application pages. Normally the script would be removed by filters before the page is shown to the user, but in this case, it is able to slip through. The malicious script will then be executed in the context of, allowing it to perform requests under the user’s session. Keep in mind this happens before the application asks for any permissions. Visiting the page while being logged into Facebook is enough to get it started, which is normally the case when a user is viewing new messages.

When following such a link, the malicious script shows a fake update procedure for the Adobe Flash Player as a distraction. The user is intimidated with warnings when attempting to leave the page too early, but the whole attack only takes a few seconds to complete.

Meanwhile in the background, the script checks who is currently viewing the page by parsing the current site for the user’s ID. The script than starts issuing hidden AJAX requests to get the user’s profile page from Facebook. Because the user is logged in and has a valid session, the script can perform all the needed actions to submit a post, a classic session-riding attack. In this case, it will post a link to some spam sites. The script also ensures that it only posts once per user by checking if there is already a spam message shown on the user’s wall. The posted messages vary and are updated by the attacker. We have seen advertisements for “weight loss products” and also “free iPad give away” campaigns being used, as can be seen in the screenshot. Those spammed links point to harmless but annoying pages. Visiting those sites will not infect your profile, at least not at the time of writing this article.

But the script has more to it; it will also search for any of your friends UID’s and send them a direct message with a link to an infected application site. This way your friends might fall for the malicious script and start a new wave all over again. So watch out for suspicious private messages from your friends.

One of the bait messages sent is: “Hey, What the hell are you doing in this video? Is this dancing or what?? lol http://[removed]”

Such injected malicious scripts have a high potential for doing all sorts of damage. It could modify your profile or, as in this case, send out infected messages, or even possibly add apps or friends. Even if the script would do something that needs a CAPTCHA to be solved, it could reflect it back to the user and try a social engineering trick in order to get the user to solve it.

This example is just another example of the sophisticated attacks that we see on Facebook every day. On a side note, the same domain is also used to serve a Facebook phishing site with a fake login screen. So clearly the attackers are running various scams on the side.

Fortunately we have not seen the injection vulnerability being used by other attack groups yet. The security team at Facebook has been informed and is working to patch the vulnerability in short order. Measures have already been implemented to short circuit any further attempts at exploitation.

Android.Bgserv Found on Fake Google Security Patch

On March 6,2011, Google published the application “Android Market Security Tool”, a tool designed to undo the side effects caused by Android.Rootcager. This application was automatically pushed to devices of users who had downloaded and installed infected applications.

Symantec has identified suspicious code within a repackaged version of the “Android Market Security Tool”. This package was found on an unregulated third-party Chinese marketplace. This threat seems to be able to send SMS messages if instructed by a command-and-control server located at the following address:


Analysis of the application is still ongoing, however, what is shocking is that the threat’s code seems to be based on a project hosted on Google Code and licensed under the Apache License:

Here are a few snippets taken from Google’s hosted project:

We have added detection for the trojanized version of Google’s application as Android.Bgserv.

Multi-browser heap address leak in XSLT

It's not often that I find a bug that affects multiple different codebases in the same way, but here is an interesting info-leak bug that is currently unpatched in Firefox, Internet Explorer and Safari.

I'm releasing it now for a few reasons:
  1. The bug was already publicly noted here.

  2. This bug cannot damage anyone in and of itself; it's a low severity info-leak that does not corrupt anything. It needs to be paired with other bugs, perhaps as an exploit aid against ASLR.

  3. This is a rare and unique opportunity to directly compare vendor responses and response times for a near-identical bug. It's nice that this is a lower-severity issue as all vendors tend to treat critical issues with at least some urgency; lower severity issues serve as a better differentiator.

The bug
The bug is in the generate-id() XPath function, and is sometimes used in XSL transforms. Here's an web page that simply calls generate-id() and renders the result as a web page:

Let's see how this renders in different browsers:

Firefox (64-bit Linux)

There is no "obfuscation" that this is a raw heap address. Since Firefox is open source, we can go and look at the source code to find that indeed, the string is generated from a pointer (txXPathNodeUtils::getXSLTId):
const char gPrintfFmt[] = "id0x%016p";

Internet Explorer 8 (Windows 7)

Doesn't look like a heap address, does it? If, however, you strip off the "ID" prefix and treat the string as a [A-Z0-5] base32 encoded "little endian" string, you resolve to a nice heap address. At that address is a pointer in msxml.dll, possibly the address of a vtable for some internal xml node class.

Safari 5 (Mac OS X)

Also does not immediately look like a heap address, but libxslt is doing a simple transform on a heap address:

val = (unsigned long)((char *)cur - (char *)0);
val /= sizeof(xmlNode);
sprintf((char *)str, "id%ld", val);

These object ids bounce around all over the place. I don't know what is going on so I'm not making the claim that Opera is affected.

Latest stable Chrome (Chrome 10) is not affected. It has been removed from the "time to fix" competition in order to keep things fair.

It's on!! Who will fix it first and who will be the security laggard? Updates to be provided via Twitter: @scarybeasts