MalBus: Popular South Korean Bus App Series in Google Play Found Dropping Malware After 5 Years of Development

McAfee’s Mobile Research team recently learned of a new malicious Android application masquerading as a plugin for a transportation application series developed by a South Korean developer. The series provides a range of information for each region of South Korea, such as bus stop locations, bus arrival times and so on. There are a total of four apps in the series, with three of them available from Google Play since 2013 and the other from around 2017. Currently, all four apps have been removed from Google Play while the fake plugin itself was never uploaded to the store. While analyzing the fake plugin, we were looking for initial downloaders and additional payloads – we discovered one specific version of each app in the series (uploaded at the same date) which was dropping malware onto the devices on which they were installed, explaining their removal from Google Play after 5 years of development.

Figure 1. Cached Google Play page of Daegu Bus application, one of the apps in series

When the malicious transportation app is installed, it downloads an additional payload from hacked web servers which includes the fake plugin we originally acquired. After the fake plugin is downloaded and installed, it does something completely different – it acts as a plugin of the transportation application and installs a trojan on the device, trying to phish users to input their Google account password and completely take control of the device. What is interesting is that the malware uses the native library to take over the device and also deletes the library to hide from detection. It uses names of popular South Korean services like Naver, KakaoTalk, Daum and SKT. According to our telemetry data, the number of infected devices was quite low, suggesting that the final payload was installed to only a small group of targets.

The Campaign

The following diagram explains the overall flow from malware distribution to device infection.

Figure 2. Device infection process

When the malicious version of the transportation app is installed, it checks whether the fake plugin is already installed and, if not, downloads from the server and installs it. After that, it downloads and executes an additional native trojan binary which is similar to the trojan which is dropped by the fake plugin. After everything is done, it connects with the C2 servers and handles received commands.

Initial Downloader

The following table shows information about the malicious version of each transportation app in the series. As the Google Play number of install stats shows, these apps have been downloaded on many devices.

Unlike the clean version of the app, the malicious version contains a native library named “libAudio3.0.so”.

Figure 3. Transportation app version with malicious native library embedded

In the BaseMainActivity class of the app, it loads the malicious library and calls startUpdate() and updateApplication().

Figure 4. Malicious library being loaded and executed in the app

startUpdate() checks whether the app is correctly installed by checking for the existence of a specific flag file named “background.png” and whether the fake plugin is installed already. If the device is not already infected, the fake plugin is downloaded from a hacked web server and installed after displaying a toast message to the victim. updateApplication() downloads a native binary from the same hacked server and dynamically loads it. The downloaded file (saved as libSound1.1.so) is then deleted after being loaded into memory and, finally, it executes an exported function which acts as a trojan. As previously explained, this file is similar to the file dropped by the fake plugin which is discussed later in this post.

Figure 5 Additional payload download servers

Fake Plugin

The fake plugin is downloaded from a hacked web server with file extension “.mov” to look like a media file. When it is installed and executed, it displays a toast message saying the plugin was successfully installed (in Korean) and calls a native function named playMovie(). The icon for the fake plugin soon disappears from the screen. The native function implemented in LibMovie.so, which is stored inside the asset folder, drops a malicious trojan to the current running app’s directory masquerading as libpng.2.1.so file. The dropped trojan is originally embedded in the LibMovie.so xor’ed, which is decoded at runtime. After giving permissions, the address of the exported function “Libfunc” in the dropped trojan is dynamically retrieved using dlsym(). The dropped binary in the filesystem is deleted to avoid detection and finally Libfunc is executed.

Figure 6 Toast message when malware is installed

In the other forked process, it tries to access the “naver.property” file on an installed SD Card, if there is one, and if it succeeds, it tries starting “.KaKaoTalk” activity which displays a Google phishing page (more on that in the next section) . The overall flow of the dropper is explained in the following diagram:

Figure 7. Execution flow of the dropper

Following is a snippet of a manifest file showing that “.KaKaoTalk” activity is exported.

Figure 8. Android Manifest defining “.KaKaoTalk” activity as exported

Phishing in JavaScript

KakaoTalk class opens a local HTML file, javapage.html, with the user’s email address registered on the infected device automatically set to log into their account.

Figure 9. KakaoTalk class loads malicious local html file

The victim’s email address is set to the local page through a JavaScript function setEmailAddress after the page is finished loading. A fake Korean Google login website is displayed:

Figure 10. The malicious JavaScript shows crafted Google login page with user account

We found the following attempts of exploitation of Google legitimate services by the malware author:

  • Steal victim’s Google account and password
  • Request password recovery for a specific account
  • Set recovery email address when creating new Google account

An interesting element of the phishing attack is that the malware authors tried to set their own email as the recovery address on Google’s legitimate services. For example, when a user clicks on the new Google account creation link in the phishing page, the crafted link is opened with the malware author’s email address as a parameter of RecoveryEmailAddress.

Figure 11. The crafted JavaScript attempts to set recovery email address for new Google account creation.

Fortunately for end users, none of the above malicious attempts are successful. The parameter with the malware author’s email address is simply ignored at the account creation stage.

Trojan

In addition to the Google phishing page, when “Libfunc” function of the trojan (dropped by the fake plugin or downloaded from the server) is executed, the mobile phone is totally compromised. It receives commands from the following hardcoded list of C2 servers. The main functionality of the trojan is implemented in a function called “doMainProc()”. Please note that there are a few variants of the trojanwith different functionality but, overall, they are pretty much the same.

Figure 12. Hardcoded list of C2 servers

The geolocation of hardcoded C2 servers lookslike the following:

Figure 13. Location of C2 Servers

Inside doMainProc(), the trojan receives commands from the C2 server and calls appropriate handlers. Part of the switch block below gives us an idea of what type of commands this trojan supports.

Figure 14. Subset of command handlers implemented in the dropped trojan.

As you can see, it has all the functionality that a normal trojan has. Downloading, uploading and deleting files on the device, leaking information to a remote server and so on. The following table explains supported C2 commands:

Figure 15. C2 Commands

Before entering the command handling loop, the trojan does some initialization, like sending device information files to the server and checking the UID of the device. Only after the UID checking returns a 1 does it enter the loop.

Figure 16 Servers connected before entering command loop

Among these commands, directory indexing in particular is important. The directory structure is saved in a file named “kakao.property” and while indexing the given path in the user device, it checks the file with specific keywords and if it matches, uploads the file to the remote upload server. These keywords are Korean and its translated English version is as per the following table:

Figure 17 Search file keywords

By looking at the keywords we can anticipate that the malware authors were looking for files related to the military, politics and so on. These files are uploaded to a separate server.

Figure 18 Keyword matching file upload server

Conclusion

Applications can easily trick users into installing them before then leaking sensitive information. Also, it is not uncommon to see malware sneaking onto the official Google Play store, making it hard for users to protect their devices. This malware has not been written for ordinary phishing attempts, but rather very targeted attacks, searching the victim’s devices for files related to the military and politics, likely trying to leak confidential information. Users should always install applications that they can fully trust even though they are downloaded from trusted sources.

McAfee Mobile Security detects this threat as Android/MalBus and alerts mobile users if it is present, while protecting them from any data loss. For more information about McAfee Mobile Security, visit https://www.mcafeemobilesecurity.com.

Hashes (SHA-256)

Initial Downloader (APK)
• 19162b063503105fdc1899f8f653b42d1ff4fcfcdf261f04467fad5f563c0270
• bed3e665d2b5fd53aab19b8a62035a5d9b169817adca8dfb158e3baf71140ceb
• 3252fbcee2d1aff76a9f18b858231adb741d4dc07e803f640dcbbab96db240f9
• e71dc11e8609f6fd84b7af78486b05a6f7a2c75ed49a46026e463e9f86877801

Fake Plugin (APK)
• ecb6603a8cd1354c9be236a3c3e7bf498576ee71f7c5d0a810cb77e1138139ec
• b8b5d82eb25815dd3685630af9e9b0938bccecb3a89ce0ad94324b12d25983f0

Trojan (additional payload)
• b9d9b2e39247744723f72f63888deb191eafa3ffa137a903a474eda5c0c335cf
• 12518eaa24d405debd014863112a3c00a652f3416df27c424310520a8f55b2ec
• 91f8c1f11227ee1d71f096fd97501c17a1361d71b81c3e16bcdabad52bfa5d9f
• 20e6391cf3598a517467cfbc5d327a7bb1248313983cba2b56fd01f8e88bb6b9

The post MalBus: Popular South Korean Bus App Series in Google Play Found Dropping Malware After 5 Years of Development appeared first on McAfee Blogs.

Heads-up: 2FA provider Duo Security to be acquired by Cisco (ugh)

Enlarge / Artist's impression of how this deal feels from this author's chair. (credit: Getty Images / Gary Hanna / Lee Hutchinson)

US-based two-factor authentication provider Duo Security announced this morning that it is in talks to be acquired by networking giant Cisco. According to Duo’s press release, Duo will become a “business unit” under Cisco’s Security Business Group, and current Duo CEO Dug Song will become the unit’s general manager.

Ars is a happy Duo customer, and we use the product extensively to apply 2FA to a variety of our internal services; beyond that, several Ars staffers (myself included) use Duo’s free tier to wrap 2FA around our own personal stuff, like Linux PAM authentication and Mac/Windows logins. Duo’s flexibility and ease of use has been a huge driver of success for the company, which says it has about 12,000 customers.

But the worry here is that Cisco is going to murder the golden goose—and, as a former Cisco customer, I’m struggling to feel anything but dread about all the ways in which this acquisition might kill everything that’s good about Duo.

Read 18 remaining paragraphs | Comments

Cloud Clustering Vulnerable to Attacks

The authors thank John Fokker and Marcelo CaroVargas for their contributions and insights.

In our upcoming talk at the Cloud Security Alliance Summit at the RSA Conference, we will focus our attention on the insecurity of cloud deployments. We are interested in whether attackers can use compromised cloud infrastructure as viable backup resources as well as for cryptocurrency mining and other illegitimate uses. The use of containers has increased rapidly, especially when it comes to managing the deployment of applications. Our latest market survey found that 83% of organizations worldwide are actively testing or using containers in production. Applications need authentication for load balancing, managing the network between containers, auto-scaling, etc. One solution (called a cluster manager) for the automated installation and orchestration of containers is Kubernetes.

Some key components in the Kubernetes architecture appear below:

High-level Kubernetes architecture.

  • Kubernetes master server: The managing machine oversees one or more nodes
  • Node: A client that runs tasks as delegated by the user and Kubernetes master server
  • Pod: An application (or part of an application) that runs on a node. The smallest unit that can be scheduled to be deployed. Not intended to live long.

For our article, we need to highlight the etcd storage on the master server. This database stores the configuration data of the cluster and represents the overall state of the cluster at a given time. Kubernetes saves these secrets in Base64 strings; before Version 2.1 there was no authentication in etcd.

With that knowledge, security researcher Giovanni Collazo from Puerto Rico started to query the Shodan database for etcd databases connected to the Internet. He discovered many and by executing a query, some of these databases started to reveal a lot of credentials. Beyond leaking credentials from databases and other accounts, what other scenarios are possible?

Leaking Credentials

There are several ways that we can acquire credentials for cloud services without hacking into panels or services. By “creatively” searching public sites and repositories, we can find plenty of them. For example, when we searched on GitHub, we found more than 380,000 results for certain credentials. Let’s assume that half of them are useful: We would have 190,000 potentially valid credentials. As Collazo did for etcd, one can also use the Shodan search engine to query for other databases. By creating the right query for Django databases, for example, we were able to identify more cloud credentials. Amazon’s security team proactively scans GitHub for AWS credentials and informs their customers if they find credentials.

Regarding Kubernetes: Leaked credentials, complete configurations of the DNS, load balancers, and service accounts offer several possible scenarios. These include exfiltrating data, rerouting traffic, or even creating malicious containers in different nodes (if the service accounts have enough privileges to execute changes in the master server).

Creating malicious containers.

One of the biggest risks concerning leaked credentials is the abuse of your cloud resources for cryptomining. The adversaries can order multiple servers under your account to start cryptomining, enriching their bank accounts while you pay for the computing power “you” ordered.

Open Buckets

We have heard a lot about incidents in which companies have not secured their Amazon S3 buckets. A number of tools can scan for “open” buckets and download the content. Attackers would be most interested in write-enabled rights on a bucket. For our Cloud Security Alliance keynote address at RSA, we created a list of Fortune 1000 companies and looked for readable buckets. We discovered quite a few. That is no surprise, but if you combine the read-only buckets information with the ease of harvesting credentials, the story changes. With open and writable buckets, the adversaries have plenty of opportunities: storing and injecting malware, exfiltrating and manipulating data, etc.

McAfee cloud researchers offer an audit tool that, among other things, verifies the rights of buckets. As we write this post, more than 1,200 writable buckets belonging to a multitude of companies, are accessible to the public. One of the largest ad networks in the world had a publicly writable bucket. If adversaries could access that network, they could easily inject malicious code into advertisements. (As part of our responsible disclosure process, we reported the issue, which was fixed within hours.) You can read an extensive post on McAfee cloud research and how the analysts exposed possible man-in-the-middle attacks leveraging writable buckets.

Clustering the Techniques

To combat ransomware, many organizations use the cloud to back up and protect their data. In our talk we will approach the cloud as an attack vector for spreading ransomware. With the leaked credentials we discovered from various sources, the open and writable buckets created a groundwork for storing and spreading our ransomware. With attackers having a multitude of credentials and storage places such as buckets, databases, and containers, defenders would have difficulty keeping up. We all need to pay attention to where we store our credentials and how well we monitor and secure our cloud environments.

The post Cloud Clustering Vulnerable to Attacks appeared first on McAfee Blogs.

DDoS Attacks in the Netherlands Reveal Teen Gamers on Troublesome Path

At the end of January, the Netherlands was plagued by distributed denial of service (DDoS) attacks targeting various financial institutions, tech sites, and the Dutch tax authorities. At the time of the attacks it was unclear who was responsible, and this led to speculation among security experts.

Coincidentally, the attacks started a few days after it was announced in the media that the Dutch General Intelligence and Security Service, the AIVD, had played a major role in relaying crucial information to their American counterparts regarding attacks of suspected Russian state-sponsored hackers.

Thus, the hypothesis that the attacks were some kind a state-sponsored retaliation was quickly formed. Security experts deemed this hypothesis possible, but it remained unproven.

Arrest

Then on February 1, an 18-year-old suspect was arrested by the National High Tech Crime Unit of the Dutch police. The suspect carelessly left behind some crucial pieces of evidence, which ultimately led to his arrest. Through open-source research, the McAfee Advanced Threat Research team was also able to find links between the arrested suspect and another known DDoS actor. At this moment the police investigation is ongoing to determine the degree of guilt and whether the suspect acted independently. But one thing is certain: The wave of attacks has stopped since his arrest.

The relative ease with which the attack was carried out is striking. The individual had presumably bought a “stresser/booter service” capacity for about €40. The stresser enabled him to launch attacks with a volume of about 40Gbps.

(Stresser, or booter, services are websites that offer distributed denial of service capability as a paid service. These websites offer a way to stress-test a host by simply filling in its IP address. The traffic power these services need can be generated from legitimate or illegitimate sources. Attacking a host or website without legal consent is a highly illegal.)

McAfee Chief Scientist and Fellow Raj Samani has written “you can disrupt your competition for the price of a cup of coffee.” This attack suggests you can disrupt entire organizations or parts of a country for the price of a pound of good coffee beans.

Thus speculation of a possible state-sponsored retaliation dissolved into an inexpensive and relatively easy method of attack, performed by a teenager.

Earlier DDoS Attacks

This sequence of events reminds me of an earlier DDoS attack I personally investigated. In 2015 one of the largest internet service providers in the Netherlands suffered a DDoS attack for three consecutive days. This attack deprived roughly 1.8 million subscribers of Internet access. In a period of several weeks and after an extensive police investigation, a group of suspects was arrested. All but one of them were teenagers, with the youngest only 14 years old. Their methods were relatively simple as well, from basic Python scripts to the use of stresser/booter services.

I clearly recall that this group of suspects had a great affinity with online gaming. They were active on popular games such as Minecraft and Call of Duty and played a lot in groups or clans. Apparently, it was common practice for the suspects to knock their opponents offline during a game in order to win. Talk about fair play.

Could there be a connection between the gaming community and DDoS attacks, or is this purely a coincidence?

Gaming and DDoS

Who doesn’t remember the crippling Mirai DDoS attacks in the fall of 2016 on DNS provider Dyn, hosting provider OVH, and the popular security blog Krebs on Security?

Brian Krebs actively investigated the group behind the Mirai attacks against his site and published his findings online. During his research into the actors he described a fascinating world within the online gaming industry. In this industry it is big business to have powerful game servers, which attract many customers. This popularity makes those servers a target for the less successful, and their weapon of choice is often DDoS attacks. Game servers are apparently knocked offline daily to push gamers to migrate to the competition. All this distributed “violence” also gave birth to a lively and sometimes shady business in DDoS protection services.

So how would someone with only marginal technical knowledge go about knocking off websites? All it takes is simple search on one of the entry-level hacker forums. We found dozens of threads (some listed below) that discussed what it would take to attack (game) servers. Subsequently, the same forum was full of advertisements and reviews of various stresser and booter services offered online.

In February news surfaced that an online gaming service offered DDoS for hire. According to the article, the operators of a gaming service were behind the building of an IoT botnet named JenX and offered it as part of the game server rental scheme.

This shows there is a definite link between the online gaming community and the use of DDoS attacks. It is worrying to see that some individuals resort to such drastic measures out of pure frustration. We can only imagine the consequences when such an individual gets a low grade in school or has a disagreement with an online retailer.

End Note

As a former law enforcement official, I am troubled to see teenagers going down a criminal path. I can understand that for teens it is not always easy to foresee the consequences of their actions. One might think that knocking off websites is all fun and games or a way to show your frustration. But from my experience the fun definitely stops when the police come knocking at the door. Then it is literally game over.

 

The post DDoS Attacks in the Netherlands Reveal Teen Gamers on Troublesome Path appeared first on McAfee Blogs.