[ Technical Tear Down: Fake Code4HK Mobile App ]

Today i’m going to talk about the Fake Code4HK Android application which the news reported here,http://www.scmp.com/news/hong-kong/article/1594667/fake-occupy-central-app-targets-activists-smartphones. The Code4HK guys had already long identified this Android mawlare this (https://code4hk.hackpad.com/Fake-Code4HK-Mobile-App-HQXXrylI6Wi) before the rest of the world did. However I probably should stop writing about Android malware but this one seems interesting for me to write though. 😛

As the thing happened almost 2weeks ago and the international activists only saw it yesterday. I was lucky to be able to grab a sample of this off Matthew Rudy Jacobs’s github. But i’ll be doing my own technical tear-down of this malware and hope to cover this comprehensively

[ Sample used in the analysis ]
MD5: 15e5143e1c843b4836d7b6d5424fb4a5
SHA1: c1e9ebd0b5ac7b6c50c69af219d163393d52df99

[ How it starts ]
It was first distributed via WhatsApp as shown in the image below.
code4hk.apk
As we can see, it’s asking participants of #OccupyCentral to download this url shortened link, http://is.gd/bh4adz
However, if you were to “Expand” this shortened URL, you will see the final url is, http://code4hk.vicp.cc/code4hk.apk
That link is not valid anymore and furthermore, that suspicious url does not belong to code4hk.
The official url for code4hk is http://www.code4.hk/

Since it’s an Android malware, let’s check the permissions of this malware and further dissect it. Now, use apktool and run the following command:

Now let’s take a look at the AndroidManifest.xml file, you should see the following and the permissions requested by the APK file.

There are interesting meta-data available to us like the following found in the cert.rsa file.

The email could be useful but there are no hits on google using that.
Another interesting but not confirmed “findings” i have is maerts spelled backwards is “stream so could ITSC mean CSTI? Council of Science and Technology Institute? I’m not sure but i’ll let everyone’s imagination run. 😀

But let’s take a look at com.v1.MainActivity first, manually converting the initial Dalvik code back to pseudo Java code.
After disassembling the .apk file with apktool and checking the Android manifest file, the first thing that i check is the MainActivity class.
We will get back something like the one shown below. Looking through the codes, we can see that it’s starting another class, StreamService.
analysis.code4hk.001

From my initial analysis, we can identify several things.
1.) It will open “qq.xml” from the Assets directory.
2.) It will create a new directory, “/sdcard/.qq/
3.) It read the contents of “qq.xml” and create a file, “/sdcard/.qq/temp.apk

If we had analysed the Android Manifest properly, “StreamService” will be started after reboot.
And if we were to analysed “StreamService” really carefully, it’s actually making use of AndroRat. 😛
If you had never seen AndroRat before, you can find a copy of it here. https://github.com/DesignativeDave/androrat
So basically, it’s getting lots of other stuff from the victims as well. o.0″

[ PhoneReceiver ]
Now let’s take a look at “PhoneReceiver” class and we can see that it will start recording all outgoing calls made by the victim(s).
o.0″ Sounds malicious to me.

If we were to check the following Android documentations,
setOutputFormat – http://developer.android.com/reference/android/media/MediaRecorder.OutputFormat.html
setAudioSource – http://developer.android.com/reference/android/media/MediaRecorder.AudioSource.html
setAudioEncoder – http://developer.android.com/reference/android/media/MediaRecorder.AudioEncoder.html
We know that the Output format is 3GPP media file format.
The source for the recording is using Microphone audio.
The encoding used is AMR (Narrowband) audio codec.

There are other interesting findings such as the naming convention of the filenames are
out_” appended with the outgoing phone number followed by “_” and resides in “/data/data/com.v1/.record/
The file extension of the files are “.amr” as shown below.
analysis.code4hk.003

[ StreamReceiver ]
One interesting thing is within the “StreamReceiver” class, it tried to read “getAll.dat” in a try..catch block and if it didn’t find it, it will activate the “features” of AndroRat”.
It will also try to read the contents of config.dat under “/assets/config.dat
This file actually contain an IP address, “61.36.11.75” & a number “1430” which we can safely assume that it’s the port number.

It also tried to use Baidu to gather location data of the victim(s) as shown below.
analysis.code4hk.004
The API could be found here: http://developer.baidu.com/map/loc_refer/com/baidu/location/LocationClient.html

Besides the IP address which we have highlighted earlier on, there are some other interesting IP address and domain name which are found within “StreamReceiver” class as shown below.
221.226.58.202
mm.v1lady.com:1430

One thing which most people may not know is that mm usually stands for “木马” or “妹妹” in China context.
I highly doubt it meant the latter. xDDD
木马” means trojan horse. 😛

It also creates of other interesting files storing all the information that it “steals” from the victim(s).
But i won’t go through each and everyone of them.

From the whois information, we can gather more information on v1lady.com as shown below:

From the whois information, we can gather more information on 221.226.58.202 as shown below:

[ FixTimeRecordReceiver ]
Now let’s take a look at “FixTimeRecordReceiver” class, we can see that the purpose of this is to record the audio using the MIC.
While it looks almost the same as “PhoneReceiver” but the recording starts in a fixed interval as it was set in “StreamService“.

There are other interesting findings such as the naming convention of the filenames are
FIX_TIME_” appended with “yyyyMMddHHmmss” (Date time of the system) and resides in “/data/data/com.v1/.record/
The file extension of the files are “.amr” as shown below.
analysis.code4hk.002

[ Conclusion ]
While this is not one of the state of the art Android Trojan, but it’s probably one of the interesting one that makes use of a known coding group in Hong Kong and spread through WhatsApp.
But there will always be questions, why are they being targeted, why send through WhatsApp and i think the number used could be those easily available “pre-paid” data sim card in Hong Kong.

I hope that this is fairly simple to understand technical tear down that people can repeat the steps on their own and learn how to analyse Android Malware.

Happy Reversing,
Jacob Soo

[Technical Tear Down] Fiesta Exploit Kit – Java Exploit (CVE-2012-0507)

Today, we’re going to look at another exploit that is delivered by the Fiesta Exploit Kit. As usual, the purpose of this post is to provide a technical understanding on how the exploit work. This time it is a JAVA exploit.

This is the link to the fiesta_ek_java_2012_0507 (The .JAR file contained 4 .class files and a .txt file containing the parameters that was passed to the JAVA applet by the launching Javascript). Do note that these are MALICIOUS files, so please run them in a “safe” environment.

[Part 1: Overview]

This exploit uses the CVE-2012-0507 vulnerability. It is a type confusion vulnerability affecting the AtomicReferenceArray class. More information about this vulnerability can be found at these 2 articles (http://schierlm.users.sourceforge.net/TypeConfusion.html and http://weblog.ikvm.net/PermaLink.aspx?guid=cd48169a-9405-4f63-9087-798c4a1866d3 ). This exploit will result in a JAVA sandbox escape and allow the attacker to perform privileged actions.

Exploiting type confusion vulnerabilities are very interesting and very different from exploiting overflow/code execution vulnerabilities. In a sense, it is much easier to perform. To fully understand how it works, we must first discuss about the JAVA sandbox.

[Part 2: Java Applets and Sandboxing]

For the full explanation, refer to http://docs.oracle.com/javase/tutorial/deployment/applet/security.html

In summary, there are 2 types of JAVA applets, Sandbox applets and Privileged applets. As the name suggests, sandbox applets run in a sandbox and have limited access to certain operations. Privileged applets do not have such restrictions but they have to be signed by a recognized CA (Certificate Authority) and the user must give permission to the applet to perform higher privileged operations. Most applets we see are sandbox applets.

The picture below shows some of the restricted operations of sandbox applets.

00

Take special notes of point #1 (cannot access local filesystem and execute files), #2(cannot connect to third party servers), #4(cannot change security level) and #5 (cannot create classloaders).

[Part 3: The Malicious Applet]

Below is the de-obfuscated Javascript code that is responsible for loading the applet.

01

The Javascript first checks that the Java version is Java 6u30 or lower. If it is lower than that, it will fetch the applet from the malicious url and start running the code in the “tampi” class. 2 paramters “peso” and “lapp” are also passed along to the applet.

In the following source codes, I have de-obfuscated some of the strings and variable names so as to make your reading easier. Let’s look at the “init” method of the “tampi” class. The “init” method is first called when a Java applet is loaded.

02

The 2 params that was passed in will be stored into the javaparam_lapp and javaparam_peso variables. Take note of the javaparam_peso which contains a URL link to the malicious server.  I will come back to it later.

Although a sandbox applet cannot create a ClassLoader, it is still able to get a handle to the Applet’s ClassLoader seen on line 17. The “lapp” parameter is the serialized form of an Object[] array. It is decoded by the “foro” method then deserialized by the ObjectInputStream and cast back to its Object[] form on line 19 and 20. The diagram below shows the reconstructed Object[].

03

The Object[] array contains 2 Objects.

  • preyx[] array containing 1 element (null at this point)
  • AtomicReferenceArray (I shall refer to it as ARA) containing 1 element
    • This is actually the same preyx[] array above, only casted as a ARA object

Line 22 to 24 is a Java Reflection call to set the first element of the ARA object to the classloader that was referenced earlier (Line 25 comment line is the non-reflection way to call the same method).  This means a reference to the Applet’s ClassLoader has been assigned into the preyx[] array. This violates JAVA’s type safety and hence a Type Confusion vulnerability.

Line 27 then calls the “juri” method on the first element of the preyx[] array which contains the ClassLoader now. Let’s look at the “preyx” class and its parent class, “odesh

04

05

The preyx class is actually a subclass of the ClassLoader class (See Update #1 for more details).

The “juri” method reads in the “teemb.class” class file and creates a Class object from it with the “defineClass” method on line 16. Take special notice of the last parameter of the method call. This is the “privilege” level to be assigned to this class. An instance of this class is then created on line 17. Let’s look at the “tampi.rous()” method.

06

The commented block is the non-reflection way to call the same methods. This is a typical JAVA privilege escalation method. It creates a ProtectionDomain which has access to “AllPermissions”. By AllPermissions, I mean ALL permissions. This means the “teemb” class would have access to all operations including file I/O onto the local filesystem, network connections to third party servers and so on. The applet can now perform whatever a normal executable jar file can perform when it is run from the local filesystem.

Let’s look at the “teemb” class now.

07

The 3 methods “lewd”, “orly” and “callWriteMethod” are helper methods.

  • lewd – some form of decoding function based on xor
  • orly – reads everything from the inputstream into the input byte array and returns the total number of bytes read
  • callWriteMethod – calls the write method of the specified class

The constructor of the “teemb” class calls the “doPrivileged” method which then calls the “run” method below.

08

Line 53 assigns the malicious URLs in “javaparam_peso” into the arrayOfString variable. For each url in there, the for loop on line 59 is executed. In summary, the for loop perform these operations.

  • Creates the temp file path to store the malicious file
  • Opens a URL stream to the malicious url
  • Read the first 256 bytes from the stream (this is the xor key)
  • If key is read successfully, read in the rest of the stream
  • Decode the rest of the stream with the xor key and store it into the temp file path
  • Use the Runtime class to execute the downloaded file in the temp file path

In gist, this is a Download and Execute code. At this point, the attacker would be able to download any malicious file from the Internet and execute it on the victim’s machine. This defeats all the restriction that was placed on sandbox applets, effectively bypassing the sandbox.

[Update #1]

The purpose of this update is to better explain the role of the vulnerability in this exploit. The original article did not really explain this part clearly.

Earlier in the article, I mentioned that preyx is a subclass of ClassLoader. This means under normal circumstances, the applet would not be able to create a preyx instance (e.g. thru a “new preyx()” call) because sandbox applets are not allowed to create ClassLoaders. CVE-2012-0507 allowed the applet to “smuggle” a reference to a preyx object into the applet’s execution environment without actually creating one.

However, the next question is why is the preyx object important? The answer is privilege escalation. In order to execute malicious operations, a higher privilege level is needed other than the sandbox privilege level. The defineClass method allows the attacker to create a class with a specified “privilege” level (thru the last param of the function call). However, the defineClass is a protected method which means only subclasses of ClassLoader would be able to call it and that is where the preyx class comes in.

To understand this easier, put yourself in the shoes of the exploit writer. The thinking would go something like this.

  • Goal is to run malicious code
  • Need a way to load a class with elevated privilege levels (defineClass method)
  • To call the defineClass method, need a subclass of ClassLoader (preyx class)
  • Normal applet would not allow the creation of a preyx instance, need a way to get a preyx object into the applet environment (CVE-2012-0507 vulnerability)

[End Update #1]

I hope you have gained a better understanding of this exploit. Until next time!!

Glenn (@_graypanda)

[ Technical Tear Down: Fake WeChat Android App (Packed using Bangcle)]

[ Sample used in the analysis ]

MD5: 35C0A075CBC6135D957BD10769E3A620
SHA1: 554FD3D80B696F0677231A54F35B61B5774F2940

This is an Android malware found in the wild. You may be wondering what’s so special about this malware as there are thousands of Android malware out there. Well, this is one of the first few Android malware that has been packed. By being packed, it make reversing almost impossible for  static code analysis. As mentioned in my previous writeup, script from @timstrazz is available if bangcle is used to pack the apk.

As we at vxsecurity.sg always encourages people to get their hands dirty, we have attached the malicious sample here.
The password is “infected29A

[ Tools Used ]
Cebero Profiler is used to disassemble the apk file to analyse the smali code.

Dex2Jar and Java Decompiler are used to decompile the apk file to a jar file and subsequently to get the java code for analysis.

Android Emulator is used for the dynamic analysis portion.

[ Before debangcling the app ]

As explained in my previous writeup, if Bangcle is used to pack an apk, when you try to reverse the file, you will notice a certain pattern like additional library files and new Java class files (ACall.class, ApplicationWrapper.class, FirstApplication.class). As shown in the picture below, this particular .apk when we decompile using dex2jar or disassembled using Profiler also contains similar files.

banksteal-bangcled

One thing my team and i found out is whenever we see this class (com.secapk.wrapper.ApplicationWrapper) and it’s be instantiated by default whenever the process is started.
We can safely deduce that it could have been packed using bangcle. So I tried using the script from @timstrazz found  here to unpack it.

Success!! It could be unpacked 🙂

[ Debangcled APK ]

The resultant of the debangcling process is a dex file which can now be reversed.

debangcled-apk

There are some obvious clues which flags out as a sorethumb to the analyst analysing the apk. Like the package name is called “com.example.banksteal“!! Who names their application banksteal anyway? And furthermore if your package name contains words like “example”, you can’t upload your apk into Google Playstore as it is deem as a generic name. So there are 2 things you can conclude even without analysing anything. 1st: This .apk is obviously from some third party market or circulated elsewhere other than the official Google Playstore. 2nd: This .apk is highly suspicious due to the naming conventions used. You can’t be 100% sure that this is a malware based on the above mentioned 2 pointers. So let’s delve in deeper.

[Analysis]

The app requests for the following permissions:

app-permissions

Upon installing the app, you will get the following icon. This is the popular WeChat Android app, a Whatsapp like instant messaging app. The App is named as “Wēixìn” in Chinese which is the pinyin name for WeChat and means micro message.

bangcle-install

 

When the app is invoked, it will first ask you for device admin permission for lock your phone, it can be seen from the code snippet below taken from the Launcher class.

launcher-device-admin

 

bangcle-activate-lockscreen

and then for your credit card details as shown from the screenshot below when the app is executed on an emulator:

bangcle-creditcard

Next, more details will be asked like the type of bank from which the credit card was issued, card’s cvc number, expiry date, social security number, address etc

bangcle-socialsecurity-number

bangcle-mastercard

Let’s say, I chose the JCB card as my credit card and fill in all the details and click next:

banksteal-email-failed-to-send-out

I am running this in an emulator and it prompts that, “The email/message is not sent out!” I hope that my Chinese translation is accurate but then this raises another question of why a messaging app needs to send out an email. Let’s look into the source code for more evidence.

If you look at the BankData class, it summarises the data it harvests:

bangcle-bankdata

 

Under the Const class you will also get the email address of the receiver.

email

 

There are more clues in the MailUtil class where the host of the receiver is resolved.

email-host

In summary, this app requests for your credit card details and mail out these details.

Well ok, what’s wrong you may ask.

Just that in an actual WeChat app registration/installation no such details are required.

[Actual WeChat App]

Now let’s look at the actual WeChat app’s permissions when downloaded from the Google PlayStore.

real-wechat3

You may think, this looks more malicious as it requests for much more permissions as compared to the previous app!!! But hold on.

Let’s take a look at the registration portion:

real-wechat1

real-wechat2

And that’s it. No credit card nor any bank details is required during installation nor registration of the official WeChat app.

[Conclusion]

The analysed application is an Android malware masquerading as the WeChat android application and request user for their credit card details. Supposedly to give the user a surprise at the end of the month!! On the other end the original app even though it requests for much more permissions, it does not cause financial loss for the user. This reiterates the point that users must not install app from unknown sources or third party markets. Most importantly, whichever app from third party or even the official Google Playstore requests for your credit card details, you are highly recommended to uninstall the app unless you feel generous 🙂

Another unique feature of this app is the usage of a packer. In this case, it is using Bangcle and we already have an unpacker available which helps in our analysis. What if a more complicated packer is used? It will further impede the analysis process. Then we have to only rely on dynamic analysis and if the apk is advanced enough to have anti-emulator techniques etc, how do we overcome this ? I will have another writeup on the possible dynamic analysis paradigm in the near future. If you have ideas, do share with us too.

David Billa (@billa316)

[ Technical Tear Down : Chrome Extension – Pro Visitor ]

Today, I’ll be doing another technical tear-down of a Chrome Extension that does more than what it advertises.
I was alerted to this particular interesting piece of Chrome extension by Janne Ahlberg when he tweeted about it here.
I’ve attached the link to the file here for anyone interested to try analysing it themselves.
nbpaecgogmkifkfgdeoalcilnjigcglb
The password to the attachment is “infected29A
I was encouraged by Emiliano Martinez of VirusTotal to upload this Chrome extension to see whether AV will detect such stuff.
I wasn’t surprised by the final outcome, 0/54
virustotal.com_001
https://www.virustotal.com/en/file/26eb50c2543a3f9c8cff8f01068140a00c639c5fe75843eb5d6175c6208147ba/analysis/1410057947/

[ Sample used in the analysis ]
MD5: bb93188a0e751f95e156f490f612d19f
SHA1: 624b9fd7e08ac10f194b835551f98c0a1c127118

[ How it starts ]
If you access the website, thousandssa[dot]pw, you will see something like the image below.
thousandssa.pw

It will keep prompting visitor(s) of that url to install Firefox extension or Chrome extension.
If you had peeped into the html of the above-mentioned url, you will see this interesting of Javascript below.

I’ve tried to download both the Firefox extension from http://www[dot]defends4987de[dot]asia/profilevisitor[dot]xpi but the url is no longer valid anymore.
So i’ve tried to download the Chrome extension from the official Google Chrome webstore, https://chrome[dot]google[dot]com/webstore/detail/nbpaecgogmkifkfgdeoalcilnjigcglb using my tool here, CRXDownloader

Since it’s an Chrome Extension, let’s check the permissions of this Adware and further dissect it.
Let’s try to understand how Chrome Extension works.
Chrome’s Extension will always require a manifest file, a background.html and possibly some JavaScript files as documented by Google here.

The manifest file, called manifest.json, gives information about the extension, such as the most important files and the capabilities that the extension might use.
For this particular Chrome extension, we can see what sort of permissions did manifest.json request for below.

From the above manifest.json, once user(s) install this Chrome extension.
We can see from the “permissions” that it requires:
“permissions”: [“tabs”, “http://*/*”, “https://*/*”, “webRequest”, “webRequestBlocking”]

For a better understanding of the permissions and what each individual permission mean, the following will be a good reference.
https://developer.chrome.com/extensions/declare_permissions
Of particular interest to us are the “tabs” and “webRequestBlocking
If you had read the documentation for “webRequestBlocking”, the API allows developers to observe and analyze traffic and to intercept, block, or modify requests in-flight.
It sure doesn’t sound safe to me.

From the above manifest.json and the documentation from here.
We can see that it will try to do 2 matches against webpages visited by user(s).
The 1st “Matching” seems like a typical FaceBook application installation url with all the required permission(s) and then running the 2 Javascript(s).
“js/jquery-1.8.2.min.js”, “js/installer.js”
The 2nd “Matching” just wants all the url with a match to “facebook.com” and then run 4 Javascript(s).
“js/jquery-1.8.2.min.js”, “js/bililiteRange.js”, “js/jquery.sendkeys.js”, “js/poster.js”

[ Dissecting installer.js ]
Let’s take a look at “installer.js” and we can see that it’s trying to install the FaceBook application on behalf of the user(s).

[ Dissecting Background.js ]
Let’s take a look at “background.js” and this is actually the more important piece of Javascript in solving the mystery around this Chrome extension.
We can see that once “background.js” actually in this case fetching information from http://shockingvisitor[dot]com (I will name this as C&C for the time being for simplicity sake) to click on “Like” on certain urls that were fetch from the C&C.

From the above information that we have gathered thus far, we can see the following “Domain Whois” information:

If we were to go to “http://shockingvisitor[dot]com/spotify/index.php/message/index”, you will see something like the image below.
shockingvisitor.com

That site probably is where the owner will configure what the Pro-Visitor_v0.6“user(s)” of this Chrome extension will “Like” on FaceBook when they are logged in.

[ Conclusion ]
Remember that i mentioned that this Chrome extension was like what it advertised.
It advertised to do these, “Instantly see who is viewing your profile” & “Check how many photo views you have” but it didn’t. 😛

While this is not a state of the art Chrome Extension Malware, but it’s probably one of the rare & interesting ones out there.
We can even see from the scripts that the author had hastily “Copy/Paste” from elsewhere.
It’s even more interesting that it even managed to survive in Chrome webstore for quite some time.

I hope that this is fairly simple to understand technical tear down that people can repeat the steps on their own and learn how to analyse Potentially malicious Chrome Extension on their own.

Happy Reversing,
Jacob Soo