Protect your Metabase instance ASAP

News and Announcements
21

You can’t do that in Jetty, please upgrade or take down your instance till you can upgrade

1 Like
22

so is this fixed in v0.46.6.4? My developer/user is stating that need to block still for another issue that may not be related. I have upgraded to the mentions version from v0.46.6.1 (earlier in the week) but don't want to block if thats still needed. Please advise

Thanks

23

Hello, we've recently noticed some suspicious activity on one of our Metabase instances. I thought it would be helpful to share some related logs here.

  • v0.46.0 - until 27 July - no activity was observed on these endpoints:

    • POST /api/database
    • PUT /api/database/:id
    • POST /api/setup/validate

  • v0.46.6.2 - starting from 28 July, 06:21:59 - several calls were made to:

    • /api/session/properties
    • followed by /api/setup/validate

Please see the detailed log below:

2023-07-28 06:21:59,577 DEBUG middleware.log :: /api/session/properties 200 12.2 ms (1 DB calls) App DB connections: 0/15 Jetty threads: 5/50 (2 idle, 0 queued) (93 total active threads) Queries in flight: 0 (0 queued)e[0m
2023-07-28 06:21:59,914 DEBUG middleware.log :: POST /api/setup/validate 400 1.6 ms (0 DB calls) 
"Instance already initialized"

2023-07-29 06:56:34,846 DEBUG middleware.log :: GET /api/session/properties 200 7.4 ms (1 DB calls) App DB connections: 0/15 Jetty threads: 5/50 (2 idle, 0 queued) (114 total active threads) Queries in flight: 0 (0 queued)e[0m
2023-07-29 06:56:35,983 DEBUG middleware.log :: POST /api/setup/validate 400 1.2 ms (0 DB calls) 
"Instance already initialized"

2023-07-29 10:05:11,307 DEBUG middleware.log :: GET /api/session/properties 200 9.6 ms (1 DB calls) App DB connections: 0/15 Jetty threads: 5/50 (2 idle, 0 queued) (114 total active threads) Queries in flight: 0 (0 queued)e[0m
2023-07-29 10:05:12,786 DEBUG middleware.log :: POST /api/setup/validate 400 1.0 ms (0 DB calls) 
"Instance already initialized"

2023-07-29 14:56:29,821 DEBUG middleware.log :: GET /api/session/properties 200 13.5 ms (1 DB calls) App DB connections: 0/15 Jetty threads: 5/50 (2 idle, 0 queued) (114 total active threads) Queries in flight: 0 (0 queued)e[0m
2023-07-29 14:56:31,336 DEBUG middleware.log :: POST /api/setup/validate 400 1.1 ms (0 DB calls) 
"Instance already initialized"

2023-07-29 17:11:37,198 DEBUG middleware.log :: GET /api/session/properties 200 8.5 ms (1 DB calls) App DB connections: 0/15 Jetty threads: 5/50 (2 idle, 0 queued) (114 total active threads) Queries in flight: 0 (0 queued)e[0m
2023-07-29 17:11:38,986 DEBUG middleware.log :: POST /api/setup/validate 400 1.2 ms (0 DB calls) 
"Instance already initialized"

2023-07-29 19:19:14,492 DEBUG middleware.log :: GET /api/session/properties 200 13.1 ms (1 DB calls) App DB connections: 0/15 Jetty threads: 5/50 (2 idle, 0 queued) (114 total active threads) Queries in flight: 0 (0 queued)e[0m
2023-07-29 19:19:15,694 DEBUG middleware.log :: POST /api/setup/validate 400 1.1 ms (0 DB calls) 
"Instance already initialized"
2023-07-29 19:19:16,538 DEBUG middleware.log :: POST /api/setup/validate 400 1.1 ms (0 DB calls) 
"Instance already initialized"

@Luiggi As far as I can tell, these were attempts to exploit CVE-2023-38646, but v0.46.6.2 was no longer vulnerable to this issue. Could you confirm that Instance already initialized implies that the exploitation attempt was unsuccessful?

I tried exploiting CVE-2023-38646 on my local v0.46.0 instance, and successful attempts appear like this:

Caused by: java.lang.ClassCastException: class java.lang.ProcessImpl cannot be cast to class org.h2.api.Trigger (java.lang.ProcessImpl is in module java.base of loader 'bootstrap'; org.h2.api.Trigger is in unnamed module of loader 'app')
	at org.h2.schema.TriggerObject.loadFromSource(TriggerObject.java:107)
	... 43 more
2023-07-31 23:27:30,615 DEBUG middleware.log :: POST /api/setup/validate 400 2.6 s (0 DB calls)
{:message
 "Error creating or initializing trigger \"SHELL3\" object, class \"..source..\", cause: \"org.h2.message.DbException: Syntax error in SQL statement \"\"//javascript\\\\000a\\\\0009java.lang.Runtime.getRuntime().exec('touch /tmp/success')\\\\000a\"\" [42000-212]\"; see root cause for details; SQL statement:\nCREATE TRIGGER shell3 BEFORE SELECT ON INFORMATION_SCHEMA.TABLES AS $$//javascript\n\tjava.lang.Runtime.getRuntime().exec('touch /tmp/success')\n$$ [90043-212]"}

as a result /tmp/success was created. Is it safe to assume that attempts to exploit CVE-2023-37470 would also generate exceptions similar to the one mentioned above?

I also noticed that the string "Instance already initialized" was introduced in this commit: Prevent malicious H2 connection string properties (#32733) · metabase/metabase@11c3567 · GitHub However, it wasn't present in version v0.46.6.2, so I am uncertain of its origin. My personal attempts have similarly resulted in Instance already initialized .

24

agree, those attempts were unsuccessful

25

... and what about the message "Token does not match the setup token."?
We only got those before blocking all the relevant URLs at proxy level.

26

I guess those were just bots testing, we haven't received any report about a vulnerability that is effective with a response like that one

27

Hello @Luiggi,

Thank you so much for all the information you posted.
There are some steps which I have taken to prevent any vulnerability.

  1. Isolated the network.
  2. Blocked the API endpoints you mentioned above.
  3. Upgraded to latest version.
  4. Rotated all keys.

I know your post mentioned that if we cannot block the endpoints, then it makes sense to isolate Metabase, but we just did that as well to prevent any other risk.

Can we expect some more fixes for this vulnerability or the Metabase team have resolved these vulnerabilities and I can skip step 1 (Isolate Metabase) ?

Thanks

28

If you upgraded to the latest version then it should be fine now. We haven’t received anything else from that specific attack vector basically because you can’t use h2 anymore (which was the root of the problem)