SANS Stormcast Thursday, October 2nd, 2025: Honeypot Passwords; OneLogin Vuln; Breaking Intel SGX; OpenSSL Patch

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

previous

next

Honeypot Passwords; OneLogin Vuln; Breaking Intel SGX; OpenSSL Patch

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 Thursday, October 2nd, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ulrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Master's Degree Program in Information
 Security Engineering. Today's diary comes yet again from one
 of our undergrad interns, Draden Borowick, wrote this
 diary looking at the passwords collected by the honeypot and
 then comparing them to the Have I Been Pwned list. Have I
 Been Pwned, you're probably familiar with, is a website
 that does collect passwords from password breaches and you
 can look up if a particular password has already been
 leaked in one of these breaches and that's what
 Draden is doing here with a script. This script will first
 of all summarize and extract all the passwords from the
 honeypot logs and then compare them to the Have I Been Pwned
 list. No big surprise, well most of the passwords are in
 the Have I Been Pwned list and that in part is because often
 default passwords are being attempted but also credential
 stuffing where attackers are attempting to use passwords
 that were specifically found in prior breaches. Now then
 Draden took a closer look at the remaining seven percent of
 passwords that didn't show up in Have I Been Pwned and many
 of them were derivatives of passwords like for example
 changing the year and things like this or adding a couple
 special characters. Probably the attackers attempt here to
 expand on the patterns that are commonly seen in these
 leaked password lists to hopefully gather and hit a
 couple passwords that maybe the competition hasn't
 attempted yet. And Tal Kimi with Clutch Security published
 an interesting vulnerability report for OneLogin. OneLogin
 is one of these OpenID Connect solutions, basically a single
 sign-on system. And the problem here is that if you do
 have a valid API key in order to interact with OneLogin you
 can actually retrieve a page that lists all applications.
 Now that's actually not bad and that's something that's
 part of the OpenID Connect specification. But in this
 case that page that lists all of the applications also lists
 the application secrets which should definitely not be made
 available to other users. And that can then be used in order
 to impersonate applications that have access to OneLogin.
 So certainly something that must be patched and is very
 easy to exploit. The vulnerability was originally
 found in July and shared with OneLogin. OneLogin had it
 patched mid-September and now they're publishing the blog
 post so they gave everybody a little bit of time to apply
 patches. And then we do have a new paper by researchers from
 Purdue University as well as Georgia Tech who looked into
 breaking the Intel Software Guard extension. This is
 basically a feature in modern Intel systems that's built
 around their secure enclave. And the trick that these
 researchers came up with does allow them to read or derive
 the keys from this secure enclave. The hardware
 modification they make to the system is that they add
 instrumentation to be able to inspect data written and read
 from memory. This in itself is really not that special. They
 say they spend a thousand dollars on the hardware to do
 so. But the logic analyzers and such they're using are
 commonly used in labs in order for example to validate memory
 CPUs and such and test them. The problem is not so much
 that they can read the traffic to the memory. That should be
 assumed given that well in some systems they're still not
 soldered in. So reading that there shouldn't really be that
 much of a problem. The problem then becomes is not that the
 key is being written to memory and that would be a gross
 violation of what SGX is all about. But instead they're
 observing encrypted data being sent to memory. That encrypted
 data is using deterministic encryption which means that
 for different operations it uses the same secret key. So
 if you're sending the same data well you're ending up
 with the same cipher text that is often usable in order to
 derive the key being used for the encryption. And that's
 sort of how to get to the secret key that should be
 securely stored in that secure enclave. So interesting issue.
 I'm a little bit hesitant to call it a vulnerability at
 this point. But certainly more an issue with what encryption
 algorithms and such are being used here. It doesn't
 necessarily sort of break the assumption that secret keys
 can be retrieved from the secure enclave. Just basically
 the way they're being used. Well they can be derived
 looking at enough encrypted data. And they sort of put
 together all the pieces needed in order to accomplish that.
 Defenses here. Well as usual don't leave your systems
 sitting out in the open. This attack again requires that
 they apply hardware manipulation. While this may
 be a little bit excessive it certainly does. It is one of
 the things that these secure enclaves are supposed to
 prevent. So it's certainly a valid attack against this
 particular system. And then we have patches for OpenSSL and
 the one vulnerability that sort of gets the most
 attention. Somewhat rightfully so is a vulnerability in the
 read and write in KEC unwrap. Now this vulnerability has
 potentially the ability to cause arbitrary code
 execution. Which of course is a huge deal in particular when
 you're talking about open SSL. However in order to trigger
 the arbitrary code execution you have to use a password
 based encryption. And that is hardly used as they're saying
 here in real application with this particular mode. So you
 won't really be able to exploit it in a lot of
 systems. And they also say that exploitation is very
 difficult for this particular vulnerability. And so they're
 rating it here as a moderate severity. Even though it does
 have the potential for arbitrary code execution.
 There's also a side channel attack here in the SM2
 algorithm. Again they're saying here that's not an
 algorithm that's actually implemented in open SSL. It's
 something that you sort of provide with an add-on to open
 SSL. And as a result they're also rating this moderate. The
 third vulnerability being addressed here is an out of
 bound read in the HTTP client. No proxy handling. And that is
 something that could lead to a denial of service
 vulnerability against the application. They're rating
 this one low. So update it as becomes available for your
 respective distributions. But no rush here to rush out this
 particular patch. Well and that's it for today. So thanks
 for listening. And thanks for liking and subscribing to this
 podcast. And talk to you again tomorrow. Bye.
 My name is Noah Filter. Thanks a lot. There's a intention
 here that we're getting to the restriction.