Bad Java decompilation means erroneous statement in research paper

Back in July 9, 2012, Martin Georgiev et al. published a paper entitled “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software” (download) that points out broken SSL certificates validation in various applications and third-party libraries.

One of the case studied is the Chase mobile banking app for Android. It turns out the version studied by the authors was 2.5 or earlier, released on April 23, 2012. (The APK can be found on Android-Drawer.) In paragraph 10.1, the authors wrote:

“Decompilation and analysis of this app’s code show that it overrides the default X509TrustManager. The replacement code simply returns without checking the server’s certificate. The code below is the result of reverse-engineering, thus variable names and other details may differ from the actual code.”

While the first statement is true (X509Certificate.checkServerTrusted() is overriden), the second is false. The claim was made because of improper decompilation to Java:

public final void checkServerTrusted(X509Certificate[]paramArrayOfX509Certificate,    String paramString)
{
  if ((paramArrayOfX509Certificate != null)
    && (paramArrayOfX509Certificate.length == 1))
    paramArrayOfX509Certificate[0].checkValidity();
  while (true)
  {
    return;  // makes checkServerTrusted unreachable
    this.a.checkServerTrusted(paramArrayOfX509Certificate, paramString);
  }
}

The decompiled code is incorrect: the “while(true) { return; …” is a misconstruct that lets the reverse engineer believe that this.a.checkServerTrusted() is never called.

Unfortunately, the authors relied in part on this faulty piece of Java code to claim that:

“Note the unreachable invocation of checkServerTrusted. We conjecture that this was a temporary plug during development that somehow found its way into the production version of the app.
…
Chase [is] completely insecure against a man-in-the-middle attack.”

Note that the conclusion that Chase is insecure to MiTM attacks is not disputed here. Martin Georgiev confirmed that the app was tested and was vulnerable to such attacks.

The authors may have run out of time and probably skipped the Dalvik bytecode verification step.

In fact, the routine in question is pretty simple, and JEB decompiles it to a clean:1

Now, it looks clear that the original checkServerTrusted() gets called, if and only if the certificates’ array is null or the array does not contain just one certificate.

Decompilation is not a guaranteed process, but one should use professional tools to minimize exposure to bugs. A manual check of the low-level bytecode or assembly is also a requirement before making claims that a particular code path is or is not executed.

Thanks to Juliano Rizzo for pointing out this potential issue.

Japanese Contact Stealer

Let’s have a quick look at a variant of Android.Uracto, an app that steals (and potentially spams) contacts from Android devices. There is nothing particularly interesting about this piece of malware, but it’s the occasion to demonstrate some of JEB less-known and forthcoming abilities.

Upon startup, the app displays the following spinner, that translates to “Reading the articles…”:

2

The onCreate() method for the main activity displays the above spinner, and also starts a new Thread, that will create and run a Progress object. Here it is:

3

4

The run() method will call postMailList(). This method gets the ContentResolver for the app, and enumerates all entries having the “vnd.android.cursor.item/name” MIME type. According to the documentation, these entries represent “contacts’ proper names”.

5

A buffer representing the data1, data2, and data3 fields (respectively, Display Name, Given Name, and Family Name) is dynamically created.

[JEB specific]

Notice the optimizations that allowed the creation of that compact construct:

  • for-loop optimization
  • string concatenation
  • aggressive variable substitution

Some of these optimizations are already present in 1.0.x, others will be included in the 1.1 versions.

[/JEB specific]

The final data (“contact1, contact2, …”) is dumped on the external memory storage, encoded and POST’ed to hxxp://jap2012.com/data/main.php.

6

Find the decompiled activity here: solution.newsandroid.MainviewActivity

Sample MD5: ba73e96caa95999321c1cdd766bdf58b

Korean SMS Interceptor

Let’s inaugurate this blog by looking at a fairly simple piece of Android malware, an SMS interceptor app whose prime targets are South Korean users.

The app impersonates a Starbucks coupon (스타벅스 쿠폰) app.

1

Let’s check the decompiled Java code.

When the user starts the app, it displays a fake error message, indicating that the server is out-of-service, and terminates. In the meantime, it has registered and started the malicious service com.catchspam.catchservice.

3

Notice that a preference variable “runYN” is set to “execute” (실행.) More on it later.

The malicious service does two things:
– First, it registers the cellphone number by POST’ing it to hxxp://it7980.com/Android_SMS/installing.php. (If the number is Korean and starts with the prefix +82, it receives “special treatment”.)
– Then, it registers a BroadcastReceiver meant to process incoming text messages.

4

The BroadcastReceiver com.catchspam.catchsms2 processes SMS_RECEIVED intents. The last PDU is processed and (supposedly) contains the text message.

In the following screenshot, notice that the author implemented a minimal C&C-like behavior:
– If the text reads “execute”, the runYN preference variable will also be set to “execute”.
– If the text matches the “magic passphrase”, that variable will be set to “pause”. (It roughly translates to: “Back and forth the same versus luck ♥ Lee ♥ ♥ Please call 1588-1588”.)
Later, runYN is checked and the interception procedure will bail if it is not set to “execute”. This allows the author to enable/disable the interception, either globally or for specific phone numbers.

5

The intent broadcast is cancelled to prevent other apps (and eventually, the user) from processing the SMS. Finally, the message is POST’ed to the author’s server. The data format is “mobile=<number>&revsms=<textmessage>”.

SMS stealers can be simple annoyance or steal personal data. In this case, it might be used to capture 2-factor authentication codes sent by online banking websites.

Download the sample here.