Javascript Malware Cross-Contamination in Android apks

A colleague of mine, specifically from a different AV vendor, was poking around some files and was curious as to what these somewhat odd files where;
VirusTotal Analysis Sha1: e4105ae117e62c784e26ae113a6119bd33a570cf
VirusTotal Analysis Sha1: 16111c45832a20914cfd9306501b406e2ae89b58
An apk (Android package) which is being detected by a ton of vendors, as having a javascript trojan dropper inside of it. Wait what? Is this some interesting new breed of Android malware, possibly leveraging USB attacks too!? Well, no - no it isn’t, it actually just is a curious case of cross-contamination. These files appear to be “infected” inside the embedded HTML files;

1
2
3
4
5
6
champagne:html tstrazzere$ grep -ir "script" * | less
cs/tethering_help.html:
cs/tethering\_usb\_help.html:
cs/tethering\_wifi\_help.html:
da/tethering_help.html:
...

We can see the offending code which is being flagged, nothing to do with any of the actual Android parts. We can see this is the actual detected part by just looking it up on VirusTotal.

1
2
champagne:html tstrazzere$ echo -n $'' | shasum
3c4e3917661442be9ec92adf6ba5b93989a4dd7e -

Which looking up that sha1 gives us;
VirusTotal Analysis Sha1: 3c4e3917661442be9ec92adf6ba5b93989a4dd7e
So does this seem intentional, or accidental? Was someone actually trying to infect Android devices, or was this just a strange mishap? I’m inclined to believe this was just a strange coincidence, both of the applications are the Android settings application, “com.android.settings” - and signed with the commonly found AOSP debug signer. What appears to have happened, is someone was compiling the AOSP, possibly for a custom ROM, and had these HTML files located on an infected host. The virus then infected these HTML files by injecting the javascript load code, and then these APKs where bundled. We can see that these where actually properly bundled;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
champagne:elad tstrazzere$ jarsigner -verbose -verify com.android.settings_1eaffc274ae549e0ecb4145857ae3fa6ad0fd3c5.apk 

39208 Wed Apr 16 07:40:50 PDT 2008 META-INF/MANIFEST.MF
39250 Wed Apr 16 07:40:50 PDT 2008 META-INF/CERT.SF
1714 Wed Apr 16 07:40:50 PDT 2008 META-INF/CERT.RSA
sm 53588 Wed Apr 16 07:40:50 PDT 2008 AndroidManifest.xml
sm 1710 Wed Apr 16 07:40:50 PDT 2008 assets/html/cs/tethering_help.html
sm 1027 Wed Apr 16 07:40:50 PDT 2008 assets/html/cs/tethering\_usb\_help.html
sm 987 Wed Apr 16 07:40:50 PDT 2008 assets/html/cs/tethering\_wifi\_help.html
sm 1433 Wed Apr 16 07:40:50 PDT 2008 assets/html/da/tethering_help.html
sm 833 Wed Apr 16 07:40:50 PDT 2008 assets/html/da/tethering\_usb\_help.html
sm 904 Wed Apr 16 07:40:50 PDT 2008 assets/html/da/tethering\_wifi\_help.html
sm 1585 Wed Apr 16 07:40:50 PDT 2008 assets/html/de/tethering_help.html
sm 922 Wed Apr 16 07:40:50 PDT 2008 assets/html/de/tethering\_usb\_help.html

s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystone
i = at least one certificate was found in identity scope

jar verified.

The interesting part is that the signature did verify, meaning that at time of signing for this APK, that javascript file was included. So did this actually do anything to the devices? No - not really, however there might be someone with a custom ROM which has all these files on their device. Since the url’s being added are all long since dead, there shouldn’t any adverse side effects. Though it would appear that the application is going to read the contents of the HTML files in, then load them into an AlertDialog - where that javascript should not actually perform any actions. As a last side note - I did edit the output that is displayed in this blog to be “hxxp” opposed to “http”. When I didn’t do this, even though the scripts where not being executed, Google Safe Browsing was blocking me from ever seeing my own blog :)