One of the better decisions we took at my firm was to not allow direct access to any production DB to analytics visualization tools like Metabase and Redash.
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.
Also your production database is optimized for different workloads than your analytics database.
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.
That's a great idea and it articulates something I have thought about the whole "use boring tech" things (which I support). It doesn't preclude letting people use the shiny new thing. You can always let them plug it in and use it. But the core of the system should be as simple as possible and based on thoroughly understood tech (from the point of view of the team in question/accessible labor market).
How many of you have received this notice via an official security advisory channel you're monitoring/acting on? If so, which advisory service do you use and how you configure it? Learning about HN is useful, but far from a reliable solution.
I think it's important to review the term "Zero Trust" because so many companies are getting it wrong.
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.
This is why I try to put everything behind NGINX with basic auth. Unfortunately not everything works well that way but in this case I suspect that this is made unexploitable by anyone without the password.
Ha, I was just about to go in here and say the same thing.
"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.
I like NGINX, but I prefer how simple it is to set up Caddy with basic auth. Caddy is already simpler to configure (and has automatic SSL via Let's Encrypt), but it's so simple to get its basic directive working compared to NGINX that I do it by default now.
Perhaps a naive question, but if running metabase within a docker container, what permissions would this RCE have? AFAIK the container has network access and access to the mounted volumes and that's it right?
Presumably the metabase instance also has credentials to access some databases, some of which may be have enough privileges to also get RCE on the database machines (as well as messing with the data they hold).
The container has access to whatever database you connect metabase to for BI. If the db connection credentials are available to the container, it's possible a malicious actor could access your prod db.
> Extremely severe. An unauthenticated attacker can run arbitrary commands with the same privileges as the Metabase server on the server you are running Metabase on.
Java deserialization strikes another one down, I assume?
hannofcart|2 years ago
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.
jimmytucson|2 years ago
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.
namaria|2 years ago
nneonneo|2 years ago
This should further emphasize the need to isolate these tools and ensure they are only accessible to people who need them.
98codes|2 years ago
MattJ100|2 years ago
lecha|2 years ago
swe_dima|2 years ago
Mandatum|2 years ago
unknown|2 years ago
[deleted]
not_your_vase|2 years ago
xctr94|2 years ago
exabrial|2 years ago
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.
kevincox|2 years ago
tedeh|2 years ago
"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.
vdfs|2 years ago
tlrobinson|2 years ago
square_usual|2 years ago
lomereiter|2 years ago
nullcipher|2 years ago
riadsila|2 years ago
vxNsr|2 years ago
thomasfromcdnjs|2 years ago
Aka if I am running Metabase locally.
Mandatum|2 years ago
MuffinFlavored|2 years ago
unknown|2 years ago
[deleted]
not_your_vase|2 years ago
kmitz|2 years ago
smithcoin|2 years ago
Dachande663|2 years ago
JJJollyjim|2 years ago
hiatus|2 years ago
throwaway6734|2 years ago
formerly_proven|2 years ago
Java deserialization strikes another one down, I assume?
theanonymousone|2 years ago
Mandatum|2 years ago
To all of the auth tokens and user creds? Why not.
jacob_rezi|2 years ago
exabrial|2 years ago