Attackers Exploiting WinRAR UNACEV2.DLL Vulnerability (CVE-2018-20250)

Earlier this month Check Point Research reported discovery of a 19 year old code execution vulnerability in the wildly popular WinRAR compression tool. Rarlab reports that that are over 500 million users of this program. While a patched version, 5.70, was released on February 26, attackers are releasing exploits in an effort to reach vulnerable […]

The post Attackers Exploiting WinRAR UNACEV2.DLL Vulnerability (CVE-2018-20250) appeared first on McAfee Blogs.

Earlier this month Check Point Research reported discovery of a 19 year old code execution vulnerability in the wildly popular WinRAR compression tool. Rarlab reports that that are over 500 million users of this program. While a patched version, 5.70, was released on February 26, attackers are releasing exploits in an effort to reach vulnerable systems before they can be patched.

One recent example piggybacks on a bootlegged copy of Ariana Grande’s hit album “Thank U, Next” with a file name of “Ariana_Grande-thank_u,_next(2019)_[320].rar”

When a vulnerable version of WinRAR is used to extract the contents of this archive, a malicious payload is created in the Startup folder behind the scenes. User Access Control (UAC) is bypassed, so no alert is displayed to the user. The next time the system restarts, the malware is run.

Figure 1 – Malformed Archive detected by McAfee as CVE2018-20250!4A63011F5B88
SHA256: e6e5530ed748283d4f6ef3485bfbf84ae573289ad28db0815f711dc45f448bec

Figure 2 – Extracted non-malicious MP3 files

Figure 3 – Extracted Malware payload detected by McAfee as Generic Trojan.i
SHA256: A1C06018B4E331F95A0E33B47F0FAA5CB6A084D15FEC30772923269669F4BC91

In the first week since the vulnerability was disclosed, McAfee has identified over 100 unique exploits and counting, with most of the initial targets residing in the United States at the time of writing.

 

McAfee advises users to keep their anti-malware signatures up to date at all times. McAfee products detect known and unknown malformed ACE files exploiting the vulnerability as CVE2018-20250![Partial hash] starting with the following content

  • V2 DATs version 9183 released March 2, 2019
  • V3 DATs version 3634 released March 2, 2019

Additional GTI coverage exists for email-based attacks, in tandem with the Suspicious Attachment feature. When this feature is enabled, Artemis![Partial hash] detections will occur on known exploits.

The post Attackers Exploiting WinRAR UNACEV2.DLL Vulnerability (CVE-2018-20250) appeared first on McAfee Blogs.

McAfee Protects Against Suspicious Email Attachments

Email remains a top vector for attackers.  Over the years, defenses have evolved, and policy-based protections have become standard for email clients such as Microsoft Outlook and Microsoft Mail.  Such policies are highly effective, but only if they are maintained as attacker’s keep changing their tactics to evade defenses.  For this reason, McAfee endpoint products […]

The post McAfee Protects Against Suspicious Email Attachments appeared first on McAfee Blogs.

Email remains a top vector for attackers.  Over the years, defenses have evolved, and policy-based protections have become standard for email clients such as Microsoft Outlook and Microsoft Mail.  Such policies are highly effective, but only if they are maintained as attacker’s keep changing their tactics to evade defenses.  For this reason, McAfee endpoint products use a combination of product features and content for increased agility.  In McAfee Endpoint Security (ENS) 10.5+, such protection is enabled via the ‘Detect suspicious email attachments’ option and maintained through DAT content.  This capability goes beyond the level of protection offered by email clients by not only blocking applications and scripts, but also a variety of threat types in their native form, as well as those compressed and contained within archives and other formats.

Figure 1 – ENS 10.6.1 Configuration Screen

An example of this capability in action can be seen against a recent spam run.

In this campaign, a malicious email message contained the attachment BANK DETAILS.ZIP.  Inside this archive was the file BANK DETAILS.ISO.  Malicious ISO spam has been increasing over the past six months, and while it is common for ISO files to be blocked by email clients, this is not the case where the ISO is inside of a ZIP.  Inside the BANK DETAILS.ISO file resides BANK DETAILS.EXE.  Email clients will typically block executable files attached to messages, but not if they are inside a container.

When the email client attempts to write the attachment to disk, ENS scans inside the ZIP and subsequently the contained ISO and EXE files (ZIP -> ISO -> EXE).

Figure 2 – ENS Toaster Popup

In this case, 2-year-old DAT content proactively stopped the threat.

If the system had not been protected, an unsuspecting user might open the ZIP to reveal the ISO.

Figure 3 – Inside ZIP file showing ISO file

The ISO can then be accessed via Windows Explorer, which appears as a DVD Drive containing the executable, password-stealing, payload.

Figure 4 – EXE file inside Bank Details.ISO

Since the advent of policy-based email attachment blocking, attackers have continued to seek ways to evade that protection. ISO abuse may be the latest chapter in the story, but others are sure to follow.

Tens of thousands of new and unique malicious attachments are blocked each month via the ‘Suspicious Attachment’ detection feature.

The post McAfee Protects Against Suspicious Email Attachments appeared first on McAfee Blogs.

JAVA-VBS Joint Exercise Delivers RAT

The Adwind remote administration tool (RAT) is a Java-based backdoor Trojan that targets various platforms supporting Java files. For an infection to occur, the user must typically execute the malware by double-clicking on the .jar file that usually arrives as an email attachment. Generally, infection begins if the user has the Java Runtime Environment installed. […]

The post JAVA-VBS Joint Exercise Delivers RAT appeared first on McAfee Blogs.

The Adwind remote administration tool (RAT) is a Java-based backdoor Trojan that targets various platforms supporting Java files. For an infection to occur, the user must typically execute the malware by double-clicking on the .jar file that usually arrives as an email attachment. Generally, infection begins if the user has the Java Runtime Environment installed. Once the malicious .jar file runs successfully on the target system, the malware silently installs itself and connects to a remote server through a preconfigured port. This allows it to receive commands from the remote attacker and perform further malicious activities. Recently, McAfee labs has seen a surge in a variant which comes as a JAR attachment via a spam email and uses the famous Houdini VBS worm to infect user.

Infection chain:

The malware’s spreading mechanism is the same as in previous versions. It arrives in a spam email with a .jar attachment. The contents of the email are carefully crafted to lure victims using social engineering techniques. We can summarise the whole infection chain as shown in the below snippet:

 

The spam email may look like this:

The parent JAR file:

To keep things simple, we just called the attached .jar file as a parent jar file and named it Sample.jar. Generally, Adwind comes in an obfuscated form to hide its malicious intent. Its payload and configuration file (which serves as an installation file) are encrypted with the DES, RC4, or RC6 cipher, depending on the variant. The Adwind backdoor will decrypt itself on the fly during execution. In this variant we can see the contents of Manifest.MF. It has main class bogjbycqdq.Mawbkhvaype.

Mawbkhvaype.class

The main task of this class is to check for a resource file available in the Jar bundle. Here, resource mzesvhbami is a vbs file. Mawbkhvaye.class will check for mzesvhbami in the resource section and later drop bymqzbfsrg.vbs in the user’s Home directory before executing it with the help of wscript.

Bymqzbfsrg.vbs

It has a huge chunk of obfuscated base64 encoded data present. The below snippet shows the partial part of Bymqzbfsrg.vbs script.

Once deobfuscated and decoded, the base64 encoded data converts to ntfsmgr.jar and is dropped in %appdata%/Roaming. The below snippet shows the conversion of base64 encoded data into Jar file:

Decoded to JAR file (ntfsmgr.jar)

Ntfsmgr.jar

Here, important files present in ntfsmgr.jar are drop.box, mega.download and sky.drive which will be used later for creating the configuration file for the malware.

Final Payload:

Ntfsmgr.jar has operational.Jrat as the main class. The purpose of operational.Jrat is to drop another .jar file into the %TEMP% folder with random file name [underscore] [dot] [random numbers] [dot] class, e.g. _0.1234567897654265678.class, which will be the actual payload and later will perform malicious activities on the user’s system. The below snippet shows the routine present in operational.Jrat for creation of the final payload in %TEMP% location.

The contents of Manifest.MF looks somewhat similar to ntfsmgr.jar. All the other files in the final Java archive will be decrypted on the fly and will infect the system. After Adwind successfully infects a system, we have seen it log keystrokes, modify and delete files, download and execute further malware, take screenshots, access the system’s camera, take control of the mouse and keyboard, update itself, and more. We are not going to dig into this threat in this direction now but you can read more about Adwind here and here. In this blog we will now discuss another part of the story, Bymqzbfsrg.vbs

Working of Bymqzbfsrg.vbs

After successful execution, Bymqzbfsrg.vbs drops ntfsmgr.jar and sKXoevtgAv.vbs in %appdata%/Roaming.

Bymqzbfsrg.vbs dynamically executes a method naira inside the script by using ExecuteGlobal, as seen in the below snippet.:

Dynamic execution of the script looks like this:

The below snippet shows the script for dropping sKXoevtgAv.vbs in %appdata%Roaming.

Here we see the script for dropping ntfsmgr in %appdata%Roaming.

At the time of execution, sKXoevtgAv.vbs decodes itself to Houdini vbs worm which is the final payload. The first few lines of the script are as follows:

The attacker may perform many malicious activities on the victim’s machine, including::

  • Downloading and executing files on the victim’s machine
  • Running command instructions
  • Updating or uninstalling a copy of itself
  • Downloading and uploading files
  • Deleting a file or folder
  • Terminating certain process

Enumerating files and folders on the victim’s machine

Additional Points:

  1. For persistence it creates a run entry.

When the ntfsmgtr.jar runs, it adds itself into the start-up so that it will be run whenever the system starts.

  1. It checks for installed anti-malware products on the system.

  1. If available, it copies the installed Java Runtime files to a temporary directory within the victim’s home directory, otherwise it downloads from the web and copies in the same directory.

Conclusion:

In past, we have seen threat actors using two similar functioning malware families in a single infection. Usually, threat actors chose this path for higher probability of successful infection.

The hashes used in the analysis:

Sample.jar: 07cb6297b47c007aab43311fcfa9976158b4149961911f42d96783afc517226a

Ntfsmgr.jar: ee868807a4261a418e02b0fb1de7ee7a8900acfb66855ce46628eb5ab9b1d029

McAfee advises users to keep their antimalware signatures up to date at all times. McAfee products detect the malicious jar files as Adwind-FDVH.jar! [Partial hash] and Adwind-FDVJ.jar! [Partial Hash], with DAT Versions 9137 and later.

The post JAVA-VBS Joint Exercise Delivers RAT appeared first on McAfee Blogs.

Your Smart Coffee Maker is Brewing Up Trouble

IOT devices are notoriously insecure and this claim can be backed up with a laundry list of examples. With more devices “needing” to connect to the internet, the possibility of your WiFi enabled toaster getting hacked and tweeting out your credit card number is, amazingly, no longer a joke. With that in mind, I began […]

The post Your Smart Coffee Maker is Brewing Up Trouble appeared first on McAfee Blogs.

IOT devices are notoriously insecure and this claim can be backed up with a laundry list of examples. With more devices “needing” to connect to the internet, the possibility of your WiFi enabled toaster getting hacked and tweeting out your credit card number is, amazingly, no longer a joke.

With that in mind, I began to investigate the Mr. Coffee Coffee Maker with Wemo since we had previously bought one for our research lab (and we don’t have many coffee drinkers, so I didn’t feel bad about demolishing it!) My hope was to build on previous work done by my colleague Douglas McKee (@fulmetalpackets) and his Wemo Insight smart plug exploit. Finding the similar attack vector absent in this product, I explored a different avenue and was able to find another exploit. In this post I will explore my methodology and processes in detail.

All Wemo devices have two ways of communicating with the Wemo App, remotely via the internet or locally directly to the Wemo App. Remote connectivity is only present when the remote access setting is enabled, which it is by default. To allow the Wemo device to be controlled remotely, the Wemo checks Belkin’s servers periodically for updates. This way the Wemo doesn’t need to open any ports on your network. However, if you are trying to control your Wemo devices locally, or the remote access setting is disabled, the Wemo app connects directly to the Wemo. All my research is based on local device communication with the remote access setting turned off.

To gain insight on how the coffee maker communicates with its mobile application, I first set up a local network capture on my cellphone using an application called “SSL Capture.” SSL Capture allows the user to capture traffic from mobile applications. In this case, I selected the Wemo application. With the capture running, I went through the Wemo app and initiated several standard commands to generate network traffic. By doing this, I was able to view the communication between the coffee maker and the Wemo application. One of the unique characteristics about the app is that the user is able schedule the coffee maker to brew at a specified time. I made a few schedules and saved them.

I began analyzing the network traffic between the phone application and the Mr. Coffee machine. All transmissions between the two devices were issued in plaintext, meaning no encryption was used. I also noticed that the coffee maker and the mobile app were communicating over a protocol called UPNP (Universal Plug and Play), which has preset actions called “SOAP ACTIONS.” Digging deeper into the network capture from the device, I saw the SOAP action “SetRules.” This included XML content that pertained to the “brew schedule” I had set from the mobile application.

A Mr. Coffee “brew” being scheduled.

At this point I was able to see how the Wemo mobile application handled brewing schedules. Next, I wanted to see if the coffee maker performed any sort of validation of these schedules so I went back into the mobile application and disabled them all. I then copied the data and headers from the network capture and used the Linux Curl command to send the packet back to the coffee maker. I got the return header status of “200” which means “OK” in HTTP. This indicated there was no validation of the source of brewing schedules; I further verified with the mobile application and the newly scheduled brew appeared.

Curl command to send a “Brew” schedule to the Wemo Coffee maker.

Screenshot of the Curl command populating the Wemo app with a brew schedule

At this point I could change the coffee maker’s brew schedule without ever using the Wemo mobile application. To understand how the schedules were stored on the Wemo coffee maker, I decided to physically disassemble it and look at the electronics inside. Once disassembled, I saw there was a Wemo module connected to a larger PCB responsible for controlling the functions of the coffee maker. I then extracted the Wemo module from the coffee maker. This looked almost Identical to the Wemo module that was in the Wemo Insight device. I leveraged Doug’s blog on exploitation of the Wemo Insight to replicate the serial identification, firmware extraction, and root password change. After I obtained root access via the serial port on the Wemo device, I began to investigate the way in which the Wemo application is initiated from the underlying Linux Operating System. While looking through some of the most common Linux files and directories, I noticed something odd in the “crontab” file (used in Linux to execute and schedule commands).

It appeared the developers decided to take the easy route and used the Linux crontab file to schedule tasks instead of writing their own brew scheduling function. The crontab entry was the same as the scheduled brew I sent via the Wemo application (coffee-3) and executed as root. This was especially interesting; if I could add some sort of command to execute from the replayed UPNP packet, I could potentially execute my command as root over the network.

With the firmware dumped, I decided to look at the “rtng_run_rule” executable that was called in the crontab. The rtng_run_rule is a Lua script. As Lua is a scripting language, it was written in plaintext and not compiled like all the other Wemo executables. I followed the flow of execution until I noticed the rule passing parameters to a template for execution. At this point, I knew it would be useless trying to inject commands directly into the rule and instead looked at modifying the template performing the execution.

I went back to the Wemo mobile application network captures and started to dig around again. I found the application also sends the templates to the Wemo coffee maker. If I could figure out how to modify the template and still have the Wemo think it is valid, I could get arbitrary code execution.

Template with the correct syntax to pass Wemo’s verification

There were 3 templates sent over, “do,” “do_if,” and “do_unless.” Each of the templates were Lua scripts and encoded with base64. Based on this, I knew it would be trivial to insert my own code; the only remaining challenge would be the MD5 hash included at the top of the template. As it turned out, that was hardly an obstacle.

I created an MD5 hash of the base-64 decoded Lua script and the base64 encoded script separately, simply to see if one or the other matched the hash that was being sent; however, neither matched the MD5 being sent in the template. I began to think the developers used some sort of HMAC or clever way to hash the template, which would have made it much harder to upload a malicious template. Instead, I was astounded to find out that it was simply the base64 code prepended by the string “begin-base64 644 <template name>” and appended with the string “====.”

At last I had the ability to upload any template of my choice and have it pass all the Wemo’s verification steps necessary to be used by a scheduled rule.

I appended a new template called “hack” and added a block of code within the template to download and execute a shell script.

Within that shell command, I instructed the Mr. Coffee Coffee Maker with Wemo to download a cross-complied version of Netcat so I can get a reverse shell, and also added an entry to “rc.local.” This was done so that if the coffee maker was power cycled, I would have persistent access to the device after reboot, via the Netcat reverse shell.

The final aspect of this exploit was to use what I learned earlier to schedule a brew with my new “hack” template executing my shell script. I took the schedule I was able to replay earlier and modified it to have the “hack” template execute 5 minutes from the time of sending. I did have to convert the time value required into the epoch time format.

Converting time to Epoch time.

Now, I sat back and waited as the coffee maker (at my specified time delay) connected to my computer, downloaded my shell script, and ran it. I verified that I had a reverse shell and that it ran as intended, perfectly.

This vulnerability does require network access to the same network the coffee maker is on. Depending on the complexity of the user’s password, WiFi cracking can be a relatively simple task to accomplish with today’s computing power. For example, we demonstrate a quick and easy brute force dictionary attack to crack a semi-complex WPA2 password (10 characters alpha-numeric) in the demo for the Wemo Insight smart plug.  However, even a slightly more complex password, employing special characters, would exponentially increase the difficulty of a brute force attack. We contacted Belkin (who owns Wemo) on November 16th, 2018 and disclosed this issue to them. While the vendor did not respond to this report, we were pleasantly surprised to see that the latest firmware update has patched the issue. Despite a general lack of communication, we’re delighted to see the results of our research further securing home automation devices.

This vulnerability shows that not all exploits are overly complicated or require an exceptional amount of effort to pull off, if you know what to look for. This vulnerability exists solely because a few poor coding decisions were made in conjunction with a lack of input sanitation and validation. Even though this target does not contain sensitive data and is limited to your local network, it doesn’t mean malicious hackers are not targeting IOT devices like this. These devices may serve as a sought-after target as they are often overlooked from a security standpoint and can provide a simple and unmonitored foothold into your home or business network. It is very important for any consumer, when purchasing new IOT gadgets, to ask themself: “Does this really need to be connected to the internet?” In the case of a coffee maker, I’ll let you be the judge.

The post Your Smart Coffee Maker is Brewing Up Trouble appeared first on McAfee Blogs.