Hello and welcome to the Friday, March 14th, 2025
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ullrich and today I'm recording from
Jacksonville, Florida. In today's diary, Guy is talking
about how to use Microsoft's business intelligence tool,
Microsoft BI, in order to better understand what's
happening with binaries uploaded to your honeypot. The
honeypot uses Kauri. Kauri, of course, is able to collect any
files that an attacker uploads to the honeypot. We support
this as an option in the honeypot. But then, of course,
you also want to go over the data and see if you found
anything new and interesting. Well, with business
intelligence, it's fairly straightforward. Guy goes over
the process to import this file data into business
intelligence and then slice and dice it, look for
anomalies, look essentially for odd and interesting things
using business intelligence. A pretty interesting tool.
Personally, not that familiar with it. But Guy has been
using it more and more to look at honeypot data and is pretty
happy and successful in doing so. And we got an interesting
vulnerability this week that I probably should have covered
yesterday. But the things were a little bit messy about. Let
me describe this a little bit. It's about Apache Camel.
Apache Camel is an open source integration framework. It
helps to essentially connect different APIs together. And
it's quite popular, for example, to orchestrate
Kubernetes clusters. That being said, well, there was
recently a fairly simple-to -exploit vulnerability in
Apache Camel that required you to set a specific header.
Essentially, all you need to do is add a command to the
header as a value and then the command will be executed. Now,
you may say, how can something simple, stupid like this
happen? Well, the problem was that these headers were only
supposed to be used sort of internally. And any external
request with a header like this, well, was supposed to be
filtered. But the filters were case sensitive. So by being a
little bit creative with upper lowercase, it was fairly easy
to bypass these filters and execute commands. Now, doing
so with filters. The problem, however, was that this fix was
not complete. It's also possible to exploit
essentially the same vulnerability by just adding
this header name and the parameter as a get parameter
to your request. And that's, of course, a lot easier to
exploit. Headers, odd headers like this particular, are
relatively straightforward to filter. Well, once you have
simple URL parameters and you're able to exploit this
very trivial arbitrary command execution vulnerability, that
sort of puts the entire vulnerability at a new level.
There were initially sort of a little bit of messed up
vulnerability disclosure process where there were posts
about this big vulnerability without any details. Well, we
do have patches available now. Make sure you apply the
latest, greatest patch that will also fix the parameter
vulnerability, not just the header vulnerability. So that
again applies to Apache Camel. And one place to look for it
is your Kubernetes clusters. But it may show up in all
kinds of other different pieces of software and such.
So it's basically one of those integration frameworks,
middleware type softwares that are often sort of an add-on to
existing systems. And then we got an out-of-cycle bulletin
from Juniper. Juniper affixes with this bulletin an already
exploited vulnerability in JunOS. The vulnerability
doesn't sound that severe at first because in order to
exploit, an attacker already has to have a highly
privileged account and access to the device. On the other
hand, once an attacker is able to exploit this vulnerability,
the attacker is essentially able to compromise the
integrity of the device. So escape any kind of sandboxing
and such that the user is supposed to be confined to.
This vulnerability again has already been exploited.
According to the bulletin, at least one case is known to
Juniper. However, it's often put together with like some of
the recent Volt Typhoon attacks and the like. And
initially sort of has been a little bit labeled as an
attack against out-of-date routers. But then again, this
is a current new update for JunOS. So make sure that
you're not vulnerable. If you're running JunOS Evolved,
you are not vulnerable to this particular issue. And if
you're using any systems with AMI BIOS, in particular, if
they support Redfish, which is sort of an HTML5 remote access
interface for your system, well, be aware there is an
update for you likely around there. And it fixes a
vulnerability with a CVSS score of a perfect 10. This is
an authentication bypass vulnerability. So as long as
the Baseboard Management Controller, the BMC interface,
is exposed to the network, an attacker should be able to
completely compromise your system. Well, and that's it
for today. So thanks again for listening. Have a great
weekend and talk to you again on Monday. Bye.
