Hello and welcome to the Wednesday, January 28, 2026
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. Well, today's diary comes from one
of our undercredit interns, Fares Azhari, wrote about the
initial stages of romance scams. You probably received
some of these text messages yourself that look like they
were just misrouted. Someone typing the wrong phone number
and looking for an old friend. Well, this is just the start
of it. The goal here is to retain the interest of the
victim. That's the recipient of this text message. Get them
involved in a more elaborate conversation. And of course,
in the end, getting money out of them. Now, what Fares found
here is that there were likely multiple scammers involved
here impersonating the same individual. Also, the money in
the end, well, was apparently being extracted via crypto
coin scams. Fares, of course, didn't follow up on the actual
crypto coin scam, but let it be at that stage. The scammer
was, of course, no quiet insistence after investing
some time into the conversation to actually get
Fares then to take the next step, which didn't happen
here. A couple sort of comments on this. So first of
all, these scams are very common. Most people don't fall
for them. But sadly, ever so often, someone does fall for
these scams. And from what I have heard from people who try
to help victims is that it can sometimes be very difficult to
convince the victim that this is actually a scam. So that's
an added problem here. And I think it's probably also
related with the victim not really wanting to admit that
they fell for something that in hindsight was a very
obvious scam. The other thing that sort of made the news
ever so often is that the scammers here, which well are
essentially sort of call centers, aren't always
scamming voluntarily, but that there are also victims of some
sorts of human trafficking and such that are basically being
forced to conduct these scams. So a very complex case and
scam overall. And best thing, of course, is don't respond to
these scams. Well, maybe have some fun with them if you want
to do it and waste some time off yourself and the scammer.
But your time is probably more valuable than the time of the
scammer. Then we do have a patch for the patch for the
patch that was originally triggered by React to Shell.
Remember back in December, we were all worried about React
to Shell, the remote code execution vulnerability in
React server components. Well, that was patched relatively
quickly, but then there was a denial of service
vulnerability that wasn't completely patched. So that
was patched also, I think, around New Year. And now we
have another denial of service vulnerability that had to be
patched. So that's another sort of leftover of that React
to Shell. Again, it's only denial of service. So it's not
another React to Shell, but something you probably want
to, well, patch as you get around it. And OpenSSL
released updates at this time fixing one vulnerability in
more recent OpenSSL version. That's three and later that
may lead to code execution. Now I say here may and should
probably say it's probably not going to lead to code
execution. It's probably more going to be a denial of
service. But what's happening here is that we do have a
classic stack-based buffer overflow. This one is in the
CMS auth envelope data parsing. And this is something
that happens before sort of any signatures and so are
verified. So it's pre-auth occasion and could potentially
be exploited via SMIME messages. The actual
vulnerabilities of your classic buffer overflow, you
have these IV parameters, for example, that should have
fixed length. So that's the length of the buffer being
assigned. But then due to the fairly tricky sometimes ASN.1
encoding in these certificates, the key
material, well, you can actually specify a larger
length than the standard allows, which then leads to
that buffer overflow. So get it updated. But I don't think
too many systems are using OpenSSL version 3 yet. It's
still sort of a little bit newer. So if you don't use
that, you don't have a problem here. And like I said, the
exploitation is tricky because usually these stack-based
buffer overflows are reasonably well mitigated with
various compiler options and such. And then we got an
interesting Kubernetes issue. I call it, I don't call it a
vulnerability because Kubernetes calls this expected
behavior. What's happening here is if you're connecting
to the API and you have get permissions to connect to the
API and you set up a WebSocket. The problem is that
your permissions are only verified as you're starting
the WebSocket. Because with WebSockets, it's not like
normal HTTP. You no longer have individual requests. You
now have a connection. So with normal HTTP, you have to
authenticate and access control every single request.
With WebSocket, you really, if you do it right, only have to
basically authenticate and access control the user at the
beginning of the connection. However, the problem here is
that then later the user may send create or permissions
requiring create permissions, like for example, to the slash
exec endpoint, which does give the user access to execute
arbitrary commands on the kubelet. So that's the basic
risk here that if you are giving user limited permission
to the nodes proxy, then they can escalate their permission.
Really sort of more awareness item that you're aware of
this, that you know that what you're doing here by giving
these permissions as the advisory here notes. Well,
it's sadly sometimes needed for monitoring and such that
you do assign those permissions. So it may not be
that easy to further and accurately restrict those
permissions. Well, and this is it for today. So thanks for
listening. Thanks for liking. Thanks for subscribing to this
podcast and talk to you again tomorrow. Bye.
Bye.
