Podcast Detail

SANS Stormcast Thursday Apr 3rd: Juniper Password Scans; Hacking Call Records; End to End Encrypted GMail

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

previous
next
Podcast Logo
Juniper Password Scans; Hacking Call Records; End to End Encrypted GMail
00:00

Surge in Scans for Juniper “t128” Default User
Lasst week, we dedtect a significant surge in ssh scans for the username “t128”. This user is used by Juniper’s Session Smart Routing, a product they acquired from “128 Technologies” which is the reason for the somewhat unusual username.
https://isc.sans.edu/diary/Surge%20in%20Scans%20for%20Juniper%20%22t128%22%20Default%20User/31824

Vulnerable Verizon API Allowed for Access to Call Logs
An API Verizon offered to users of its call filtering application suffered from an authentication bypass vulnerability allowing users to access any Verizon user’s call history. While using a JWT to authenticate the user, the phone number used to retrieve the call history logs was passed in a not-authenticated header.
https://evanconnelly.github.io/post/hacking-call-records/

Google Offering End-to-End Encryption to G-Mail Business Users
Google will add an end-to-end encryption feature to commercial GMail users. However, for non GMail users to read the emails they first must click on a link and log in to Google.
https://workspace.google.com/blog/identity-and-security/gmail-easy-end-to-end-encryption-all-businesses

Podcast Transcript

 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!