In recent years, malware toolkits aimed at the Windows platform have developed rapidly, with malware authors constantly adding new features and providing greater automation. Though enterprise security teams have been challenged by such sophisticated toolkits, they at least understood that Windows was the primary gateway to an enterprise's key digital assets and could work toward securing that avenue. Despite the explosion of mobile devices on enterprise endpoints, Windows was the gate to the kingdom, with malware authors devoting the lion's share of their resources to the platform. Obad.a, a newly discovered strand of Android malware, may just change that perception.
In this tip, we'll discuss what makes Obad.a noteworthy, how it compares to Windows-based malware and how enterprises can go about mitigating this sophisticated new breed of malware on Android devices.
Researchers at Kaspersky Lab were the first to disclose details on Obad.a, comparing it to Windows-based malware that, at least until this point, has been universally considered to be more sophisticated than anything seen on mobile platforms. When reviewing what the Kaspersky researchers uncovered, it's easy to see that the comparisons they made weren't hyperbole. Obad.a contains much of the same functionality that characterizes most modern Windows malware: It sends premium rate SMS messages (similar to spam), downloads other malware, runs commands on the infected device and attacks other devices over Bluetooth connections. In an update from Kaspersky Lab, they outlined how Obad.a spreads using malicious SMS messages.
All malware authors draw inspiration from existing malware and exploits, and then look to add specific functionality for their malware based on what they're trying to accomplish, so it's not surprising that mobile malware authors would look to highly successful Windows malware for new features. Malware authors of all stripes are now starting to use professional software development practices where programs are modular to include new functionality. In many traditional software projects, the programming environment abstracts some of the complexities of the platform and operating system from the programmer to aid in the development for new platforms and operating systems.
Though the pervasiveness of malware on Android devices is widely known among the information security community, not many security pros are necessarily aware that Android malware authors have started including more advanced functionality from Windows malware. The authors of Obad.a made analyzing its binaries more difficult by encrypting the strings in the file, obfuscating the code and making it more difficult to convert the code to Java code for analysis.
It also exploited two zero-day vulnerabilities to further impede analysis, kept files associated with the malware unlisted and hid itself from the list of applications that have device administrator access. Obad.a checks if the infected device has Internet access, and if so, it downloads the main Facebook Web page to use as the decryption key for the command-and-control (C&C) addresses. Obad.a has a remote shell that can connect to a C&C infrastructure, so it can update itself to include additional functionality. It can also monitor SMS messages for commands to execute.
With all of this said, Obad.a currently represents a low risk for enterprises, having constituted only 0.15% of all Android malware infection attempts detected by Kaspersky. Though many comparisons abound between general Windows malware and this new Android malware, Obad.a still lacks some of the most advanced functionality developed in the last couple of years for Windows machines. Those advanced operations include the ability to extract stored passwords and capture text input, passwords and other sensitive data along with other functions that disable security tools installed on the device to prevent its removal.
Responding to advanced Android malware
Obad.a may represent only a tiny fraction of the malware currently populating Android devices, but enterprises must still be aware of the threat posed by increasingly sophisticated mobile malware. Unfortunately, the fragmented Android ecosystem provides minimal to no protection from the widespread exploitation of Android vulnerabilities. This fragmentation, combined with the reliance on cellular carriers for patching, makes it difficult to apply patches that remediate vulnerabilities exploited by malware on Android systems.
This is where a third-party utility, such as antimalware software or a security monitor, could be used to give additional protection to Android devices. Enterprises, or individuals, may want to investigate third-party patches for Android devices or custom ROMs where the security vulnerabilities were patched. Applying a third-party patch, however, may cause unforeseen issues with stability, support or even potentially the security of the system, much like the issues that can crop up due to third-party patches on Windows. The complexities of patching and managing Android devices without a mobile device management system may outweigh the risk posed by Obad.a, though.
Ultimately, enterprises should take some standard steps outlined by US-CERT for securing mobile devices to combat Obad.a and the like, along with raising basic security awareness among users. According to the first report from Kaspersky, the only functionality made available by Obad.a that allows an infected device to attack another device relies on Bluetooth being enabled, so to eliminate that attack vector, either disable Bluetooth or only enable it when necessary in a trusted environment. Raising the security awareness of users so they don't click on links in potentially malicious SMS messages will also prevent the spread of Obad.a. These steps should go a long way toward preventing the spread of Obad.a in an enterprise environment.
About the author:
Nick Lewis, CISSP, is the information security officer at Saint Louis University. Nick received his Master of Science in information assurance from Norwich University in 2005, and in telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick worked at the University of Michigan and at Boston Children's Hospital, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University.
Learn how to devise a more secure lock screen pattern for Android devices
Deploy Android apps more safely in enterprise environments via the Dexter static analysis tool