On January 15, Goncalo Esteves from Essex, UK plead guilty on 3 charges of computer offenses under UK law:
2 charges against Section 3A of the Computer Misuse Act 1990 (Making/adapting/supplying an article intended for use/to assist in the commission of a section 1 or 3 Computer Misuse offense)
1 charge against Section 327(1) and Section 334 of the Proceeds of Crime Act 2002 (Concealing/disguising/converting/transferring/removing criminal property)
This was the result of a collaborative investigation that Trend Micro and the National Crime Agency (NCA) in the United Kingdom initiated back in 2015, when the two organizations signed a Memorandum of Understanding (MOU) to work together in the fight against cybercrime. This collaboration is not restricted to this case alone, with Trend Micro actively continuing to assist the UK, as well as other international law enforcement partners, in their fight against cybercrime.
Esteves was responsible for the creation of the crypting service Cryptex Reborn and Cryptex Lite, for which he was charged and found guilty. In addition to these, he operated the website reFUD.me, a popular Counter AntiVirus (CAV) service. While not malware themselves, both of these tools were key components that support large underground business models of a number of cybercrime groups.
Both versions of Cryptex are examples of crypting services. They take a particular program—almost always malware—and modify it to attempt to bypass the detection engines of the major antivirus companies. Such modified malware is generally referred to as FUD (Fully UnDetectable). However, this approach primarily focuses on older signature-based scan engines some security solutions use, being substantially less effective against modern cross-generational blends of connected threat defense techniques such as those used in Trend Micro’s XGen solutions. The tool was simply called “Crytpex” in 2011 before branching into the full (Reborn) and limited feature (Lite) versions, with Cryptex Reborn sold for $20 per month or a lifetime offering of $90.
Figure 1. Advertisement for Cryptex listing many of its features
reFUD.me was a Counter Antivirus (CAV) service. Such services allow users to upload a sample they want scanned, and the sample will then be tested for detection against 30-40 of the best-known AV companies’ products.
Cybercriminals can use such services to ensure as few companies as possible detect their malware before deploying it against their targets (again, only based on signature scanning engines). Note that several other multi-scanner services exist, however, a key difference with reFUD.me is that all sharing of samples or feedback data with the various AV companies are disabled. This makes it more useful for anyone concerned with those same AV companies detecting the files they upload.
Figure 2. Example scan result in reFUD.me
In this particular case, not only were two key enablers of criminal activity removed from the internet, but also we hope the conviction sends a strong message to those who provide such tools to support cybercrime. They should realize that they are no more immune from justice than the malware creators themselves.
For us, this is a continuation of Trend Micro’s long-term commitment to work with international law enforcement against those behind cybercrime, to help achieve our goal of making the world safe for the exchange of digital information. On a more personal note, this case all began in mid-2015 with our CTO Raimund Genes signing the MOU with the NCA. Raimund passed away last year, but we’d like to think that he’s proud of the impact this partnership is making.
Figure 3. Picture taken at the signing of the MOU by then Deputy Director of the National Intelligence Hub Steve Haywood, with Trend Micro’s CTO Raimund Genes who passed away last year
by Gilbert Sison, Rheniel Ramos, Jay Yaneza, and Alfredo Oliveira
We came across a new variant of the disk-wiping KillDisk targeting financial organizations in Latin America. Trend Micro detects it as TROJ_KILLDISK.IUB. Trend Micro Deep Discovery proactively blocks any intrusions or attacks associated with this threat. Initial analysis (which is still ongoing) reveals that it may be a component of another payload, or part of a bigger attack. We are still analyzing this new KillDisk variant and we will update this post as we uncover more details about this threat.
KillDisk, along with the multipurpose, cyberespionage-related BlackEnergy, was used in cyberattacks in late December 2015 against Ukraine’s energy sector as well as its banking, rail, and mining industries. The malware has since metamorphosed into a threat used for digital extortion, affecting Windows and Linux platforms. The ransom note, like in the case of Petya, was a ruse: Because KillDisk overwrites and deletes files (and doesn’t store the encryption keys on disk or online), recovering the scrambled files was out of the question.
Figure 1: KillDisk’s infection chain
How is it dropped in the system?
This KillDisk variant looks like it is intentionally dropped by another process/attacker. Its file path is hardcoded in the malware (c:\windows\dimens.exe), which means that it is tightly coupled with its installer or is a part of a bigger package.
Figure 2: The new KillDisk variant’s parameter to shut down the affected machine
KillDisk also has a self-destruct process, although it isn’t really deleting itself. It renames its file to c:\windows\0123456789 while running. This string is hardcoded in the sample we analyzed. It expects its file path to be c:\windows\dimens.exe (also hardcoded). Accordingly, if disk forensics is performed and dimens.exe is searched, the file that will be retrieved will be the newly created file with 0x00 byte content.
How does it delete files?
This new KillDisk variant goes through all logical drives (fixed and removable) starting from drive b:. If the logical drive contains the system directory, the files and folders in the following directories and subdirectories are exempted from deletion:
Program Files (x86)
Recovery (case-sensitive check)
System Volume Information
Before a file is deleted, it is first randomly renamed. KillDisk will overwrite the first 0x2800 bytes of the file and another block that’s 0x2800-bytes big with 0x00.
Figure 3: Code snippets showing how KillDisk overwrites then deletes files
How does it wipe the disk?
The malware attempts to wipe \\.\PhysicalDrive0 to \\.\PhysicalDrive4. It reads the Master Boot Record (MBR) of every device it successfully opens and proceeds to overwrite the first 0x20 sectors of the device with “0x00”. It uses the information from the MBR to do further damage to the partitions it lists. If the partition it finds is not an extended one, it overwrites the first 0x10 and last sectors of the actual volume. If it finds an extended partition, it will overwrite the Extended Boot Record (EBR) along with the two extra partitions it points to.
Figure 4: Code snippets showing how KillDisk reads/scans the MBR (top, center), and overwrites the EBR (bottom)
What happens after the MBR, files, and folders are overwritten and/or deleted?
KillDisk has a numeric parameter that denotes the number of minutes (15 being the default) it will wait before it shuts down the affected machine. To try to reboot the machine, it will try to terminate these processes:
Client/server run-time subsystem (csrss.exe)
Windows Start-Up Application (wininit.exe)
Windows Logon Application (winlogon.exe)
Local Security Authority Subsystem Service (lsass.exe)
This is done most likely to force a reboot or dupe the user into restarting the machine. Terminating csrss.exe and wininit.exe, for instance, will cause a blue screen of death (BSOD). Terminating winlogon.exe will prompt the user to log in again, while terminating lsass.exe will cause a reboot. KillDisk also uses the ExitWindowsEx function to forcefully restart the machine.
Figure 5: Code showing KillDisk forcefully rebooting the system
What can organizations do?
KillDisk’s destructive capabilities, and how it could be just a part of a bigger attack, highlight the significance of defense in depth: securing the perimeters — from gateways, endpoints, and networks to servers — to further reduce the attack surface. Here are some best practices for organizations.
Keep the system and its applications updated/patched to deter attackers from exploiting security gaps; consider virtual patching for legacy systems.
Deploy security mechanisms such as application control/whitelisting and behavior monitoring, which can block suspicious programs from running and thwart anomalous system modifications.
Proactively monitor the system and network; enable and employ firewalls as well as intrusion prevention and detection systems.
Implement a managed incident response policy that will drive proactive remediation strategies; further strengthen the organization’s security posture by cultivating a cybersecurity-aware workplace.
Trend Micro XGen security provides a cross-generational blend of threat defense techniques against a full range of threats for data centers, cloud environments, networks, and endpoints. It features high-fidelity machine learning to secure the gateway and endpoint data and applications, and protects physical, virtual, and cloud workloads. With capabilities like web/URL filtering, behavioral analysis, and custom sandboxing, XGen protects against today’s purpose-built threats that bypass traditional controls and exploit known, unknown, or undisclosed vulnerabilities. Smart, optimized, and connected, XGen powers Trend Micro’s suite of security solutions: Hybrid Cloud Security, User Protection, and Network Defense.
In the second half of 2017 Pawn Storm, an extremely active espionage actor group, didn’t shy away from continuing their brazen attacks. Usually, the group’s attacks are not isolated incidents, and we can often relate them to earlier attacks by carefully looking at both technical indicators and motives.
Pawn Storm has been attacking political organizations in France, Germany, Montenegro, Turkey, Ukraine, and the United States since 2015. We saw attacks against political organizations again in the second half of 2017. These attacks don’t show much technical innovation over time, but they are well prepared, persistent, and often hard to defend against. Pawn Storm has a large toolset full of social engineering tricks, malware and exploits, and therefore doesn’t need much innovation apart from occasionally using their own zero-days and quickly abusing software vulnerabilities shortly after a security patch is released.
In summer and fall of 2017, we observed Pawn Storm targeting several organizations with credential phishing and spear phishing attacks. Pawn Storm’s modus operandi is quite consistent over the years, with some of their technical tricks being used repeatedly. For example, tabnabbing was used against Yahoo! users in August and September 2017 in US politically themed email. The method, which we first discussed in 2014, involves changing a browser tab to point to a phishing site after distracting the target.
We can often closely relate current and old Pawn Storm campaigns using data that spans more than four years, possibly because the actors in the group follow a script when setting up an attack. This makes sense, as the sheer volume of their attacks requires careful administration, planning, and organization to succeed. The screenshots below show two typical credential phishing emails that targeted specific organizations in October and November 2017. One type of email is supposedly a message from the target’s Microsoft Exchange server about an expired password. The other says there is a new file on the company’s OneDrive system.
Figure 1. A sample of a credential phishing email Pawn Storm sent in October and November 2017
Figure 2. Second type of credential phishing email that was sent by Pawn Storm in November 2017. The logo of the target organization has been removed from the screenshot and the color was changed as not to reveal the source.
While these emails might not seem to be advanced in nature, we’ve seen that credential loss is often the starting point of further attacks that include stealing sensitive data from email inboxes. We have worked with one of the targets, an NGO in the Netherlands targeted twice, in late October and early November 2017. We successfully prevented both attacks from causing any harm. In one case we were able to warn the target within two hours after a dedicated credential phishing site was set up. In an earlier attack, we were able to warn the organization 24 hours before the actual phishing emails were sent.
Olympic Wintersports Federations
We have seen several International Olympic Wintersport Federations, such as the European Ice Hockey Federation, the International Ski Federation, the International Biathlon Union, the International Bobsleigh and Skeleton Federation and the International Luge Federation, among the group’s targets in the second half of 2017. This is noteworthy due to the timing correlation between several Russian Olympic players being banned for life in fall, 2017. In 2016, Pawn Storm had some success in compromising WADA (the World Anti-Doping Agency) and TAS-CAS (the Court of Arbitration for Sport). At that time, Pawn Storm sought active contact with mainstream media either directly or via proxies and had influence on what some of them published.
In the week of the 2017 presidential elections in Iran, Pawn Storm set up a phishing site targeting chmail.ir webmail users. We were able to collect evidence that credential phishing emails were sent to chmail.ir users on May 18, 2017, just one day before the presidential elections in Iran. We have previously reported similar targeted activity against political organizations in France, Germany, Montenegro, Turkey, Ukraine, and the United States.
Beginning in June 2017, phishing sites were set up mimicking the ADFS (Active Directory Federation Services) of the U.S. Senate. By looking at the digital fingerprints of these phishing sites and comparing them with a large data set that spans almost five years, we can uniquely relate them to a couple of Pawn Storm incidents in 2016 and 2017. The real ADFS server of the U.S. Senate is not reachable on the open internet, however phishing of users’ credentials on an ADFS server that is behind a firewall still makes sense. In case an actor already has a foothold in an organization after compromising one user account, credential phishing could help him get closer to high profile users of interest.
The future of politically motivated campaigns
Rogue political influence campaigns are not likely to go away in the near future. Political organizations have to be able to communicate openly with their voters, the press and the general public. This makes them vulnerable to hacking and spear phishing. On top of that, it’s also relatively easy to influence public opinion via social media. Social media platforms continue to form a substantial part of users’ online experience, and they let advertisers reach consumers with their message.
This makes social media algorithms susceptible to abuse by various actors with bad intentions. Publishing stolen data together with spreading fake news and rumors on social media gives malicious actors powerful tools. While a successful influence campaign might seem relatively easy to do, it needs a lot of planning, persistence, and resources to be successful. Some of the basic tools and services, like ones used to spread fake news on social media, are already being offered as a service in the underground economy.
As we have mentioned in our overview paper on Pawn Storm, other actors may also start their own campaigns that aim to influence politics and issues of interest domestically and abroad. Actors from developing countries will learn and probably adapt similar methods quickly in the near future. In 2016, we published a report on C Major, an espionage group that primarily targets the Indian military. By digging deeper into C Major’s activities, we found that this actor group not only attacks the Indian military, but also has dedicated botnets for compromised targets in Iranian universities, Afghanistan, and Pakistan. Recently, we have witnessed C Major also showing some interest in compromising military and diplomatic targets in the West. It is only a matter of time before actors like C Major begin attempting to influence public opinion in foreign countries, as well.
With the Olympics and several significant global elections taking place in 2018, we can be sure Pawn Storm’s activities will continue. We at Trend Micro will keep monitoring their targeted activities, as well as activities of similar actors, as cyberpropaganda and digital extortion remain in use.
Last year, we saw the Fanta SDK malware target Russian bank Sberbank users and employ unique defensive measures. Now, another bank malware family has appeared, targeting even more Russian banks while using new and evolved obfuscation techniques. This family is named FakeBank, and so far the related samples we have collected number in the thousands. These samples show that the malware targets not only Sberbank, but also other Russian banks like Letobank and the VTB24 bank. Our samples have random package names and pose mostly as SMS/MMS management software to lure users into downloading them. The table below shows the samples’ names:
English Translation of Russian Names
ММС – Пoсланиe
ММС – Send
ММС – Сообщениe
CМC – Фотo
CМC – Photo
СMС – Соoбщение
СMС – Composition
СMC – Послание
СMC – Message
Table 1. Names of the banking malware samples
Actually, these advertised SMS management capabilities are turned against the victim. The malware intercepts SMS in a scheme to steal funds from infected users through their mobile banking systems.
The banking malware have spread mainly across Russia and other Russian-speaking nations. The table below shows a list of detections per country.
Figure 1. Top countries where samples were detected; there were detections in other countries but they totaled less than 1%
Intercepting SMS leads to transferring funds
The malicious app can control an infected user’s open and close network function and also silently connect to internet. This means that it can send information to its command and control server (C&C) without the user’s knowledge. It also inspects the device for anti-virus software, and if detected, will exit without executing any malicious behavior. This is a tactic that helps it remain unreported and under the radar.
The malware also steals information from the device and uploads it to the C&C server. The sensitive data collected includes: users’ phone numbers, a list of installed banking apps, the balance on any linked bank card, and even location information.
Figure 2. Captured network packet
Figure 3. The app collects the balance of whatever card is connected to the app
To further guarantee the success of the data collection, the malware forbids the user from opening the device settings, likely to prevent uninstallation. Some samples we detected also required admin privileges from the user, which gives the malware even more access to the device.
Figure 3. Once the malware is installed, the icon appears on the device screen and asks for permissions
Figure 4. Once the user approves this request, the icon disappears and the malicious behavior starts
The malware goes further and even takes over the user’s SMS. First it replaces the default SMS management program with its own and hides the icon. This way it can upload and analyze any SMS received and even delete any messages locally. This means that any verification or query from the bank to the user can be intercepted and removed. It can even call an assigned phone number, send specified SMS, and steal call logs and contact lists.
Most significantly, all this access to the device’s SMS gives the malware an avenue to silently steal money from users’ bank account. Since users bind their bank accounts to their device and receive notifications on the same device, the malware can intercept sensitive account information. It can then reset bank account passwords through received security code messages and start transferring money.
FakeBank also stops the user from opening the target bank’s legitimate app, to prevent any modifications to the relationship between the bank card number and your phone number. We can assume that the malware developer is very familiar with the bank message format and transfer process, as all the payment SMS notifications are noted and scrambled by C&C.
It is worth noting that the National Institute of Standards and Technology (NIST) officially discouraged the use of SMS as a method of two-factor authentication. Mobile users should choose other means of authentication if it is offered by the apps and services they use.
One malicious payload, with evolved obfuscation
One of the notable elements of this malware is the way it hides its payload. The malware has different behaviors that make it harder for infected users to get rid of it, and for security solutions to detect it.
It actually uses three different methods to obfuscate the malicious payload. The techniques range in complexity and the developers seem to be taking a multilayered approach to avoid exposure.
The first layer of obfuscation is a common shell protection, which is a frequently used technique. There are actually some open source tools or services that provide shell protection to APKs. But it is also easy to reverse. A single standard memory dump will allow someone to get the real meaningful code.
In the next layer, the malware developers use reflection (a means for an application to collect information or manipulate itself) to invoke all the system calls. This is simply a confusion tactic to make the code harder to understand. The malware also encrypts all of its strings, including the class name and functions, and joins them as a file in the assets folder. They typically use standard encryption methods like (DES/BASE64) or a simple bit operation. Below are some snippets of code illustrating the techniques:
Figure 5. Code to reflect invoke system calls, showing basic string obfuscation for class name and method name before decryption
Figure 6. Code to reflect invoke system calls, showing basic string obfuscation for class name and method name after decryption
The malware uses runtime decryption to find specific strings. The code below shows how it locates exact strings through an index for concrete functions which reference an encrypted file in the assets folder.
Figure 7. This function hides the icon of the malicious app
The entire procedure described above is running in a native .SO file. This means that the code is more flexible. Also to deobfuscate it, dynamic analysis and a hook are needed.When the malware app loads a .SO file, it will decrypt it and generate the strings in the memory.
Figure 8. How the malware decrypts and generates the string
Again, the malware finds the exact string through an index and uses a native call for the concrete function.
Figure 9. This function again hides the icon; it’s the same function as Figure 5.
Though the first technique is easily resolved, the others are problematic methods of obfuscation. Layering all these techniques in one sample shows that the developers are more committed to evading detection and experimenting with different techniques to achieve success.
Looking into the C&C infrastructure
The malware has registered numerous C&C domains and many of the domain names are recent, with some still alive. These C&C domains have common IP addresses (184.108.40.206 and 220.127.116.11) that are located in Poland Warmia-Masuria. Other IP addresses (18.104.22.168 and 22.214.171.124) are located in Russia.
These C&C address have the same format: http://hxxp[domain]/[random str]/index.php.
Based on the Whois information for C&C domain, we found that most are registered under the same company. This company is known to be connected to other fraudulent domains, and has been outed by other news sources. It is possible that the registrar has set up privacy protection for the registrants of fraud domains.
Users should be wary of downloading apps from untrusted sources. And devices should also be equipped with comprehensive mobile security that can mitigate mobile malware. Trend Micro Mobile Security Personal Edition and Mobile Security Solutions detect all related threats in this attack. And Trend Micro’s Mobile App Reputation Service (MARS) covers Android and iOS threats using leading sandbox and machine learning technologies. It can protect users against malware, zero-day and known exploits, privacy leaks, and application vulnerability. For a list of the IOCs related to this threat please see the appendix for this post.
This year’s first Patch Tuesday is a busy one. Microsoft released 56 updates that include patches for the Meltdown and Spectre vulnerabilities. The patches also addressed security issues in Windows OS, Internet Explorer, Edge, Office, ChakraCore, ASP.NET, and .NET Framework. Sixteen were rated critical and 38 important, 20 of which can result in remote code execution (RCE).
Three of these were disclosed through Trend Micro’s Zero-Day Initiative:
CVE-2018-0796 — an RCE vulnerability in Microsoft Excel
CVE-2018-0758 — a memory corruption vulnerability in the scripting engine in Microsoft Edge
CVE-2018-0772 — a memory corruption vulnerability in Microsoft browser-related services (Internet Explorer, ChakraCore, Edge)
Note that Microsoft implemented a new process for delivering patches. A registry key that verifies the compatibility of the antivirus (AV) software with the OS/system is now required in order to deploy and apply patches. Trend Micro customers can find additional product-specific information and solutions — such as adding specific registry key — via these technical support articles for Home and Home Office users and Businesses.
Meltdown and Spectre
On January 3, Microsoft released an emergency update for Windows 10 as well as recommendations and best practices for clients and servers. This month’s Patch Tuesday included updates for other operating systems, but Microsoft held off on rolling out patches for devices running on AMD processors, citing reports that they became unbootable (blue screen of death) after the updates were installed. Microsoft is currently working with AMD to resolve this issue. The fixes’ impact on PC and server performance varies; it also depends on the system’s workload.
Apple also released its patches for Spectre (CVE-2017-5753 and CVE-2017-5715) in macOS High Sierra, iOS, and Safari. Apple addressed Meltdown (CVE-2017-5754) last January 5. Meltdown and Spectre are ecumenical; the U.S. Computer Emergency Readiness Team (US-CERT) has a list of affected vendors and references on their advisories, such as Google (e.g., Android) and Linux Kernel’s.
Other Notable Vulnerabilities
Of note is CVE-2018-0802, a memory corruption vulnerability in Microsoft Office reportedly under attack. Exploiting it entails luring a would-be victim with a specially crafted malicious document. The attack chain resembles that of a similar vulnerability (CVE-2017-11882) that was actively exploited by various hacking groups in mid-December last year. The security update addresses CVE-2018-0802 by removing the Equation Editor functionality.
CVE-2018-0786 is a vulnerability in .NET Framework and .NET Core related to certificate validation. As per Microsoft’s advisory, an attacker can exploit this flaw by sending a specially crafted certificate marked as invalid to a vulnerable, targeted system, but whose components are used for a specific purpose. It bypasses Enhanced Usage Key tagging/application policies, which, in turn, can allow hackers to carry out further attacks.
Meanwhile Adobe released an update (APSB18-01) addressing an out-of-bounds read vulnerability (CVE-2018-4871) in Adobe Flash that can lead to information exposure when successfully exploited. This was disclosed via Trend Micro’s Zero Day Initiative.
We spotted a malicious app (detected by Trend Micro as ANDROIDOS_BKOTKLIND.HRX) that appears to be the first developed using Kotlin—an open-source programming language for modern multiplatform applications. The samples we found on Google Play posed as Swift Cleaner, a utility tool that cleans and optimizes Android devices. The malicious app, which has 1,000-5,000 installs as of writing, is capable of remote command execution, information theft, SMS sending, URL forwarding, and click ad fraud. It can also sign up users for premium SMS subscription services without their permission.
Figure 1. Swift Cleaner, the malicious app posing as an Android cleaning app
Using Kotlin to develop malware
Google announced Kotlin as a first-class language for writing Android apps in May 2017. Since Kotlin’s release, 17 percent of Android Studio projects started to use the programming language. Twitter, Pinterest, and Netflix are among the top apps that use Kotlin.
Kotlin is described as concise, drastically reducing the amount of boilerplate code; safe, because it avoids entire classes of errors such as null pointer exceptions; interoperable for leveraging existing libraries for JVM, Android, and the browser; and tool-friendly because of its capability to choose any Java IDE or build from the command line.
Its tooling support is also quite handy: Android Studio 3.0 provides tools for helping users with Kotlin. In addition, it can convert all Java files or code snippets on the fly when pasting Java code into a Kotlin file.
However, it’s still unknown if the abovementioned features of Kotlin can make a difference when creating malware.
Figure 2. Package structure of the malicious app developed using Kotlin
Upon launching Swift Cleaner, the malware sends the victim’s device information to its remote server and starts the background service to get tasks from its remote C&C server. When the device gets infected the first time, the malware will send an SMS to a specified number provided by its C&C server.
Figure 3. Malicious app collects and sends victim’s device information via SMS
After the malware receives the SMS command, the remote server will execute URL forwarding and click ad fraud.
Figure 4. Left: C&C server sends task via network. Right: code snippet of the malware in process.
Figure 5. Malicious app uploading the finished task to the C&C Server
The malware can also upload the information of the user’s service provider, along with the login information and CAPTCHA images, to the C&C server. Once uploaded, the C&C server automatically processes the user’s premium SMS service subscription, which can cost the victim money.
Figure 6. The malicious app uploads the token that will be used to subscribe to a premium SMS service
Figure 7. The malicious app uploads the CAPTCHA image used to subscribe to a premium SMS service
Users should take advantage of mobile security solutions such as Trend Micro Mobile Security to block threats from app stores before they can be installed. Enterprise users should consider installing a solution like Trend Micro Mobile Security for Enterprise. This features device management, data protection, application management, compliance management, configuration provisioning, and other features so employers can balance privacy and security with the flexibility and added productivity of BYOD programs.
Trend Micro’s Mobile App Reputation Service (MARS) covers Android and iOS threats using leading sandbox and machine learning technology. It can protect users against malware, zero-day and known exploits, privacy leaks, and application vulnerability.
We have disclosed this security issue to Google, who verified that Google Play Protect has protections in place to protect users from this malware family.
The vulnerability can allow an attacker to steal information such as passwords, encryption keys, or essentially anything that the affected system has processed. Unfortunately, the desire to improve performance significantly compromised the existing security building blocks of mainstream operating systems (Windows, Linux, and Mac OS at least) that protects the privacy of user data. Proof of concept code for both attacks has been made public; no attacks are believed to have used these newly discovered vulnerabilities.
This post explains what these vulnerabilities are, how these vulnerabilities arose in the first place, and what vendors are doing to mitigate this threat.
Background: What is Memory Isolation
Memory virtualization is one of the basic security concepts in current operating systems. It brings memory isolation between user processes, ensuring one user cannot access and modify another user’s data. This is implemented nowadays with paging. There are large and complex kernel tree structures for each process called page tables (PT), describing the mapping between virtual and physical addresses and also defining access privileges. Supporting hardware called the memory management unit (MMU) in each modern CPU ensures this translation will be as efficient as possible. There are several layers of caches, called the translation lookaside buffer (TLB), that contain translation data. Each TLB miss leads to a time-consuming lookup in the PT hierarchy executed by the page fault trap handler.
Current operating systems like Windows, Linux, and macOS (including their mobile derivatives like Android and iOS) all use the same concept. Initially, it was expected that kernel privileged code and data would be mapped to the same virtual address of each process to simplify kernel code access to user data. Each change of virtual mapping (switching PT) usually leads to TLB flushing and is inevitable during process context switches. There was another reason for mapping kernel space to user virtual space – to reduce TLB misses when changing a virtual address mapping during the switch from user mode to the kernel code and back. This was so common that Intel recommended it as a best practice and allocated a single register to keep a pointer to the actual PT. This register is then expected to be populated during context switches. The ARM architecture, by contrast, has two PT pointer registers instead.
Kernel code/data is protected from direct access by user code with MMU access control. Many kinds of attacks have been discovered exploiting kernel code bugs, leading to privilege escalation and system control. To carry out these attacks, the attacker would need to know two things: what the vulnerability is, and what is the address of related kernel code and/or data.
To defend against this, operating systems implemented address space layout randomization (ASLR) years ago. Specifically, in the case of the kernel, it is kernel ASLR (KASLR). Protection is based on keeping the addresses of kernel structures secret from user processes. There are many attacks against KASLR, some of which can be found here. Many of these attacks are based on measuring statistical differences between accessing memory when TLB is hit or missed; these statistics are based on the hardware implementation of the MMU and cannot be easily hidden.
In October 2017, researchers from Graz TU published a proposal to split the process PT into two. One is active when the process is executing kernel code (this is essentially the original PT). The second is a partial copy used for mapping user pages and some additional kernel pages needed for context switching, syscalls, and interrupt handling. The rest of kernel space is invisible; this PT is active when executing in user space. The kernel switches between these PTs when it is entering and exiting the syscall. This technique was called KAISER (Kernel Address Isolation to have Side-channels Efficiently Removed) and was able to defend against all known KASLR attacks with an added overhead of less than 1%.
Soon enough, work began to implement KAISER. In the Linux kernel, urgent (but silent) work began on a kernel page-table isolation (KPTI) implementation in November of 2017, which was based on KAISER. This part of the kernel is sporadically changed, with discussions taking place long before any code is written. Needless to say, the work to implement KPTI caught the attention of some observers because of its unusual nature.
Changes in this part of the kernel can have a significant impact on performance. Early tests showed a 5% impact in most cases, with worst-case tests indicating a 50% performance hit. On November 16, it became clear that something like KAISER was being implemented in Windows as well. The Linux KPTI was finally committed to the kernel on December 29.
Meltdown and Spectre
It soon became clear why KAISER was suddenly being implemented: it was an effective defense against Meltdown.
Both Meltdown and Spectre rely on security flaws in the speculative execution of CPU instructions. Modern processors are so fast that executing instructions in order one-by-one would lead to the CPU waiting for memory access, which takes several hundred clock cycles. Modern CPUs try to execute instructions that are ready for execution while waiting for memory read/write operations. It can be checked later if the instructions that were executed speculatively were correct; if the results are not needed, the effect on the CPU’s internal state and memory should be removed. This is called speculative execution and out of order execution.
Unfortunately, some side effects of speculative execution remain in the CPU’s state at low levels. For example, if there is an unsuccessful speculative move of a word from memory to a register at the end, the register contains the original value, but the cache is modified by the read cycle. The researchers who discovered Meltdown and Spectre used low-level CPU states to gain access to protected memory regions.
Meltdown (CVE-2017-5754) allows an unprivileged user to access the complete kernel (and physical) memory of a computer. This attack is relatively simple to execute; to carry it out, attackers need to run their own program on the target system. This attack is particularly damaging to shared systems (such as cloud services), as an attacker with access to one virtual machine can use Meltdown to access other VMs on the same physical system. Meltdown is specific to Intel systems; AMD and ARM processors are not affected.
Spectre (CVE-2017-5753, CVE-2017-5715) is a broader vulnerability. Spectre relies on issues with speculative execution itself to be carried out. In its current form, the attack is more complicated as more prerequisites must be fulfilled. One of them is a code gadget, which must be found in code shared by both victim and attacker. One Spectre variant limits attack to a single process space; the second requires superuser access.”
The real challenge with Spectre is mitigation. Unlike Meltdown (which could be mitigated via patches to the operating system), Spectre requires changes to the hardware itself. All modern x86 processors from Intel and AMD, as well as ARM processors, are believed to be vulnerable. This makes mitigating this vulnerability extremely costly, making it a long-term problem for the technology industry as a whole. Now that awareness about Spectre and the problems with speculative execution have been raised, it is up to CPU manufacturers to see how both high performance and good security can be maintained moving forward.
Solutions and best practices
Users have no way to mitigate this threat; the responsibility of doing so ultimately falls on vendors who have released multiple patches to mitigate Meltdown. Microsoft has released documents that cover both server and client versions of Windows:
Apple’s December updates for macOS (released last December 2017) already resolved this vulnerability as well. As noted earlier, patches for Meltdown have been merged into the Linux kernel. It is up to individual vendors to release this update for their distribution; some vendors such as Debian, Red Hat, and SUSE have released bulletins and patches as appropriate.
In early December, we found a total of 36 apps on Google Play that executed unwanted behavior. These apps posed as useful security tools under the names Security Defender, Security Keeper, Smart Security, Advanced Boost, and more. They also advertised a variety of capabilities: scanning, cleaning junk, saving battery, cooling the CPU, locking apps, as well as message security, WiFi security, and so on.
The apps were actually able to perform these simple tasks, but they also secretly harvested user data, tracked user location, and aggressively pushed advertisements.
Figure 1. Malicious apps found on Google Play, detected by Trend Micro Mobile Security
We notified Google of these apps, and at the time of writing all the apps have been removed from Google Play.
After first launching, the apps will not appear on the device launcher’s list of applications, and shortcuts will also not appear on the device screen. Since the apps are hidden, users will only see the notifications sent by the app. They typically push alarmist security warnings and pop-up windows to the users.
Figure 2. Code snippet showing how icon is hidden
After manual inspection, we found that this action is conditional. The “hide” function of the malware is explicitly designed not to run on specified devices, as seen in the code below:
Figure 3. The malware code showing how specific devices are excluded from the “hide” behavior
The excluded devices are: Google Nexus 6P, Xiaomi MI 4LTE, ZTE N958St and LGE LG-H525n. It is possible the malware developers knew that this tactic would not work on these devices, or they wanted to avoid being checked by Google Play during inspection periods.
Once the app is running, the user will be bombarded with “security” notifications and other messages from the malware. After checking the original code, we found that most detection results from the notifications are false. For example, if the user installs another app, then it will immediately be reported as suspicious. Or the user will be sent notifications like “10.0 GB files are being wasted,” which will prompt some kind of action.
But the data shown in these messages are fake — they are just used to add a layer of legitimacy to the app.
Figure 4. The many notifications with fake data being pushed by this app
The developers of these apps go far to make their notifications believable. For an example, see the figure below. If the user clicks the button to resolve the detected “Fraud SMS Broadcast Vulnerability,” then the app will just show a simple animation illustrating that the problem has been ‘resolved.’ This way, the user will think the app is working and will not be suspicious of it.
Figure 5. The detection result about System Vulnerability
Figure 6. Code snippet for the RESOLVE button
But as the app sends these notifications, it is also able to collect the victim’s private data, including specific location details, and send them to a remote server.
Figure 7. Code snippet showing how the app collects private data of user
Also, when the user is bombarded with all these notifications, many different advertisements appear. The aggressive ads show up during many different scenarios — for example, after the app sends notices to unlock the device screen or if the user is told to connect to a charger. The user is bombarded with ads with almost every action. It is clear that one of the main focuses of the app is ad display and click fraud.
Users are actually asked to sign and agree to a EULA (end-user license agreement) which describes the information that will be gathered and used by the app. But we can still say that the app abuses privacy because the collection and transmission of personal data is unrelated to the functionality of the app.
The app is able to upload user data information, installed app information, as well as attachments, user operational information, and data on activated events to a remote server. We can see in Figure 7 how user information and the user’s operational events can be uploaded.
Figure 8. The leaked privacy data of user operation
The apps can also collect private data like the Android ID, Mac address, IMSI (which identifies the network operator the user is subscribed to), information about the OS, brand and model of the device, device specifics (like dots per inch and screen size), language, location information (from the city the device is in to the longitude and latitude), and data on installed apps like Google Play and Facebook. The app also notes what permissions are granted or not, specifically, usage stats, accessibility, and read notification bar.
To secure mobile devices and protect valuable data, there are certain steps you can take. Here are some tips:
Vendors are usually quick to patch their applications and software so users should always have the latest version. Updating is essential for keeping mobile devices as secure as possible against known threats.
Download apps from trusted sources. Users should check reviews or comments on the app page to make sure it is legitimate and has no unwanted behaviors.
Manage what is shared online. Make sure to use privacy settings on all your apps and sites. Some sites can broadcast location, email, phone numbers, or more to the public by default.
Be aware of the scope of app permissions. Apps sometimes require more than the basic default permissions. Make sure the installed apps only have access to features they need.
Users should also invest in multilayered mobile security solutions that can protect devices against online threats, malicious applications, and even data loss. Able to protect both enterprises and individuals, Trend Micro Mobile Security has advanced protection capabilities that can identify known threats and prevent them from damaging mobile devices or compromising data.
Our appendix lists the indicators of compromise (IoCs).
As manufacturers develop Internet of Things (IoT) devices that integrate with widely popular internet-based applications, more and more users see the value in purchasing such devices. Ease of integration becomes an incentive for users to consider adding these products to their network of devices. But while the ease of use can be enticing, these products can also be susceptible to security issues that could introduce far-reaching problems.
To see just how safe and secure IoT devices are and to what extent an attacker can manipulate an IoT device, we tested the built-in security of a particular IoT device type — internet-connected speakers.
A Sound Hack
For our case study titled The Sound of a Targeted Attack, we tested a fairly popular IoT device and discovered that it exposed user data along with other pertinent information that can be used in an attack. In the case study, we used the Sonos Play:1 as our test unit and also looked into the Bose SoundTouch. After the tests, we reached out to Sonos, which responded quickly to fix the security gaps. The gaps addressed include a denial-of-service (DoS) bug which now returns an HTTP error code 412 (Precondition failed). A more detailed account of the updates made by Sonos can be found in the case study. We also reached out to Bose and are currently waiting for their response.
Whereas previous studies focused on seizing control of speakers like the Amazon Echo and Google Home, the results of our case study led to unique findings. These include security gaps that resulted from a simple open port that gave anyone on the internet access to the device and user information. The first glaring finding was access to email addresses that are linked to music streaming services synced with the device. Another was access to a list of devices as well as shared folders that were on the same network as the test device. We also got BSSID information that, paired with an existing API that queries specific BSSIDs, gave us the approximate location of access points used by the test unit. And lastly, we were able to see the device’s activities, such as current songs being played, control the device remotely, as well as play music through URI paths.
The implications of these gaps go beyond the loss of device control. Internet-connected speakers — and in turn, IoT devices — may be exposing information that can be used by attackers in malicious schemes. By first breaking into the case test device, a Sonos Play:1 speaker, to spot security issues, we were able to come up with plausible attack scenarios that can be used not just against home users but also against enterprise networks. And while the test unit used was an internet-connected speaker and updates for Sonos Play:1 have been rolled out, similar issues in other IoT devices can exist and give attackers the same upper hand.
Prerequisites for an Attack on IoT Devices
Regardless of the target IoT device, attackers make use of several elements when launching an attack. In any scenario, an attacker will utilize information that is accessible as well as exploitable. Listed below are prerequisites for IoT attack scenarios, which we formulated based on our tests on the Sonos speakers:
Existing insecurity — A device may have a security lapse that gives an attacker something to take advantage of. This may come in the form of a lack of authentication process, an unpatched vulnerability, or information leakage from an external source. For the test unit, it was its open access to user information, among other things.
Exploitable device capabilities – Given that IoT devices vary in form and function, certain devices may have unique capabilities which attackers can exploit. In the case of an internet-connected speaker, the attacker could utilize the ability to play music from an online source.
Publicly available personally identifiable information (PII) – These can come from legitimate sources such as online search tools or social media, as well as from data breach information made public. In the case study, we found 727 unique email addresses that could be loaded into open source intelligence tools such as Maltego. We also saw several email accounts connected to previously reported breaches such as River City Media, LinkedIn, and last.fm.
Using the above attack prerequisites found in the case study, we were able to formulate three specific attack scenarios utilizing the internet-connected speakers. Again, any device with the same or similar vulnerability can be at risk of experiencing these attacks.
An attacker can send a customized phishing email based on the target’s musical preference.
Through an Nmap scan, we observed that the application running the Sonos Play:1 test device communicated with TCP/1400. Following that led us to an unauthenticated URI page.
Figure 1. Services shown from Nmap scan
The URI led to a site which was used to populate the applications that control the device and also contained information exposed without requiring authentication. It also included information about tracks currently being played, libraries connected to the device, devices used to control the speakers, devices that were in the same network as the speakers, as well as email addresses associated with audio streaming services synced with the device.
This exposure is not limited to home users. In a workplace scenario, an exposed device which identifies and lists down other IoT devices connected to the same network can give an attacker plenty of information to work on. Bad actors could find machines such as printers with existing vulnerabilities and use that to gather further information or as an entry point.
Figure 2. Contents of the status page of the Sonos
Aside from finding an entry point, an attacker could use the exposed information for spear-phishing. By studying the target’s musical preference based on the tracks being played, an attacker can tailor-fit an email and send it to the email address linked to the target’s music streaming account. This increases the success rate of schemes to compromise businesses too.
In a way, any IoT device which leaks personal or network information can give an attacker leverage for a successful attack.
An attacker can track down where the target lives and find out if they’re home.
This can be done using a website that compounds multiple sources of Wi-Fi geolocation. In the case study, we queried specific BSSIDs related to the test device and mapped out the location. The information came from the wireless access points (WAPs) the device tried to access during installation.
Figure 3. Address mapped with SSIDs
After determining the location of the target, an attacker can monitor the presence data available from the device, such as the times when the speaker is activated and deactivated. The pattern can more or less tell the attacker when the target is awake, asleep, or even when the target is not around.
This hybrid attack involving cyber and physical elements presents new dangers that home and enterprise users should be aware of. Devices leaking presence data not only make users easier to predict — they can also put the user at physical risk.
An attacker can play a fake recorded message and trick the target into downloading malware.
Using information found on the URI path like model numbers and serial numbers, an attacker can disrupt the user’s device, halt any song currently playing, and play a crafted status message containing misleading information.
Similar to the first attack scenario, an attacker could then send tailor-fit emails to accounts tied to the music streaming applications. This time, the email could contain a fake message from the manufacturer along with a link that downloads malware instead of a software update.
To make the email more believable, the attacker can search the target’s email address against online search tools that can locate people based off of public information, and add personalized details to the pre-recorded message. This scheme poses great risk to businesses that use internet-connected speakers or have Bring Your Own Device (BYOD) programs.
With a different IoT device, attackers can get creative and exploit other functions. Imagine what they could do if they had access to security cameras, a router, the thermostat, or even a FitBit.
Assuming that an IoT device inherently protects a user’s personal information and is safe to introduce to a network is risky. Cybercriminals will soon be exploring new ways to abuse IoT devices. As the production and consumption of IoT devices increase, the lack of built-in security becomes more and more of an issue. With all these devices connected to each other via networks and the internet, it could take just one security gap to compromise a user – or an entire network. From exposed features that could be exploited to devices leaking personal information on the internet, product insecurities have led to attacks and will continue to do so.
One of the more recent security incidents involved brands of smartwatches for children.
They were found to have vulnerabilities that can allow attackers to track the wearer’s movement, eavesdrop on conversations, and communicate with the wearer. This shows that even popular devices can fall short or leave massive gaps in terms of ensuring their products’ security.
The problem of unsecured internet-connected devices is not limited to home users but also extends to workplace environments when seemingly safe IoT devices are introduced into the company network, as was shown in the attack scenarios. Whether these devices are installed to improve productivity or are simply brought to work by employees, the risk of having an exposed and unsecured device should not be taken lightly.
Mitigating IoT Insecurities
Given that IoT devices need to be connected to the internet, manufacturers have to ascertain that what they produce poses very minimal risk to the buying public. With all the information fed to internet-connected devices, it is considerably difficult for users to know if these are protected properly by the built-in security that comes with the product. Although consumers are also tasked to employ proper security practices on their end (like applying fixes), manufacturers should also make sure that what they produce pose little to no security risk to their customers.
While IoT devices are connected to the internet, they should never be exposed. In the case of the test device, manufacturers should make sure that ports connecting to the devices cannot be accessed directly from the internet. Manufacturers should also secure data that’s being stored or compiled by these IoT devices and conduct security audits — including regularly reading public forums discussing their products.
At the same time, consumers and enterprise IT administrators should not rely entirely on manufacturers to do all the heavy lifting. Users should check their routers for rules that might provide outside access to devices and folders on the network. If access is needed, it should be limited to as few devices as possible. They should enable password protection on all devices if possible and replace default passwords immediately with stronger ones.
Users can also visit websites like WhatsMyIP to scan their network for any open ports. They should also make sure that the firmware of their IoT devices is updated as well. Businesses with BYOD programs must be aware of what internet-connected devices are being used by employees at work and ensure security guidelines are provided.
As we move to a more internet-connected world, manufacturers, consumers, and IT administrators must exercise a security-first mindset. With all the personal data managed and kept by IoT devices, securing them should be just as important as ease of use and integration with applications that run them.
To find out how we came up with the attack scenarios, read the full case study titled The Sound of a Targeted Attack. It also includes a rundown of exposed services our test unit had, the types of information that were made publicly available due to security gaps, and a Shodan query of exposed internet-connected speakers.
Android’s regular security update for December 2017 included a fix for a serious vulnerability that could allow attackers to modify installed apps without affecting their signature. This would allow an attacker to gain access to the affected device (indirectly). First found by researchers in July, this vulnerability (designated as CVE-2017-13156, and also called the Janus vulnerability) affects versions of Android from 5.1.1 to 8.0; approximately 74% of all Android devices have these versions installed.
We have found at least one app in the wild using this technique. This particular version of the app used the vulnerability to make itself more difficult to detect by mobile security solutions. It’s possible that it could be used in the future to compromise other apps and access the information of the user.
The installation packages of Android apps (.APK files) are actually .ZIP files. The .ZIP file format has several characteristics that allowed this attack to take place. See the basic .ZIP file structure below:
Figure 1. .ZIP file structure
The file structure consists of three parts: the file entries, a Central Directory, and an End of Central Directory. The Central Directory contains information for each file in the archive; applications use this directory to find the memory location to access that file as needed.
However, there is no requirement that each file entry is next to one another. You can even have arbitrary data located in that part of the .ZIP file, as seen below:
Figure 2. .ZIP file structure (with arbitrary data in red)
The attacker can place a malicious DEX file at the start of the APK file, as seen below. A vulnerable version of Android will still recognize this as a valid APK file and will attempt to execute it.
Figure 3. Added DEX component to APK file
The Android Runtime (ART) is responsible for loading the DEX code from the APK file. It examines this file, and because of the DEX code in the header, it is recognized as a DEX file and executed directly. ART considers the code after this (the original contents of the APK) as garbage data, which it ignores. However, it still regards this file as a valid APK file. Accessing APK data like resources and assets works similarly with common apps.
In general, malware can abuse this vulnerability in two ways.
Firstly, it can be used to hide a payload. Malware may disguise itself as a single clean DEX file, with the malicious payload stored in the APK file loaded later. This is how the app discussed below uses it.
Secondly, it can be used to update an already installed app without the knowledge of the original developer. An attacker can use this to access the protected data of the original app such as user credentials and private information. Impersonating the identity of legitimate apps can also bypass some security solutions.
Attacks in the wild
Once this vulnerability was disclosed, we checked our existing malware samples to see if any known malware samples used it. We found one malware sample that did use this particular vulnerability, but not in the way that was expected. We detect this as ANDROIDOS_JANUS.A. We have also worked with Google to take the appropriate measures and alert users (Google has flagged this app as malicious).
This particular app was previously found on Google Play as a junk cleaner, but was later updated to become a news app; it was not present in the Play store.
Figure 4. Icon of new version of app exploiting Janus
The malware used the vulnerability for dynamic code loading. The embedded DEX file contains only a small payload that decrypts the actual payload from various assets and dynamically loads it. This is done via the Janus vulnerability that builds a malformed app with a DEX file in the header, followed by the actual payload inside the APK code itself. This is meant to bypass malware scanners that will handle this file as a DEX file and pronounce it clean, ignoring the malicious code.
It will run as a background service when the Android device boots. It connects to its C&C server and receives commands to install more malware, which is the extent of its current behavior.
Figure 5. Code for downloading other malware
It was imagined Janus could be used to update already-installed applications on the device maliciously. Our analysis of the code indicates that this app does not intend to carry out any app update attacks, and Janus is being used to avoid security solutions. However, we cannot rule out the possibility of malware using this attack to act as a downloader.
Mitigation for Developers
Android 7.0 (Nougat) introduced a new signature scheme (version 2). The signature certificate and digest are moved from the meta section to an APK signing block located between the file entries and the Central Directory in the APK file. It protects the integrity of the other three sections.
Figure 6. Added signing block to APK file
Gaps between the file entries are still allowed. However, it checks the entire segment from the start of the file until the start of the APK signing block: this means that any tampering will break the signature integrity check. It’s still possible to inject a DEX file into the header, but a successful attack still requires resigning the APK signing block.
For compatibility reasons, developers generally prefer a mixed signature (version 1 and 2) scheme. The effect of mitigation varies with different devices. In devices that do support it, version 2 is enforced with rollback protection.
Figure 7. Rollback protection
This attack is still possible on devices with older Android versions with only version 1 of the signing scheme. However, until Nougat is rolled out to more devices, we recommend that developers continue with mixed signing.
The impact of this vulnerability is broadly similar to the Master Key vulnerability that hit Android several years ago. Both vulnerabilities allowed for legitimate apps to be modified without the knowledge of their users.
If a malicious app that exploited this vulnerability made its way to an app store, then users would face two risks at the same time: either a malicious app would be passed off as a legitimate app, or a malicious app installed via the app store modifies legitimate apps in large numbers.
Not all mobile security solutions can meet this challenge. Malicious DEX code embedded in normal apps are capable of evading many security solutions. Enterprise MDM solutions may not detect these apps either, and they are also vulnerable to being modified by malicious apps. Vendors have to improve their ability to scan and detect malicious Android apps.
Trend Micro solutions like Mobile Security for Android (also available on Google Play) are already capable of detecting these types of threats. Mobile Security for Enterprise provides device, compliance and application management, data protection, and configuration provisioning, as well as protects devices from attacks that leverage vulnerabilities, preventing unauthorized access to apps, as well as detecting and blocking malware and fraudulent websites.
Trend Micro’s Mobile App Reputation Service (MARS) covers Android and iOS threats using leading sandbox and machine learning technologies. It can protect users against malware, zero-day and known exploits, privacy leaks, and application vulnerabilities.
Indicators of Compromise
The app with the following hash is connected to this threat: