Podcast Detail

ANS Stormcast Monday, April 21st: MSFT Entra Lockouts; Erlang/OTP SSH Exploit; Sonicwall Exploit; bubble.io bug

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

previous
next
Podcast Logo
MSFT Entra Lockouts; Erlang/OTP SSH Exploit; Sonicwall Exploit; bubble.io bug
00:00

Microsoft Entra User Lockout
Multiple organizations reported widespread alerts and account lockouts this weekend from Microsoft Entra. The issue is caused by a new feature Microsoft enabled. This feature will lock accounts if Microsoft believes that the password for the account was compromised.
https://www.bleepingcomputer.com/news/microsoft/widespread-microsoft-entra-lockouts-tied-to-new-security-feature-rollout/
https://learn.microsoft.com/en-us/entra/identity/authentication/feature-availability

Erlang/OTP SSH Exploit
An exploit was published for the Erlang/OTP SSH vulnerability. The vulnerability is easy to exploit, and the exploit and a Metasploit module allow for easy remote code execution.
https://github.com/exa-offsec/ssh_erlangotp_rce/blob/main/ssh_erlangotp_rce.rb

Sonicwall Exploited
An older command injection vulnerability is now exploited on Sonicwall devices after initially gaining access by brute-forcing credentials.
https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0022

Unpatched Vulnerability in Bubble.io
An unpatched vulnerability in the no-code platform bubble.io can be used to access any project hosted on the site.
https://github.com/demon-i386/pop_n_bubble

Podcast Transcript

 Hello and welcome to the Monday, April 21st, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ulrich and today I'm recording from
 Jacksonville, Florida. Looks like this weekend was not a
 good weekend for administrators using Microsoft
 Entra for authentication. Microsoft apparently made live
 a new feature. They're calling it MACE and the idea behind
 the feature is not a bad idea. It does flag accounts whose
 credentials have been compromised in the past. So
 they're tying into some kind of backend. I'm not sure if
 it's have I been pwned or something they built
 themselves. But if you're using credentials that were
 found in recent compromises, the account is then
 automatically locked. The problem is that, well, a lot
 of accounts apparently were affected by this. Some report
 like about a third of their accounts were flagged. So you
 got this rash of alerts. And of course, attackers haven't
 necessarily taken advantage of this issue. So it's very
 possible that the account itself is still fine. It's a
 little bit tricky how you should react to these alerts.
 Of course, you should probably ask your users to update their
 passwords. But on the other hand, having a third of your
 users all for a sudden disabled is often not really
 sustainable from customer support as well as from a
 business perspective overall. So you may need to find a
 quick workaround here to keep these accounts going for now.
 It's not clear what exactly was compromised. If just the
 password showed up in any compromises of the username
 and password combination showed up. Of course, the
 second being much more dangerous than your users just
 using a somewhat weak password that someone else may have
 used as well. And then that password was compromised. Like
 I said, don't ignore these alerts. But you may come
 Monday as you get to the office. Need to find a
 workaround to at least keep business going until you got
 this all sorted out. Well, apparently attackers are using
 a neat, quick social engineering trick in order to
 gain access to remote users via Zoom. The trick involves,
 first of all, getting into a Zoom call with the victim.
 This is often done under some kind of pretense, like being a
 company they would like to work with. And then the
 attacker is changing their real name in Zoom to the word
 Zoom. And now if the attacker is requesting system access,
 it looks pretty much like Zoom, the software itself, is
 requesting system access, making it more likely for the
 victim to approve the request. That, of course, is then in
 turn used by the attacker to execute commands on the
 victim's system. Apparently, it's possible in Zoom to
 globally disable this feature across an organization. This
 may not necessarily be what you want to do, given that
 this feature is sometimes used legitimately in customer
 support scenarios, for example. But overall, where
 your best bet is educate users about these risks. And I can
 see that similar attacks will also work for other remote
 conferencing platforms, not just Zoom, because they all
 have fairly similar feature sets. And SonicWall updated an
 older advisory from September 2021, indicating that this
 particular arbitrary code execution vulnerability is now
 being exploited. The reason this particular vulnerability
 actually, I think, hasn't been exploited so far is that it
 doesn't give you access to the system. So you do need valid
 credentials. That also explains the somewhat lower
 CVSS score of 7-ish for this particular vulnerability. But
 we all know that the credential brute forcing is
 heavily used against these kind of SLBP and other border
 devices. So once the attacker gains access to the device
 using a probably lower privileged account, they can
 now use this vulnerability to execute arbitrary commands and
 essentially get a privileged escalation on the device. If
 you do find a device that you suspect to be compromised,
 definitely keep that in mind, in particular if you think
 that the attacker logged in using some lower level
 credentials. How do we have? Well, more trouble in no-code
 land. This time it's Bubble .io. Bubble.io is one of those
 no-code platforms that allow you to quickly generate apps
 using AI. Well, they actually ran into an issue that we talk
 about in the Defending Web App class, that with
 Elasticsearch, some developers are tempted to expose
 Elasticsearch directly to the user because it's so easy to
 access it with JavaScript. That's exactly what Bubble.io
 did. They expose Elasticsearch to JavaScript requests created
 by the user. Now, in order to keep users apart in that
 scenario, they're encrypting the payload. However, they
 don't really use a secret here in the encryption. They're
 using the app name, which, of course, you know what app name
 people are using. And then they're using an IV
 initialization vector, but they're not using a random
 one. There are only two across all the different applications
 that are hard-coded into the JavaScript. And that way,
 well, it's very easy to derive the encryption key for a
 random application. And with that decrypt the code being
 returned for that application. And then the biggest problem
 here overall is that even though Bubble.io was notified
 by researchers who discovered the flaw back in 2024, they
 yet have to deploy a fix. So if you're using Bubble.io,
 your applications are currently still vulnerable. I
 just took a quick look at the Bubble.io website and couldn't
 really find anything if they have fixed anything since the
 vulnerability was publicly released. Well, that's it for
 today. Thanks to all that said hi in Orlando last week. In
 two weeks, I'll be actually in San Diego. And I'll be
 teaching the Network Inclusion Detection class again. I'll
 also be, of course, at Sans Fire. And as I announced last
 week, you'll occasionally see QR codes, links for the class
 here in these daily podcast videos. If you're not
 listening or if you're not watching, if you're listening
 instead, of course, links will be on the ISC website. Thanks
 and talk to you again tomorrow. Bye.