05 Nov The Android Trojan Svpeng now capable of mobile phishing Roman Unuchek
04 Nov Android 4.4 arrives with new security features - but do they really matter? Stefan Tanase
30 Sep Ad Plus instead of AdBlock Plus Dmitry Bestuzhev
05 Sep Obad.a Trojan now being distributed via mobile botnets Roman Unuchek
17 Aug Android 4.3 and SELinux Stefano Ortolani
14 Aug GCM in malicious attachments Roman Unuchek
Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
Since we published our first blog post about the mobile Trojan Trojan-SMS.AndroidOS.Svpeng, the cybercriminals have improved its functionalities. Now Svpeng is capable of phishing as well, trying to harvest the financial data of users.
When a user launches the banking application of one of Russia’s largest banks, the Trojan substitutes the opened window with a phishing window, designed to steal the victim’s login and password for the online banking system:
The data the user enters is sent to the cybercriminals.
Last week, Google has released the 4.4 (KitKat) version of their omni-popular Android OS. Between the improvements, some have noticed several security-related changes. So, how much more secure is Android 4.4?
When talking about Android 4.4 (KitKat) major security improvements, they can be divided into 2 categories:
1. Digital certificates Android 4.4 will warn the user if a Certificate Authority (CA) is added to the device, making it easy to identify Man-in-the-Middle attacks inside local networks. At the same time, Google Certificate Pinning will make it harder for sophisticated attackers to intercept network traffic to and from Google services, by making sure only whitelisted SSL certificates can connect to certain Google domains.
2. OS hardening SELinux is now running in enforcing mode, instead of permissive mode. This helps enforce permissions and thwart privilege escalation attacks, such as exploits that want to gain root access. Android 4.4 comes compiled with FORTIFY_SOURCE set at level 2, making buffer overflow exploits harder to implement.
In late May we reported on the details of Backdoor.AndroidOS.Obad.a, the most sophisticated mobile Trojan to date. At the time we had almost no information about how this piece of malware gets onto mobile devices. We have since been examining how the Trojan is distributed and discovered that the malware owners have developed a technique which we have never encountered before. For the first time malware is being distributed using botnets that were created using completely different mobile malware.
So far we have discovered four basic methods used to distribute different versions of Backdoor.AndroidOS.Obad.a.
The most interesting of these methods were the ones where Obad.a was distributed along with another mobile Trojan - SMS.AndroidOS.Opfake.a. This was recently described in the blog GCM in malicious attachments. The double infection attempt starts when a user gets a text message containing the following text:
Not many weeks ago Google released a new revision of its flagship mobile operating system, Android 4.3. Although some say that this time updates have been quite scarce, from a security perspective there have been some undeniable improvements (among others, the "MasterKey" vulnerability has been finally patched). One of the most prominent is SELinux. Many cheered the event as a long-awaited move, while others criticized its implementation. Personally, I think that the impact is not that easy to assess, especially if we were to question the benefits for end-users. In order to shed some light we can't help but analyze a bit more what SELinux is, and what is its threat model.
Android OS offers an interesting service known as Google Cloud Messaging, or GCM. This service allows small (up to 4 KB) messages to be sent via the Google server from their mobile devices in JSON format. These messages may contain any structured data, such as links, advertising information, or commands.
In order to use this service, a developer must first receive a unique ID for his applications, which will be used to register the applications with GCM. After registration, the developer may send data to all devices on which the registered applications are installed, or to just some of them.
The service is used to determine the coordinates of stolen telephones, remote phone settings, send out messages about the release of new game levels, new products, and more.
It would be surprising, of course, if virus writers did not attempt to take advantage of the opportunities presented by this service. We have detected several malicious programs that use GCM as a C&C.
Last weeks have been quite busy with announcements of either master keys or Chinese master keys being unveiled, both qualifying as critical vulnerabilities for the Android platform. Although things have finally calmed a bit, we are still waiting for the final act in Las Vegas at Black Hat USA, where Jeff Forristal (the researcher who discovered one of the two afore-mentioned vulnerabilities) will discuss all the pertaining details (you never know whether some surprise is to be expected). Nevertheless, we now have enough information to assess its impact.
First off, the term "master key" is a bit deceiving; the vulnerability, in fact, does not involve any cryptographic primitive, but instead it is all about stashing inside an Android application (the apk file) two versions of the same resource so to partially evade some integrity checks. The impact is, however, prominent, since it means that an adversary is able to tamper with an apk file signed by a trusted authority, so to include a modified resource thereby replacing the genuine one (it is easy too see the case of a modified classes.dex as the most dangerous).
From the user's perspective, this means that an application released and signed by "FamousCompany (tm)" might include some pieces of malicious code without the user noticing. This whole matter, however, is heavily mitigated by the fact that the Play Store (the most widely adopted application store) has been patched so to refuse applications packed as zip files including the same file twice. Nevertheless, based on some reports, some applications in the Play Store are packed like that, although harmlessly, and very likely by mistake (the zip file of the app in question included the same png resource twice). This means, however, that the security checks are only performed upon newly uploaded applications, and do not cover the whole set of applications.
If that was not enough, only few devices (reportedly only the Samsung Galaxy S4) are known to run the code patching this vulnerability. This is quite of interest if we consider that many users retrieve applications from third-party applications stores, which might not vet the uploaded apk files. If the widely discussed device fragmentation is not killing the development industry, we wonder how many users would be likely to accept it if that would result in a constant exposure to bugs like this. Anyway, this is another reason why the very same researchers have released an application checking whether your device is exposed. Kaspersky Lab products actively check that the device is clean from applications exploiting either vulnerabilities by querying the Kaspersky Security Network (KSN). That being said, best way to keep yourself safe from this unwinding chain of events is also avoiding third-party application stores, and leaving the check box "Install from Unknown Source" unselected.
In the past, we've seen targeted attacks against Tibetan and Uyghur activists on Windows and Mac OS X platforms. We've documented several interesting attacks (A Gift for Dalai Lamas Birthday and Cyber Attacks Against Uyghur Mac OS X Users Intensify) which used ZIP files as well as DOC, XLS and PDF documents rigged with exploits.
Several days ago, the e-mail account of a high-profile Tibetan activist was hacked and used to send targeted attacks to other activists and human rights advocates. Perhaps the most interesting part is that the attack e-mails had an APK attachment - a malicious program for Android.
On March 24th, 2013, the e-mail account of a high-profile Tibetan activist was hacked and used to send spear phishing e-mails to their contact list. This is what the spear phishing e-mail looked like:
In regards to the message text above, multiple activist groups have recently organized a human rights conference event in Geneva. We've noticed an increase in the number of attacks using this event as a lure. Here's another example of such an attack hitting Windows users:
Going back to the Android Package (APK) file was attached to the e-mail, this is pushing an Android application named "WUC's Conference.apk".
This malicious APK is 334326 bytes file, MD5: 0b8806b38b52bebfe39ff585639e2ea2 and is detected by Kaspersky Lab products as "Backdoor.AndroidOS.Chuli.a".
After the installation, an application named "Conference" appears on the desktop:
If the victim launches this app, he will see text which "enlightens" the information about the upcoming event:
In mid-February 2013 a Kaspersky user from Malaysia asked us to check a Google Play application called My HRMIS & JPA Demo developed by Nur Nazri.
The user was suspicious about the large number of permissions required by the app, though its only stated function was to open four websites.
Users of inexpensive Android smartphones typically look for ways to accelerate their devices, for example, by freeing up memory. Demand for software that makes smartphones work a little faster creates supply, some of which happens to be malicious. In addition to legitimate applications, apps that only pretend to clean up the system have appeared on Google Play.
We have come across PC malware that infects mobile devices before. However, in this case it’s the other way round: an app that runs on a mobile device (a smartphone) is designed to infect PCs.
On January 22, 2013 Kaspersky Lab discovered the following application on Google Play:
The app is obviously quite popular and has a good rating:
This application has a twin brother that has an identical feature list but a different name: