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.
