← SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)
SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)
SANS Stormcast Tuesday Feb 25th: Unfurl Updates; Google Ditches SMS; Paypal Phish; Exim, libXML, Parallels Vuln
00:06:10
SANS Stormcast Tuesday Feb 25th: Unfurl Updates; Google Ditches SMS; Paypal Phish; Exim, libXML, Parallels Vuln
Loading summary
Transcript1 lines
- [00:00]
A
Hello and welcome to the Tuesday, February 25, 2025 edition of the Sands and at Storm Centers Stormcast. My name is Johannes Ulrich 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 explaining hey, this is the page. These are parameters it for example recognizes if part 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 BlueSky 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 as 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 halftime 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 pretend emails from PayPal. The problem here is that when you're changing your mailing address with PayPal, PayPal will send you 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 DKIM, DMARC 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 often mention that in my web page and 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, vulnerability in XM the mail server. Now this is SQL injection vulnerability, which is a little bit odd for a mail server. Mail servers like XM optionally use SQL Database as a backend. And that's exactly what's happening here. If you're using SQLite as a backend for XM, 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 etern 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. 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 XM, 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 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 again for listening and talk to you again tomorrow. Bye.