Hello and welcome to the Monday, February 17th, 2025
edition of the Science Internet Storm Center's
Stormcast. My name is Johannes Ulrich and today I'm recording
from Jacksonville, Florida. Well, we've got a couple of
diaries from this weekend to talk about. First one by
Xavier about interesting Python matter that displays a
blue screen of death. Well, actually, not the real one.
It's sort of an approximation simulation of one. Not 100%
sure why they're doing this. A couple possible reasons are,
first of all, tricking the user into rebooting the
system, which sometimes could, for example, activate some
payload. Also, there is an 800 number listed on the boot
screen, on that blue screen. I did call it earlier and it
went to some kind of depth collection agency. Not really
sure what it's all about. Could be that this used to be
used by some kind of tech support scam as well. Or as
Xavier suggests, maybe it's just a simple anti-debugging
technique. Well, in a second diary, Xavier is talking about
issues with volatile IP addresses. You hardly ever get
a static IP address, in particular for any kind of
consumer connection. And even if you have a static IP
address, let's say you co -locate a server, you rent
some kind of virtual server in a data center, well, you're
not going to hold on to this virtual server forever. And
that's sort of where the problem comes in. Xavier set
up a new infrastructure for a pen test, meaning he set up a
couple of proxies and systems like that on a newly deployed
virtual server. That IP address that was assigned to
that virtual server apparently had been used by another
organization in the past. And as a result, his
infrastructure now received these requests. This is an
issue that keeps coming up where, for example, some name
server records still point to IP address that are no longer
used by the particular entity. This often sort of goes
undetected because either that domain is completely unused or
the other name servers may still be working just fine.
And it's never really noticed that one of these name servers
doesn't really exist anymore. Really important to keep good
inventories as to what IP addresses you're using and be
agile here. So make it easy to change IP addresses. And this
is really the same also for IPv6, IPv4. IPv4 affects both
protocols because quite often you're dealing with these
ephemeral resources that you set up, use for a while, and
then tear down. Well, and then we have an interesting
vulnerability in Postgres, the SQL database. When I first
read sort of the headline, I thought, well, is this
actually a real vulnerability? Because the way it was sort of
described was a SQL injection vulnerability in Postgres.
That doesn't really sound like a vulnerability because if you
have access to Postgres, well, you can execute arbitrary SQL
commands. You don't necessarily need a SQL
injection. But the tricky part here is that Postgres, as part
of their supporting library, LibPQ, does provide a number
of functions to escape parameters. And these
parameters are not properly escaped if you're using these
built-in functions in LibPQ. And that's really the
vulnerability here. Exploitability is, I think, a
little bit questionable. It does require you to do a
couple of a little bit unusual things like creating commands
as input then for PSQL, the command line utility. Not
really how I would write queries like this, but I'm not
using Postgres that much. It has, however, already been
exploited. And late last year, we had the famous compromise
of Beyond Trust that then led to the compromise of a number
of government organizations. And apparently, this
vulnerability was sort of one of the key vulnerabilities
being exploited there. So certainly something that you
should update quickly if you are using Postgres and have
any systems like this exposed to the internet. But again,
this is this supporting library. So it's very possible
that a web application that uses Postgres sort of as a
back end, and I think that's kind of what happened here
with Beyond Trust, assumes that Postgres does the right
thing. And as a result, you're now vulnerable to a SQL
injection without any fault of the developer of the web
application. And then we have a good write-up from Welexity
about recent social engineering-based attacks
against OAuth. Now, OAuth is, of course, one of these fairly
complex authentication schemes often used to delegate
privileges to mobile applications, devices and the
like. And one of the complexities behind OAuth is
that there are a number of different authentication flows
that can be used in order to authenticate a device, an
application, a web service using OAuth. The
authentication flow that's being abused here, and
apparently by some Russian threat actors, is the device
authentication flow or device code authentication. This is
something that you often see in input-constrained devices
like smart TVs, and you probably have done it at some
point, where you try to connect an application, like
some kind of streaming application device to your
account. The streaming application is telling you,
hey, go to this particular URL, log in, and then provide
this device code, which often is just a fairly short alpha
-numeric code. Then the device is being logged in to the
particular account. Now, this scheme is not just used for
streaming applications, but also, for example, for more
sensitive things like video conferencing and such. And
that's apparently where it's being abused here. The
attacker is essentially trying to connect their device to
your account. They receive the device code. Now, they are
sending you a phishing email or an SMS, and that's
apparently the preferred method here, tricking you into
entering that device code into your account, associating the
attacker's device with your account. Interesting trick,
and like I said, it's really more a social engineering
phishing kind of trick. But keep in mind, OAuth itself is
not really phishing-resistant OAuth occasion. It really
depends on what you're sort of putting on top of that, how
you're actually authenticating to your OAuth provider, to
your authentication service here. And that's sort of being
exploited here. According to Vilexi, there's also sort of a
longer pretense usually happening here, where the
attacker first establishes some report with the victim
before they actually then launch the attack. Well, and
this is it for today. Thanks for listening. Thanks to
everybody subscribing to this podcast. It's available on all
of your favorite podcast platforms. Lately, I upped a
little bit the game on YouTube. If you enjoy sort of
more videos, something more visual with subtitles and
such, so you have that available. Still working on
adding some subtitles also to the podcast feed. So it's also
available on other platforms. Any feedback is welcome. And
as always, please recommend this podcast. Please leave
good reviews. And at the very least, ever so often, like
click the five stars and thanks. Bye.
