SANS Stormcast Friday Feb 21st: Kibana Queries; Mongoose Injection; U-Boot Flaws; Unifi Protect Camera Vulnerabilities; Protecting Network Devices as Endpoint (Austin Clark @sans_edu)

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/9334.mp3

previous

Kibana Queries; Mongoose Injection; U-Boot Flaws; Unifi Protect Camera Vulnerabilities; Protecting Network Devices as Endpoint (Austin Clark @sans_edu)

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Austin's paper sounds interesting. Do you know where we can find it? Thank you in advance

Posted by amon on Fri Feb 21 2025, 14:08

Login here to join the discussion.

Podcast Transcript

 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.