Latest / Tech Talks With Kinsoft / Metabase - The Reporting Tool That Held Every Key, and the Five Companies That Found Out

Transcript

Metabase - The Reporting Tool That Held Every Key, and the Five Companies That Found Out · Tech Talks With Kinsoft

• 0:00
  I want you to just imagine a scenario on your
• 0:03
  own network right now. Like really picture your
• 0:05
  company's data infrastructure. Okay, yeah. If
• 0:09
  you had to guess the most catastrophic threat
• 0:11
  to that environment. I mean, your mind probably
• 0:14
  jumps to a sophisticated, you know, multistage
• 0:17
  ransomware attack targeting the core databases.
• 0:20
  For sure. You're looking at the big target. Exactly.
• 0:23
  You're likely not losing sleep over the quiet
• 0:26
  internal analytics dashboard to sitting on a
• 0:28
  random server in the corner. I mean, you probably
• 0:31
  don't even classify that reporting tool as a
• 0:33
  production system. Right. And it's a massive
• 0:35
  blind spot for most engineering teams. We are.
• 0:38
  Well, we're fundamentally conditioned to armor
• 0:39
  the front door. We lock down the primary databases.
• 0:42
  We scrutinize internet -facing apps. Yeah. But
• 0:45
  internal BI tools, you know, business intelligence,
• 0:48
  they're almost always treated as read -only conveniences.
• 0:51
  They just generate charts. They aren't supposed
• 0:53
  to be threat vectors. But that assumption is
• 0:56
  exactly what we are tearing down today. So our
• 0:58
  mission for this deep dive is to unpack an incredibly
• 1:01
  revealing transcript from Tech Talks with Kinsoft.
• 1:04
  They did this massive postmortem on the recent
• 1:07
  Metabase zero -day vulnerability. Officially
• 1:10
  tracked as CVE -2026 -72898. Right. And our goal
• 1:15
  isn't just to do some forensic play -by -play.
• 1:18
  We really want to understand the architectural
• 1:20
  philosophy, the underlying way we build software
• 1:22
  today that allowed a literal 10 out of 10 severity
• 1:26
  breach. to just hide completely in plain sight.
• 1:29
  Yeah. And to give some context on how chaotic
• 1:31
  this actually was, the source material opens
• 1:33
  with some rapid fire corrections just because
• 1:36
  the facts on the ground were shifting. hourly.
• 1:38
  It was moving so fast. It really was. Initially,
• 1:40
  the vendor issued an advisory with no CVE attached
• 1:43
  and the severity score was entirely self -reported.
• 1:46
  Right. Which, I mean, it completely undersold
• 1:48
  the danger for a few days. Oh, absolutely. But
• 1:50
  now it is an official 10 out of 10 on both the
• 1:53
  CVSS 3 .1 and 4 .0 scales. And it immediately
• 1:57
  triggered a cease or remediation deadline. Which
• 1:59
  is huge. Yeah. Also, just as a quick, aside from
• 2:02
  the source, to clear up some industry confusion.
• 2:04
  Yeah. LexisNexis happens to have a completely
• 2:07
  unrelated product also called Metabase. Right.
• 2:10
  There is no connection whatsoever. We're talking
• 2:13
  strictly about the BI platform based in San Francisco.
• 2:17
  And that BI platform is exactly where we have
• 2:19
  to start because the core danger here, it isn't
• 2:21
  just that the application got compromised. uses
• 2:25
  this fantastic analogy, actually. They say Metabase
• 2:28
  doesn't just hold your data, it holds the way
• 2:30
  in. It's the key ring. Precisely. It is the key
• 2:33
  ring. I mean, to generate those pretty graphs
• 2:35
  for the sales team, Metabase needs connection
• 2:38
  strings, credentials, API tokens, basically for
• 2:42
  every single data warehouse, Snowflake instance,
• 2:44
  and Postgres database you pointed at. Wow, yeah.
• 2:47
  So if an attacker breaches the web server hosting
• 2:49
  your blog, they own the blog. But if they breach
• 2:52
  Metabase, they don't just own the dashboard,
• 2:53
  they... Deal the master key ring that unlocks
• 2:57
  every single core data repository connected to
• 2:59
  it. Which really puts the scale of this exposure
• 3:03
  into perspective. Because Metabase isn't some
• 3:05
  niche tool, right? They claim over 100 ,000 organizations
• 3:09
  use their platform across 150 countries. It's
• 3:13
  everywhere. It is. They're deeply embedded in
• 3:16
  the infrastructure of massive financial and tech
• 3:19
  companies. Yeah. I'm talking N26, Revolut. gojek
• 3:23
  these are heavily regulated high stakes environments
• 3:26
  and we actually have hard data on the blast radius
• 3:30
  thanks to internet wide scans run by wiz and
• 3:33
  dataman Right around August 8th. Okay, let's
• 3:36
  unpack this. What did they find? Well, they found
• 3:38
  that roughly 13 % of all cloud environments globally
• 3:42
  were running a self -hosted instance of Metabase.
• 3:44
  13 %? I mean, that is a staggering number. But
• 3:47
  here is the stat that actually made my jaw drop
• 3:49
  when I read the source. Wow, the exposure stat.
• 3:51
  Yes. Of those self -hosted instances, roughly
• 3:54
  a quarter were fully accessible from the public
• 3:56
  internet. Yeah, that's rough. The data men telemetry.
• 4:00
  pinpointed over 4 ,300 highly vulnerable instances
• 4:04
  just openly sitting on the web. They were touching
• 4:06
  government networks, health care, aviation, finance.
• 4:10
  It essentially means thousands of organizations
• 4:13
  left a master key ring hanging on a hook on the
• 4:16
  outside of their building. Basically, yeah. And
• 4:19
  once attackers realized that hook was there,
• 4:21
  the timeline of exploitation compressed to an
• 4:23
  almost terrifying degree. The speed of, this
• 4:27
  is what really gets me. So August 2nd, a Sunday,
• 4:29
  is the first documented intrusion. An attacker
• 4:32
  breaches a Metabase instance owned by an AI coding
• 4:35
  company called KiloCode, and they're just poking
• 4:37
  around for about four hours. Just scaring it
• 4:39
  out. Right. And then the very next day, August
• 4:42
  3rd, the attacks escalate. Exponentially. They
• 4:45
  hit Metabase's own managed cloud infrastructure.
• 4:48
  Tenants like Checkly, Framework, Tally, they
• 4:50
  all get hit essentially simultaneously. But,
• 4:53
  you know, you do have to give Metabase credit
• 4:55
  where it's due here. Fair enough. On that exact
• 4:57
  same day, August 3rd. They actually detect the
• 5:00
  abnormal behavior, isolate the exploited endpoints,
• 5:04
  identify the root cause in the code, and push
• 5:06
  a patch across their entire managed cloud. Wow.
• 5:10
  Yeah, same -day detection and remediation for
• 5:12
  cloud tenants is exceptional engineering. It
• 5:15
  is exceptional, but, well, it didn't stop the
• 5:18
  bleeding for the rest of the world. Because by
• 5:20
  Thursday, August 6th, Metabase publishes its
• 5:23
  public security update for the self -hosted community.
• 5:26
  And then the weekend hits and everything just
• 5:28
  falls apart. By August 10th and 11th, the CVE
• 5:32
  is formalized. Security researchers at WIS publish
• 5:34
  a full reverse engineering write -up. Which,
• 5:37
  ironically, inadvertently gives attackers the
• 5:39
  exact blueprint to build open source exploits.
• 5:42
  Exactly. CISA adds it to the known exploited
• 5:44
  vulnerabilities catalog. And then this ransomware
• 5:47
  group, Shiny Hunters, they list Metabase on their
• 5:50
  extortion site. So from the first quiet intrusion
• 5:52
  on August 2nd to a fully weaponized, globally
• 5:55
  scaled export circulating on the open Internet,
• 5:58
  it was nine days. Nine days. That window for
• 6:01
  remediation, it just doesn't exist anymore. It
• 6:03
  really doesn't. And I want to dig into how this
• 6:06
  happened. Because this wasn't some, you know,
• 6:08
  standard buffer overflow or complex memory corruption.
• 6:11
  The anatomy of this 10 out of 10 flaw is honestly
• 6:15
  kind of elegant. It really is. The entry point
• 6:18
  was a single, unauthenticated endpoint. It was
• 6:21
  a PST request to API slash session slash reset
• 6:25
  underscore password. Which, to be clear, is an
• 6:28
  endpoint deliberately designed to be accessed
• 6:30
  by people who aren't logged in. Right. Obviously.
• 6:33
  It's supposed to take two arguments, a token
• 6:35
  proving you requested a reset and your new password.
• 6:38
  So if I'm an attacker. And I intercept that request.
• 6:41
  I don't just send a token and a password. I inject
• 6:43
  an extra field. I slip a user ID into the payload.
• 6:46
  And this is where the source completely changed
• 6:49
  my perspective on secure coding. This flaw wasn't
• 6:52
  caused by a broken piece of code. It was caused
• 6:54
  by four individually correct, highly documented
• 6:57
  software behaviors chaining together flawlessly.
• 7:01
  What's fascinating here is the concept of composition
• 7:03
  flaws. None of the four steps we are about to
• 7:05
  discuss are actually bugs. Not a single one.
• 7:08
  Not one. First, Metabase is written in Clojure.
• 7:11
  When the attacker's web request hits the backend,
• 7:14
  the system attempts to merge the incoming payload
• 7:17
  with the result of a failed authentication check.
• 7:20
  Okay, so a standard merge. Right. And Clojure's
• 7:23
  merge function does exactly what the manual says.
• 7:25
  It combines two data maps, but crucially, it
• 7:27
  does not strip out unexpected keys. Oh, wow.
• 7:30
  So the attacker's injected user ID survives the
• 7:34
  merge simply because there was no legitimate
• 7:36
  user ID to overwrite it. I was trying to visualize
• 7:39
  this when I read it, and it feels like a data
• 7:41
  smuggling operation. It really does. It's kind
• 7:44
  of like a bouncer at a club. The attacker walks
• 7:46
  up, fails the VIP list check, but subtly hands
• 7:50
  their VIP badge to the guy behind them, which
• 7:53
  is the payload. That's a great way to look at
• 7:55
  it. Right. The bouncer did their job by rejecting
• 7:58
  the first guy. But the club's back end system
• 8:00
  just automatically prints a wristband for whatever
• 8:03
  badge gets handed to it next. It doesn't even
• 8:05
  verify if it belongs to someone on the list.
• 8:07
  That is a highly accurate analogy because step
• 8:10
  two is the JSON parser. The payload. complete
• 8:14
  with that sum of old user id gets parsed from
• 8:17
  json into a closure map and the parser works
• 8:20
  perfectly exactly it works perfectly keeps the
• 8:22
  malicious key now step three is where the architecture
• 8:25
  really betrays them metabase uses a sql query
• 8:29
  builder library called honey sql right honey
• 8:31
  sql has this specific keyword called raw if you
• 8:35
  pass data tagged with raw You are explicitly
• 8:38
  telling the database, do not parameterize this.
• 8:41
  Treat this as literal SQL code. Which is wild,
• 8:43
  right? I mean, parameterization is the golden
• 8:45
  rule of database security. It separates the code
• 8:48
  from the user's data so you can't run an injection
• 8:50
  attack. Why would a developer ever include a
• 8:53
  raw bypass? Well, because developers demand flexibility.
• 8:56
  BI tools have to generate these insanely complex,
• 8:59
  highly customized queries across dozens of different
• 9:02
  database dialects. So it's a performance thing
• 9:04
  or just to make it work? Just to make it work.
• 9:06
  Yeah. Parameterization often breaks down when
• 9:08
  you're trying to dynamically construct really
• 9:10
  complex table joins on the fly. So the raw keyword
• 9:14
  was a deliberate documented feature for the developers
• 9:17
  to use when the standard engine just couldn't
• 9:20
  handle the complexity. Wow. But the attacker
• 9:23
  leverages that feature. Yeah. And that brings
• 9:25
  us to the sync, which is the final step. Right.
• 9:28
  The system takes that smuggled user ID. Assumes
• 9:32
  it's a safe integer because, hey, it came from
• 9:34
  the password reset flow and drops it into a database
• 9:36
  lookup using that raw keyword. And suddenly the
• 9:39
  attacker is executing arbitrary, unparameterized
• 9:42
  SQL directly against Metabase's own internal
• 9:45
  application database. Incredible. And they did
• 9:48
  all of this from the password reset page without
• 9:50
  authenticating once. This is exactly why SCADA
• 9:53
  code analysis tools completely missed this. I
• 9:56
  mean, if you run a scanner on that code, it sees
• 9:58
  the closure merge and says, yeah, valid function.
• 10:00
  Yep. the honey sql raw command and says yep known
• 10:03
  library feature the vulnerability doesn't exist
• 10:05
  in any single line of code it exists entirely
• 10:07
  in the seams between those functions it fundamentally
• 10:10
  challenges how we audit software we review components
• 10:13
  in isolation but the explosive reaction only
• 10:16
  happens when they are combined under malicious
• 10:18
  conditions and what's almost tragic about this
• 10:20
  is how simple the fix was yeah when wiz reverse
• 10:24
  engineered the patch they found metabase fixed
• 10:27
  this 10 out of 10 vulnerability with about three
• 10:29
  lines of code. Three lines. They just added a
• 10:32
  validation check to ensure the user ID was a
• 10:35
  positive integer before letting it touch the
• 10:37
  database. Three lines to stop an internet -wide
• 10:40
  meltdown. But, you know, by the time those three
• 10:42
  lines were deployed, the attackers were already
• 10:44
  inside. Because this was a blind SQL injection
• 10:47
  into the application database, the attacker could
• 10:50
  manipulate the backend to forge a valid administrator
• 10:53
  session. Let that sink in for a second for everyone
• 10:55
  listening. They forged an admin session without
• 10:58
  a password. They didn't phish an employee. They
• 11:01
  didn't have to intercept a multi -factor authentication
• 11:02
  prompt. They bypassed the entire authentication
• 11:06
  apparatus. They just walked right past it. Exactly.
• 11:08
  And once they had that forged session, they possessed
• 11:11
  the key ring. Which leads us directly into the
• 11:14
  fallout. The source material spends a lot of
• 11:17
  time analyzing the victim response. They specifically
• 11:20
  praise what they call the honest five. The honest
• 11:22
  five, right. Because we don't know the full count
• 11:25
  of Metabase cloud tenants that were breached,
• 11:27
  but five companies published highly detailed,
• 11:30
  incredibly transparent postmortems of their own
• 11:33
  breaches. And you rarely see this level of honesty
• 11:35
  because, you know. Legal teams usually sanitize
• 11:38
  these disclosures into oblivion. Oh, absolutely.
• 11:41
  Checkly was one of the five. They do synthetic
• 11:43
  monitoring. They're SOC2 certified, deeply engineering
• 11:46
  focused. Yeah. And they reported that the attacker
• 11:48
  had 26 minutes of read -only query access against
• 11:52
  their connected data warehouse. But 26 minutes
• 11:54
  of read -only access to a central data warehouse
• 11:57
  is catastrophic. Yeah. Treckley admitted the
• 12:00
  attacker pulled plaintext custom headers, hashes
• 12:02
  of OpenTelemetry API keys, and encrypted integration
• 12:05
  tokens for Slack, Vercel, and CoreLogix. Framework,
• 12:09
  the modular laptop company, was another one.
• 12:11
  They found out on August 6th that their data
• 12:14
  had been exfiltrated three days earlier. Yeah.
• 12:17
  They lost massive amounts of personally identifiable
• 12:20
  information, PII. Full names, emails, billing,
• 12:24
  and shipping addresses. The only silver lining
• 12:26
  there was that their payment processing was entirely
• 12:28
  segregated. Tally, the form builder, had a similar
• 12:31
  exposure. They lost emails and hash passwords.
• 12:35
  At the time of the source publication, there
• 12:37
  was actually an open question regarding whether
• 12:39
  Tally's password hashes were salted. Why does
• 12:42
  that matter so much? Well, if you don't salt
• 12:44
  a hash, attackers can crack them exponentially
• 12:46
  faster using pre -computed rainbow tables. It's
• 12:49
  a huge risk. Oh, right. Then we have KiloCode,
• 12:53
  the first known victim from August 2nd. They
• 12:55
  lost PII and user prompts. But what's brutal
• 12:58
  is that three days into their incident response,
• 13:00
  they realized the attacker hadn't just queried
• 13:03
  the database. They had extracted access tokens
• 13:05
  for KiloCode's internal Slack bot. That's terrifying.
• 13:09
  It is. They had to frantically invalidate all
• 13:11
  those tokens before the attacker pivoted into
• 13:13
  their internal communications. But the standout
• 13:15
  response here really belongs to N8N, a workflow
• 13:18
  automation company. The source rightly calls
• 13:21
  their disclosure a masterclass in forensic scoping.
• 13:24
  I loved this part. They didn't just say, oh,
• 13:26
  data was accessed. They narrowed the blast radius
• 13:29
  to exactly 136 records. But what makes their
• 13:33
  postmortem exceptional is their technical honesty
• 13:35
  regarding non -deterministic queries. Yes. OK,
• 13:38
  so this part actually confused me initially.
• 13:40
  They explicitly stated that out of those 136
• 13:44
  records, they couldn't be 100 % sure if 62 of
• 13:49
  them were actually accessed. Right. Why couldn't
• 13:51
  they just look at their SQL logs and see exactly
• 13:53
  what? the attacker downloaded? Because database
• 13:56
  logs generally record the question that was asked,
• 13:59
  not the answer that was given. Oh, okay. Yeah.
• 14:01
  So if an attacker injects a non -deterministic
• 14:04
  query, like select all from users order by random
• 14:07
  limit 10, the log proves the attacker asked for
• 14:10
  10 random users. But it doesn't log which 10
• 14:13
  random users the database handed over. Exactly.
• 14:15
  Or if the query relied on a hyper -specific timestamp
• 14:19
  that has since passed, the defenders just cannot
• 14:21
  replicate the exact state of the database at
• 14:23
  the moment of the attack. And NAN admitted this
• 14:26
  blind spot instead of pretending they had perfect
• 14:28
  visibility. They own the ambiguity. And here's
• 14:31
  where it gets really interesting for you as a
• 14:33
  listener. While NAN was doing this incredibly
• 14:36
  deep forensic sweep, They actually found a completely
• 14:39
  unrelated three -year -old bug. Yeah. It had
• 14:42
  already been fixed, but historically it had left
• 14:44
  25 passwords sitting in plain text in an old
• 14:48
  table. And they disclosed it anyway. I mean,
• 14:50
  they were investigating a massive zero -day fire,
• 14:53
  stingled upon the cold ashes of a three -year
• 14:56
  -old mistake, and proactively contacted those
• 14:59
  25 users. That is the gold standard for security
• 15:02
  culture right there. Oh, without a doubt. But
• 15:04
  stepping back, Checkly's postmortem contained
• 15:06
  an admission that I think applies to almost everyone
• 15:08
  listening to this deep dive. When they audited
• 15:11
  the 26 minutes of queries, they realized their
• 15:14
  analytics environment simply had far more permissions
• 15:17
  and access to highly sensitive data than it actually
• 15:20
  required to build its charts. It is a massive
• 15:23
  violation of the principle of least privilege.
• 15:26
  scaled across their entire infrastructure i mean
• 15:28
  if a bi tool only exists to visualize daily sales
• 15:32
  metrics why does its database credential have
• 15:35
  the authority to pull from the hashed passwords
• 15:37
  table exactly or they open telemetry token configuration
• 15:40
  we over permission internal tools because it's
• 15:44
  just faster for the developers now i do want
• 15:46
  to talk about how metabase handled this because
• 15:49
  the source paints a very nuanced picture of vendor
• 15:51
  responsibility here it is a fiercely debated
• 15:54
  scorecard Let's start with the commendations.
• 15:57
  Detecting an unknown zero -day intrusion on your
• 16:00
  managed cloud environment and deploying a patch
• 16:02
  globally on the exact same day is phenomenal.
• 16:05
  It really is. They also handed incredibly detailed
• 16:07
  forensic logs directly to the victims. Checkly
• 16:10
  explicitly stated they would not have been able
• 16:12
  to scope their own breach without Metabase providing
• 16:15
  those internal logs. Right. I look at that same
• 16:17
  -day cloud patch and think, that is heroic incident
• 16:20
  response. Yeah. But then you look at the self
• 16:22
  -hosted site and it's a completely different
• 16:24
  story. There was a full three -day gap between
• 16:27
  Metabase containing the attack on their own cloud
• 16:29
  on August 3rd and issuing the public advisory
• 16:32
  on August 6th. And this is where the friction
• 16:34
  is. Metabase protected their paying cloud tenants
• 16:37
  instantly. But by delaying the public disclosure,
• 16:41
  they left thousands of open -source, self -hosted
• 16:45
  instances completely blind on the internet. While
• 16:47
  attackers were actively hunting them. Exactly.
• 16:49
  Attackers who had already reverse -engineered
• 16:52
  the cloud patch. And the fact that they released
• 16:54
  the advisory without a CVE identifier compounded
• 16:57
  the disaster. Automated security scanners and
• 17:00
  triage dashboards, they pull from CVE databases.
• 17:04
  By not securing that CVE for nearly a business
• 17:06
  week, Metabase basically ensured that every automated
• 17:09
  defense system on the planet was silent. The
• 17:12
  dashboards were green while the servers were
• 17:14
  burning. It really highlights the extreme tension
• 17:17
  between protecting managed infrastructure and
• 17:20
  fulfilling your obligations to the open source
• 17:22
  community. And the chaos was amplified by the
• 17:26
  attribution fog. Oh, right. Who actually executed
• 17:29
  this campaign? Well, on August 11th, a notorious
• 17:32
  ransomware syndicate called Shiny Hunters claimed
• 17:35
  responsibility by listing Metabase on their extortion
• 17:37
  site. But the source is extremely adamant on
• 17:41
  this point. Treat that as a claim, not a verified
• 17:44
  fact. Because in threat intelligence, claims
• 17:46
  are cheap. The data miner analysis labeled the
• 17:49
  shiny hunters post as an unconfirmed placeholder.
• 17:52
  Interesting. Yeah. The listing only advertised
• 17:54
  about seven gigabytes of data and it lacked all
• 17:57
  of the descriptive metadata, sample proofs and
• 17:59
  scoop details that shiny hunters typically uses
• 18:02
  to prove they actually have the goods. It fits
• 18:04
  their operational pattern, you know, compromising
• 18:06
  a central platform to harvest data from downstream
• 18:09
  targets. But a pattern is not proof. But regardless
• 18:12
  of who did it, there was a secondary threat that
• 18:15
  emerged in the aftermath that really unsettled
• 18:17
  me. The source code leak? Yes. Cyber news researchers
• 18:20
  were digging through the published archive dumps,
• 18:22
  and they found 174 gigabytes of source code originating
• 18:27
  from nearly 300 private database repositories.
• 18:31
  Which is arguably worse than losing the data
• 18:33
  itself. Really? How so? Well... If a company
• 18:36
  used a secrets manager, their immediate data
• 18:38
  loss might be contained. But exfiltrated source
• 18:41
  code provides an attacker with a treasure map.
• 18:44
  They can pull that code offline, feed it into
• 18:47
  advanced static analyzers, and just spend months
• 18:49
  looking for the next composition flaw in the
• 18:51
  seams of the architecture, completely undetected.
• 18:54
  So what does this all mean for us? You know,
• 18:57
  the source crystallizes this entire disaster
• 18:59
  into five highly actionable lessons. And they
• 19:02
  aren't theoretical. These are things you need
• 19:03
  to check on Monday morning, lesson one. Treat
• 19:05
  your BI tools as production systems. You cannot
• 19:08
  view them as passive dashboards. They are the
• 19:10
  key ring. You must ruthlessly audit the service
• 19:13
  accounts connected to them. Enforce strict minimum
• 19:15
  read -only access scoped entirely to the tables
• 19:18
  required for the specific charts being generated.
• 19:21
  Definitely. Lesson two. Hide your internal endpoints.
• 19:25
  The fact that Metabase's entire API, including
• 19:28
  the password reset endpoint, was sitting openly
• 19:31
  on port 3000 exposed to the public internet is
• 19:33
  staggering. It's an unforced architectural error.
• 19:36
  Engineers rationalize it by saying, well, our
• 19:38
  remote employees might need to reset their BI
• 19:41
  dashboard password from home. But if an application
• 19:44
  does not serve external customers, it should
• 19:47
  never route directly to the public internet.
• 19:49
  Put it behind an identity -aware proxy or a VPN.
• 19:51
  If those 4 ,000 vulnerable instances had simply
• 19:54
  restricted port 3 ,000 to internal traffic, this
• 19:58
  exploit would have bounced harmlessly off their
• 20:00
  firewalls. Lesson three really redefines cloud
• 20:03
  security. I think. Using a managed cloud service
• 20:06
  does not make you invincible. Remember, the Metabase
• 20:08
  cloud tenants were patched perfectly on the same
• 20:10
  day. And yet Framework, Checkly, and Tally still
• 20:13
  lost their data because the exfiltration happened
• 20:15
  in the hours before the patch existed. This is
• 20:18
  the terrifying reality of fourth -party risk.
• 20:21
  If you are a customer buying a laptop from Framework,
• 20:24
  your PII was breached. Not because Framework's
• 20:27
  engineers made a mistake. And not even because
• 20:29
  Framework's vendor messed up. But because of
• 20:31
  the vendor's vendor. Exactly. Because a vulnerability
• 20:33
  in a third -party open source library used by
• 20:37
  Framework's BI vendor was exploited. Traditional
• 20:40
  compliance audits are virtually blind to that
• 20:43
  depth of supply chain risk. Which brings us to
• 20:46
  lesson four. When a breach like this occurs,
• 20:48
  rotating passwords is not enough. You have to
• 20:51
  rotate everything. Because the initial vector
• 20:53
  allowed the attacker to forge an active administrative
• 20:56
  session, if you apply the three -line patch,
• 20:59
  you stop new attackers from getting in. But the
• 21:01
  attacker with the forged token is already inside.
• 21:04
  Wow, so the patch doesn't kick them out. No,
• 21:06
  their session survives the software patch. You
• 21:08
  must systematically revoke all active sessions,
• 21:11
  and you have to rotate every single credential
• 21:13
  for every downstream database connected to the
• 21:15
  tool. And the source provided this incredibly
• 21:18
  elegant one -minute log check to determine if
• 21:21
  you were hit. You basically query your web access
• 21:23
  logs. You look for a POST request to API slash
• 21:27
  session slash reset underscore password that
• 21:30
  returns an HTTP 400 failure code. Okay. If that
• 21:33
  exact request is followed immediately by a GE2
• 21:36
  request to API slash user slash current returning
• 21:39
  an HTTP 200 success code, you've been breached.
• 21:43
  It's brilliant in its simplicity. A failed password
• 21:46
  reset instantly followed by a successful authenticated
• 21:49
  API call. It perfectly tracks the attacker failing
• 21:52
  the token check but successfully smuggling the
• 21:54
  payload to forge the session. And finally, Lesson
• 21:56
  5. Stop hiding secrets in plain sight. Checkly
• 22:00
  realized their most critical exposure wasn't
• 22:02
  even the core database structure. It was that
• 22:04
  their own developers and customers were typing
• 22:06
  plain text API integration tokens directly into
• 22:10
  free text configuration fields. Because it was
• 22:12
  faster than setting up the encrypted secrets
• 22:14
  manager. Human friction will always route around
• 22:17
  security. If the encrypted secret store requires
• 22:20
  five extra clicks, developers will paste the
• 22:23
  AWS key into the description field. You have
• 22:26
  to actively scan your configuration stores for
• 22:28
  credential formats and forcefully deprecate plain
• 22:31
  text entry fields. Looking at the entirety of
• 22:34
  this incident, it is a masterclass in unintended
• 22:37
  consequences. Four perfectly documented, mathematically
• 22:41
  correct functions, a merge, a parser, a query
• 22:45
  builder, and a database lookup. No broken code.
• 22:48
  No broken code. But layered together, they forged
• 22:50
  a 10 out of 10 weapon that bypassed authentication
• 22:52
  completely. turning a read -only analytics dashboard
• 22:55
  into a master key that gutted dozens of companies
• 22:57
  in a matter of hours. It really forces us to
• 23:00
  evolve beyond hunting for broken code and start
• 23:02
  hunting for toxic interactions between correct
• 23:04
  code. But, you know, if we are talking about
• 23:06
  evolution, there is one final, deeply unsettling
• 23:09
  detail from the source text that fundamentally
• 23:11
  indicts how the cybersecurity industry prioritizes
• 23:14
  risk. Scoring model, right? Yes. The EPSS score.
• 23:18
  the exploit prediction scoring system it is an
• 23:21
  advanced mathematical model that ingests threat
• 23:24
  intelligence and calculates the raw probability
• 23:26
  that a specific vulnerability will actually be
• 23:29
  exploited in the wild it's the dashboard that
• 23:32
  every security operations center relies on right
• 23:34
  yeah when you have 10 000 alerts you sort by
• 23:36
  the epss score to figure out what actually needs
• 23:39
  patching today exactly but let's look at the
• 23:42
  reality of this metabase zero day we had an active
• 23:45
  10 out of 10 severity of vulnerability. It was
• 23:48
  actively being mass scanned across the entire
• 23:50
  internet. It was actively being exploited to
• 23:53
  exfiltrate massive amounts of corporate data
• 23:55
  from high profile targets. It was officially
• 23:58
  enshrined on CISA's known exploited vulnerabilities
• 24:01
  catalog. And throughout this entire active meltdown,
• 24:04
  the predictive EPSS score for the CVE was sitting
• 24:08
  at well under 1%. Under 1%. So the algorithm
• 24:11
  essentially told security teams that this active
• 24:14
  global fire was mathematically irrelevant. Yes.
• 24:17
  And this leaves you with an incredibly provocative
• 24:19
  question to mull over. We rely on these advanced
• 24:23
  predictive triage models to cut through the noise.
• 24:26
  But if the algorithm completely blinds us to
• 24:29
  a 10 out of 10 active threat, because the math
• 24:31
  mathematically ranks it as low risk, are our
• 24:34
  automated prioritization tools actually creating
• 24:37
  new vulnerabilities? Wow. As the source stated
• 24:40
  so perfectly, confirmed beats predicted every
• 24:43
  time. That is heavy. If your company's security
• 24:46
  team relies on a predictive scoring dashboard
• 24:48
  to decide what gets patched today, what massive
• 24:51
  active fires are they completely ignoring right
• 24:53
  now? Simply because the algorithm assured them
• 24:56
  the probability was under 1%. It's a scary thought.
• 24:59
  It makes you question the very foundation of
• 25:01
  how we defend our networks. And it should definitely
• 25:03
  make you rethink exactly what might be quietly
• 25:05
  sitting on port 3000 of your own infrastructure
• 25:08
  right now, holding the master key ring to your
• 25:10
  entire business. Thanks for joining us on this
• 25:12
  deep dive.