Hello and welcome to the Thursday, April 3rd, 2025
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ullrich and today I'm recording from
Jacksonville, Florida. Our SSH Honeypots did pick up some odd
username-password combinations yesterday. Now there are a lot
of odd username-password combinations, but these sort
of crossed our thresholds, what we consider significant.
And looking at it further, it actually may be somewhat
interesting. The username that we are seeing, and this was
really just last week, was t128 and the password
128troutes. Turns out this is a Juniper product, actually
originally created by 128 Technologies. So that's where
the t128 and 128troutes part comes from. And this is now a
Juniper product, a part of their session smart networking
platform. This is one of the default passwords being used.
There's also root and then the same 128troutes password that
is being used here. It's not really clear why we saw sort
of this surge last week. There is always a little bit
scanning for this password combination, but sort of in
the single digits, nothing really that I consider
significant. Last week we had it sort of in the 20,000
attempts per day. So certainly way, way more, multiple orders
of magnitude more than what we usually see for this
combination. Now doing some Googling around this, I saw
some support forum posts where users apparently are having
issues disabling this password. So this is a well
-known password that you're supposed to disable per the
manual, but apparently this sometimes doesn't work quite
right. So double check and maybe add this combination to
your own internal SSH scans. Make sure that you have
nothing exposed that works with this username and
password combination. And then thanks to Evan Connelly for
writing up an interesting vulnerability that Evan found
in Verizon's API. Now, typically don't really sort of
talk a lot about vulnerabilities like this, but
in this case I think there's some lessons to be learned
from the vulnerability and beyond. So that's why I'm
covering it here. The vulnerability is actually
interesting because it's sort of a classic mistake that
people are making when they're doing authentication and
access control. The vulnerability in question here
affected an API that Verizon offers as part of its call
filtering service where a user may request a list of their
call history, basically sort of a log of their calls. In
order to do so, you connect to the API endpoint, you
authenticate with a JWT, which is not a bad idea. That JWT
then includes your phone number. So you would think,
okay, we're done. Pretty straightforward. Verizon just
takes the phone number from the JWT and returns your call
log for that phone number. Well, that's not exactly
what's happening. What we have in addition to the JWT is a
header that indicates what phone number you would like to
retrieve. And that header, of course, is not authenticated.
So Verizon reads the phone number from that header
instead of the JWT. And that, of course, allows an attacker
then to essentially authenticate for whatever
phone number they actually own and then use the JWT with the
header that actually indicates the phone number they would
like to receive logs for to retrieve anybody's call
history. Again, this only affected Verizon, but sort of
a very classic kind of vulnerability where you're
relying on non-digitally signed data like the header
instead of using the digitally signed data like the JWT in
this example. Verizon reacted appropriately here. Evan did
report it to them and immediately acknowledged the
report. And a month later when Evan checked in again, well,
the vulnerability was fixed. So good work here. No bug
bounty involved here as far as I know. Now, the other problem
to this is, of course, that, well, you know, what this
means is anybody's call history could have leaked. And
this is a general problem that has happened before where
providers like Verizon have offered web interfaces to
retrieve like SMS messages to retrieve call histories. And
then in these web applications or here the API, they had
vulnerabilities allowing for the data to leak. That's
something that you need to be aware of. And yet another
reason why you have to be a little bit careful with
trusting phone numbers, trusting SMS messages to stay
private. And yesterday I hinted that there was a Gmail
encrypted email story that I wasn't really sure about
covering, but well, it looks like it's right. And I think I
know now a little bit more why it makes sense and also the
issues. So the problem that Gmail is trying to tackle here
is end-to-end encrypted email. The big problem with email
messages is that while they usually are encrypted with TLS
as they traverse the internet, the end user doesn't really
have any control over that. So that's where end-to-end
encrypted email comes in, where I'm encrypting my email
in my email client before it's actually being sent to any
mail server. And then the recipient will decrypt it.
There are a couple of solutions for this. There's
PGP. There is SMIME. SMIME already being supported by
Gmail, but none of these technologies really has taken
off. And in part it is just a usability nightmare kind of to
try to explain to a non -technical user how to get
keys, how to get everything properly signed, and then also
how to verify that the signatures are correct and
such. So there are a couple of solutions now that are
basically doing everything transparent to the user in the
client. ProtonMail is probably the biggest one. They have a
Webmail client that then uses JavaScript to decrypt emails
on the client and the encryption keys themselves are
only stored encrypted on ProtonMail's servers. So that
way it's possible for them to encrypt the email using public
keys, but you will then in your browser decrypt a private
key and decrypt the email. All of this works pretty well. The
problem is now what if you send an email to someone not
within ProtonMail? Well, that's what Gmail here is
trying to address. I don't quite like the solution.
That's sort of where my problem was yesterday. It's a
very common solution, this problem, where if you're
sending an email from Gmail using this new sort of
encrypted email feature, the recipient will just receive a
link. The link will tell them, hey, there is email waiting
for you. Click on the link and then you'll be asked to log
into Google and you'll present it with a lower feature Gmail
client that allows you to read the email and I believe also
do simple things like respond to the email. So the big
problem I have with these kind of schemes is the link and
that, of course, is sort of a phishing attack waiting to
happen. Again, usability, user interface is a big part of
this. Now, they put some administrative controls around
this and this is at first at least being only rolled out to
Google workspace users. So basically companies that are
using Gmail and they're giving their IT administrators here
some control over making these measures to default or also
applying classification levels and such. Also some logging
and data loss prevention. So your IT management is still
able to access those encrypted emails. But it's another legal
problem in some ways for end -to-end encrypted emails.
Looks interesting. I'm still not quite happy with the
overall solution because it involves the links. I haven't
really seen anything better on the other hand. So let's see
if Google makes something work here where others certainly
have failed. Well, and this is it for today. So thanks for
listening and talk to you again tomorrow. Bye. Bye! Bye!
Bye! Bye!
