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.
