SANS Stormcast Tuesday Feb 25th: Unfurl Updates; Google Ditches SMS; Paypal Phish; Exim, libXML, Parallels Vuln

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

previous

next

Unfurl Updates; Google Ditches SMS; Paypal Phish; Exim, libXML, Parallels Vuln

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

New Discussions closed for all Podcasts older than two(2) weeks
Please send your comments to our Contact Form

Podcast Transcript

 Hello and welcome to the Tuesday, February 25th, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich and today I'm recording from
 Jacksonville, Florida. Quick diary from Jim today about an
 update to Ryan Benson's tool Unfurl. Unfurl at first sounds
 pretty straightforward and simple. It takes a URL, takes
 it apart into its components. Now that itself can be a
 little bit complex. URLs can come in many forms and shapes
 but Unfurl goes beyond just sort of you know explaining
 hey this is the page, these are parameters. It for example
 recognizes if part of the URL is a timestamp and then will
 convert it. So really handy if you try to understand what the
 URL is all about. The latest update fixes a couple bugs in
 the software but also adds support for blue sky URLs. And
 according to an article in Forbes, Google is moving away
 from SMS as a second factor as an option for its Gmail
 service and other similar Google services. Now Google of
 course has been pushing passkeys and has sort of been
 pushing people away from SMS for a while. But this push
 will not become stronger in the sense that SMS will no
 longer be supported at all or phone calls for that matter.
 Another option that Google is offering is sort of an app
 based authentication scheme where you scan a QR code on
 the website using a phone that's already logged in to
 Google's services. So that way you are confirming your
 account. App based systems have had a little bit of bad
 rep because many of them were sort of either very simplistic
 where you just had to press a button in order to log in.
 Others like Microsoft had this little bit cumbersome sort of
 number scheme. You have to enter a number and you have to
 make sure that you stay authenticated while you do all
 of this and half time it fails. But Google sort of
 tries to find a little bit in between solution here that's
 user friendly in the form of a QR code. Nothing really to
 enter but still provides the security to counter
 authentication fatigue where you just press a button and
 are tricked by the attacker into pressing that button for
 the attacker. And Bleeping Computer came across an
 interesting scam that phishers are using in order to portent
 emails from PayPal. The problem here is that when
 you're changing your mailing address with PayPal, PayPal
 will send an email and that's not a bad thing. You probably
 want to be notified of that. But the attacker then uses a
 part of the address as a message to the victim. So the
 way this works is that you will receive a message from
 PayPal. It's authentic from PayPal. It does validate all
 of the checks like the Kim, the Mark and the like and SPF.
 But the attacker then changed part of the address, part of
 the new updated address to a message that states, hey, you
 just purchased a MacBook for a lot of money. And if you think
 you didn't do that, please call that 800 number or click
 on that link, which then turns out to be a tech support scam
 or some kind of phishing malware site that you're being
 tricked to click on. Interesting attack. And I
 would believe it's probably possible with other sites as
 well where an attacker can trigger an email to an
 arbitrary email address where the attacker is able to modify
 a good part of the body of the email, like in this case, the
 address. And of course, I've mentioned that in my web
 application security classes that validating addresses is
 one of the more difficult things because yes, there is a
 lot of possibilities here. It's hard to because of
 constraint, what strings someone may enter into an
 address field. And then we have a couple of
 vulnerabilities to talk about. First of all, a vulnerability
 in Exim, the mail server. Now, this is SQL injection
 vulnerability, which is a little bit odd for a mail
 server. But mail servers like Exim optionally use SQL database
 as a backend. And that's exactly what's happening here.
 If you're using SQLite as a backend for Exim, then you may
 be vulnerable if you have the ETRN, the extended turn
 command enabled, which as far as I know, is usually enabled
 in mail servers. It's sort of one of those convenience
 options that just tells a mail server that's trying to
 deliver some email to you that you're willing to accept,
 well, all email they have for you sort of in one connection.
 So it makes things a little bit more efficient. But the
 real problem here is there's an optional argument for the
 ETRN command if the client that's connecting to your
 server chooses to use it. And that's where the SQL injection
 happens. It's a very straightforward SQL injection.
 A proof of concept is already available and could open up
 all data that's stored in the SQLite database. Again, that's
 for SQLite. So if you're using that with Exim, then you may be
 vulnerable. And for any Mac users out there using
 parallels for virtualization, there is an unpatched
 privilege escalation vulnerability. Details were
 disclosed last week, may have mentioned it last week, don't
 quite remember, but I'll add the link to the blog post with
 details to the show notes again. Well, and this is it
 for today. So thanks for listening and talk to you
 again tomorrow. Bye.