SANS Stormcast Monday Feb 17th: Fake BSOD; Volatile IPs; Postgresql libpq SQL Injection; OAUTH Phishing

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

previous

next

Fake BSOD; Volatile IPs; Postgresql libpq SQL Injection; OAUTH Phishing

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