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.
