New iBanking - KitKat SMS bypass done wrong, obfuscation done right

iBanking malware seems to be on the rise recently. It is not a new malware, it's circulating for more than a year now, but it seems to be the go-to choice for some of the more popular e-banking attacks. It's usually coupled with the PC infection (by some webinject-capable malware), which convinces the user to install either a "specially crafted" banking app, antivirus solution or some other uses trustworty-sounding name.

Anyhow, I recently got my hands on two interesting things: one is the "new" iBanking sample, which tries to fool Android > 4.3 SMS_DELIVER mechanism. The second one is the panel and the builder of the iBanking. Let's have a look, but first a quick recap of iBanking features and modus operandi. We will be looking at this sample.

Templating

iBanking has a dozen of what it calls "templates". Each template is in fact one of the apps that iBanking pretends to be. So you can have a template for a specific bank, a template that makes it look like mobile antivirus and so on. Templates differ slightly in the layout, but mostly in the provided graphics and color scheme, although some of them seem to support specific commands (more on that later on). Dr. Web template is presented on the screenshot below.



Looking at the (leaked) crimeware kit it seems that the buyer has to specify a template that he or she wants. This way if the template gets "burned" the attacker has to buy another one, effectively paying for the same malware twice. If you have any additional (or entirely different) information about the sales tactic, feel free to contact (and/or correct) me.

However, you can still make some personalization when you get the crimeware kit. You can change the hardcoded C&C numbers, HTTP C&C URL and bot ID. All of these changes are done in a curious way. Crimeware kit comes with an app sample that is disassembled (using apktool), then sed is run to replace the variables and then the app is assembled (again using apktool) and signed. Screenshot below illustrates part of that process.


SMS communication

iBanking is certainly one of the most feature-packed Android trojans (although it does not try to decrypt the WhatsApp messages like FinSpy did). If you have a look at the ek class you'll see a list of SMS commands, some of which are:
  • wipe data - does a factory reset, sent as a last command to prevent device forensic,
  • sms start <number>/ sms stop - starts and stops SMS forwarding to a specified number,
  • call start <number> / call stop - starts and stops call forwarding (done using the *21* code),
  • sms list / call list - send a log of text messages or calls (respectively),
  • start record / stop record - starts and stops audio recording (using the mic in your phone),
  • greed - this is unusual. It will display a notification with some text to the user and switch the app main view. It's only for one template and I don't have a sample with that template so I'm not sure what the notification text is and what the purpose of it is.
How does the app know that the command was sent from the attacker and not from the third party? Either because the text message was sent from one of the two hardcoded C&C numbers or the number that previously authenticated itself. Authentication is performed by sending the hardcoded password. This way the attackers can change C&C if they lose the phone number. Clever, huh?

Encryption and obfuscation

The fun part is also the encryption that they use to hide the actual password in the app. Previously the password was stored in plaintext, but now it's encrypted using propriatery algorithm pictured below (can be found in the cD class).


As you can see b is responsible for converting the hex-encoded text to actual bytes. Then, in the last two lines of a, the encrypted message is xored with a keystream made using an "almost" LPRNG, but it includes not only the keystream variable but also the ciphertext byte. All in all, seems like a good effort in cryptography, not a usual xor with a byte.

And there's more! In the same class we have two method declarations that have the same name and same arguments, but differ in the static modifier and the returned type. One is:

public static String a(String paramString)

and the other one is:

public final byte[] a(String paramString)

Surely, Java does not allow for such an abomination, right? That's true, Java doesn't (and don't call me Shirley). When I tried to reproduce this I've got the following error:

 error: method a() is already defined in class ...

However, smali is more flexible. After some testing it seems that Dalvik VM takes into account also the returned type. So if you compile the project, then disassemble it using apktool, change method name, build it and run, you can have two methods with the same name and arguments. But you don't have to believe me, I've prepared a MWE and you can have a look for yourself.

Despite my best effort, I cannot seem to invoke the non-static (instance) method. All in all, it's a really good obfuscation that fooled me during this analysis.

SMS_DELIVER

Since Android KitKat (4.4) there is a new approach to handling the text messages. There is a special, designated SMS app and there can be only one. You can of course change it  - for example when the attackers try to convince you that you'll be better off with their app. However, if you don't change it you will be notified about every incoming message and every outgoing message will be recorded. This, of course, is a behavior that the criminals do not want, especially when they forward your SMS OTP messages. So they implemented a workaround which is a little... wrong. Let's have a look.


So, if the version number starts with 4.4 then mute the audio. This of course will somehow work - user won't be notified of the incoming message by sound, but there is a problem with the notification bar, which still shows that you received a text message, because it is the newest notification. Apart from that, there is also another problem. It will not work on Android Lollipop, which is 5.0.x version. And 5.0.x does not start with 4.4.

What about the HTTP?

Well, HTTP is really not interesting and is left rather unused. However, I did find two active panels using the mighty powers of the Google search engine, so I wouldn't say it is extinct. One is even in the .ir TLD.

Comments

Post a Comment

Popular posts from this blog

Having fun with AndroidManifest.xml

Image
Before w will get back to Sandrorat let's have some fun. It's weekend after all, or rather it was weekend when I wrote this post. Everyone that ever tried to see the insides of the APK file knows what's an AndroidManifest.xml file is. Some even know that, inside the APK, it's not a real XML, but rather a compressed, binary form of an original XML. This compressed form was first abused in the Android.OBAD malware . Compressed form of an XML differs with the real XML in at least one key aspect, hidden in the String Pool. Let's have a look at a compressed AndroidManifest.xml file of the previously mentioned Sandrorat sample and see if we can do something interesting with it. If you want to skip directly to the fun part, just ignore the next section.
Read more

Android malware based on SMS encryption and with KitKat support

Image
Most of the malware based on the SMS C&C communication channel is not compatible with Android 4.4 KitKat. This is due to the fact that KitKat introduced a concept of one messaging app, which all other apps had to go trough before they send or handle a received text message. This prevented malware from hiding received short messages or sending without saving them in the "Sent" folder. Well, it wasn't hard to predict that this state of affairs wouldn't last long and that malware authors would eventually catch up. Malware described here not only supports KitKat, but also uses an open-source SMS encryption tool  as a basis for its code. Let's have a look at the insides of the new sample (hash: 84e2e9e8430792b583d02d3cc1bf8535 ) and let's call it SmsSecure, just for the sake of brevity.
Read more

Sandroid RAT analysis: Part I - synthetic communication

Image
My first post is about Sandrorat, a fairly new RAT tool that was prominent for being a part of a Polish spam campaign . The analyzed sample hash is bed05d8eace6a7ebc5dec7141ea4b9cc559f1b2aab8848e2c79df7a79de39b9d . Sample was obtained thanks to The Honeynet Project . Everything is synthetic First part will be about a little known synthetic methods and the way Sandrorat uses them to obfuscate the code . This sample declared three different services:
Read more