By Darin Smith.TeamTNT is actively modifying its scripts after they were made public by security researchers.These scripts primarily target Amazon Web Services, but can also run in on-premise, container, or other forms of Linux instances.The group's payloads include credential stealers,...


[[ This is only the beginning! Please visit the blog for the complete entry ]]

TeamTNT targeting AWS, Alibaba

New research shows threat actors increasingly leveraging social networks for attacks, with LinkedIn being used in 52% of global phishing attacks.

Shipping, retail, and tech companies are no longer the most popular brands used to hide phishing attacks. Instead, social media platforms have become the brands of choice used to dupe victims and steal their personal data, with LinkedIn-related lures accounting for a full 52% of all global phishing attacks during January, February, and March of 2022, according to new data.

LinkedIn phishing-lure use exploded by 44% over the previous quarter, when it was used in just 8% of phishing attempts, according to Check Point's latest Brand Phishing Report.

"As well as LinkedIn being the most targeted brand by a considerable margin, WhatsApp maintained its position in the top ten, accounting for almost 1 in 20 phishing-related attacks worldwide," the report said.

Shipping is still a draw, even though LinkedIn overtook DHL as the brand most often used in phishing attacks. DHL is now the second-most abused brand, behind 14% of attempts during the same time period. FedEx moved up from seventh place to fifth over the past quarter, with 6% of all phishing attempts spoofing its brand.

**Check Point's List of Top 10 Abused Brands**  

1.  LinkedIn (accounting for 52% of all global phishing attacks over the quarter)
2.  DHL (14%)
3.  Google (7%)
4.  Microsoft (6%)
5.  FedEx (6%)
6.  WhatsApp (4%)
7.  Amazon (2%)
8.  Maersk (1%)
9.  AliExpress (0.8%)
10.  Apple (0.8%)

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

LinkedIn Brand Now the Most Abused in Phishing Attempts

Amazon AWS amazon-ssm-agent before 3.1.1208.0 creates a world-writable sudoers file, which allows local attackers to inject Sudo rules and escalate privileges to root. This occurs in certain situations involving a race condition.

Compare

Choose a tag to compare

**Amazon SSM Agent - Release 3.1.1208.0 - 2022-04-04**

![@mmcgovs](https://avatars.githubusercontent.com/u/95885330?s=40&v=4) mmcgovs released this

· 7 commits to mainline since this release

3.1.1208.0

`b3a8f2b`

Compare

Choose a tag to compare

*   Updated ec2detector module to use Get-CmiInstance instead of wmic.exe
*   Fixed file creation mode of ssm-agent-users sudoer file

**Assets**2

*   Source code (zip)
*   Source code (tar.gz)

CVE-2022-29527: Release Amazon SSM Agent - Release 3.1.1208.0 - 2022-04-04 · aws/amazon-ssm-agent

The Apache Log4j hotpatch package before log4j-cve-2021-44228-hotpatch-1.1-13 didn’t mimic the permissions of the JVM being patched, allowing it to escalate privileges.

**Amazon Linux 2 Security Advisory:** ALAS-2021-1732  
**Advisory Release Date:** 2021-12-22 21:17 Pacific  
**Advisory Updated Date:** 2022-04-28 05:31 Pacific

**Severity:** Important  

**Issue Overview:**

The Apache Log4j hotpatch package starting with log4j-cve-2021-44228-hotpatch-1.1-13 will now explicitly mimic the permissions of the JVM attempting to be updated.

**Affected Packages:**

log4j-cve-2021-44228-hotpatch

**Issue Correction:**  
Run _yum update log4j-cve-2021-44228-hotpatch_ to update your system.  

  

**New Packages:**

noarch:  
    log4j-cve-2021-44228-hotpatch-1.1-13.amzn2.noarch

src:  
    log4j-cve-2021-44228-hotpatch-1.1-13.amzn2.src

CVE-2021-3100: ALAS2-2021-1732

Incomplete fix for CVE-2021-3100. The Apache Log4j hotpatch package starting with log4j-cve-2021-44228-hotpatch-1.1-16 will now explicitly mimic the Linux capabilities and cgroups of the target Java process that the hotpatch is applied to.

The Apache Log4j hotpatch package starting with log4j-cve-2021-44228-hotpatch-1.1-16 will now explicitly mimic the Linux capabilities and cgroups of the target Java process that the hotpatch is applied to.

In order to mimic the Linux capabilities of the target process, Amazon Linux 1 customers need to be running kernel version 4.14.275-142.503 or later, while Amazon Linux 2 customers on ARM need to be running kernel versions 4.14.275-207.503, 5.4.188-104.359, 5.10.109-104.500 or later. Amazon Linux 2 customers on Intel or AMD instances do not need an updated kernel.

CVE-2022-0070: CVE-2022-0070

The Apache Log4j hotpatch package before log4j-cve-2021-44228-hotpatch-1.1-12 didn’t mimic the permissions of the JVM being patched, allowing it to escalate privileges.

**Amazon Linux 2 Security Advisory:** ALAS-2021-1732  
**Advisory Release Date:** 2021-12-22 21:17 Pacific  
**Advisory Updated Date:** 2022-04-18 19:42 Pacific

**Severity:** Important  

**Issue Overview:**

The Apache Log4j hotpatch package starting with log4j-cve-2021-44228-hotpatch-1.1-12 will now explicitly mimic the permissions of the JVM attempting to be updated.

**Affected Packages:**

log4j-cve-2021-44228-hotpatch

**Issue Correction:**  
Run _yum update log4j-cve-2021-44228-hotpatch_ to update your system.  

  

**New Packages:**

noarch:  
    log4j-cve-2021-44228-hotpatch-1.1-13.amzn2.noarch

src:  
    log4j-cve-2021-44228-hotpatch-1.1-13.amzn2.src

Feeling creative? Submit your caption and our panel of experts will reward the winner with a $25 Amazon gift card.

The above cartoon is in a need of a caption, and we're depending on you, dear Dark Reading readers, to come up with something that tickles our collective funny bone. Here are four ways to submit your idea:  

*   Email _\[email protected\]_ with the subject line "Dark Reading April Toon."
*   Via social media: Twitter, Facebook, and LinkedIn.

The contest ends Wednesday, May 11, 2022. We look forward to your submissions.

**Last Month's Winner**  
Congratulations to Nextiva risk manager Bruce Walton, whose winning caption (below) for our March "Sleep Like a Baby" contest rose above many amusing options. A $25 Amazon gift card is on the way. 

Thank you to everyone who participated.

    

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Name That Toon: Helping Hands

Researchers should take extra care in deploying data-science applications to the cloud, as cybercriminals are already targeting popular data-science tools such as Jupyter Notebook.

Always looking for an easy compromise, attackers are now scanning for data-science applications — such as Jupyter Notebook and JupyterLab — along with cloud servers and containers for misconfigurations, cloud-protection firm Aqua Security stated in an advisory published on April 13.

The two popular data science applications — used frequently with Python and R for data analysis — are generally secure by default, but a small fraction of instances are misconfigured, allowing attackers to access the servers with no password, according to the Aqua Security's researchers. In addition, after setting up its own server as a honeypot, the company detected in-the-wild attacks that attempted to install cryptomining tools and ransomware onto accessible instances of the software.

Signs that there are attackers targeting data-science environments is worrisome, considering that the researchers setting up those environment are largely uninformed about cybersecurity, says Assaf Morag, lead data analyst with Aqua Security.

"We know, based on our experience with application security, that developers are starting to learn more about security, but what about data scientists?" he says. "Are they gaining a proper education? My training is as a data scientist, and there were no focus on data security."

**Looking for Misconfigurations**  
In the past, threat actors have frequently scanned the Internet for servers running insecurely configured application. Last year, for example, a misconfigured Git server using default login credentials allowed attackers to steal source code for Nissan's mobile apps, market-research tools, and vehicle-connected services. Over the past five years, a significant number of data breaches have been caused by misconfigured storage servers — such as Amazon's Simple Storage Service (S3) buckets — that were found by attackers.

Research conducted in 2020 found that misconfigured cloud services, containers, and servers are attacked within hours of appearing online. The research, which used an insecurely configured Elasticsearch instance, was targeted by 175 scans over 11 days, increasing to 435 requests over the subsequent 2 weeks, including searches for particular terms such as "password" and "wallet."

The attacks on data-science tools used similar tactics, as seen through the lens of its honeypots, Aqua Security stated in its advisory.

"Most of the attacks got initial access via misconfigured environments," the company stated. "After gaining access, adversaries attempted to achieve persistence by creating a new user in the notebook or adding Secure Shell (SSH) keys. Then, most of the attacks executed a cryptominer, trying to get a quick gain."

The problem is that a small minority of the instances are configured to allow anyone to access the notebook server. During the research, for example, the Aqua Security researchers saw a novel attempt at using access gained through Jupyter Notebook to run a Python-based crypto-ransomware program.

"Normally, access to the online application should be restricted, either with a token or password or by limiting ingress traffic," Aqua Security wrote in the ransomware advisory. "However, sometimes these notebooks are left exposed to the internet with no authentication means, allowing anyone to easily access the notebook via a web browser."

**Lock Down Data Tools**  
Overall, data scientists and the Jupyter Project appear to be doing a credible job in securing the software. In total, less than 1% of the approximately 10,000 of instances of Jupyter Notebook are configured for open access, according to scans using the Shodan search engine. The fact that attackers are targeting the servers, however, should prompt defenders to focus on ensuring that the data-science tools are locked down, says Aqua Security's Morag.

"There will always be a zero-day or another misconfiguration that users did not know about, like Log4shell or Spring4 shell," he says. "While those do not apply to Jupyter Notebook, they show that you need to have another layer of protection. If you rely on the network to protect you, it is not enough these days, I think."

The Aqua research is not the first to expose vulnerabilities and misconfigurations of data-science tools. In 2021, researchers from cloud-security firm Wiz.io found that Microsoft created an insecure implementation for linking Jupyter Notebook instances to Azure Cosmos DB databases, allowing attackers to create a connection between an instance of Jupyter Notebook and the database service, which then allowed the attacker to access all other databases using the same service.

Attackers' strategy of targeting a new community of technical users is not new. Threat actors have already started targeting machine-learning researchers and the data behind artificial-intelligence and machine-learning systems, according to experts.

Data Scientists, Watch Out: Attackers Have Your Number

An issue was discovered in Amazon AWS VPN Client 2.0.0. A TOCTOU race condition exists during the validation of VPN configuration files. This allows parameters outside of the AWS VPN Client allow list to be injected into the configuration file prior to the AWS VPN Client service (running as SYSTEM) processing the file. Dangerous arguments can be injected by a low-level user such as log, which allows an arbitrary destination to be specified for writing log files. This leads to an arbitrary file write as SYSTEM with partial control over the files content. This can be abused to cause an elevation of privilege or denial of service.

**Vulnerabilities Overview**

**Affected Product**

The AWS VPN Client application is affected by an arbitrary file write as SYSTEM, which can lead to privilege escalation and an information disclosure vulnerability that allows the user’s Net-NTLMv2 hash to be leaked via a UNC path in a VPN configuration file. These vulnerabilities are confirmed to affect version 2.0.0 and have been fixed in version 3.0.0.

To fix the vulnerabilities, upgrade to version 3.0.0 which can be downloaded here.

**Vendor:** Amazon Web Service (AWS)  
**Product:** AWS VPN Client (Windows)  
**Confirmed Vulnerable Version:** 2.0.0**Fixed Version:** 3.0.0

**CVE-2022-25166: Arbitrary File Write as SYSTEM**

A race condition exists during the validation of OpenVPN configuration files. This allows OpenVPN configuration directives outside of the AWS VPN Client allowed OpenVPN directives list to be injected into the configuration file prior to the AWS VPN Client service, which runs as SYSTEM, processing the file. Dangerous arguments can be injected by a low-level user such as “log”, which allows an arbitrary destination to be specified for writing log files.

The impact is an arbitrary file write as SYSTEM with partial control over the contents of the file. This can lead to local privilege escalation or denial of service.

**CVE-2022-25165: Information Disclosure via UNC Path**

It is possible to include a UNC path in the OpenVPN configuration file when referencing file paths for directives (such as “auth-user-pass”). When this file is imported to the AWS VPN Client and the client attempts to validate the file path, it performs an open operation on the path and leaks the user’s Net-NTLMv2 hash to an external server.

The impact is information leakage of a user’s Net-NTLMv2 hash. This could be exploited by having a user attempt to import a malicious VPN configuration file into the AWS VPN Client.

**What Is AWS VPN Client**

AWS VPN Client is a desktop application that can be used to connect to the AWS Client VPN.

From the product website:

_The client for AWS Client VPN is provided free of charge. You can connect your computer directly to AWS Client VPN for an end-to-end VPN experience. The software client is compatible with all features of AWS Client VPN._

**Arbitrary File Write as SYSTEM Technical Details**

AWS VPN Client installs a Windows service which runs as SYSTEM acting as a wrapper to a custom OpenVPN client executable. A low privileged user can use the AWS VPN Client to attempt to connect to a VPN using an imported OpenVPN configuration file. 

There are known dangerous OpenVPN directives which perform actions such as running commands or writing log files to a specific destination during a VPN connection. AWS VPN Client attempts to restrict the OpenVPN directives which can be used in the configuration file, but the check fails as it is performed prior to the execution of the OpenVPN executable. This makes it possible to race the execution of the OpenVPN executable after the configuration file has been validated and inject disallowed directives into the file.

Below you can see a log file produced by the AWS VPN service which shows the time between the successful validation of the configuration and the execution of the OpenVPN client.

![](https://rhinosecuritylabs.com/wp-content/uploads/2022/04/log_File.png "log_File")

It is easy enough to use a Powershell script to then monitor the log file and upon successful validation of the configuration file immediately write the malicious directive to the configuration file prior to the OpenVPN executable processing it.

With the ability to inject disallowed directives it would seem as easy as adding one of the directives which allows executing a command into the configuration file giving an easy path to privilege escalation. Although in this case it was not this straightforward as AWS VPN service starts the OpenVPN executable with the “–script-security 1” flag, which prevents external binaries or scripts from being executed.

Although we cannot directly run commands, it is still possible to use the “log” directive to redirect log output to any path or file of our choosing. Since execution is done as the SYSTEM user this gives us a privileged file write where we partially control the content. In the simplest case this could be used to write a batch script to an administrator’s startup directory.

A proof of concept for CVE-2022-25166 can be found on our Github repo here.

**Information Disclosure via UNC Path Technical Details**

AWS VPN Client performs validation on configuration files which are imported into the client as a VPN profile. One of the validation steps consists of checking if a file path exists when any file paths are supplied to directives which accept a file path as an argument.

Some examples of valid directives that accept files paths are

*   auth-user-pass
*   ca

Validation by AWS VPN Client is done by performing a file open operation on the path to ensure it exists.

![](https://rhinosecuritylabs.com/wp-content/uploads/2022/04/code_block.png "code_block")

AWSVPNClient.Core.dll contains OvpnConfigParser.cs which has the “CheckFilePath” method used to check if a file path is valid. This simply calls File.Open on the supplied file name.

This can be exploited by providing a file that contains UNC paths as the file path. When the file is validated before being imported it will open the UNC path and send the user’s Net-NTLMv2 hash to an external server.

A proof of concept for CVE-2022-25165 can be found on our Github repo here.

**Conclusion**

**Disclosure Timeline**

Similar to the Pritunl CVE and blog post recently released, this vulnerability demonstrates the exploit potential in high-privilege Windows processes — such as those used by VPN clients.  This also shows how common application flaws are still present in sensitive applications, whether from open source providers or major tech companies.  
Stay tuned for another VPN release in the coming weeks!

 

2/15/2022

Vulnerabilities reported to AWS

2/16/2022

Acknowledged by AWS

3/4/2022

AWS confirmed the issues have been addressed in version 3.0.0

4/12/2022

Full Disclosure (blog post) released

CVE-2022-25165: CVE-2022-25165: Privilege Escalation to SYSTEM in AWS VPN Client - Rhino Security Labs

An issue was discovered in ThoughtWorks GoCD before 21.3.0. An attacker with privileges to create a new pipeline on a GoCD server can abuse a command-line injection in the Git URL "Test Connection" feature to execute arbitrary code.

Tag

#amazon