Hello and welcome to the Friday, February 21st, 2025
edition of the SANS and Storm Center's Stormcast. My name is
Johannes Ullrich and today I'm recording from Jacksonville,
Florida. Well, in Diaries today we had one by Guy
showing us how to use the Elasticsearch piped query
language in order to do a little bit more interesting
queries against Honeypot data using some of the recent
expansions to that query language. Nice little use of
Honeypot data really just to gain some experience with
these query features in a more sane environment before sort
of rolling something like this into production and actually
deploying it to your Elasticsearch instance and
build dashboards around it. Well, if you're using MongoDB,
be aware there is an interesting injection
vulnerability. Not calling it here SQL injection, even
though some of the write-ups call it that way, but Mongo
technically is no SQL, but the vulnerability is very similar.
And it's actually not in Mongo itself. Remember we had
recently that Postgres vulnerability where an
associated database had the actual injection problem.
Similar here, there is a library called Mongoose.
Mongoose is an object data modeling library. It
simplifies queries by basically just allowing you to
store, retrieve JavaScript objects from MongoDB. Mongoose
does then the rewriting into the actual query language.
Well, that's going wrong here. There were actually earlier
patches late last year that were not sufficient. So
definitely make sure that if you're using MongoDB and if
you're using Mongoose as sort of that intermediate layer to
query MongoDB, that you have everything up to date. Same is
true for many of these object relational mapping, object
data mapping libraries. They abstract a lot of the
underlying query languages. But as a result, of course,
you're relying on these libraries to do any escaping
prepared statements and such correctly, which sometimes
fails like in this case or in the Postgres case. And then we
got a number of vulnerabilities. I think it's
a total of six in U-Boot. U-Boot is a bootloader that you
often see in a bedded system. I remember seeing it, for
example, in NetOptics taps. I sort of ran into that, I
think, last year. But this is a type of system where you
would find U-Boot. And like many bootloaders, one of the
goals of the bootloader is to ensure the integrity of all
the software being loaded, basically the operating
system. Well, that's exactly the nature of these
vulnerabilities that the attacker could essentially
inject malicious software that would then not be recognized
or the modification would not be recognized. And that could
lead to essentially bootloader malware that's very difficult
to detect and to eradicate. Updates are available from the
U-Boot project. It's an open source project. But, of
course, you typically don't install sort of U-Boot from
scratch. So wait for your particular devices or so to
possibly come up with the respective update. And if
you're using the very popular Unify cameras as part of the
Unify Protect system, be aware there is a new camera firmware
that's available. So this is not a new version of Unify
Protect. It's just the camera firmware that needs to be
updated here. It fixes two critical vulnerabilities and
then a couple of, well, high -medium vulnerabilities.
Essentially, as far as the critical vulnerabilities go,
are off-occasion bypass issues that would allow remote
control at least of the cameras. Because the updates
should be applied automatically, in my
experience, and applied relatively quickly. But you
may want to double-check that the firmware that you're
running is at least 474.106. Older versions are vulnerable.
Well, and today it's Friday again. So I have with me
another sans.edu student. Austin, could you introduce
yourself, please? Sure. I'm Austin Clark. I'm the
Enterprise Security Architect at the Department of
Transportation and a sans alumni. So great. And your
research paper was about network devices. Can you sort
of briefly explain what the topic was all about? Sure. It
was basically how to treat network devices like endpoints
and detect adversary actions when they target them
specifically. How to protect those network devices and
detect miter attack techniques. Yeah, and I think
there is hardly a day, definitely not a week in this
podcast, where I'm not talking about vulnerabilities in
various network devices. So it has been a big issue. What are
some of the logs or such that you're considering here from
these network devices? Sure. Sure. The key logs that we
were able to use for detections were syslog, which
was not as helpful as the AAA logs. Given that you're
collecting this data over the network, and of course it's a
little bit different data than you're getting from a normal
endpoint at a normal server or something like that. Do you
see different usage patterns or such that in these network
devices compared to your classic endpoint devices when
it comes to these logs? Yeah. So it's always your network
administrators that are logging in. So the logs, when
they're coming into something like a Splunk Seam or Elastic,
they're a lot lower. There's not as many of the logs. And
that means your detections can have a much higher fidelity.
You can also filter out a little bit easier the known
good. Like there's a specific scanner account or an admin
account that they're using from a specific network
appliance that uploads configs or backs up configs. You're
really able to filter out the noise fairly easily and get to
clear detections. Once you expose these network devices
to the internet, does that change when you have more
background noise from just random attacks? Oh,
absolutely. You almost never want these kinds of network
devices, switches, routers, wireless LAN controllers
exposed to the internet. We see specialized network
appliances that are getting attacked constantly. We see
CVEs for F5s, Cisco VPN concentrators, Palo, all the
time. So you really don't want your internal network devices
exposed to the internet ever. But yet we still see it in
Shodan all the time. Yeah, it still happens. Because I think
one of the advantages you mentioned is like that lower
log volume. And theoretically, you could get that for your
normal endpoints too if you could restrict what your users
are doing kind of to only very specific things, which of
course doesn't work like for your standard, let's say,
workstation or something like this. But what you're saying
is basically that for these internal network devices, you
can limit where the connections come from and you
can limit who's connecting to it, maybe even when they're
connecting to it. So this makes it much easier to then
create some kind of rules and learning around it. Yeah,
absolutely. AAA is a super powerful tool. What I've seen
in a lot of networks is they just give the network admins
privilege 15 and let them go with that. But you really
could lock it down and block certain commands like clear
logging and clear archive, erasing and exporting PKI.
Exporting PKI is an esoteric thing that almost no network
admin uses, but yet they have the capability when they
aren't limited. Right. You could block those commands and
write detections on them so that the SOC analysts can
immediately get alerted when those kinds of actions occur.
I think I remember in your paper you wrote about
installing a set of authorities, I believe, and
updating them in the device. That would be something that
really should almost never happen. Yeah, it should almost
never happen. There's no reason to export the PKI so
you can reuse it, but it is a command on certain Cisco
devices. Yeah. So what kind of attacks do you see against
these? Who is attacking those devices? Yeah. So the paper
definitely starts out with the why. And the why is really
important. So we see multiple Russian threat actors
consistently attacking network devices. Grizzly Step,
Dragonfly, Berserk Bear, and even some Middle East non
-nation state hacktivists like Gecko Jackal. So if those are
in your threat profile, you're going to want to prioritize
looking at your network devices more in depth, looking
at the logs, doing these detections, implementing these
protections. You mentioned a couple seams, Splunk,
Elasticsearch. They all work with these kind of logs. Yes.
So almost every seam can ingest syslog from Cisco
devices or other network devices as well as AAA logs.
But the beauty of the rules that I wrote are they're in
the SGMA rule format. So you can import them to any seam
that SGMA supports an export for. So QRadar, all the big
popular ones. And those detections can be implemented
fairly easily for the SOC analysts to start tuning. And
they're definitely going to need tuning in any enterprise.
I don't remember the rules that you specifically wrote,
but typically the SGMA rules are fairly readable. Or so
even if you don't have an automatic import, you can
probably rewrite them in whatever rule language your
seam supports. Absolutely. It's a simple human readable
YAML. It's not JSON. Okay. I like JSON better than YAML. I
do like JSON, but at least the SGMA rules are easy to read.
Yeah. Okay. Excellent. So anything you learned since you
wrote the paper? It was a while ago that you wrote the
paper. So anything that you learned applying some of this?
Yeah. So the paper was basically a big purple team
event. Generate the logs, use Kali Linux to exploit and
attack the devices, see the logs that are generated, write
the rules. And then I tested the rules in the enterprise
environment. And so I've tested them in a few
enterprise environments since then. And it's critical to
tune the detections. That's number one. A few more people
have updated SGMA rules. So now there are Juniper and
Huawei as well. The Cisco ones were the first ones that
actually were added to SGMA for network devices
specifically. That's different than just the network-based
detections with like ZEK or something. And then I worked
very closely with MITRE to get the network enterprise matrix
updated. There was originally only 27 techniques. And then
when I contributed the results of this paper, it jumped to 40
techniques in April of 2022. And since then, it's already
up to 90. So people are really looking at network devices.
They're seeing how many different detections they can
implement. And I think this space is still something that
every SOC needs to have. Yeah, so thanks. Great to have you
here. So thanks for contributing what you learned.
And yeah, that's it for today. So thanks for listening. And
talk to you again on Monday. Bye.
