Threat Report

This week Skylight Cyber bursts Kaspersky’s Shadowhammer bubble. Dive into some Apache and PHP 0-days. Also, both Cisco and Georgia tech learn that there are no second chances in security.

BARIUM likely responsible for Shadowhammer

Kaspersky is slow dripping information on Shadowhammer, but the community is not waiting. Out of 57,000 observed infections Kaspersky identified only 600 targets Shadowhammer targeted for second stage infection. Shadowhammer identifies targets based a unique identifier assigned to a network interface controller (NIC), called a media access control address (MAC address).

In the possibly the least efficient method of sharing information possible, Kaspersky created an executable and a website for you to submit your MAC address and see if you were one of the 600 known to be sought out by Shadowhammer. This seems like sharing but is actually not sharing. By not giving out the list and making everyone check their site and run their executables, Kaspersky can gather additional data about who was targeted by seeing where positive matches are coming from and getting some secondary intel for the talks they are planning later.

A group called Skylight Cyber popped up and wasn’t having it. They extracted and published the MAC addresses from the executable to their recently registered site. Here they are on github. You can double check their work by using the Kaspersky site to look up a MAC address.

I ran the list of MACs through two different vendor lookup databases to see what vendors were associated with these MACs. Then I found out someone else already did this so I’m just going to include their work.

There were interesting things to note from this data. A majority of the targeted MAC addresses are related to vendors from Taiwan that make up our technology supply chain, with the exceptions being Huawei, VMware, and Intel. With so few MAC addresses targeted, I assume that the threat actor used MAC addresses as a way to single out targets of interest they had identified in some other way. This may have been through some ASUS internal data.

A MAC address doesn’t typically leave your local network. So, it’s not something a remote attacker would know. This was not an elaborate drag net this was very focused.

If I were at some of these companies higher in prevalence like AzureWave Technologies, Liteon Technology, or Hon Hai Precision, I would be taking a good look around. There is a chance that they are actively targeting your employees. They might be targeting the exact employees they need to install more undetected supply chain backdoors. Remember we only got approximately 600 MAC addressed observed from 57,000 of a potential 1,000,000 infections. If that pattern held true, there could be 10,526.3 targeted MAC addresses.

AzureWave Technologies, Inc (Taiwan) – Manufactures and sells wireless connectivity and image processing solutions worldwide.

Lite-On (Taiwan) - Primarily manufactures consumer electronics, including LEDs, semiconductors, computer chassis, monitors, motherboards, DVD, and CD devices, and other electronic components.

Hon Hai Precision Ind. Co.,Ltd (Taiwan) – Trading as Foxconn Technology Group and better known as Foxconn, is a Taiwanese multinational electronics contract manufacturing company.

There is a good chance we already know who is responsible for Shadowhammer. Certain evidence collected draws a link to the ShadowPad incident from 2017. The actor behind the ShadowPad incident has been publicly identified by Microsoft in court documents as BARIUM. BARIUM is an APT actor known to be using the Winnti backdoor. Recently, ESET wrote about another supply chain attack in which BARIUM was also involved.

The following indicators were indicators of compromise related to Shadowhammer.

Domains and IPs:

• asushotfix[.]com
• 141.105.71[.]116

Some of the URLs used to distribute the compromised packages:

• hxxp://liveupdate01.asus[.]com/pub/ASUS/nb/Apps_for_Win8/LiveUpdate/Liveupdate_Test_VER365.zip
• hxxps://liveupdate01s.asus[.]com/pub/ASUS/nb/Apps_for_Win8/LiveUpdate/Liveupdate_Test_VER362.zip
• hxxps://liveupdate01s.asus[.]com/pub/ASUS/nb/Apps_for_Win8/LiveUpdate/Liveupdate_Test_VER360.zip
• hxxps://liveupdate01s.asus[.]com/pub/ASUS/nb/Apps_for_Win8/LiveUpdate/Liveupdate_Test_VER359.zip

Hashes (Liveupdate_Test_VER365.zip):

• aa15eb28292321b586c27d8401703494
• bebb16193e4b80f4bc053e4fa818aa4e2832885392469cd5b8ace5cec7e4ca19

Carpe Diem: The story of a PHP 0-day and an Apache privilege escalation

Apache has been vulnerable to a local root privilege escalation from October, 2015 to Aril, 2019 due to an out-of-bounds array access leading to an arbitrary function call. The vulnerability is triggered when Apache gracefully restarts. In standard Linux configurations, the logrotate utility runs this command once a day, at 6:25AM, in order to reset log file handles. Carpe Diem.

This vulnerability affects mod_prefork, mod_worker and mod_event. Based on the researcher’s report, the success rate of the exploit is 100 percent if Apache has more than four workers. But, if the exploit fails, it can be restarted the next day as Apache is not interrupted. Apache’s error.logwill nevertheless contain notifications about its workers segfaulting.

The researcher also disclosed a PHP use after free zero day in this report that he chained with the Apache vulnerability to get remote code execution. Based on his report PHP never responded to the vulnerability report. This isn’t the only Apache vulnerability to make some waves recently. Check out CVE-2019-0211 while you’re at it.

Cisco fumbles RV320 critical code execution patch

RedTeam Pentesting has recently release information on three Cisco vulnerabilities for the Cisco RV320 web UI, which were previously patched by Cisco in firmware version 1.4.2.19. It appears that the patch was insufficient to prevent exploitation. The Cisco RV320 web interface is still vulnerable to unauthenticated command injection, diagnostic retrieval, and configuration export. Based on the reporting timeline Cisco had six months to fix these critical vulnerabilities and their solution was to block requests with a Curl user-agent. When the researcher reported that the fix was insufficient Cisco requested more time, however the researcher declined to extend the publishing date. As far as I am aware, there is no patch available for these vulnerabilities. You should limit access to the web interface for the Cisco RV320 until Cisco can get it patched up for good.

We'd love to hear your thoughts. Find us on Twitter, LinkedIn or write in to hello@perchsecurity.com

Next: Threat Report Wednesday March 27th 2019