Hello and welcome to the Tuesday, June 3rd, 2025
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ullrich and this episode brought to you by
the SANS.edu Graduate Certificate Program in
Industrial Control Systems Security is recorded in
Jacksonville, Florida. Well, in diaries today, Xavier came
across an interesting malware sample that takes advantage of
SSH on Windows. That's something we have seen for
years and years in Linux. Linux, of course, always had
SSH as one of its standard components, typically pre
-installed. Now, Windows started doing this a couple of
years ago and now pretty much any new Windows system that
you are using has an SSH client at least pre-installed.
Now, the SSH client, of course, does not listen on any
port by default. That's exactly sort of what that
malware takes care of. It does deploy a simple SSH client
configuration file that will basically instruct the system,
the SSH client, to connect to a particular command control
server and then forward connections from that command
control server to an internal listening port. As Xavier
points out, this configuration file is actually not 100%
syntactically correct. So, it probably doesn't work quite
the way it was deployed here. The particular command control
server, yes, it's no longer listening. I would just want
to point out that they're using SSH over port 443. Of
course, that's supposed to better blend in with common
network traffic. However, if you do have any kind of
network monitoring system, that should really raise a
flag. If you all of a sudden have SSH over port 443, that's
a pretty simple and straightforward detection.
Pretty much all the network monitoring systems will tell
you about this. So, definitely something to take care of and
make sure that you're able to detect a backdoor like this,
not just for Linux, but also for Windows. Well, and then we
have more problems with certificate authorities.
Google announced that they will stop trusting two
certificate authorities, Chunghwa Telecom and Netlock.
Chunghwa Telecom, so it's with a Chinese telecom company.
Netlock, associated with a Hungarian company. Now,
similar action is also pending in the larger server authority
browser forum. So, this may in the near future also affect
other browsers. As far as Google Chrome is concerned,
Google Chrome will stop trusting certificates being
issued by these two server authorities as of July 31st.
So, any certificate issued after that date will not be
trusted. If your certificate issued now, it will still be
trusted until it expires. So, you don't have to do anything
immediately now. But, yes, definitely, you know, find a
different set of authority if you want to still use your
records to be trusted. I looked a little bit into, you
know, what the reason is behind that. For Chunghwa,
apparently, they didn't observe the CAA DNS record.
That's a DNS record where you are indicating which set of
authorities are able to actually issue certificates on
behalf of your domain. And during some cutover, they
didn't check that properly. And then they also didn't
revoke affected certificates in a timely manner. If you
remember, there was, like, Let's Encrypt had a similar
issue, but they ended up revoking, like, millions and
millions of certificates as a result. Here, the revocation
really was the problem. They didn't properly respond to
that incident. For NetLock, it's actually a little bit
more problematic. They did issue signing certificates.
So, in immediate certificates that could be used to sign
other certificates on NetLock's behalf. And they
didn't disclose that they actually issued those signing
certificates. So, then related certificates didn't show up in
sort of transparency logs and the like. And that, of course,
could then allow, like, you know, a larger sort of machine
-in-the-middle attack, which is certainly an important
concern here. And, again, that's why they get kicked
out. And, also, they didn't really respond in any timely
manner to these issues. Neither of these certificates
authorities, I think, has a large user base. So, the
impact should be minimal. But, again, double-check what
certificates you're using, if any of them are being signed
by these set of authorities, or if any of your vendors are
using the set of authority. That can be a problem if, for
example, automatic update processes and such are failing
because you no longer trust these certificates. If you,
for example, connect to some vendor's web server to pull in
updates. Well, then we got a critical update from Qualcomm
for their Adreno graphics processing units or their GPU.
This particular driver is mostly used on Android. So,
that's where you have to watch out for this patch. And, well,
it is already being exploited. It's a privilege escalation
vulnerability. But, given it's already being exploited, you
definitely should try to apply related updates as soon as
possible. Of course, it's part of that Android ecosystem. So,
you pretty much have to wait for an Android update for your
particular device that will include this patch. Well, and
this is it for today. So, thanks again for listening and
talk to you again tomorrow. Bye.
