We've been seeing cases of malware that first debuted on other operating systems being ported over to Android. Here's another trojan that fits the bill.
OpFake was first found on Symbian and Windows Mobile. In its latest incarnation on Android, the trojan (still) appears to be an Opera Mini app… whose only permission request is to send SMS messages:
Turns out the app (we detect it as Trojan:Android/OpFake.D) sends the messages on launch:
In previous cases, we usually saw these SMS messages hard-coded into the classes; this time, the message contents and telephone numbers are stored in a "config.xml" file and are encoded. Here's the garbled code:
The string becomes readable when decoded using base64 decoding, showing the SMS messages sent by the app on execution:
Amidst my usual adventure with Android malware analysis, I saw this snippet of code while skimming through a particular sample's class modules.
Late last year, I was looking deeper into the Portable Network Graphics (PNG) image format, especially the fields that hold textual information. Upon seeing the code, it immediately triggered my suspicion as to why would the application need to check for the existence of the "tEXt" chunk of a PNG file.
I continued to glance through the code and found out where this particular code gets called to identify the image file of interest.
This part of the code tells that the file of interest uses the resource name "icon.png" and is bundled with the application. The image would then be opened and passed to the method where the code that checks for the PNG chunk (Figure 1) is called.
Inspection of the APK package's resources yields three files with similar name. Since it is only interested in the first occurrence of the tEXt chunk, I quickly pulled out a hex viewer and inspected the first tEXt chunk in every file. They all contain the same binary data for that specific chunk. Here is how the image appears when rendered as well as its internal representation in a hex viewer.
This image is also used as the application's icon, therefore, it would be very visible during and after its installation on a device.
As of this moment, the data in Figure 3 made little sense to me but it is also not normal for the tEXt chunk to have a binary data or unreadable string, so I continued to analyze the rest of the code in Figure 1. Further analysis revealed that it reads the hidden data in Figure 3 and performs XOR bitwise operation against a hardcoded text streams (the "key") for each and every byte read.
I am more of a Python person so I created this small script to decode the hidden information from Figure 3, which algorithm is based on what I understood with the rest of the code in Figure 5. After executing the script (Figure 6.a), and to my surprise, I saw some readable English words and numbers!
While it still doesn't give a clear picture of what those plain text information signify to the application, at this point I figured out that it employs steganography to hide these data (Figure 6.b) from within the tEXt chunk data of the PNG file (Figure 3). Looking at the strict definition of steganography though, it's debatable whether this sample would really be considered steganographic, since it is just a simple embedding of encoded data in one of the chunks of the PNG file.
Continuing with the analysis of the rest of the code in Figure 5, it further strengthens the fact that those hidden information (partial screenshot shown below) are used to support the main motive of the application (i.e., sending SMS to premium numbers).
In addition to discovering the code above, I've also run the application on an Android device emulator to verify that it is indeed using those information for the SMS sending operation. And here it shows that an outgoing SMS event was captured with details similar to the decoded data in Figure 6.b (except for the last four digits of the "Message" below). The event happened as soon as I hit the "Next" button from the main UI of the newly installed application.
Facebook is recently doing a decent job at keeping survey spam posts at bay (all things considered).
So, what's an entrepreneurial Facebook spammer to do? Well, some have tweaked their master plan, and have expanded their use of "cloud" services.
Using Amazon's S3 file hosting service solves quite a few problems for these perpetrators. Number 1, Amazon's S3 web service is pretty inexpensive to set up, therefore they can still earn from the surveys. Number 2, because Facebook has been pretty successful at blocking suspicious URLs linked to spam, hosting their scam's code in a safe and popular domain such as amazonaws.com gives them a better chance to sneak through Facebook's protections.
The diagram below basically shows the whole flow of the agenda.
All browsers other than Chrome and Firefox are served with a survey page, thereby ending in actual monetization if the spammer's surveys are filled out and submitted. This monetization happens within the Cost Per Action (CPA) marketing model, which is behind most social media spam. Geo-location techniques are used in an attempt to broaden the spammer's survey completion rate. Depending on the location, the fake Facebook page issues a survey that redirects to a specific affiliate marketer.
Firefox and Chrome are used as avenues to further spread the scam via Facebook by use of a fraudulent YouTube browser plugin. A fake Facebook page displays a plugin installation if visited from either of those two browsers.
Spammers recently began using plugins as part of their cat and mouse battle with Facebook.
Upon installing the plugin, a redirector URL is generated by randomly selecting from the usernames, mo1tor to mo15tor, in the Amazon web service. Then, the link generated is shortened through bitly.com via the use of any of the 5 hardcoded userID and API key-pairs. These key-pars gives a spammer the ability to auto-generate bit.ly URLs for the Amazon web service link. This ultimately leads to a redirection to the fake Facebook page.
Perhaps, in an attempt to confuse defenses, it also produces a random non-existent domain using the format wowvideo[random number].com. However, only the Amazon S3 web service and bit.ly URLs are working links.
Below is the structure of the post:
Title: [Video] Father Melts Baby's Brain With Motorboat Sounds Messages:
• hahaha this video will bend your mind • have you all seen this yet? • stop it! his eyes are going to pop out!! • Its eyes are black because it has no soul • must be experimental technology from mother russia! • im afraid i have some bad news • i want you to all see this
Summary: Total meltdown! I bet you have never seen this before! Main URL: www.wowvideo[random number].com
Here's an example:
The offending add-ons can be removed using "Uninstall" in Firefox and "Remove" in Chrome:
On a side note, the Firefox plugin which was distributed… was archived on a Mac.
Just in case you thought this was a "Windows" problem. ;-)
There's breaking news coming out of Poland. Hackers, reportedly associated with Anonymous, have been attacking Polish government websites to protest this week's scheduled signing of the Anti-Counterfeiting Trade Agreement (ACTA).
ACTA is an intellectual property treaty. Poland announced on January 19 that it would sign the treaty on January 26, 2012.
A Twitter account called @AnonymousWiki called for action against the Polish government.
And, what is also quite interesting and shocking — hackers have claimed that the password and login to premier.gov.pl's admin panel was admin (login) and admin1 (password).
There are also reports a hacked laptop belonging to a deputy of Michał Boni, Poland's Minister of Administration and Digitization.
This situation will develop further.
Updated to add:
Though it is among the sites listed above, we would like clarify that premier.gov.pl was not DDoS attacked, but rather, was hacked and defaced by a group called the Polish Underground, who, according to a Polish colleague of ours, explicitly deny having anything to do with Anonymous.
We're sure that most of you have at least heard of SOPA. Major websites such as Wikipedia have blacked out sections of their content today to raise awareness.
In some locations, Google has blacked out its logo.
The concern of many speech and privacy advocates is that SOPA, which stands for Stop Online Piracy Act, greatly expands the legal authority of US government agencies to seize control of foreign hosted websites, in the name of combating piracy.
And the issue isn't just about Hollywood and "content piracy". Pharmaceutical companies are also involved, and some Canadian based sites are joining today's blackout as well. They fear being lumped in with fake viagra spam related sites.
The related US House and Senate bills can be read from thomas.gov: SOPA; and PIPA, ProtectIP Act.
Ethics, law, and politics aside, we at F-Secure Labs are concerned more about implementation. Laws such as SOPA seem almost guaranteed to start an Internet "arms race" as speech advocates (and yes, pirates) innovate new technologies.
And then those new technologies will get co-opted by criminals (which we've seen happen far too often). Seems better not to start an arms race if you can avoid it.
Also of interest, TED.com will be putting Mikko's TEDxBrussels talk on their front page today as part of their SOPA awareness. Read more about it from the TED Blog.
Brod, a researcher on our Threat Research team has been tasked with tracking emerging Mac based threats. Microsoft Excel is one of the tools he uses to chart variants. From April to December 2011, there have been several dozen new Mac threats.
Well, that's nothing when compared to Windows malware — but it's definitely something when compared to the number of Mac threats seen prior to 2011.
Keep in mind that by "new", we're referring to unique variants, and not the raw number of unique binaries that we've seen. We prefer a more conservative approach when counting malware. The more generic and family based, the better.
As we correctly predicted back in May (YouTube video), Mac malware has not scaled continuously due to market share, but rather, is more the result of opportunist "bubble economies" that have produced new threats in fits and starts.
We expect more of the same for 2012.
Edit: A small revision has been to the spreadsheet linked above.
Yesterday, we stumbled across this ad from an Android-related site:
Clicking this led to a malicious Android Market. Note that this isn't the official Android Market, but a fraudulent site designed to look something like the real thing.
Samples found here are detected as Trojan:Android/FakeNotify.A.
As usual, other malicious sites are hosted on the same IP address as the malicious Android Market. One site that came to our attention claimed to unlock hidden features of the phone. This same site was also found to be promoted in Russian forums.
Upon visiting the site, it indicates that it is a "Phone Optimizer":
The text above mentions that mobile phone manufacturers are known to hide phone functionalities in order to earn money. The idea is that the manufacturers would then earn money through an OS update that unlocks the hidden features. This site claims to check your phone for such hidden features and unlock them.
Here's an example of the scan result, and its English translation:
The phone model was correctly identified by checking the User Agent. The download link leads to a malicious file that sends premium SMS to a number based on the country location.
The malicious page does not only target Android devices. If accessed using an Android phone, it issues a file called optimizer.apk; otherwise, it downloads the file optimizer.jar.
We detect this malware as Trojan:Android/FakeNotify.A (the APK), and Trojan:Java/FakeNotify.C (the JAR).
Our Browsing Protection for Mobile is able to block the malicious links identified in this blogpost:
Incidentally, for our readers: If you guys come upon suspicious mobile samples, please feel free to send them to us for analysis at: android-labs[at]f-secure[dot]com. Please include the keyword "Sample" in the e-mail's subject line.
Threat Insight post by — Raulf and Karmina (Also, thanks to Dima for his Russian contribution and English translation.)
An Android application package (APK) can include multiple modules; one or more of these modules may be an advertisement SDK. That's pretty normal nowadays, as many Android developers currently use such modules to compensate for providing their products to users for free. So what happens if the app is clean, but the ad module is fishy?
When the user accepts and grants permission for the main app to install (assuming they really understood or care about the permissions requested), the user is also by extension allowing the ad modules to use those same permissions. Sometimes, the permissions are only used by the ad module, not the main application.
Currently, Android apps don't differentiate between permissions used by the main app, and those used by the ad modules. And when it comes to security, that's still a gray area, both for users and analysts. As an example, here is a screenshot of the Permissions tab of an ad-supported app downloaded from the official Android Market, with a very generic description of the permissions:
Wouldn't it be clearer to the user if the Permissions tab indicated how the permissions were used by both the main app and the ad module? Or better still, there was a separate permissions tab for the ad module? This would give the user with a clearer idea of what the main app/ad module will do, and they would be in a better position to chose whether they want to proceed with the installation.
We had a recent case that illustrated this — Spyware:Android/AdBoo.A, where the main app was clean, but the ad module was the problem: it collected confidential user information and sent it out to a remote server.
Now, most advertising services need some info from the phone in order to serve "targeted" advertisements, but for AdBoo, we considered that the module was asking for rather too much info. And since the ad module basically shared the permissions of its host main app, there's no way to block the ad module and leave the main app.
Once the permissions are granted to the app, the ad module can proceed. If it only displays legitimate ads, that's fine. If the module includes a questionable routine, that's not so fine. In AdBoo's case, the module collects details from the phone, some of which are highlighted in the screenshot below:
And here are the corresponding Smali codes where these information were actually collected before serving the advertisement banners:
On a related note, currently there is no clear indication whether the app will include ads, or what kind of ads will be displayed, before or during installation. Some developers will clearly state in their documentation that an app will include ads, but not all developers are that thorough. Wouldn't it be clearer for the users if the apps were clearly designated as "ad-supported" or "ad-free"?
And a final issue — not all developers control the type of ads being displayed in their products. Ad modules usually pull materials from third-party advertisement providers, sometimes from multiple services, which makes it trickier all around to control the type of ads being displayed. At worst, that seems to have led to some cases of adult ads being displayed in apps meant for children.
For the fifth year now we are arranging a course on malware (malicious software) analysis in co-operation with Aalto University in Helsinki, Finland. The first lecture is on January 18th by our Chief Research Officer, Mikko Hypponen. If you are studying at Aalto, we'd be glad to see you on the course!
If you have been following the threat landscape, you may have noticed that Android users are increasingly at risk to malware related scams. In our labs this means a lot of hard work with Android malware analysis. A part of this effort is done by one of our researchers, Johannes Rave, who joined F-Secure Labs after attending the Aalto course last year. Johannes is working on his thesis about automatic detection of Android threats. Among other things, he has been looking into automating analysis work by using tools like the PandaBoard development board (pictured below).
On the same note, we've also decided to introduce more Android malware analysis techniques to the course. With some other updates to the agenda, this spring the course is called "Reverse Engineering Malware". After the course we hope that students will have all the skills needed to analyze all types of malware, be it on good old Windows or other platforms such as Android.
Today we've been reading through a 208 page European Commission report called: Special Eurobarometer 359, Attitudes on Data Protection and Electronic Identity in the European Union (PDF). One thing is very clear. European attitudes on digital privacy and identity vary greatly by culture, and even adjoining countries have some interesting differences.