The link knows all.

Dave Bittner: Hello, everyone and welcome to the CyberWire's "Research Saturday." I'm Dave Bittner and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems and protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. [ Music ]

Muhammad Danish: The motivation behind this study was that private intended links are -- are more relaxed than the public endpoints of a website. So, it means that they have relaxed authentication and validation. Plus, they also lack security checks because there is an implicit trust that only the intended users will access the link. But we are all aware of the fact that SMS data gets leaked and it is not a secure channel. So, the websites should not trust, just based on the fact that they're sending the URLs or the links to a phone number and only the intended users will access them.

Dave Bittner: That's Muhammad Danish, PhD candidate at the University of New Mexico and lead author and cybersecurity researcher for the study, "Private Links, Public Leaks: Consequences of Frictionless User Experience on the Security and Privacy Posture of SMS Delivered URLs." [ Music ] Well, the paper talks about a frictionless user experience. What does that mean in practice and -- and why is it so important?

Muhammad Danish: Yes, so when we were disclosing our findings to the service providers, one of them mentioned that we wanted to have a balance between a frictionless user experience. It means that users prefer to click on the link and just be there without having to do like authentication, OTP codes or anything else. So, it makes the life easier for the users, but it also brings them at risk of their data getting leaked. And that is the balance, which is hard for the companies. And mostly what we have seen is that they prefer user experience, smooth user experience over security and privacy of the users and their services.

Dave Bittner: Well, let's dig into the core discovery here. I mean what did you all actually find when you started analyzing these SMS delivered URLs?

Muhammad Danish: So, we -- when we started with the SMS delivered URLs, we saw that they were exposing user PII and anyone with the link could see that information and harvest that. So, there were a few discoveries that we made. So, first you click on the link, you go to a web page and it's either static data, pre-filled form for a loan application, or you are directly logged into someone's profile. So, we wanted to see the root cause behind it. And most of these were due to misconfigured APIs or even using good practices or good tools in a bad way. For example, GraphQL is a solution for over-fetching, but when it's misconfigured, it doesn't work as intended. So, we have seen those cases too. So, I talked about over-fetching, but what over-fetching is that we initially were looking into just the data visible in UI, but while looking into the cause of the exposure, we saw that the network logs has additional PII, apart from what is visible or required in the UI. And that led us to further explore the URLs on the backend side too. And we -- interestingly, we saw that there were a lot of websites which showed user PII in the network logs but there was nothing in the UI. And while during a responsible disclosure, we were told that it's something they did years back and they forgot. It's like legacy code they forgot to update or they looked at the UI only but they didn't know that someone could also look into the network logs, even though anyone with a browser can see those logs.

Dave Bittner: What kind of personal information are we talking about here?

Muhammad Danish: So, there was a wide variety of personal information, but the more common were name, email address, phone number, addresses, because a majority of them were order pages or things like that. But then there were more severe ones. For example, there was -- there were multiple loan applications with your Social Security, your bank account details, credit score, date of birth, family details, you name it. Then there were also like, insurance codes. So, one of the examples that we discussed in our paper was from Evercode. So, you go there, you fill out an insurance code, you don't like the quote at the end, you leave it. Then you get a URL via SMS to click on that and continue your code. And you -- so, we got ahold of one of those URLs and we saw the user's prefilled insurance application with all the details. But the interesting part was that the part of the URL, the part that comes after like the.com/, that was pretty short and that was used to identify those applications. So, we changed like one character in that and we reached another user's insurance code. So, imagine doing that automatically using a simple Python script. You could enumerate millions of users' insurance codes with their personal information, including some of the sensitive details regarding them. And that company noted that they had like 30 million some insurance codes.

Dave Bittner: And -- and so, it really demonstrates how one leaked link could put other users at risk.

Muhammad Danish: Yes. So, yes. So, we only look -- so we couldn't get ahold of everyone's phones to see their SMS, so we used the public SMS gateways as a lens to look into this issue. And people could argue that it is the user's mistake because they used the public SMS gateways to sign up for these services. But when you can enumerate to other users too, then it is not just that user who's getting affected. It's all other users who never used SMS gateways or don't even know about those.

Dave Bittner: The research describes URLs as acting like credentials. Why is treating a link as proof of identity such a risky thing to do?

Muhammad Danish: Yes. So, as I mentioned, the SMS data gets leaked pretty frequently and SMS is an unencrypted channel. So, there's no guarantee that those links you send via SMS will only be received by the person you are sending to. And then we also noted that most of the links were active. Like, I think 46% of the links were active two years after they were sent. So, for example, if I register for a service, I go out of country or I change my phone number and that phone number is assigned to someone else, they still keep getting those SMS messages with the links, even though it is not me. So, that's one use case then. So, there are a lot of ways where the links you send via SMS can be obtained by other people, intentionally or unintentionally. [ Music ]

Dave Bittner: We'll be right back. [ Music ] The research talks about this notion of over-fetching, where the system returns more data than the user ever sees on the screen. Can -- can you describe to us what's going on there?

Muhammad Danish: Yes. So, basically when the front end of a website needs data, it -- it requests the backend mostly using an API. And for example, the one example that we discussed in the paper was from a delivery service. So, the order page only needed the address where it was delivered. But what the backend sent was all the metadata of the order, including the driver's name, phone number and the driver's car plate number. So, it is more damaging because in most of the cases during security reviews, these logs are not audited. So, they look at the UI. They see, "Oh, we are doing a good job. We are not leaking any additional PII or any additional information more than what we need." But when someone looks at the logs, they see a whole lot.

Dave Bittner: You mentioned, you know, the -- the potential for someone to spin up a Python script to just harvest these -- these -- this information sequentially or randomly. Are there any other ways that you considered in the research that attackers could take advantage of these weaknesses?

Muhammad Danish: Yes, so one way -- so, we have seen two types of like innumerable websites. So, some use like a short -- a random but a short token. And the security policies have clearly mentioned that you should have tokens that have at least 64 bit of entropy. But majority of the ones that we saw had less than that. And then there were worse cases where for example there was a quote, a shipping code and the shipping ID was 147 and the token was also 147. And when you do 148, you go to the 148th code and like that. So, that's one aspect we looked into. We didn't enumerate due to ethical reasons, but we did a small manual check of ten attempts and saw that there were no restrictions on that. The other thing that we saw that could have been enumerated but we couldn't do due to ethical reasons was that you click on the URL. They have some authentication. Like, they would say we have an authentication parameter. We saw an example of a pharmacy. I think pharmacy code or something. But they had date of birth as a authentication parameter. But if someone wanted, they could enumerate that even if they go with one second per attempt and they enumerate all hundred years like 1926 to 2026, they could do that in ten hours. And we know people can do much quicker than that, like shrinking the errors -- the possible errors based on possibility of the age and like doing much quicker attempts using botnets. But we did not do that due to ethical reasons as I mentioned.

Dave Bittner: How did the companies respond when you and your colleagues did a responsible disclosure here?

Muhammad Danish: Yes, so that was I think the hardest part of the research to get them to respond, mostly. So, initially the first issue we had was that we couldn't find a proper security page or vulnerability disclosure page. There were only a handful that had proper security or vulnerability disclosure page. And even among the ones that we had, they also had issues. So, one of them was using a key for encryption but that key expired three years ago. And then comes the ones that did not even had any security page. But for those, we tried connect -- connecting with them using their customer service emails and if they didn't respond, we then had to call them. And during our calls in one of the example, I called them. I talked to them for like 15 minutes with the customer service and at the end they didn't understand and neither directed me to someone who did understand and they said okay, we'll respond to your email. And I never heard back from that. And it is one of a big company. It's not like small service providers. And then the third stage was that there were companies which did not had any emails and even if they had emails, they were not working. So, that's like our part reporting and then hearing back from them, we only heard from 17 out of like more than 100 that we reported and 132 did not even respond. So, that's the issue. Like, so one of the companies that we just talked to on the phone they said that we didn't respond to the email because we get a lot of spam emails, spam security emails and we thought this is a spam too, even though that email had full detailed description of the issue including video of how we found the issue and how they can replicate it to confirm. But, still.

Dave Bittner: Yes, that must have been frustrating for you.

Muhammad Danish: Yes.

Dave Bittner: Well, what are the take homes then? I mean what -- what are your recommendations for both sides of the coin here? I mean, you've got the people who are the developers who are using these SMS links to send to their customers, ut then you also have the people who are receiving them. Do you have advice for both of those groups?

Muhammad Danish: Yes. So, first for the developers, the issue is not that we don't have any defined good practices for these things. Everything is there. But the issue is that they are not being studied by the developers or they are studied but not implemented. And these issues as I discussed are not in small companies. There are some big names in there too. And I agree, you can't be 100% secure, but there are things -- these are the things that are like simple and at least we should be able to cover these spaces. For the users, I think they should not give their like -- especially their sensitive information to websites that are not what can I say, the websites that are not well-established or like too secure. But I don't have a lot for the users because they can't guess even like big names.

Dave Bittner: It's hard to know ahead of time that this is what you're going to be sent, right?

Muhammad Danish: Yes. Yes, but --

Dave Bittner: Yes.

Muhammad Danish: -- the one thing that I saw for the users was that they could look into if it is too bad of a website, then they should not put in their information, especially the sensitive information because I've seen a lot of -- a lot of loan application, they're like one page websites and new websites or some random websites and people still filling up their personal details to get a loan quote or something. [ Music ]

Dave Bittner: Our thanks to Muhammad Danish from the University of New Mexico for joining us. The research is titled "Private Links, Public Leaks: Consequences of Frictionless User Experience on the Security and Privacy Posture of SMS Delivered URLs." We'll have a link in the Show Notes. And that's "Research Saturday," brought to you by N2K CyberWire. We'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you a step ahead in the rapidly changing world of cyber security. If you like our show, please share a rating and review in your favorite podcast app. Please also fill out the survey in the Show Notes or send an email to cyberwire@n2k.com. This episode was produced by Liz Stokes. We're mixed by Elliott Peltzman and Tre Hester. Our executive producer is Jennifer Eiben. Peter Kilpe is our publisher and I'm Dave Bittner. Thanks for listening. We'll see you back here next time. [ Music ]