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.
