SANS Stormcast Monday, July 7th, 2025: interesting usernames; More sudo issues; CitrixBleed2 PoC; Short Lived Certs

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

previous

interesting usernames; More sudo issues; CitrixBleed2 PoC; Short Lived Certs

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 Monday, July 7th, 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 Undergraduate Certificate Program in Applied
 Cybersecurity is recorded in Jacksonville, Florida. Well,
 to start out with a couple of interesting ssh/telnet usernames
 that I observed the last couple of days showing up in
 our honeypots. First of all, well, not a chance this is
 real. That's the username I suspect this username is
 selected in order to actually fingerprint honeypots.
 Honeypots that we are using based on Cowrie will
 occasionally, sort of randomly, allow any credential
 to work. This prevents people from basically just using some
 simple credentials. And also, well, eventually we do want
 actually attackers to log in to see what they're up to. And
 then, of course, attackers can use that against us by using
 these obviously non-existing usernames and password
 combinations. And if they work, well, there's a good
 chance that they are connected to a honeypot. Other notable
 usernames that I've seen is one SCADA admin that
 apparently is related to the Rapid SCADA systems. On
 Mastodon, user John Timmis also confirmed that pointing
 to the relevant documentation at Rapid SCADA. I originally
 wasn't able to find that particular username. But there
 are also others, of course, like admin12345 and such that
 are being used by Rapid SCADA. Now, the next set of usernames
 is GPU001, GPU002. Not 100% sure what they are associated
 with. But, of course, GPU, well, that's a hot thing these
 days with AI training and the like. GPU001 and 002, that
 particular format, appears to be often used as a host name
 in some systems hosting GPUs. Not necessarily a username as
 far as I can tell. But if anybody has any details there,
 please let me know. And we have a second issue with Sudo
 that I forgot to cover on Thursday last week. This was
 also discovered by Rich Merch from Stratascale. And it also
 is related to a not very frequently used option of
 Sudo. This option is the host option. It allows a user to
 specify a different host. And in the Sudo configuration, you
 can basically define a certain host. The intent really was
 for the option to be used with the list option. So, you can
 basically list rules based on the host that you would like
 to use. Well, it turns out it also works for the edit
 option. Which, of course, then allows for a relatively
 trivial privilege escalation of vulnerability. Again,
 update Sudo. These vulnerabilities have been
 around for quite a while. I believe this one was 13 years,
 if I remember correctly. And most Linux distributions are
 vulnerable and have released updated packages. And we do
 now have a detailed explanation and proof of
 concept exploit for the Citrix Bleed 2 vulnerability that was
 patched about two weeks ago. WatchTowr has a great write
 -up on this. I won't go into all the little details here.
 Just quickly, how do you detect a possible attack? It's
 actually the login page that is vulnerable here. And how
 the login parameter is being parsed. If you just send a
 post request to the authentication endpoint with
 short content with the word just login. Important is the
 word login. And that you don't have an equal sign here. And
 that triggers the vulnerability. The result that
 you get back will be random memory content in the initial
 value field here of the response. So if you're seeing
 some random characters in this particular field, that will
 tell you that you are vulnerable. And I mentioned
 how Let's Encrypt is now starting to provide very short
 -lived certificates. Down to six days for the lifetime
 certificate. This is optional, but opens up some new
 possibilities like getting certificates for IP addresses.
 Well, it looks like Instagram is actually starting to
 experiment with this. And kind of showing how to
 operationalize some of these super short-lived
 certificates. So the Instagram certificates now are only
 valid for seven days. They're not using Let's Encrypt. I
 believe they're using Google as their server authority. But
 they're actually rotating these certificates daily. So
 this is basically how you avoid any possible issues with
 missing like an update. You don't want to do it too close
 to the expiration date. But they basically get a new
 certificate each day. And each certificate will then be valid
 for seven days. Well, and this is it for today. So thanks
 again for listening and talk to you again tomorrow. Bye.