Hello and welcome to the Tuesday, November 4th, 2025
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ullrich, recording today from
Jacksonville, Florida. And this episode is brought to you
by the SANS.edu Master's Degree Program in Information
Security Engineering. This weekend we did see a large
number of exploit attempts for the XWiki SolrSearch
vulnerability. This vulnerability was added to the
known exploited vulnerabilities catalog on Friday. So no real
surprise that we see some exploits for it, in particular
since this vulnerability has gotten quite a bit of coverage
over the weekend. There are a couple odd things about these
exploit attempts. First of all, what took him so long?
The original advisory that was published by XWiki to alert
users of this vulnerability actually pretty much had
exploit code attached to it. It had a proof of concept
exploit that showed you how to take advantage of this
vulnerability. And it was pretty straightforward how to
do so. The other odd thing here was the user agent being
used by the actor who, according to our data, is
pretty much responsible for all of the exploits. Well,
this was actually an email address. The email address is
with atomicmail.io, which is an encrypted and somewhat
anonymous email provider. So yes, certainly something that
an attacker may use, but not really sure why they're sort
of advertising themselves here. And I haven't really
seen this email address being used before. So this seems to
be unique to this particular exploit. But let me know if
you have seen it before. The other thing is that, well,
pretty much as expected, the exploit is used to download an
additional script from a website and then execute it.
But if you go to this website, you actually end up on a
rapper's sort of promotional page. And the name of the
exploit script happens to be an opposing rapper. They're
both like in Chicago, so they're different gangs. Both
are doing time these days, so unlikely they're directly
involved with this. But it could be some kind of fan or
whatever who came up with this exploit and is just using
these names. Really kind of a lot of stuff here with that
and not sure what to make of it. If anybody has any more
details, let me know. I reached out to the email
address and user agent, but haven't gotten any reply yet
so far. Either way, patch your ex-wikis if you are using
them. And at this point, as always, assume compromise. Let
me have an interesting and a little bit of tricky
vulnerability that affects AMD's Sen 5 processors. For a
change, it's not one of those speculative execution
vulnerabilities or anything like this, but instead a weak
random number generator. The RDC function, which is meant
to create good random numbers, Intel has similar functions in
their CPUs, does occasionally return zero, even though,
well, that would be not the next random number it's
supposed to return. And it also indicates that the result
is good. There's a flag that is being set whenever it
returns a random number. It tells you if it's a good
random number or not. But in this case, the signaling shows
success, but the random number is just zero. And that happens
more often than zero should show up just randomly. There
is a patch in the works from AMD for this, but they also
offered a couple of workarounds. One, probably
that's the easiest, in my opinion, to deploy is where
you just, to the boot options of your Linux kernel, add an
option in order to basically turn off that behavior. Also,
if you're using the 64-bit version of RDC, then you're
not affected by this particular bug. And then
again, it's just the Sen5 processors, even though other
processors, of course, have that RDC command, but they're
not affected by it. For a complete list of all the
processes that fall into that Sen5 category, well, refer to
AMD's advisory for this. A little bit hard to tell how
exploitable this is depends on how often that zero result is
coming back. But of course, from a security point of view,
random numbers are being used for many, like, cryptographic
keys and such. So certainly important to fix that
eventually. It will at least make it a lot easier to brute
force cryptographic keys, even though it may not still be
trivial. And, well, malicious extensions via OpenVSX appear
to not be going away. I mentioned yesterday how
they're trying to improve the security of their ecosystem
somewhat. The latest example here comes from John Tuckner
with Secure Annex. And interestingly here that they
basically found this extension that's supposed to help with
Solidity, which is a language or a configuration language
used for smart contracts. And yes, it's supposed to, like,
you know, properly mark them up. But of course, it's
targeting people who are working with cryptocurrencies
in order to steal credentials. And this is something that
really sort of, I think, I noted with all of these
malicious extensions that they pretty much exclusively target
crypto developers. So if you are in the business of
developing software that deal with cryptocurrency, be very,
very careful. That's pretty much the exclusive target of
these kind of malicious extensions. Yes, it doesn't
mean that other developers shouldn't be careful because
we also have seen a little bit stuff like cloud credentials
and such being stolen. But the number one target here is
really developers of smart contracts and crypto coin
software. Well, and this is it for today. So thanks for
listening and thanks for recommending and liking and
whatever you do to make this podcast more popular. And as
always, if there is a story I missed, if there's a story I
should not have covered, well, please let me know. Thanks and
talk to you again tomorrow. Bye.
