A Jira vulnerability that’s leaking data in the public cloud.

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

Dave Bittner: [00:00:25] And now a quick word about our sponsor, Juniper Networks. NSS Labs gave Juniper its highest rating of "Recommended" in its 2019 Data Center Security Gateway Test. To get your copy of the NSS Labs report, visit juniper.net/SecureDC or connect with Juniper on Twitter or Facebook. That's juniper.net/SecureDC. And we thank Juniper for making it possible to bring you Research Saturday.

Dave Bittner: [00:00:57] And thanks also to our sponsor, Enveil, whose revolutionary ZeroReveal solution, closes the last gap in data security: protecting data in use. It's the industry's first and only scalable commercial solution enabling data to remain encrypted throughout the entire processing lifecycle. Imagine being able to analyze, search, and perform calculations on sensitive data, all without ever decrypting anything – all without the risks of theft or inadvertent exposure. What was once only theoretical is now possible with Enveil. Learn more at enveil.com.

Jen Miller-Osborn: [00:01:38] This type of vulnerability short-circuits logins, essentially. It lets the attacker abuse trusted relationships between applications and the servers that are hosting them.

Dave Bittner: [00:01:47] That's Jen Miller-Osborn. She's Deputy Director of Threat Intelligence for Unit 42 at Palo Alto Networks. The research we're discussing today is titled, "Server-Side Request Forgery Exposes Data of Technology, Industrial, and Media Organizations."

Jen Miller-Osborn: [00:02:03] So, when an attacker can craft the URL that the server is sending a request to the application, they can force it to look wherever they want within an environment, basically. So they're able to almost basically have full access to an internal environment – especially cloud environments, are especially dangerous for this because of the way they are structured with the metadata API. And essentially, what this ends up allowing an attacker to do is use internal resources, which typically don't take requests from outside the internal environment, are now accessible because attackers able to already be in that internal environment, and they can query those internal things directly. It's almost like the internal API now becomes accessible directly from the Internet...

Dave Bittner: [00:02:49] Hmm.

Jen Miller-Osborn: [00:02:49] ...Which is exactly what you don't want to have with any sort of API at all, but that's what this vulnerability allows to happen, is that kind of connection between the attacker and the internal resources.

Dave Bittner: [00:03:00] And the vulnerability is because of a bug somewhere along the lines?

Jen Miller-Osborn: [00:03:05] Yep, it's just a web application vulnerability. And it's relatively common in a number of APIs, because it's just taking advantage of trusted relationships which are common especially inside an environment where the architects were already assuming that those internal devices were protected, essentially, and they were not – things could not come at them from the Internet. So this vulnerability allows that to be – that protection to be removed basically, and now all of a sudden these internal devices, someone can actually query and get data from, even though they're exploiting what is usually an advantage to speed things up within a network, and they're abusing those trusted relationships for malicious purposes. So it was something that was architected intending to be good for the system performance and the application performance, but unfortunately it is also something that can be exploited by attackers.

Dave Bittner: [00:03:55] I see.

Jen Miller-Osborn: [00:03:55] Which you see in a lot of types of attacks, right? It's not a supply chain attack, but it's exploiting the same kind of thing. They're assuming trust relationships where they can use them to get access to data they wouldn't normally get access to.

Dave Bittner: [00:04:09] And so, this sort of thing is used for getting data out of a system as opposed to, for example, writing code.

Jen Miller-Osborn: [00:04:18] Yes. This is more for taking data out. What they're able to query, they can get code depending on how it is stored. So they're accessing whatever is with that particular metadata API at that time, which can be anything from network configurations, credentials, and even source code. So it is possible, depending on the metadata that is within a particular API, that the attackers could get a company's – or some sort of application source code. They can get all the internal network configurations, they can get all sorts of credentials, which basically gives them access to do whatever they want. They know what the network looks like and they now have your legitimate credentials. So, it's a nightmare scenario for any defender.

Dave Bittner: [00:05:03] Now, one of the things you outline in the research here is that there's an issue with URLs not being properly sanitized. Can you walk us through what's going on there?

Jen Miller-Osborn: [00:05:14] Again, it's a bit of abusing the trust relationships. So, the systems are assuming that the request that's going to be coming from this trusted endpoint is going to be valid, basically – it's not going to be malicious. But the problem is when an attacker gets in, they are then able to abuse that trust relationship and redirect the response. So if they're querying for – say they're looking for some sort of internal data, like network configuration or credentials – instead of that reply being sent back to the actual server that made it internally, which is what the system thinks is happening, the attackers are actually able to redirect it to go to wherever they want, basically. So they can redirect that data from its intended internal – where it should have gone –they'll redirect it to something they're controlling instead, and that's how they'll get access to the data. You can see there's – it's actually easier to see visually. We have an example in the blog where you can see where they add the redirect to it.

Dave Bittner: [00:06:18] So, how prevalent is this? In the scanning that you did, how big an issue are we talking about here?

Jen Miller-Osborn: [00:06:24] So, we found seven thousand instances that seemed to be exposed and vulnerable to this. We did not go any further than scanning them to double check. That was unfortunate. I mean, seven thousand is a lot. And they were spread across a number of different public clouds.

Dave Bittner: [00:06:43] And there are patches available?

Jen Miller-Osborn: [00:06:45] Yes. This is something that could be taken care of. And actually, it's not even so much of a patch – it's the shifting by the cloud providers themselves to not allow this sort of HTTP URL redirect, in that particular instance. But there's also a separate patch itself.

Dave Bittner: [00:07:05] But I guess one of the lessons here is that there's a lot of systems that go unpatched for a variety of reasons. 

Jen Miller-Osborn: [00:07:12] Mm-hmm. And there's systems that sometimes get set up that are then forgotten about or not properly maintained, and they just kind of sit on the Internet for a long period of time. And in some cases the organizations don't even have them listed as assets anymore, which is one of the reasons we try to do these sorts of research. And then when and if we can actually identify people, we let them know so they can remediate it. And if nothing else, we try to make sure we can get the data out there just so hopefully this prompts people that may not have patched an instance in a while to kind of go take a look and see what's going on and see if they need to upgrade.

Jen Miller-Osborn: [00:07:50] One of the things for this we noted – Azure actually isn't vulnerable to this because it blocks SSRF requests, and we're seeing more of the cloud providers are also moving to that same protection. They're just not allowing that to happen environment at all.

Dave Bittner: [00:08:04] So, let me just get really basic with you here and walk through it together. I mean, if I was a bad guy out there trying to take advantage of this, and I'm doing my own scans and I'm finding systems that are potentially vulnerable. You know, a system pops up that is vulnerable, I think it's interesting, and I'd like to get inside. What do I do next to – how do I execute my my evil plans?

Jen Miller-Osborn: [00:08:26] You just start trying to send crafted URLs to the vulnerable devices to see if they work.

Dave Bittner: [00:08:32] Hmm.

Jen Miller-Osborn: [00:08:35] It's one of those things where it's relatively automated, in a sense, where it has a specific pattern. So once they've identified that it's vulnerable, then they can actually start trying to exploit that vulnerability... 

Dave Bittner: [00:08:47] I see.

Jen Miller-Osborn: [00:08:46] ...Which is not particularly difficult to exploit, unfortunately.

Dave Bittner: [00:08:51] So in terms of protecting yourself against this, what are your recommendations?

Jen Miller-Osborn: [00:08:57] Upgrade, if you're on one of the cloud providers...

Dave Bittner: [00:08:59] Apply the patch, yeah.

Jen Miller-Osborn: [00:09:00] ...That has shifted this, and apply a patch. This is really one where SSRF just needs to not be allowed in those environments. And if you are going to allow this sort of vulnerability, you really need to make sure you have enough other protections in place to keep this from being exploited. As we noted before, once the attackers have this sort of access, they basically pretty much run your network.

Dave Bittner: [00:09:24] And they would be presumably running under the radar here? I mean, it wouldn't – I guess they wouldn't be calling a lot of attention to themselves.

Jen Miller-Osborn: [00:09:35] It would honestly depend on the attacker. Some of them can be surprisingly noisy once they get inside the systems, because they're assuming there's not going to be a lot of logging or things on an endpoint for detection.

Dave Bittner: [00:09:47] I see. Yeah, one of the interesting things that I noted in your research here in terms of your list of remediation and best practices, was this idea of having a zero-trust network, which you kind of touched on earlier – that one of the reasons that this works is that there's this sense that once something's going on within, you know, within the castle walls, inside the moat, that it's generally trusted. But if you have a zero-trust network, that might be a way to help prevent this.

Jen Miller-Osborn: [00:10:15] Yes, absolutely. And that's something we as a company have been pushing for a number of years, is that zero trust, where, realistically, in this day and age, you can't assume any of the devices on your network are not compromised. So you need to kind of operate in the sort of mindset where you assume at any point in time that something can be compromised, so you have the extra protections in place where you don't – where vulnerabilities like this can't work, because none of the systems are trusted, so you can't exploit any sort of trust relationship.

Dave Bittner: [00:10:47] Now, one of the things that you point out in your research here, in fact, in the title, you suggest that they're going after some specific industries – technology, industrial, and media organizations. What in particular makes them vulnerable to this?

Jen Miller-Osborn: [00:11:01] It's just how they were set up. In this particular case, I don't know if it's whether the attackers were targeting that or that's just who happened to be vulnerable to this particular vulnerability, if that makes sense.

Dave Bittner: [00:11:14] Yeah. So if you're in a particular type of business, there's a particular way that you're likely to setup things and that aligns with this vulnerability, I suppose.

Jen Miller-Osborn: [00:11:24] Mm-hmm. Yeah, this was more just kind of happenstance, more so than any targeting.

Dave Bittner: [00:11:30] So, what are the take-homes here? What do you want people to take away from this research that you're sharing?

Jen Miller-Osborn: [00:11:35] That they need to go check their cloud instances and see if they are vulnerable to this, and even keep in mind just the problems that trusted relationships within a network can bring. And maybe reconsider their protection strategy, or at least maybe then they'll have more of an informed position on how they should make that decision – if they need to do any re-architecting. Hopefully, people that have these instances where they haven't patched in a while, will go and check their own, and they'll patch or upgrade if they're found to be vulnerable to it. Yeah, we're really just hoping by getting this out there that we can help with protections, because it is potentially pretty bad.

Dave Bittner: [00:12:22] That's Jen Miller-Osborn from Palo Alto Networks Unit 42. The research we were discussing today is titled, "Server-Side Request Forgery Exposes Data of Technology, Industrial and Media Organizations." We'll have a link in the show notes.

Dave Bittner: [00:12:42] Thanks to Juniper Networks for sponsoring our show. You can learn more at juniper.net/security, or connect with them on Twitter or Facebook.

Dave Bittner: [00:12:51] And thanks to Enveil for their sponsorship. You can find out how they're closing the last gap in data security at enveil.com.

Dave Bittner: [00:12:59] 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 technology. Our amazing. CyberWire team is Elliot Peltzman, Puru Prakash, Stefan Vaziri, Kelsea Bond, Tim Nodar, Joe Carrigan, Carole Theriault, Ben Yelin, Nick Veliky, Bennett Moe, Chris Russell, John Petrik, Jennifer Eiben, Peter Kilpe, and I'm Dave Bittner. Thanks for listening.