SANS Stormcast Wednesday May 28th 2025: Securing authorized_keys; ADAuditPlus SQL Injection; Dero Miner vs Docker API

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

previous

next

Securing authorized_keys; ADAuditPlus SQL Injection; Dero Miner vs Docker API

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Wednesday, May 28, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ulrich and this episode brought to you by
 the SANS EDU Bachelors Degree Program in Applied
 Cybersecurity is recorded in Jacksonville, Florida. Well,
 today we have a quick diary, nothing really too exciting
 and special, but it's really about the security of SSH. In
 particular, the authorized keys file. Now, we all know
 that we should use keys for authentication, not passwords.
 But the number one thing that I sort of see all these bots
 doing is that after they breach a Unix system, they
 will add a key of their choosing to the authorized
 keys file, giving them essentially a backdoor into
 the system. So securing the file certainly sounds like a
 good idea, in particular on some of these IoT and smaller
 Unix systems. I think the number one lesson here is that
 if you want to manage these keys centrally, you don't have
 to put them into the user's home directory. There is a
 simple configuration with SSH, at least with OpenSSH, that
 pretty much everybody is using, that allows you to
 store all the key files for all the users into a special
 directory. You basically just use the username or the
 numeric user ID as the name of the file for each user. And
 that way you have centrally managed access. The files only
 need to be readable by the users. They don't need to be
 writable by users. So that way an attacker should no longer
 be able to modify these files at will, at least not all of
 these bots and such that we see performing this particular
 technique. And of course, that also makes then monitoring
 these files a lot simpler to detect any changes, in
 particular unauthorized changes, of course, early.
 Also talk about IoT vulnerabilities. There is a
 good example here that I saw in a blog post from OneKey.
 OneKey makes software to find security vulnerabilities. So
 one of those software scanning softwares. And they took a
 look at MeteoBridge. MeteoBridge is, well, the
 Meteor stands for meteorology. It's to connect various
 weather stations together. It's commercial software
 that's being distributed. And, well, it suffers from a very
 basic, really, vulnerability. But something, sadly, not too
 uncommon. The query string being passed to the URL as
 part of a get request contains data that's then being passed
 to an eval command without further inspection. Eval, as I
 always say, it's one letter away from evil. It's a command
 that you always should avoid. And if you use it, you have to
 use it with utmost care that you're validating all user
 input that's being passed to it. There's also a little bit
 problem here that part of this application is written just in
 bash. And bash is not the greatest language to really do
 a lot of input filtering and security stuff, particularly
 with different white space issues and such. So
 definitely, I think, something that I would stay away from.
 Use Perl. Use Python if you want a simple scripting
 language. But bash usually should be avoided for
 applications like this. Really hard to get them right. But,
 yeah, given that the exploit is very simple, they also
 published a little proof of concept here. Very
 straightforward. So if you're a classic OS command injection
 vulnerability, that then, of course, could be used to add
 data to your authorized keys files. And Manage Engine did
 publish two security advisories affecting AD Audit
 Plus. It was a little bit on the fence whether or not I
 should cover these vulnerabilities because
 they're really privileged escalation vulnerabilities. So
 the attacker must be authenticated. The reason I
 cover them is because they're very similar to prior
 vulnerabilities in Manage Engine products. They're SQL
 injection vulnerabilities in APIs in the product. And
 similar vulnerabilities in the past have been exploited in
 various attacks. So kind of likely that you will see some
 exploitation here in the near future as well, in particular,
 since attackers are now kind of ready to go with these two
 vulnerabilities. So take a look at your installs and
 probably want to patch this. But, again, it's really more
 sort of lateral movement kind of vulnerability. And talking
 about exposed APIs, one API you definitely don't want to
 expose is your Docker API. And yet again, Kaspersky came
 across the attack that abused exposed Docker APIs. In this
 particular case, the attacker, well, was doing what attackers
 do typically with these type of vulnerabilities. They used
 them to then install crypto coin miners. Not only did they
 just launch new systems, new containers within the system
 that they compromised, but then also did compromise
 existing containers to also then add their crypto miner.
 Well, this is something that shouldn't be that difficult to
 detect given the increase in CPU time, but still remains
 one of the more common techniques being used by
 attackers against Docker APIs that are exposed. Well, and
 this is it for today. So thanks for listening. And,
 well, just a reminder, I hope to see some of you at SANS
 Fire and also the SANS.edu programs. If you talk to
 anybody at admissions and such, let them know that it
 was the podcast that sort of got you there. So that's it
 for today. Thanks again for listening and talk to you
 again tomorrow. Bye. Bye.