Podcast Detail

SANS Stormcast Tuesday Apr 1st: Apache Camel Exploits; New Cert Authorities Requirements; Possible Oracle Breach

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9388.mp3

previous
next
Podcast Logo
Apache Camel Exploits; New Cert Authorities Requirements; Possible Oracle Breach
00:00

Apache Camel Exploit Attempt by Vulnerability Scans
A recently patched vulnerability in Apache Camel has been integrated into some vulnerability scanners, like for example OpenVAS. We do see some exploit attempts in our honeypots, but they appear to be part of internal vulnerablity scans
https://isc.sans.edu/diary/Apache%20Camel%20Exploit%20Attempt%20by%20Vulnerability%20Scan%20%28CVE-2025-27636%2C%20CVE-2025-29891%29/31814

New Security Requirements for Certificate Authorities
Starting in July, certificate authorities need to verify domain ownership data from multiple viewpoints around the internet. They will also have to use linters to verify certificate requests.
https://security.googleblog.com/2025/03/new-security-requirements-adopted-by.html

Possible Oracle Breach
Oracle still denies being the victim of a data berach as leaked data may show different.
https://doublepulsar.com/oracle-attempt-to-hide-serious-cybersecurity-incident-from-customers-in-oracle-saas-service-9231c8daff4a
https://www.theregister.com/2025/03/30/infosec_news_in_brief/
https://www.darkreading.com/cyberattacks-data-breaches/oracle-still-denies-breach-researchers-persist

Podcast Transcript

 Hello and welcome to the Tuesday, April 1st, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich and today I'm recording from
 Jacksonville, Florida. Well, today I found some exploit
 attempts against a recent Apache Camel vulnerability.
 Camel is one of those data exchange frameworks. It's
 essentially used to make it easier in enterprise systems
 to shuffle data from one system to the other, receive
 the data, manipulate it, and so on. Recently, they
 published a fairly straightforward to exploit
 vulnerability. There are two headers in Camel that can be
 used to execute operating system commands. That's kind
 of the point of these headers, but they're access controlled
 and they're checking if these headers are present or not.
 The only problem is that when they're checking if the
 headers are present, they're looking for specific upper
 lower case patterns. Well, kind of Camel case. And when
 it's actually then being executed, the case doesn't
 matter. So it's pretty straightforward to bypass the
 filter by just using all lower case, all upper case,
 something like that. That's not then blocked by the
 initial check and the operating system commands will
 still be executed. At this point, I wouldn't really sort
 of call what we're seeing as exploited in the wild. It
 looks more like vulnerability scans. Even the one I have
 here really looked more like sort of an internal
 vulnerability scan that ended up in one of our other
 honeypots for some reason. Could of course be some
 internal lateral movement or something like this, but I
 doubt it is. They're using a standard vulnerability scanner
 here and don't really think that this is actual attack
 activity, but just shows it's extremely easy to exploit this
 vulnerability. In order to exploit the vulnerability, you
 need to run Apache Camel not in a standard configuration.
 And I'll refer to the Camel announcement for all the
 details here. The problem with this is that the CVSS score of
 the vulnerable is actually quite low. It's sort of in a
 medium range, like 4 or 5. The CVSS score is quite low. And
 that may cause you to overlook the vulnerability. The low CVSS
 score is based on, well, the vulnerability not being
 exploitable in the default configuration. But if you have
 a vulnerable configuration, it's trivial to exploit. And
 then we have an update on certificate requirements by
 the Certificate Authority Browser Forum. That's the
 industry group that sets the standards for certificate
 issuance. Nothing too crazy. They just had a vote and
 approved these proposals. They're going to be effective
 in July. Some of the crazier stuff like certificates valid
 only for six days and such. I don't see it here. There are
 really two main new things. One is a multi-perspective
 issuance corroboration. What it refers to is that the
 Certificate Authority needs to verify data that's being used
 to corroborate that this is your domain, like DNS lookups.
 They need to use various viewpoints from the internet.
 So they can't just do these lookups from one data center.
 And then also something that I'm surprised hasn't been
 there already. And that's linting, which refers to,
 well, making sure that the certificate is actually
 properly formed. And I don't see a specific linter being
 specified here. But I'll refer in the show notes to the
 little Google write up here, which I think summarizes it
 pretty well. So as far as the end user is concerned, that
 shouldn't really have any effects. Your Acme clients and
 such should just work as before. Just know when they
 are then verifying, for example, your secret file that
 you put like in your .well -known directory. Well, these
 requests should come from various data centers around
 the world, not just sort of one request. And then we had a
 couple of queries actually coming in about the Oracle
 breach, or I should say the suspected Oracle breach. There
 has been some suspicion that Oracle's cloud environment was
 breached to some point. The health part of Oracle's cloud
 actually admitted to a breach affecting that part of the
 cloud. But some group did also publish data that they claim
 came from other Oracle cloud customers. And some of the
 customers have validated that data. I can't really tell you
 which side is wrong, or you know, what exactly happened. I
 think that's still very much open to interpretation. The
 real question is, what should you do? And well, it comes
 back down to that cloud providers are part of your
 supply chain. So you need to establish some trust to these
 cloud providers. If you lose the cloud providers, then
 well, maybe they're not the provider that you should be
 using. But of course, that's sort of a more longer term
 discussion immediately. Well, really up to you. I can't
 really tell you how you perceive the risk, but
 changing credentials, changing passwords, API keys and such
 is certainly something to consider. And if you're using
 Oracle's cloud, definitely make sure that your data is
 not in that leaked data. There are a couple of sites that
 allow you to search that data. Another issue always to
 consider here is the data may not come from Oracle itself.
 It may come from one of their suppliers or maybe a
 completely different place. It just happens to be that, you
 know, people with some of these have that use similar
 passwords across different providers. So take a look at
 it if you're using Oracle's cloud. But at this point, I
 think it's very much open what exactly happened. I hope that
 Oracle will come up with either, hey, you know, we have
 been breached. This is what happened. Or well, we
 identified that this data is coming from somewhere else.
 Either way, it would be nice to have sort of a definite
 resolution with evidence and everything. for what exactly
 happened. Well, and this is it for today. Thanks for
 listening. Just a quick note, there will be no April Fool's
 jokes on the United Storm Center website. We don't
 really think that's something we want to get into. And be
 careful, of course, of other sites that may engage in that.
 Thanks and talk to you again tomorrow. Bye.