google / tsunami-security-scanner-plugins

This project aims to provide a central repository for many useful Tsunami Security Scanner plugins.
Apache License 2.0
860 stars 178 forks source link

AI PRP: BentoML Insecure Deserialization RCE #482

Open secureness opened 1 month ago

secureness commented 1 month ago

reference: https://github.com/protectai/ai-exploits/blob/main/bentoml/README.md I think it is easy to exploit but I must find a solution to create a python pickle easily with java.

secureness commented 1 month ago

is it possible to write this plugin in Python, because we need to use the pickle function to serialize the payload with Python?

maoning commented 1 month ago

is it possible to write this plugin in Python, because we need to use the pickle function to serialize the payload with Python?

I'm currently working on creating a setup script to run python Tsunami plugins with the main Java program, I will update here once it's ready.

maoning commented 1 month ago

@secureness you can now test out python plugins using https://github.com/google/tsunami-security-scanner/blob/master/quick_start_advanced.sh

The script is not thoroughly tested, let me know if you run into any issues.

secureness commented 1 month ago

@maoning someone said in comments of the CVE report in huntr.dev that only versions between 1.2.0 - 1.2.4 are vulnerable, I haven't tested other versions myself yet, do you accept this as a PRP?

maoning commented 1 month ago

@secureness Could you also check for exposed BentoML API (report it as a medium severity finding) in addition to the RCE vuln (report it as a critical finding)? For exposed BentoML API, the worst thing could happen is that the inference service can queried by anyone right? Is there any interesting API endpoints that have additional security risks?

secureness commented 1 month ago

@maoning we can check for a specific swagger UI with a Title containing the bentoML: https://docs.bentoml.com/en/latest/bentocloud/how-tos/call-deployment-endpoints.html#interact-with-the-deployment

we need to know at least one of the HTTP endpoints from Swagger UI to send a pickled payload to that endpoint to exploit the CVE.

So, the logic is this: first check for an exposed swagger UI and find an HTTP endpoint from the UI, and finally exploit the CVE, report the CVE and exposed UI otherwise only report the exposed UI.

maoning commented 1 week ago

@secureness sounds good, you can proceed forward with this plugin. As exposed API doesn't leads to RCE, let's leave it out of the implementation (After discussing with the team, we think it is better for Tsunami to only focus on RCE vulns).

Please complete the following: