SANS Stormcast Wednesday, April 30th: SMS Attacks; Apple Airplay Vulnerabilities

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

previous

SMS Attacks; Apple Airplay Vulnerabilities

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 Wednesday, April 30th, 2025
 edition of the SANS and Internet Storm Center's Stormcast.
 My name is Johannes Ullrich and today I'm recording from
 Jacksonville, Florida. Today I expanded a little bit on work
 that I already wrote about last Thursday's and thats attacks
 against SMS gateways and tools. Now on Thursday I
 talked particularly about attacks against Teltonika,
 networks, gateways. These are sort of standalone devices
 more or less that you can use to basically programmatically
 send SMS messages. But of course that's actually not
 what most people are using to send SMS messages. Most people
 are using some kind of API. API, Twilio comes to mind as
 one of the big ones offering these services. Broadband.com
 and a couple of other companies like this. So I went
 through our logs today to see what other ways I see how
 attackers are trying to attack these types of SMS gateways.
 And well, no big surprise here. I saw a number of
 different techniques being used here. First of all, well,
 WordPress. I sort of stopped of course talking a little bit
 about WordPress vulnerabilities. There are
 just so many about the plugins in particular. And turns out
 there are dedicated plugins that allow you to send SMS
 messages from WordPress. And these plugins of course are
 attacked. What we are seeing here in our data is mostly
 attempts to fingerprint WordPress sites to check if
 they're running one of these plugins. And then it's assumed
 that once they find that a particular site has this
 plugin installed, they will then actually attempt to
 exploit it. Now, there's also a couple of a little bit odd
 and broken scans here. Like these, yes, sort of WordPress
 scans. But notice that percent, percent, target,
 percent, percent. That's often left over when people sort of
 build these templates and then are not properly filling them
 in and dealing with them. But we also see plenty of scans
 for SMS API related configuration files. Like
 these ENV files that are often used to store environment
 variables that then contain access credentials for a
 particular SMS service. Focusing a little bit here on
 Twilio, not because they're particular vulnerable. But,
 well, they're sort of the big one here, particular for
 smaller sites that are sending SMS messages. And that's why
 they sort of keep showing up here. We also do have a couple
 sort of unique tools like this SMS.py script, for example.
 I've seen this actually being scanned for quite a bit. And
 then SMS underscore Bomber dot exe. That is a tool that's
 specifically designed to send SMS very quickly. It supports
 spreading them out across multiple different APIs and
 also across proxies. It comes actually with an interesting
 configuration file that has a list of various APIs it
 supports, including credentials for these
 respective APIs. I haven't tested them. I'm not sure if
 those credentials that they basically distribute via their
 Git repository are still valid. I doubt it. I consider
 them really more sort of sample credentials. And, of
 course, you have then to replace with credentials that
 you stole somewhere else. Also, some proxy attempts.
 Then, again, your SMS Bomber does support the use of
 proxies. So, we do have some scans of our honeypots where
 they're checking if our honeypot is a proxy that's
 able to then relay these requests to various SMS APIs.
 Overall, if you are sending SMS from your application,
 make sure you are protecting credentials. If these
 credentials get lost, first of all, you'll get stuck with a
 pretty substantial bill, probably. And then the number
 you are sending those texts from, well, that number could
 be marked as spam or fraudulent. So, you pretty
 much, if this happens, have to use a new number, which, of
 course, may be bad for a reputation and such if people
 already know that they expect messages from you from a
 particular number. Researchers from Oligo did find 23
 different vulnerabilities in Apple's AirPlay. Now, before
 you panic here, these vulnerabilities have been
 fixed. If your system is up to date, you should be good.
 AirPlay, if you're not familiar with it, it's Apple's
 protocol to stream audio and video to devices within the
 local network. And that's a little bit where the problem
 comes from. It's, as a protocol, designed to be used
 on the local network. And with that, well, it kind of lives
 in that illusion of having sort of a secure network
 environment. It does offer some authentication, but there
 is a substantial attack surface pre-authication, that
 protocol. And that's in part where the issue lies here in
 this vulnerability. The vulnerabilities have spanned
 the entire gamut from zero -click remote code execution
 all the way here to denial of service, where not all of the
 23 vulnerabilities, in particular denial of service
 vulnerabilities, did get a CVE number from Apple. So we have
 less than 23 CVE numbers in case you're counting. But
 there are a couple of different types of attacks. So
 first of all, of course, the most severe one is the remote
 code execution attack. It does not require user interaction
 as long as you do allow all devices from the local network
 to connect to your system. The second one here is then an
 attack against speakers and receivers that support the
 AirPlay protocol. This is a vulnerability that's sort of
 inherent to the software development kit that is used
 to implement this protocol. And then we also do have
 vulnerabilities in CarPlay devices. They are exploitable
 also in some cases via Bluetooth and, yes, USB. But,
 of course, that's probably the most difficult part here to
 actually exploit. One interesting part here is with
 the entire pairing process, in particular if Bluetooth is
 involved, there may be a pin code displayed on the device,
 which may be the screen in your car. And it's not
 unreasonable that someone being in close proximity to
 your car may be able to see that number and with that
 actually complete the authentication. Again, these
 vulnerabilities are patched. If you do want to take a look
 on your own Apple device in the AirDrop and HandOff
 settings, that's sort of where you find them. You can just
 turn off the AirPlay receiver. And if you do leave it turned
 on, you have the option to either only allow the current
 user, that's sort of your most secure mode here, or then
 anyone on the same network or everyone. AirPlay itself is
 exposed on port 7000. Yeah, so you may want to review your
 AirPlay settings. At least, like I said, limit them to
 current user, maybe turn it off altogether. Personally, I
 hardly ever see a reason to sort of stream video audio to
 like a laptop or something like this. It's really more
 meant for systems like Apple TV, and that's usually not
 something that you're moving around much to untrusted
 networks. Well, that's it again for today. Sorry for
 running a little bit longer today on the two individual
 stories. Hope you don't mind that too much. Well, if
 there's anything I should do different, if there's any
 story that I missed, please let me know. And that's it for
 today. Thanks for liking and recommending this podcast.
 Again, if you happen to be at the RSA conference, stop by at
 the SANS booth. And that's it. Talk to you again tomorrow.
 Bye.