CyberWire Daily - An abuse of trust: Potential security issues with open redirects. [Research Saturday]

Episode Date: March 5, 2022

Guest Mike Benjamin, VP of Security Research at Fastly, joins Dave Bittner to talk about the Fastly Security Research Team's work on "Open redirects: real-world abuse and recommendations." Open URL redirection is a class of web application security problems that makes it easier for attackers to direct users to malicious resources. This vulnerability class, also known as “open redirects,” arises when an application allows attackers to pass information to the app that results in users being sent to another location. That location can be an attacker-controlled website or server used to distribute malware, trick a user into trusting a link, execute malicious code in a trusted way, drive ad fraud, or even perform SEO manipulation. Knowing how an open redirect can be abused is helpful — but knowing how to design around it in the first place is even more important. Mike walks us through what his team uncovered, explains how redirects are used, how they can be abused, and how you can prevent that abuse. The research can be found here: Open redirects: real-world abuse and recommendations Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. of you, I was concerned about my data being sold by data brokers. So I decided to try Delete.me. I have to say, Delete.me is a game changer. Within days of signing up, they started removing my personal information from hundreds of data brokers. I finally have peace of mind knowing my data privacy is protected. Delete.me's team does all the work for you with detailed reports so you know exactly what's been done. Take control of your data and keep your private life Thank you. JoinDeleteMe.com slash N2K and use promo code N2K at checkout. The only way to get 20% off is to go to JoinDeleteMe.com slash N2K and enter code N2K at checkout. That's JoinDeleteMe.com slash N2K, code N2K. 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 threats and vulnerabilities, solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. 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 redirections occurred server side and said, hey, you actually want the HTTPS version. 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. And now, a message from our sponsor, Zscaler, the leader in cloud security.

Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security. Zscaler Zero Trust Plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement,

connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com slash security. 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. Is this and what I've always assumed is that somehow I've been stuck in a like an endless loop and the browser is interceding there to stop that. Is that typically what's happening in a situation like that? Yeah, that's a good assumption. In short, somebody wrote some bad JavaScript is what most likely happened there. Okay, fair enough. Imagine that. Yeah, that never happens. So 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. 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? 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, look at the domain you're about to click on the link of. We all see, you know, bank.com. Okay. Make sure it says bank.com, not some bunch of other characters from another domain than bank.com or bank.com than other characters. We look and we try to assess trust of 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 the right website told you to go somewhere else. to go somewhere else. And so we've taught the world to trust a domain, trust something they're going to. 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 as a user, as an end user, 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. So the redirect can actually be part of the, it can be embedded in that URL itself. Correct.

Yeah. So the example of HTTP and HTTPS is an easy one. Server administrator puts something server side and says, everybody that goes here, go there. However, when somebody has written, say, 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.com with a redirection to bad domain.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. And in a situation like that, would my browser even make a stop at the good URL or would it just immediately go to the bad one? And so the first one we described is what you just said. You see nothing. And that's typically done at an HTTP protocol level. And 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 just moves on. And so that would be completely transparent, you don't even see it. 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

click. You didn't require the user to do anything. 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. Well, let's dig into some of the abuses that you all track here in the blog post. You start off with phishing. 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. And 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. 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,

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. Right. So functionally, what's going to happen is you're going to go to the good place. Yep. 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 reader actually 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. 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?

We hope you do, Dave. We really do. So the right way to think about it is the most simple is don't take any input, right? This is back to, you know, 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 the exact right place. And really the last choice is to require the end user at 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. 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. Absolutely. 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? 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

is 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, it 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. I see. And then you also outline here issues with cross-site scripting. What's going on with that? 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. 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 parse 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. There's another thing that you all outline here. You found some interesting things on GitHub. Can you take us through what you describe? Yeah, and this was really the impetus for why we wrote the research in the article, was this is not a new class vulnerability. This is 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. But more importantly, during one of our hunts, we came across a GitHub repository that contained about 3,000 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 3,000 URLs repeated over and over again

for each of the domains they were trying to manipulate. 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. 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 URLs, the arguments in the application names and the file names all contain things that should make us all think, oh, this might be a redirect. I should pay attention to that. So that was really good news. Big old blinking neon signs in the code, right? Absolutely. 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? Well, I think the first place to think about is on the developer's side.

is to think that 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. Put 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 asks for their download, they're less apt to click on the form that asks

for their credentials, they're less likely to fill out things like that. And so that particular interaction is a positive one. 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. 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's hosting that application is really the right answer. business, whoever's hosting that application is really the right answer. Is there anything that folks should be setting preferences in their browsers to help tamp some of this down? Or is this just one of those things where 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? 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 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. 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. 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 is 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 is 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, you're hearing someone else explain what's going on can lead to new insights and new understanding. Absolutely. And I think, you know, personally, as we 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 redirection for many years, 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. 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. Cyber threats are evolving every second, and staying ahead is more than just a challenge.

It's a necessity. That's why we're thrilled to partner with ThreatLocker, a cybersecurity solution trusted by businesses worldwide. ThreatLocker is a full suite of solutions designed to give you total control, stopping unauthorized applications, securing sensitive data, and ensuring your organization runs smoothly and securely. Visit ThreatLocker.com today to see how a default- default deny approach can keep your company safe and compliant. 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 Elliot Peltzman, Trey Hester, Brandon Karp, Eliana White, Puru Prakash, Justin Sabey, Tim Nodar, Joe Kerrigan, Kirill Terrio, Ben Yellen, Nick Vilecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick, Jennifer Iben, Rick Howard, Peter Kilpie, and I'm Dave Bittner. Thanks for listening. We'll see you back here next week.