Podcast Detail

SANS Stormcast Wednesday, March 4th, 2026: CrushFTP Brute Force; Android Patches 0-Day; 0Auth Phishing Abuse

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

previous
Podcast Logo
CrushFTP Brute Force; Android Patches 0-Day; 0Auth Phishing Abuse
00:00

Podcast Transcript

 Hello and welcome to the Wednesday, March 4th, 2026
 edition of the SANS Internet Storm Centers Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu undergraduate certificate program in applied
 cybersecurity. Today's diary is about, well, some brute
 force attacks against Crush FTP. Actually, I'm not sure if
 I should even call it a brute force attack. It's really more
 just looking for common default passwords. However, I
 just want to put a couple of things clear here. First of
 all, this is not a vulnerability in Crush FTP.
 There have been significant vulnerabilities in the past.
 This is not one of them. All they're looking for is for
 users who set up Crush FTP with an admin user of Crush
 Admin and a password of Crush Admin. I went through the
 setup of Crush FTP. And as you're setting it up, it
 basically asks you, hey, you know, what is the username you
 want to use for Crush FTP, for the admin user? In the
 documentation, Crush Admin is one out of a few that they
 recommend kind of that you use for a username. However, there
 is no default or recommended password. So really, if you're
 picking the password Crush Admin, it's on you. It's your
 mistake. It's nothing really that Crush FTP really did
 wrong here, other than maybe they should prevent some
 really stupid passwords like that. And today is also
 Android patch Tuesday. So with that, we got patches from
 Google for 140 different vulnerabilities. Noteworthy
 here is one vulnerability that affects the Qualcomm display
 drivers. And this particular vulnerability is already
 exploited in the wild. And well, it's one of those memory
 management issues. They have released a patch for it now
 with this update. So make sure that you're keeping your
 Android phones updated, even though it, as I always say,
 may take a while for these patches to actually show up
 for you, depending on what particular phone you have and
 what carrier you're using. When people talk about OAuth,
 they often get lost sort of in some of the little technical
 details, whether to use proof keys and the like. And while
 all of this is important, there's really sort of one big
 problem with OAuth. And that's user perception. Basically,
 how the user really perceives all these redirects and
 permissions and prompts and such they're being faced with
 as they're logging in via OAuth. Microsoft now
 documented a phishing campaign that takes advantage of some
 of that confusion. What they're doing is they're
 basically using the OAuth redirect URL. And what happens
 here is that the attacker is basically presenting a link as
 part of phishing email that links to a legitimate
 Microsoft website in this case, which is their OAuth
 endpoint. But of course, the rest of the OAuth
 authentication data is invalid. They do present a
 redirect URI. And well, what OAuth does is if it can't make
 sense of the request, it'll just send you back to the
 redirect URI, which then is the phishing page. Since the
 user originally clicked on something that was a valid
 Microsoft link, they are now much more likely to fall for
 the phishing attack because they may not necessarily
 revalidate the URL after all these redirects are done,
 which of course are usually invisible to the user. So the
 end effect here is that the victim is then being tricked
 into downloading malware from a website that's absolutely
 not affiliated with Microsoft. So your classic sort of
 malware style phishing attack. And then this malware does
 install various spyware credentials dealers or
 whatever the attacker came up with in this case. And just a
 reminder about something that I have covered here, I think
 last week, and that's Google API keys. It used to be that
 Google API keys weren't supposed to be secrets and
 that you could easily include them in JavaScript, in various
 Android or other apps on decline. That has changed
 since Google's AI offerings were released. And we now have
 victims that basically got stuck with bills of tens of
 thousands of dollars for exposing their API key. So
 please double check if you are exposing these API keys,
 either invalidate them or refer to Google's
 documentation on how to properly secure them. But yes,
 this is an ongoing issue. Thank you.