Hello and welcome to the Wednesday, June 4, 2025
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ullrich and in this episode brought to you by
the SANS.edu Credit Certificate Program in
Cybersecurity Leadership. I'm recording in Jacksonville,
Florida. Well, in diaries today I looked a little bit
more at the vBulletin vulnerability that I mentioned
earlier this week and exploits that we observed around this
particular vulnerability. vBulletin again, it's a
bulletin board software. It's quite popular. It's a
commercial offering, not an open source offering in that
sense. It's written in PHP. And I think this vulnerability
really has two sort of interesting aspects that I
think haunt a lot of sort of vulnerabilities and also
vulnerability mitigation. Now, this vulnerability was first
really explained by this particular blog post from
Egidio Romano. I think I mentioned the wrong name in
the diary originally, but Egidio here is the one that
really sort of dove into this patch that vBulletin had
released about a year ago and then explained how this
particular vulnerability can get exploited. That's sort of
really where it gets interesting. So, vBulletin
implements an API as so many web applications. And this API
does expose specific classes. Now, the problem here is that
in PHP version 8.1, how you access particular methods in
these classes changed somewhat. So, methods that you
considered being protected, not accessible to basically
any call from outside the class have now been exposed in
PHP version 8.1. Now, there's more details to it. It
basically uses these reflections which are used to
sort of interrogate classes and figure out, you know, how
to call a particular method. And that's really sort of
where the change happened. It's, in my opinion, not a
well-documented change. I looked at the 8.1 change log,
didn't really see it there. But then in the actual PHP
manual for the reflection method, invoke method here, it
does actually mention that, yes, you know, this change was
made in version 8.1. So, from the vBulletin board point of
view, certainly something that's easily overlooked. On
the other hand, well, you know, you want a patch. You
want to keep your PHP versions up to date. So, here actually
updating your PHP version did introduce this vulnerability.
The second part to this is on the vBulletin side. So,
vBulletin did release a patch about a year ago, back in
April. And the problem with the patch was that they didn't
really explain, well, why you should apply the patch. There
was no details of what exactly is wrong with the old version.
It is labeled a security patch, but then it just says
to maintain site security, you should apply this patch as
soon as possible. And that, of course, is not enough
information for anybody, particularly, you know, given
the risks with patching, to quickly apply this patch. So,
you have on the one side where if you were too eager to
patch, then you introduce the PHP vulnerability. On the
other hand, if you delayed patching, and that's sort of
the vBulletin part, because there was no clear
vulnerability that you're going to patch. Well, again,
you know, you would have missed this particular update.
So, in short, if you're running vBulletin do update,
we do see some scans out there. There is one threat
actor who is using a couple different IP addresses who
appears to be particular interest in this vulnerability
and has, like, for a few days now scanned for vulnerable
systems here. Don't yet exactly know what they're
after. They're also looking, like, for what looks like
brute forcing and such. So, certainly something that you
want to keep an eye on and patch. And Google pushed out
an update for Google Chrome. This update does fix three
different security vulnerabilities where one of
these vulnerabilities, an out -of-bounds read and write in
v8, is already being exploited. And Google
mitigated this vulnerability with a configuration change.
Of course, not a ton of detail here, as typical for Google's
security updates. Just patch. And, as usual, Google Chrome
does a reasonable good job in patching itself regularly.
Just make sure to restart Google Chrome, like, once a
day. And the web-nail system, RoundCube, did release an
update that fixes a deserialization vulnerability.
It's exploitable only by users who are authenticated. But
given that you often have all users in your organization
connected to a particular RoundCube instance, that may
not be too far of a stretch. And just a couple weeks ago,
there was, like, that big news story about how these web-mail
systems are being exploited. So, pay attention and double
-check that it's up-to-date. And finally, noteworthy
patches. We also got one from HP for its StoreOnce software.
The patches are fixing vulnerabilities found during
the Zeroday Initiative's Pwn-to-Own contest. And, well,
there are authentication bypass vulnerabilities and
then remote code execution vulnerabilities. So, it
doesn't really matter if these remote code execution
vulnerabilities require authentication because you can
bypass it. Certainly, critical vulnerabilities that must be
patched quickly. Well, that's it for today. So, thanks again
for listening. Thanks for leaving good comments about
this podcast. If you like it, let me know. Or, if you don't
like it, let me know too. But don't leave a bad comment.
Just let me know what to fix here with this podcast. And,
other than that, I hope to see some of you at Sands Fire in
mid-July in Washington, D.C. either online or in person.
But, we've got some special treats if you're coming in
person. Like our Honeypot Workshop. We're giving away a
limited number of free Honeypots. And, also a number
of other events and such that we do have for attendees who
actually join us live in D.C. Well, that's it. And, thanks
everybody. And, talk to you again tomorrow. Bye.
