Mobile banking vulnerability: Android repackaging threat

2012-05-03

Seolwoo Joo

AhnLab Inc., Republic of Korea

Changyeon Hwang

AhnLab Inc., Republic of Korea
Editor: Helen Martin

Abstract

From a security point of view, Android's openness is one of its down sides. Researchers Seolwoo Joo and Changyeon Hwang show how a repackaged mobile banking app can be used to steal users' banking credentials.


Android is now the most popular smartphone platform. The main feature of Android is openness. Android enthusiasts often install ‘custom ROMs’ on their devices – modified versions of Android OS.

But from a security perspective, the openness of Android can be dangerous. We have researched the Android ecosystem and mobile malware, and have found a critical security threat in the Android ecosystem.

Specifically, we were able to download a mobile banking application from Google Play and inject a malicious function into it using a repackaging technique. We then proved that the repackaged app would be able to leak users’ banking information.

Android issue: repackaging

Using a repackaging technique, source code can be added to the APK (Android package) file. Resources can also be changed. The process is as follows:

  1. Unpack an APK file with apktool. Apktool is an open-source reverse engineering tool for APK files. It can decode resources and rebuild them after modifications.

  2. Decompile the Java source code with JAD. JAD can extract source code from class files.

  3. Modify the Java source and resources using Eclipse.

  4. Rebuild the file using apktool.

  5. Sign the code using jarsigner.

Sequence of repackaging.

Figure 1. Sequence of repackaging.

Android issue: market & unknown sources

There are several easy ways to distribute repackaged Android apps.

Apps can be registered on the official Android market (Google Play), or on various third-party markets. There is no technical test when an app is registered, so anyone who has an account can register their app freely.

APK files can also be installed directly onto smartphones if the ‘Unknown sources’ option is checked. This may cause a very serious security problem.

Unknown source.

Figure 2. Unknown source.

A malware writer could upload a malicious repackaged app to a web page or send it by email. Android users installing the app onto their smartphone won’t notice that it is a repackaged app because it looks and behaves just like the original one.

Android malicious code examples using repackaging techniques

Repackaging techniques that can be used on the Android platform allow malicious code to be disguised as a normal app. It is difficult to distinguish between repackaged malicious code and a normal app because the repackaged app usually appears to function in exactly the same way as the legitimate one. Let’s take a look at some examples of malicious code.

Geimini

Geimini is a trojan that is bundled into many valid Android apps. The example shown in Figure 3 is a repackaged version of the Monkey Jump 2 game that contains the Geimini trojan – the icon is identical to that of the valid app.

Geimini icon.

Figure 3. Geimini icon.

The permissions that are required during installation are shown in Figure 4.

Geimini permissions.

Figure 4. Geimini permissions.

If the installed malicious code is run, some private information is sent to the attacker via a specific web page. The information that is sent is as follows:

  • List of installed applications

  • List of applications that are running

  • Network status

  • SIM number and phone number

  • SMS information

  • Contacts information

  • GPS information.

KungFu

The KungFu trojan has been around for a long time. Recently, a new version of KungFu has been discovered bundled with repackaged versions of the Angry Birds Space game. The repackaged malicious app spreads mainly through third-party markets and, when installed, has the same icon as the legitimate version of the game.

The game can be played as normal – so it is unlikely that users will detect the infection.

The permissions that are required for installation differ slightly between the malicious app and the legitimate app, as shown in Figure 5.

KungFu permissions and normal app permissions.

Figure 5. KungFu permissions and normal app permissions.

The KungFu trojan uses the GingerBreak exploit to gain root access to the device and install the malicious code. Once the malicious app is installed, criminals can send commands to compromised Android devices, instructing them to download additional code or push URLs to be displayed in the smartphone’s browser. Infected devices become zombies under the control of the criminals.

Mobile banking vulnerability

Banking apps handle critical financial information, so their security must be strong. We found that most of the banking apps used in Korea are vulnerable to repackaging threats.

Using a proof of concept, we will show how the password for the digital signature certificates used in mobile banking can be hijacked. The process is outlined in Figure 6.

Process of repackaging.

Figure 6. Process of repackaging.

1. Save the banking app to a PC

First, the banking app is downloaded to a PC from the Android device. We used ASTRO, which can be downloaded (free of charge) from Google Play. It has the useful function of backing up Android apps to an SD card.

ASTRO – application backup.

Figure 7. ASTRO – application backup.

2. Decompile

Usually, decompiling PC applications is a complicated task, but Android apps can easily be decompiled by using the open-source tool apktool.

For this process we need only one simple command, as shown in Figure 8.

Decompiling the banking app using apktool.

Figure 8. Decompiling the banking app using apktool.

3. Analysis and injection of malicious code

Once the code has been decompiled it can be analysed to find the part that relates to accessing the digital signature certificate (knowledge of the Java language is required). We found the code easily by searching the string that is shown when the user inputs the wrong password. Figure 9 shows the code that processes the password.

The code that handles the password

Figure 9. The code that handles the password

The ‘c’ which is a member of ‘com.sf.secure.ui.crypto.SignCertPasswordWindows’ has the password.

{image}

197 : iget-object v1, p0, Lcom/softforum/xecure/ui/crypto/SignCertPasswordWindow;->c:Ljava/lang/String;

The SendMsg() function is added so that the string can be sent to the attacker, and two lines are inserted (as highlighted in Figure 9) to call the function into the code phase. The SendMsg() function is shown in Figure 10.

The SendMsg function.

Figure 10. The SendMsg function.

In the same way, a criminal would be able to hijack the user’s sensitive information including their account number, login details etc.

This banking app does not have permission to send SMS messages, so the permission is added by inserting ‘Android.permission.SEND_SMS’ into the AndroidManifest.xml file, as shown in Figure 11.

Modify the XML permissions.

Figure 11. Modify the XML permissions.

4. Build & code sign

The modified code can then be rebuilt using apktool, as shown in Figure 12.

Rebuilding the app using apktool.

Figure 12. Rebuilding the app using apktool.

The code can be signed to build the APK by using jarsigner, as shown in Figure 13.

Code signing using jarsigner.

Figure 13. Code signing using jarsigner.

5. Install malicious app

There are many ways to install the malicious app on the victim’s device. In this example, adb – which is included in the Android SDK – is used for installation (see Figure 14).

Installation.

Figure 14. Installation.

Result

When the victim launches the repackaged app, every function will work normally, but the password for the digital signature certificate will be sent to the criminal. Since the app appears to work as normal, the victim won’t notice that anything is wrong.

Repackaged banking app and password.

Figure 15. Repackaged banking app and password.

Conclusion

User information can be leaked through repackaged mobile banking apps. Criminals are able to steal victims’ money using stolen user credentials. This could become a very serious problem because the number of users of mobile banking is growing rapidly. It is important for the security industry to find ways of protecting mobile banking apps from repackaging attacks such as this – as well as finding ways to protect other apps that deal with sensitive user information.

twitter.png
fb.png
linkedin.png
googleplus.png
reddit.png

 

Latest articles:

VB2017 paper: The (testing) world turned upside down

We often hear that anti-virus is dead, but if that is really so, where does it leave anti-malware product testing?

FAME – friendly malware evaluation framework

The FAME framework is intended to facilitate analysis of malicious files, leveraging as much knowledge as possible in order to speed up and automate end-to-end analysis of malware.

VB2017 paper: Crypton - exposing malware's deepest secrets

As malware researchers, a significant part of our work is dedicated to reverse engineering various cryptographic algorithms in order to extract malware’s encrypted content. Julia Karpin and Anna Dorfman describe an automated approach, based on a…

VB2017 paper: Walking in your enemy’s shadow: when fourth‑party collection becomes attribution hell

Attribution is complicated under the best of circumstances. Sparse attributory indicators and the possibility of overt manipulation have proven enough for many researchers to shy away from the attribution space. And yet, we haven’t even discussed the…

Throwback Thursday: CARO: a personal view

As a founding member of CARO (Computer Antivirus Research Organization), Fridrik Skulason was well placed, in August 1994, to shed some light on what might have seemed something of an elitist organisation, and to explain CARO's activities and…


Bulletin Archive