Hacking Anything LLM via Reversing CVE’s(Duplicates)

5 min readMar 21, 2024

Hi Everyone, This is Basavaraj, Back again with one more writeup :) ……You can check my older writeups here https://basu-banakar.medium.com/

What is Anything LLM?
A full-stack application that enables you to turn any document, resource, or piece of content into a context that any LLM can use as references during chatting. This application allows you to pick and choose which LLM or Vector Database you want to use as well as supporting multi-user management and permissions.

#1. LLM02: Stored XSS (Insecure Output Handling) — Easy Peasy

Found this disclosed XSS issue and I was going through the fix.

The fix was only added via dompurify (Basically an input sanitization only), Still, HTML Execution is possible.

So there was no output sanitization, Let's exploit via LLM02: Insecure Output Handling

Understanding the Vulnerability:
Insecure Output Handling pertains to the insufficient validation, sanitization, and management of outputs produced by large language models (LLMs) before their utilization downstream.
This vulnerability exposes systems to risks akin to granting users indirect access to additional functionality through manipulable prompt inputs.
Distinguishing from Overreliance:
Unlike Overreliance, which focuses on the broader issue of excessive dependency on the accuracy of LLM outputs, Insecure Output Handling specifically addresses the security risks associated with LLM-generated outputs before they traverse downstream.
Potential Exploitation and Impacts:
Exploiting Insecure Output Handling vulnerabilities can lead to severe security breaches, including XSS and CSRF in web browsers, as well as SSRF, privilege escalation, or remote code execution in backend systems.
The vulnerability’s impact can be exacerbated under certain conditions, such as granting excessive LLM privileges or susceptibility to prompt injection attacks.
Common Vulnerability Scenarios:
Third-party plugins lacking robust input validation mechanisms.
Overprivileged LLM access, enabling unauthorized escalation of privileges or execution of remote code.
Vulnerability to prompt injection attacks, allowing attackers to manipulate inputs for unauthorized access.
Mitigation Strategies:
Implement thorough validation and sanitization processes for LLM-generated outputs before downstream utilization.
Restrict LLM privileges to prevent unauthorized access and privilege escalation.
Enhance security measures to thwart prompt injection attacks and other forms of manipulation.
By prioritizing the mitigation of Insecure Output Handling vulnerabilities, organizations can bolster the security posture of their systems and mitigate the associated risks posed by large language models.
Source : https://owasp.org/llm , https://llmtop10.com/llm02/

Let's jump in.

I have deployed Anything LLM in my local server, and the instance looks like this

Now I will send some XSS payloads as input for chat and that's not working.

However, there is some protection due to dompurify.

Let's ask LLM to give some XSS payloads(Might execute), But no luck :(

Let's fool LLM and get it done, So finally we got XSS because of unsanitized output.

#2. SSRF (Server Side Request Forgery) — Easy Peasy

I was going through some of the disclosed reports on https://huntr.dev and came across some SSRF reports like these.

So while revalidating these disclosed issues, I came to know that the fix for aws metadata access is only made on the cloudformation stack i.e.

Cloudformation stack used for deploying anything LLM on aws ec2

This indicates that iptables to drop any outgoing packets (traffic leaving the instance) with a destination IP address of 169.254.169.254, except for those initiated by the root user (--uid-owner root). This IP address (169.254.169.254) is commonly used for accessing the instance metadata service on AWS EC2 instances.

So while doing a fix analysis on the code level came to know that there is no fix available for cloud metadata access

As we can see above, access has been restricted to IPs starting with 192, 172, 10, 127, and followed by the regex check whether it is an internal IP or not.

What next?

Let’s deploy Anything LLM on the AWS cloud manually(Without using the cloudformation stack) and exploit the SSRF.

#03. Full read Local SSRF via within docker port scan using server-side URL redirection.

After analyzing all the disclosed SSRF’s, I came to know that, the Anything LLM team had added a fix on the docker container level, i.e any requests that hit the host machine’s internal IPs that request will be Blocked/Dropped(Which is basically an isolated network limited to only to one container).

And I have verified the fix like this.

Run a Python HTTP server on the host machine

2. Now hit this via a vulnerable feature in the Anything LLM instance

Trying bypass via server-side URL Redirection, No luck :(

Because it is not hitting the internal host which is on the host machine.

But still, there is one attack scenario here.
What if the user(Anything LLM User) hosts some other service within the same container i.e Anything LLM :)

Let’s try that

Let's log into the Anything LLM container and create a Python web server