Research Saturday 3.5.22
Ep 222 | 3.5.22

An abuse of trust: Potential security issues with open redirects.

Transcript

Rick Howard: Hey, everybody. Check out our new First Principles Guide to Cybersecurity. This guide goes through key CSO Perspectives podcast episodes, discussions, and essays that help you understand the challenges that security teams are faced with every day, and will lay out the fundamentals of topics that are universally and continually relevant to ensure that you are situationally aware and prepared for potential cyber events. Let the CyberWire help you along your path of professional development and continuing education on cybersecurity. Download the guide today at thecyberwire.com/firstprinciples.

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

Mike Benjamin: I think the most simple example we can all relate to is we go to the HTTP version of a website and then all of a sudden the browser lands us at the HTTPS version. Well, that's a redirect, right? The browser has sent you to a different place. The reason the browser knows to do that is actually the server has told it to do so. And so the URL redirection occurred server side and said, hey, you actually want the HTTPS version.

Dave Bittner: That's Mike Benjamin. He's Vice President of Security Research at Fastly. The research we're discussing today is titled, "Open Redirects: Real World Abuse and Recommendations."

Dave Bittner: Now, at the risk of taking us completely off the rails here before we even dig into the research, I have seen along the way my browser pop up with an error message that says "too many redirects." And what I've always assumed is that somehow I've been stuck in, like, an endless loop and the browser is interceding there to stop that. Is that typically what's happening in a situation like that?

Mike Benjamin: Yeah, that's a good assumption. In short, somebody wrote some bad JavaScript, is what most likely happened there.

Dave Bittner: (Laughs) OK, fair enough. Imagine that.

Mike Benjamin: Yeah, that never happens. You're right. The browser has some built-in mechanisms to protect itself from just going in redirects forever, and you never landing and causing CPU problems and things on your computer.

Dave Bittner: Yeah. Let's dig into some of the security potential here – the issues with redirects. And the research that you all published here really nicely walks through from start to finish, from the basics. So why don't we do the same here? Can we start off with some of the basic examples here of how somebody could use a redirect for bad things?

Mike Benjamin: Definitely. Everybody here has taken a security training, or at least seen one – I'm not sure everybody's taken it. And it teaches you to look at the domain you're about to click on the link of. You know, "bank[.]com," make sure it says "banks[.]com," not some bunch of other characters from another domain then "bank[.]com," or "bank[.]com" then other characters. We look, and we try to assess trust of a URL and we teach everybody, go look at that. And so, a redirect, as we described, you really did go to the right website, and then the right website told you to go somewhere else. And so we've taught the world to trust a domain, trust something they're going to.

Mike Benjamin: Meanwhile, if there's a redirect on that website, it can send you somewhere else. And so, if it's an intentional redirect, it's going to, like we said earlier, something the site wants you to. That's fine. That's great. You're going to the right place, but you've inherently – the user, as an end user or your customer, whoever it may be – they're giving trust to that domain to not send them someplace bad or not serve them a bad file. Well, if a redirect is present on the site where it can send you to a bad domain, bad URL, whatever it might be, well, that trust is kind of violated, right? We didn't teach the world to look at the URL parameters at the end of the URL way down there that says, wow, it's going somewhere else. We only taught people to look at the domain.

Dave Bittner: So, the redirect can actually be part of the – it can be embedded in that URL itself.

Mike Benjamin: Correct. Yeah. So the example of HTTP to HTTPS is an easy one. Server administrator put something server-side that says, everybody who goes here, go there. However, when somebody has written, say, a lightweight PHP application, put it on their site, they want URL parameters to drive where it's going to go. And so in that situation, if a bad actor were to send you something that is your "good domain dot com" with a redirection to "bad domain dot com" as a URL parameter, if that PHP app lets you do that and happily tells your browser, hey, go to the other place, that's where that sort of abuse of trust occurs.

Dave Bittner: And in a situation like that, would I would my browser even make a stop at the good URL, or would it just immediately go to the bad one?

Mike Benjamin: Well, it depends. And so, we've described three different classifications of URL redirection in the research. And so, the first one we describe is what you just said – you see nothing. And that's typically done in an HTTP protocol level. So you get a 300 message, typically a 301 redirect that says, go here. And it occurs at the HTTP level – your browser doesn't need to load anything else, it just moves on. And so that would be completely transparent. You don't even see it.

Mike Benjamin: The next class we've described is one that typically is going to be in HTML or JavaScript, where there's a delay. And so it's going to actually load the entire site. Sometimes it might even pop up and tell you what it's going to do, sometimes it might not. And then you get redirected without human intervention. You didn't require the user to collect – you didn't require a user to do anything.

Mike Benjamin: And then the third class is where it says, hey, you're about to go to a site, only click if you trust it. It doesn't do anything unless you click it. And we categorize the first two as a risk, and the third one, if you have to do URL redirection, it's probably the right way to do it.

Dave Bittner: Well, let's dig into some of the abuses that you all track here in the blog post. You start off with phishing.

Mike Benjamin: The tried-and-true place threat actors start. So, we all know that emails are one of the most popular ways to deliver whatever. What if you got an email that said, go to this URL, and you looked at it and inspected it and it was the right place at the beginning, but it really sent you to a phishing page. You're more likely to trust that site, because you actually did inspect it, you actually did look at it, and enter your credentials. So, that's probably the lowest hanging fruit method, is just abuse the trust to land at a phishing page, an exact replica of the login page, and phish credentials through the URL redirect occurring on the real website.

Dave Bittner: And just to be clear here, and I apologize for – if I'm seeming opaque, but in this case, as you say, if I go ahead and inspect it – and let's just use, like, you know, I don't know, Google or Microsoft, you know, a trusted, well-known name – that could be in the URL, but the redirect is also part of the URL. And so when I click on that, I'm going to go right to the bad place.

Mike Benjamin: Right. So, functionally, what's going to happen is you're going to go to the good place... 

Dave Bittner: Yep. 

Mike Benjamin: ...And you're going to pass it a parameter as part of the URL, you're going to pass it that argument that says, hey, the redirect should go to this bad website. The application on the remote end is going to parse that and then send back to you, hey, thank you for your request, please now go to this other site. And now your browser happily listens to the good site, and goes to the bad site. So that's why that onus is on the good site developer to not implement this kind of action, because it abuses that relationship.

Dave Bittner: I see. So if I am the owner of the good site, can I be a good Samaritan here and build my site in such a way that it's not going to be possible to do this sort of thing?

Mike Benjamin: We hope you do, Dave. We really do. 

Dave Bittner: (Laughs)

Mike Benjamin: So, the right way to think about it is, the most simple is don't take any input, right? This is back to the basics of any sort of application development – if you can avoid user input, avoid it. So if you know it should just always go somewhere, just hard-code it. Don't take it as a variable. Don't take it as user input. The second would be to create a static list of what you know you should want to go to. You will only go to this subset of places, right? Validate the input, ensure that it's going to be exact right place. And really, the last choice is to require the end user, their browser, to click something to finally get to the last place. Tell them, this could be bad, to only do this if you trust it, and then make them do something. And so that would be the last option if you have to do it that way.

Dave Bittner: I see. I see. Yeah, and I think most of us have seen that sort of thing where something will pop up and say, hey, we're not sure about this, but, you know, beyond here, dragons be, so you're on your own.

Mike Benjamin: Absolutely.

Dave Bittner: Yeah. Well, let's dig into the second one you list here in the blog, and that's malware. How does that come into play?

Mike Benjamin: Well, I think we've all been sent to a URL at some point where our browser immediately downloads the file of the link destination, whether that be a PDF or an Excel document or a P32 executable, right? Whatever it may be, if that redirect is actually directly to a malicious file, we're going to download it to our computer and we may open it, right? This how a lot of malware is still distributed. And so, whatever that end file may be, it could be a redirect to an actual piece of malware that you're being sent to. And again, this all comes back to an abuse of trust. That file, just from your perspective as the user, if you didn't provide any interaction to get it, you think it actually came from the good website, and you're much more likely to open it, interact with it, whatever it may be as a result of that. 

Dave Bittner: I see. And then you also outline here issues with cross-site scripting. What's going on with that?

Mike Benjamin: The redirects we just talked about in the last two examples are going to a web server. So there's a website and it's delivering you a file, a page, whatever it may be. In the cross-site scripting example, you're just specifying another URL. Now, this URL starts with JavaScript instead of HTTPS or whatever, but the browser knows how to execute JavaScript URLs. And so, being able to actually inject scripting into the redirect obviously opens you up to an entirely other class of vulnerabilities as it relates to cross-site scripting.

Mike Benjamin: Now, there's one nuance here that's important. The 301 redirect that place where it's done at an HTTP level – all the modern browsers will not pass the JavaScript response there, so that's really good. There's that built-in mechanism. But if we go to that second class of redirect where it's actually in the page and it tells you about it before it does it, those aren't done as an HTTP redirect. They're done in JavaScript or HTML. Well, the browser needs to parse JavaScript when it's in the page, and it will then parse that JavaScript and execute it as a part of the redirect. And so that's how you open it up into cross-site scripting.

Dave Bittner: There's another thing that you all outlined here. You found some interesting things on GitHub. Can you take us through what you describe?

Mike Benjamin: Yeah. And this was really the impetus for why we wrote the research and the article, was this not a new class of vulnerability. This something that's been around for a long time. But there's new application developers all the time, and I'm sure people are still implementing this sort of problem today, so it's good to remind folks.

Mike Benjamin: But more importantly, during one of our hunts, we came across a GitHub repository that contained about three-thousand unique redirects. And so the person behind this was clearly not actually going after those three vulnerabilities we just talked about – or three attack types that we just talked about – but they were actually doing SEO manipulation. They were trying to pump up the value of domains, doing marketing things. So what we found was just these giant lists of those three-thousand URLs repeated over and over again for each of the domains they were trying to manipulate.

Mike Benjamin: And so, while going through that, there's a couple things that were interesting. First off, thank you to GitHub for removing the repository when the abuse was reported, almost instantly. But also, the redirects in a lot of cases actually were in bucket three, which was really good. They required the click through. But there was still a substantive amount that had zero interaction whatsoever, that were still live nine-plus months after they'd originally been published into the repository.

Mike Benjamin: And then the last thing that I think was particularly interesting was the URL structure. Now, many of us in the security world are used to doing threat hunts against highly obfuscated things and hidden things and stuff that's hard to find. The nice thing about this type of vulnerability is it was likely put there by accident by a developer. And developers name things in ways they want you to find and want you to see. So in the URL structure of these thousands, we found really obvious things that would stand out to all of us security people, things like "reader.php" and "external URL" and "go to URL." So the arguments in the application names and the file names all contained things that should make us all think, oh, this might be a redirect, I should pay attention to that.

Dave Bittner: (Laughs) Big blinking neon signs in the code, right?

Mike Benjamin: Absolutely.

Dave Bittner: Might as well have used the blink tag. So, let's talk about best practices then. I mean, in terms of, you know, from a user's point of view, protecting themselves against this. But also on the developer's side, what are some of the best ways to protect ourselves here?

Mike Benjamin: Well, I think the first place to think about is on the developer side. So, if I'm a reputable brand name and I have deployed a reputable application and I have reputable users, I really need to think long and hard about including this kind of application within my site. We all know it's hard to validate inputs. It's hard to do these things. And so should we even go down that journey and even implement this kind of application in the first place? The thing that can be done, though, of course, if we must, is that ability to say, user must interact. The blink tag, right? You need to know this could be bad, are you sure you want to do it? It makes people think twice about what they're about to do, or at the very least, makes them realize that they maybe shouldn't trust what comes next. And so that file download, they're less apt to click on, the form that asked for their credentials, they're less likely to fill out, things like that. And so that particular interaction is a positive one.

Mike Benjamin: To your question on what should the user do, this is hard. It really is. Thankfully, you're going to find that some attackers are lazy, because we find that in every attack we ever see, and the fact there's another URL at the end might stand out when you look at a URL you're about to click. So give it a glance. Maybe don't just look at the domain name. Now, that's easy for us in the security field to say. A little bit harder for training your average user.

Mike Benjamin: However, the non-lazy attacker there could do a number of URL obfuscation things that makes it to the point where, are we really going to deobfuscate every single URL we ever see? I think that's maybe not a reasonable thing. And so, putting it back on the developer, on the owner of the site, the business, whoever is hosting that application, is really the right answer.

Dave Bittner: Is there anything that, you know, folks should be setting preferences in their browsers to help tamp some of this down? Or is this just one of those things where, you know, something that can be used for good and is a necessary part of the infrastructure that makes the web work, can also be used for bad?

Mike Benjamin: Yeah. As it relates to a 301 or even an HTML refresh, those are things that occur so much on the web, trusting them or not trusting them is a bit of a difficult thing to recommend. There are some plugins that I know folks use that block all third-party JavaScript, even, you know, NoScript for some of the first-party JavaScript. And there are things that block refresh, but they make the web very difficult to use, and so they're not really commonly used.

Mike Benjamin: The one thing I maybe didn't mention that a user could do is, when you do get to the site and it asks you for your username and password, maybe glance back up and make sure it's still the site you thought you went to. And when you get the file, glance back up, right? Do that extra check. That's something an end user could do. But it's a bit difficult to recommend that they hamper the ability of their browser that heavily by disabling those things.

Dave Bittner: Yeah. You know, I have to say, I think what I really appreciate about this blog post that you all put out is that I think a lot of people will look at this, and as you say, this not a new thing. And I would imagine there are a fair number of security folks who are listening who are kind of like, well, yeah, sure, I know about this. But to me, this one of those things that it's worth revisiting because, you know, not only is it good to refresh your knowledge about this, but you never know, hearing someone else explain what's going on can lead to new insights and new understanding.

Mike Benjamin: Absolutely. And I think, you know, personally, as went through this, some of the exact nuances to the cross-site scripting side were things I got to learn. And so, going through this, even as myself, somebody who's well aware of URL redirects for many years, it's always fun to learn when you go through and write something to that level of depth with your teammates.

Dave Bittner: Our thanks to Mike Benjamin from Fastly for joining us. The research is titled, "Open Redirects: Real World Abuse and Recommendations." We'll have a link in the show notes. 

Dave Bittner: The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Elliott Peltzman, Tre Hester, Brandon Karpf, Eliana White, Puru Prakash, Justin Sabie, Tim Nodar, Joe Carrigan, Carole Theriault, Ben Yelin, Nick Veliky, Gina Johnson, Bennett Moe, Chris Russell, John Petrik, Jennifer Eiben, Rick Howard, Peter Kilpe, and I'm Dave Bittner. Thanks for listening. We'll see you back here next week.