SANS Stormcast Tuesday, June 3rd, 2025: Windows SSH C2; Google Removes CAs from trusted list; MSFT issues Emergency Patch to fix Crash issue; Qualcom Adreno GPU 0-day

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

previous

next

Windows SSH C2; Google Removes CAs from trusted list; MSFT issues Emergency Patch to fix Crash issue; Qualcom Adreno GPU 0-day

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

New Discussions closed for all Podcasts older than two(2) weeks
Please send your comments to our Contact Form

Podcast Transcript

 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.