Daily Archives: January 2, 2019

NRSMiner updates to newer version

More than a year after the world first saw the Eternal Blue exploit in action during the May 2017 WannaCry outbreak, we are still seeing unpatched machines in Asia being infected by malware that uses the exploit to spread. Starting in mid-November 2018, our telemetry reports indicate that the newest version of the NRSMiner cryptominer, which uses the Eternal Blue exploit to propagate to vulnerable systems within a local network, is actively spreading in Asia. Most of the infected systems seen are in Vietnam.

nrsminer_countrystatistics

November-December 2018 telemetry statistics for NRSMiner, by country

In addition to downloading a cryptocurrency miner onto an infected machine, NRSMiner can download updated modules and delete the files and services installed by its own previous versions.

This post provides an analysis of how the latest version of NRSMiner infects a system and finds new vulnerable targets to infect. Recommendations for mitigation measures, IOCs and SHA1s are listed at the end of the post.

 

How NRSMiner spreads

There are 2 methods by which a system can be infected by the newest version of NRSMiner:

  • By downloading the updater module onto a system that is already infected with a previous version of NRSMiner, or:
  • If the system is unpatched (MS17-010) and another system within the intranet has been infected by NRSMiner.

 

Method 1: Infection via the Updater module

First, a system that has been infected with an older version of NRSMiner (and has the wmassrv service running) will connect to tecate[.]traduires[.]com to download an updater module to the %systemroot%\temp folder as tmp[xx].exe, where [xx] is the return value of the GetTickCount() API.

When this updater module is executed, it downloads another file to the same folder from one of a series of hard-coded IP addresses:

nrsminer_ipaddresses

List of IP addresses found in different updater module files

The downloaded file, /x86 or /x64, is saved in the %systemroot%\temp folder as WUDHostUpgrade[xx].exe; again, [xx] is the return value of the GetTickCount() API.

WUDHostUpgrade[xx].exe

The WUDHostUpgrade[xx].exe first checks the mutex {502CBAF5-55E5-F190-16321A4} to determine if the system has already been infected with the latest NRSMiner version. If the system is infected, the WUDHostUpgrade[xx].exe deletes itself. ­Otherwise, it will delete the files MarsTraceDiagnostics.xml, snmpstorsrv.dll, MgmtFilterShim.ini.

Next, the module extracts the following files from its resource section (BIN directory) to the %systemroot%\system32 or %systemroot%\sysWOW64 folder: MarsTraceDiagnostics.xml, snmpstorsrv.dll.

It then copies the values for the CreationTime, LastAccessTime and LastWritetime properties from svchost.exe and updates the same properties for the MarsTraceDiagnostics.xml and snmpstorsrv.dll files with the copied values.

Finally, the WUDHostUpgrade[xx].exe installs a service named snmpstorsrv, with snmpstorsrv.dll registered as servicedll. It then deletes itself.

 

nrsminer_WUDHostUpgradexx_code

Pseudo-code for WUDHostUpgradexx.exe’s actions

 

Snmpstorsrv service

The newly-created Snmpstorsrv service starts under “svchost.exe -k netsvcs” and loads the snmpstorsrv.dll file, which creates multiple threads to perform several malicious activities.

nrsminer_Snmpstorsrv_activities

Snmpstorsrv service’s activities

The service first creates a file named MgmtFilterShim.ini in the %systemroot%\system32 folder, writes ‘+’ in it and modifies its CreationTime, LastAccessTime and LastWritetime properties to have the same values as svchost.exe.

Next, the Snmpstorsrv service extracts malicious URLs and the cryptocurrency miner’s configuration file from MarsTraceDiagnostics.xml.

nrsminer_urls

Malicious URLs and miner configuration details in the MarsTraceDiagnostics.xml file

On a system that is already infected with an older version of NRSMiner, the malware will delete all components of its older version before infecting it with the newer one. To remove the prior version of itself, the newest version refers to a list of services, tasks and files to be deleted that can be found as strings in the snmpstorsrv.dll file;  to remove all older versions, it refers to a list that is found in the MarsTraceDiagnostics.xml file.

nrsminer_delete_list

List of services, tasks, files and folders to be deleted

After all the artifacts of the old versions are deleted, the Snmpstorsrv service checks for any updates to the miner module by connecting to:

  • reader[.]pamphler[.]com/resource
  • handle[.]pamphler[.]com/modules.dat

If an updated miner module is available, it is downloaded and written into the MarsTraceDiagnostics.xml file. Once the new module is downloaded, the old miner file in %systemroot%\system32\TrustedHostex.exe is deleted. The new miner is decompressed in memory and the newly extracted miner configuration data is written into it.

This newly updated miner file is then injected into the svchost.exe to start crypto-mining. If the injection fails, the service instead writes the miner to %systemroot%\system32\TrustedHostex.exe and executes it.

nrsminer_decompressed_miner

The miner decompressed in memory

Next, the Snmpstorsrv service decompresses the wininit.exe file and injects it into svchost.exe. If the injection fails, it writes wininit.exe to %systemroot%\AppDiagnostics\wininit.exe and executes it. The service also opens port 60153 and starts listening.

In two other threads, the service sends out details about the infected system to the following sites:

  • pluck[.]moisture[.]tk – MAC address, IP Address, System Name, Operating System information
  • jump[.]taucepan[.]com – processor and memory specific information
Click to view slideshow.

System information forwarded to remote sites

Based on the information sent, a new updater file will be downloaded and executed, which will perform the same activities as described in “Updater Module” section above. This updater module can be used to infect systems with any new upcoming version of NRSMiner.

 

Method 2: Infection via Wininit.exe and Exploit

In the latest NRSMiner version, wininit.exe is responsible for handling its exploitation and propagation activities. Wininit.exe decompresses the zipped data in %systemroot%\AppDiagnostics\blue.xml and unzips files to the AppDiagnostics folder. Among the unzipped files is one named svchost.exe, which is the Eternalblue – 2.2.0 exploit executable. It then deletes the blue.xml file and writes 2 new files named x86.dll and x64.dll in the AppDiagnostics folder.

Wininit.exe scans the local network on TCP port 445 to search for other accessible systems. After the scan, it executes the Eternalblue executable file to exploit any vulnerable systems found. Exploit information is logged in the process1.txt file.

If the vulnerable system is successfully exploited, Wininit.exe then executes spoolsv.exe, which is the DoublePulsar – 1.3.1 executable file. This file installs the DoublePulsar backdoor onto the exploited system. Depending on the operating system of the target, either the x86.dll or x64.dll file is then transferred by Wininit.exe and gets injected into the targeted system’s lsass.exe by the spoolsv.exe backdoor.

nrsminer_propagation_method

Propagation method

x86.dll/x64.dll

This file creates a socket connection and gets the MarsTraceDiagnostics.xml file in %systemroot%\system32 folder from the parent infected system. It extracts the snmpstorsrv.dll, then creates and starts the Snmpstorsrv service on the newly infected system, so that it repeats the whole infection cycle and finds other vulnerable machines.

Miner module

NRSMiner uses the XMRig Monero CPU miner to generate units of the Monero cryptocurrency. It runs with one of the following parameters:

nrsminer_miner_parameters

Miner parameters

The following are the switches used in the parameters:

  • -o, –url=URL                  URL of mining server
  • -u, –user=USERNAME username for mining server
  • -p, –pass=PASSWORD  password for mining server
  • -t, –threads=N               number of miner threads
  • –donate-level=N           donate level, default 5% (5 minutes in 100 minutes)
  • –nicehash                      enable nicehash.com support

 

Detection

F-Secure products currently detect and block all variants of this malware, with a variety of detections.

Mitigation recommendations

The following measures can be taken to mitigate the exploitation of the vulnerability targeted by Eternal Blue and prevent an infection from spreading in your environment.

  • For F-Secure products:
    • Ensure that the F-Secure security program is using the latest available database updates.
    • Ensure DeepGuard is turned on in all your corporate endpoints, and F-Secure Security Cloud connection is enabled.
    • Ensure that F-Secure firewall is turned on in its default settings. Alternatively, configure your firewall to properly block 445 in- and outbound traffic within the organization to prevent it from spreading within the local network.
  • For Windows:
    • Use Software Updater or any other available tool to identify endpoints without the Microsoft-issued security fix (4013389) and patch them immediately.
    • Apply the relevant security patches for any Windows systems under your administration based on the guidance given in Microsoft’s Customer Guidance for WannaCrypt attacks.
    • If you are unable to patch it immediately, we recommend that you disable SMBv1 with the steps documented in Microsoft Knowledge Base Article 2696547 to reduce attack surface.

 

Indicator of compromise – IOC:

Sha1s:

32ffc268b7db4e43d661c8b8e14005b3d9abd306 - MarsTraceDiagnostics.xml
07fab65174a54df87c4bc6090594d17be6609a5e - snmpstorsrv.dll
abd64831ad85345962d1e0525de75a12c91c9e55 - AppDiagnostics folder (zip)
4971e6eb72c3738e19c6491a473b6c420dde2b57 - Wininit.exe
e43c51aea1fefb3a05e63ba6e452ef0249e71dd9 – tmpxx.exe
327d908430f27515df96c3dcd180bda14ff47fda – tmpxx.exe
37e51ac73b2205785c24045bc46b69f776586421 - WUDHostUpgradexx.exe
da673eda0757650fdd6ab35dbf9789ba8128f460 - WUDHostUpgradexx.exe
ace69a35fea67d32348fc07e491080fa635cc859 - WUDHostUpgradexx.exe
890377356f1d41d2816372e094b4e4687659a96f - WUDHostUpgradexx.exe
7f1f63feaf79c5f0a4caa5bbc1b9d76b8641181a - WUDHostUpgradexx.exe
9d4d574a01aaab5688b3b9eb4f3df2bd98e9790c - WUDHostUpgradexx.exe
9d7d20e834b2651036fb44774c5f645363d4e051 – x64.dll
641603020238a059739ab4cd50199b76b70304e1 – x86.dll

IP addresses:

167[.]179.79.234
104[.]248.72.247
172[.]105.229.220
207[.]148.110.212
149[.]28.133.197
167[.]99.172.78
181[.]215.176.23
38[.]132.111.23
216[.]250.99.33
103[.]103.128.151

URLs:

c[.]lombriz[.]tk
state[.]codidled[.]com
null[.]exhauest[.]com
take[.]exhauest[.]com
junk[.]soquare[.]com
loop[.]sawmilliner[.]com
fox[.]weilders[.]com
asthma[.]weilders[.]com
reader[.]pamphler[.]com
jump[.]taucepan[.]com
pluck[.]moisture[.]tk
handle[.]pamphler[.]com

Texas Instruments Bluetooth Low Energy Denial of Service and Remote Code Execution Vulnerability

On November 1st, 2018, Armis announced the presence of a Remote Code Execution (RCE) or Denial of Service (DoS) vulnerability in the Bluetooth Low Energy (BLE) Stack on Texas Instruments (TI) chips CC2640 and CC2650. This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) ID of CVE-2018-16986.

The vulnerability is due to a memory corruption condition that may occur when processing malformed BLE frames. An attacker in close proximity to an affected device that is actively scanning could exploit the issue by broadcasting malformed BLE frames. A successful exploit may result in the attacker gaining the ability to execute arbitrary code or cause a denial of service condition on an affected device.

There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181101-ap


Security Impact Rating: High
CVE: CVE-2018-16986

Multiple Vulnerabilities in OpenSSL Affecting Cisco Products: September 2016

On September 22, 2016, the OpenSSL Software Foundation released an advisory that describes 14 vulnerabilities. Of these 14 vulnerabilities, the OpenSSL Software Foundation classifies one as “Critical Severity,” one as “Moderate Severity,” and the other 12 as “Low Severity.”

Subsequently, on September 26, the OpenSSL Software Foundation released an additional advisory that describes two new vulnerabilities. These vulnerabilities affect the OpenSSL versions that were released to address the vulnerabilities disclosed in the previous advisory. One of the new vulnerabilities was rated as “High Severity” and the other as “Moderate Severity.”

Of the 16 released vulnerabilities:
  • Fourteen track issues that could result in a denial of service (DoS) condition
  • One (CVE-2016-2183, aka SWEET32) tracks an implementation of a Birthday attack against Transport Layer Security (TLS) block ciphers that use a 64-bit block size that could result in loss of confidentiality
  • One (CVE-2016-2178) is a timing side-channel attack that, in specific circumstances, could allow an attacker to derive the private DSA key that belongs to another user or service running on the same system

Five of the 16 vulnerabilities exclusively affect the recently released OpenSSL versions that are part of the 1.1.0 release series, which has not yet been integrated into any Cisco product.

This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160927-openssl
Security Impact Rating: Medium
CVE: CVE-2016-2177,CVE-2016-2178,CVE-2016-2179,CVE-2016-2180,CVE-2016-2181,CVE-2016-2182,CVE-2016-2183,CVE-2016-6302,CVE-2016-6303,CVE-2016-6304,CVE-2016-6305,CVE-2016-6306,CVE-2016-6307,CVE-2016-6308,CVE-2016-6309,CVE-2016-7052

I found a GCP service account token…now what?

Google Cloud Platform (GCP) is rapidly growing in popularity and i haven't seen too many posts on  f**king it up so I'm going to do at least one :-)

Google has several ways to do authentication but most likely what you are going to come across shoved into code somewhere or in a dotfiles is a service account json file.

It's going to look similar to this:

These service account files are similar to AWS tokens in that it can be difficult to determine what they have access to if you don't already have console and/or IAM access. However with a little bit of scripting we can brute force at least some of the token's functionality pretty quickly. The issue being service accounts for something like GCP compute looks the same as one you made to manage your calendar or one of the 100's of other Google services.

You'll need to install the gcloud tools for you OS. Info here:  https://cloud.google.com/sdk/

Once you have the gcloud suite of tools installed you can auth with the json file with the following command:

gcloud auth activate-service-account --key-file=KEY_FILE

If they key is invalid you'll see something like the below:

gcloud auth activate-service-account --key-file=21.json
ERROR: (gcloud.auth.activate-service-account) There was a problem refreshing your current auth tokens: invalid_grant: Not a valid email or user ID.

Otherwise it will look similar to below:

gcloud auth activate-service-account --key-file=/Users/CG/Documents/pentest/gcp-weirdaal/gcp.json
Activated service account credentials for: [python@removed.iam.gserviceaccount.com]

you can validate it worked by issuing gcloud auth list command:

gcloud auth list
                  Credentialed Accounts
ACTIVE  ACCOUNT

*       python@removed.iam.gserviceaccount.com


I put together a shell script that runs though a bunch of command to enumerate information. They only you info need to provide is the project name. This can be found in the json file in the project_id  field or by issuing the  gcloud project list command.  Sometimes there are multiple projects associated with an account and you'd need to run the shell script with for each project.

The first time you run these api calls you might need to pass a "Y" to the cli to enable it. you can get around this manual shenanigans by doing a:

yes | ./gcp_enum.sh 

This will answer Yes for you each time :-)






NCC Group also has two tools you could check out:

https://github.com/nccgroup/G-Scout

and

https://github.com/nccgroup/ScoutSuite


enjoy

CG

Vulnerability Spotlight: Multiple privilege escalation vulnerabilities in CleanMyMac X



Tyler Bohan of Cisco Talos discovered these vulnerabilities.

Executive summary


Today, Cisco Talos is disclosing several vulnerabilities in MacPaw’s CleanMyMac X software. CleanMyMac X is a cleanup application for Mac operating systems that allows users to free up extra space on their machines by scanning for unused or unnecessary files and deleting them. In all of these bugs, an attacker with local access to the victim machine could modify the file system as root.

In accordance with our coordinated disclosure policy, Cisco Talos worked with MacPaw to ensure that these issues are resolved and that an update is available for affected customers.


Vulnerability details


CleanMyMac X moveItemAtPath privilege escalation vulnerability (TALOS-2018-0705/CVE-2018-4032)


A privilege escalation vulnerability exists in the way that the CleanMyMac X software improperly validates inputs. This particular bug arises in the in the `moveItemAtPath` function of the helper protocol. If the attacker supplies `nil` in the to_path argument, the file is deleted, and any application can access this function and run it as root. Therefore, non-root users could delete files from the root file system.

For more information on this vulnerability, read our complete advisory here.

CleanMyMac X moveToTrashItemAtPath privilege escalation vulnerability (TALOS-2018-0706/CVE-2018-4033)


A privilege escalation vulnerability exists in the way that the CleanMyMac X software improperly validates inputs. This particular bug arises in the `moveToTrashItemAtPath` function of the helper protocol. If an attacker enters `nil` into the function’s fourth argument, any other application could access that function as root, allowing them to delete files from the root file system.

For more information on this vulnerability, read our complete advisory here.

CleanMyMac X removeItemAtPath privilege escalation vulnerability (TALOS-2018-0707/CVE-2018-4034)


A privilege escalation vulnerability exists in the way that the CleanMyMac X software improperly validates inputs. This particular bug arises in the `removeItemAtPath` function of the helper protocol. When executing this function, there is no validation of the calling application. Therefore, any application is able to access this function and run it as root. An attacker could exploit this vulnerability to cross a privilege boundary and delete files from the root file system.

For more information on this vulnerability, read our complete advisory here.

CleanMyMac X truncateFileAtPath privilege escalation vulnerability (TALOS-2018-0708/CVE-2018-4035)



A privilege escalation vulnerability exists in the way that the CleanMyMac X software improperly validates inputs. This particular bug arises in the `truncateFileAtPath` function of the helper protocol. When executing this function, there is no validation of the calling application. Therefore, any application is able to access this function and run it as root. An attacker could exploit this vulnerability to cross a privilege boundary and delete files from the root file system.

For more information on this vulnerability, read our complete advisory here.

CleanMyMac X removeKextAtPath privilege escalation vulnerability (TALOS-2018-0709/CVE-2018-4036)


A privilege escalation vulnerability exists in the way that the CleanMyMac X software improperly validates inputs. This particular bug arises in the `removeKextAtPath` function of the helper protocol. When executing this function, there is no validation of the calling application. Therefore, any application is able to access this function and run it as root. An attacker could exploit this vulnerability to cross a privilege boundary and delete files from the root file system.

For more information on this vulnerability, read our complete advisory here.

CleanMyMac X removeDiagnosticsLogs privilege escalation vulnerability (TALOS-2018-0710/CVE-2018-4037)


A privilege escalation vulnerability exists in the way that the CleanMyMac X software improperly validates inputs. This particular bug arises in the `removeDiagnosticsLogs` function of the helper protocol. When executing this function, a string is constructed containing the objective-c strings, `erase` and `all`. There is no validation of the calling application, which allows other applications to access this function and run it as root. This could allow a non-root user to delete the main log data from the system.

For more information on this vulnerability, read our complete advisory here.


CleanMyMac X enableLaunchdAgentAtPath privilege escalation vulnerability (TALOS-2018-0715)/CVE-2018-4041)


An exploitable privilege escalation vulnerability exists in the helper service of Clean My Mac X. This particular bug arises in the `enableLaunchdAgentAtPath` function of the helper protocol. When this function is loaded, there is no validation of the calling application, which allows other applications to access this function and run it as root. This could allow a non-root user to delete the main log data from the system.

For more information on this vulnerability, read our complete advisory here.

CleanMyMac X removeLaunchdAgentAtPath privilege escalation vulnerability (TALOS-2018-0716)/CVE-2018-4042)


An exploitable privilege escalation vulnerability exists in the helper service of Clean My Mac X. This particular bug arises in the `removeLaunchdAgentAtPath` function of the helper protocol. When this function is loaded, there is no validation of the calling application, which allows other applications to access this function and run it as root. This could allow a non-root user to delete the main log data from the system.

For more information on this vulnerability, read our complete advisory here.

CleanMyMac X removeASL privilege escalation vulnerability (TALOS-2018-0717)/CVE-2018-4043)


An exploitable privilege escalation vulnerability exists in the helper service of Clean My Mac X. This particular bug arises in the `removeASL` function of the helper protocol. This proces calls out and stops the system daemon for logging and also stops the Apple System Log facility. As both of these are root daemons, this creates a privilege issue. There is no validation of the calling application, and any other application is able to access this function, crossing a privilege boundary. Non-root users could then delete a package’s privileged information.

For more information on this vulnerability, read our complete advisory here.

CleanMyMac X removePackageWithID privilege escalation vulnerability (TALOS-2018-0718)/CVE-2018-4044)


An exploitable privilege escalation vulnerability exists in the helper service of Clean My Mac X. This particular bug arises in the `removePackageWithID` function of the helper protocol. An attacker could utilize the `--forget` command when calling this function to delete all receipt information about a particular installed package. There is no validation of the calling application in this scenario, so any application could access this function. Because this is a privileged helper, it runs as root, which then crosses a privilege boundary, allowing non-root users to delete a package’s privileged information.

For more information on this vulnerability, read our complete advisory here.

CleanMyMac X securelyRemoveItemAtPath privilege escalation vulnerability (TALOS-2018-0719)/CVE-2018-4045)


An exploitable privilege escalation vulnerability exists in the helper service of Clean My Mac X. This particular bug arises in the `securelyRemoveItemAtPath` function of the helper protocol. A user-supplied argument is passed into this function when executed. There is no validation of the calling application, therefore, any application is able to access this function, and because this is a privileged helper, it runs as root. This crosses a privilege boundary, allowing non-root users to delete files from the root file system.

For more information on this vulnerability, read our complete advisory here.



CleanMyMac X pleaseTerminate denial-of-service vulnerability (TALOS-2018-0720)/CVE-2018-4046)


CleanMyMac X contains a denial-of-service vulnerability in its helper service due to improper input validation. This particular bug arises in the `pleaseTerminate` function of the helper protocol. When executing this function, the process terminates itself and has no validation of the calling application. Therefore, any application is able to terminate this function, crossing a privilege boundary and allow non-root users to terminate this root daemon.

For more information on this vulnerability, read our complete advisory here.

CleanMyMac X disableLaunchdAgentAtPath privilege escalation vulnerability(TALOS-2018-0721)/CVE-2018-4047)


CleanMyMac X contains a privilege escalation vulnerability in the software’s helper service. This particular bug arises in the `disableLaunchdAgentAtPath` function of the helper protocol. This function calls `launchtl` and unloads the script from the provided location. All `launchtl` commands must run as root. There is no validation of the calling application, therefore, any application is able to access this function, crossing a privilege boundary. This could allow any non-root users to uninstall `launchd` scripts as root.

For more information on this vulnerability, read our complete advisory here.

Versions tested


Talos has tested and confirmed that Clean My Mac X, version 4.04 is affected by all of these vulnerabilities.




Conclusion


It is recommended that users update to the latest version of this software (CleanMyMac X version 4.2.0). There are several ways in which an attacker could bypass the usual protections in place to acquire greater access to the machine and modify the file system as root.

Coverage


The following SNORTⓇ rules will detect exploitation attempts. Note that additional rules may be released at a future date and current rules are subject to change pending additional vulnerability information. For the most current rule information, please refer to your Firepower Management Center or Snort.org.

Snort Rules: 48297, 48298