Tell HN: Upgrade your Metabase installation(github.com) |
Tell HN: Upgrade your Metabase installation(github.com) |
Always write your analytics data to a separate DB in a periodically run job. Only store aggregated anonymized data in the analytics DB you expose to internal stakeholders via tools like Metabase.
Usually production is used for fetching and updating a small number of records at a time (think updating a shopping cart), and has strict latency requirements whereas analytics involves reading a large amount of data in columns (think count group by one or two columns), and can be done in batches where the results can get a more and more stale until the next batch runs.
Mostly in that the leaves of your system (parts that nothing else connects to or builds on) are generally a low risk place to try new things sometimes. If you do run into any intractable issues, it’s also an easy spot to pluck it off and replace it.
This should further emphasize the need to isolate these tools and ensure they are only accessible to people who need them.
I can't recommend any specific tools without knowing a lot about the environment, but if you're looking for terms to google: ELT (Extract, Load, Transform) and CDC (Change Data Capture) will give you a sense of the landscape.
edit: the sibling comment that mentions Airflow is a good answer for an example of an ELT workflow.
Zero Trust does not mean: "No mor VPNs and private IP network ranges, everything is public. ::elitist hipster noises::"
Zero Trust simply means: "Just _because_ you're on a private network [or coming from a known ip], doesn't mean you're authenticated."
You should have every single one of your internal network services (like Metabase) behind a VPN like Wireguard or numerous other options. The sole purpose of this is to reduce your firewall log noise to a manageable level that can be reviewed by hand if necessary.
Obviously this isn't perfect security, but that's the _entire_ point: every security researcher says security should be an onion, not a glass sphere; many layers of independent security.
"Fortunately" some "white hat" hacker contacted us last year about another Metabase exploit. I gave him a 30 USD tip and ended up doing exactly what you are suggesting.
Now I'm glad that means I don't need to interrupt my vacation to fix this thing right now.
The old version has `hash=1bb88f5`, which is a public commit: https://github.com/metabase/metabase/commit/1bb88f5
Whereas the new version has `hash=c8912af`, which is not: https://github.com/metabase/metabase/commit/c8912af
I can't tell if that's it?
edit: I've looked at it a few times, I don't think that's it?
Aka if I am running Metabase locally.
Java deserialization strikes another one down, I assume?
To all of the auth tokens and user creds? Why not.
Then you have your warehouse database that you updated once a day with information from prod.
aka, It isn't checked in to source control publicly yet. Interesting.
I tried to "decompile" the jars and loop over the files but it didn't yield much/wasn't clean enough to be of help.
> Yes, we’ll be releasing the patch publicly, as well as a CVE and an explanation in two weeks. We’re delaying release to give our install base a bit of extra time before this is widely exploited.
From their blog.
Its a bit silly.
- https://www.golem.de/news/connect-app-cdu-verklagt-offenbar-... - https://www.heise.de/news/Modern-Solution-Anklage-gegen-Aufd...
https://www.zeit.de/digital/datenschutz/2021-08/cdu-connect-...
Also like, note: I would never publicly disclose whatever I find, I'm just curious
I observed exactly what you said about the Clojure filenames not matching up, etc. etc.
#!/bin/bash
# Variables
DIR1=~/metabase-v0.46.6.jar.src # decompiled with jd-cli / jd-gui (java decompiler)
DIR2=~/metabase-v0.46.6.1.jar.src # decompiled with jd-cli / jd-gui (java decompiler)
# Function to create fuzzy hash for each file in a directory
create_fuzzy_hashes() {
dir=$1
for file in $(find $dir -type f)
do
ssdeep -b $file >> ${dir}/hashes.txt
done
}
# Create fuzzy hashes for each file in the directories
create_fuzzy_hashes $DIR1
create_fuzzy_hashes $DIR2
# Compare the hashes
ssdeep -k $DIR1/hashes.txt $DIR2/hashes.txt
I was thinking this, or binary diffing the .class (instead of the "decompiled" .java)?
I take it to mean "can someone connect to it in an inbound manner from the public internet?"
If the answer is no, it doesn't necessarily mean that packets don't have other ways of making their way to the server, for example, a service running locally could have a webhook mechanism that fires events to an internet-accessible server whenever certain events happen.
You might trust the services you're sending requests to as part of that, but they could become compromised and send exploits as a response. Other vulnerabilities could be services running locally but that reach out to the internet to check for updates... more surface area to exploit.
If the OP was asking "I'm running this locally and I've set up my machine and firewalls to disallow any packets outside of the loopback interface", then the risk of the unpatched server is certainly reduced, but they could still be affected by another piece of software running on the same machine with internet access that is compromised first.
Anything beyond an isolated machine with 100% air-gapping is theoretically at risk.
Doesn't mean that the OP's question was a bad question or anything, they can use the answer to know how quickly they should worry about patching based on their own situation and risk tolerance.
And yes, that is what I meant. curl hackmeplease.com 57 stack traces down.