CVE-2024-46507: SSTI Leads to RCE

Yeti allows its users to create custom report templates that users can export their IoCs/intel into a custom format. The template content is not sanitized before being processed on the backend, leading to the possibility of code execution.

Templates can be used to export observables (hashes, domains, IP addresses). To successfully instantiate an export, there needs to be an observable too export. To create one, can go to Observables -> New Observable -> Save

To trigger the rendering of our malicious template, we need to select our newly created observable to export it with our malicious template.

After exporting the observables, a .txt file is downloaded.

In the .txt file, we see the output of the command that we chose in the malicious template (in this case, id).

CVE-2024-46508: Use of Static Insecure Secret

Yeti makes use of JWTs for authentication. The application is most commonly deployed using a docker-compose file. I was surprised during the installation process, there is no need to ever actually open the .env file to change anything, it was as simple as cloning the repo, running docker-compose, and the application was up in a few seconds. Furthermore, the documentation does not refer to the .env file anywhere. Concerningly, in the .env file the JWT secret was configured as “SECRET” and did not seem to be replaced at runtime. Given the fact that the .env file is not required to be modified in the installation process or mentioned in documentation, there was a good chance that instances deployed in the wild would have not changed the static secret. Furthermore, the variable naming did not make it readily apparent that it was being used for a JWT secret.

With a known JWT secret, attackers can generate valid tokens and bypass authentication. Combined with the ability to execute commands from an authenticated context, this was more concerning.

Conclusion

Vulnerability Disclosure Timeline