Hello and welcome to the Wednesday, April 16th, 2025
edition of the SANS and the Storm Center's Stormcast. My
name is Johannes Ulrich and today I'm recording from
Orlando, Florida. Xavier today wrote a diary about, well, a
little bit of an old problem and that's the abuse of free
file transfer services. As Xavier puts it, why create
your own complex command control channel if all you
need is a simple HTTPS post to a well-known free file hosting
service that may even be considered legitimate and as
such raise less suspicion than some kind of interesting
custom domain. The latest one that Xavier ran into here is
gofile.io. Now, Xavier also points out there is an older
one that he still keeps seeing and that's anonfile. In a
particular piece of software that Xavier actually found
here, gofile is used by default, but if gofile fails,
it actually then falls back to anon file. Now, the
interesting part is that anon file has been disfunct now for
a couple of years. As such, falling back to it doesn't
really make much sense, but well, this may just be sort of
a modification to an existing script. Xavier also lists a
few common other domains that are being used for this data
exfiltration. So definitely something you do want to pay
attention to. In particular, these disfunct services, given
that attackers still attempt to use them, putting in some
kind of DNS rules or so trying to figure out is someone
attempting to connect to them certainly makes some sense for
malware detection in your network. And we have a new
version of the SSH, Demon Open SSH released version 10.0.
Now, this is a functional version update. So while it
does provide some security improvements, it doesn't
necessarily fix vulnerabilities. There are two
major sort of changes from a security point of view. First
of all, the addition of quantum safe ciphers. And
secondly, there is now a new SSHD Auth Demon that takes
care of user authentication. The idea behind this is that
the pre-authication attack surface is sort of
disassociated from the rest of the SSH Demon. And with that,
any problem in this particular code would have less impact of
the rest of the SSH Demon. So there's something that you may
want to play with. But for the most part, just wait for it to
show up in your preferred Linux distribution or whatever
other operating system you're using for SSH. No critical
need to update to this version right now. And the next
vulnerability is, well, a little bit odd in the sense
that I don't understand the high CVSS score. And that's
really why I want to cover it, because that may be assigned
wrongly, or maybe I just don't understand the vulnerability
and the software correctly. It's an Apache Roller. That's
a Java-based group block software. The problem here is
that the vulnerability that's being patched here is that if
a user changes their password, their existing sessions are
not invalidated. Now, this is not a good thing, because a
user may change their password, because they suspect
their account being compromised. And with these
persistent sessions, an attacker retains access even
after the user changed their password. However, assigning
it a CVSS score of 10, which is usually the top CVSS score
and used for things like unauthenticated
vulnerabilities and remote code execution
vulnerabilities. I think something went wrong here with
the CVSS score. But anyway, if you're using Apache Roller, be
aware of the vulnerability. It may be flagged as a big deal.
You probably should patch because this is a real
vulnerability. Just how urgent you make that, I'll leave that
up to you. And if anybody has any feedback on Apache Roller,
how this particular CVSS score would be justified, let me
know. And then I have another story that really is nothing
that I usually cover, because it goes a little bit into
politics. Today, a letter from MITRE to the CVE board leaked
that apparently, as of tomorrow, MITRE's contract to
operate the CVE system may get discontinued, may no longer be
funded. What this really means? Well, we don't know
yet. It probably does not mean that CVE numbers all for a
sudden are going to go away. There are possibilities of
other funding sources, like from industry and such. The
CVE system itself is operated by MITRE for many years now, I
believe since its inception. However, it's backed by a
board of, well, large companies and other industry
organizations, some of them global, in order to support
the mission of CVE numbers and assigning vulnerability IDs.
So we'll see what happens. Just there may be at least
some temporary disruption in assigning CVE numbers. Well,
and this is it for today. So thanks for listening. Thanks
for recommending. Thanks for subscribing to this podcast
and talk to you again tomorrow. Bye.
