SANS Stormcast Tuesday, November 4th, 2025: XWiki SolrSearch Exploits and Rapper Feud; AMD Zen 5 RDSEED Bug; More Malicious Open VSX Extensions

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

previous

XWiki SolrSearch Exploits and Rapper Feud; AMD Zen 5 RDSEED Bug; More Malicious Open VSX Extensions

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 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.