CyberWire Daily - A Jira vulnerability that’s leaking data in the public cloud. [Research Saturday]

Episode Date: January 2, 2020

Unit 42 (the Palo Alto Networks threat intelligence team) released new research on a Jira vulnerability that’s leaking data of technology, industrial and media organizations in the public cloud. The vulnerability (a Server Side Request Forgery -- SSRF) is the same type that led to the Capital One data breach in July 2019. Jen Miller-Osborn is the Deputy Director of Threat Intelligence for Unit 42 at Palo Alto Networks, and she joins us to share their findings. The research can be found here: https://unit42.paloaltonetworks.com/server-side-request-forgery-exposes-data-of-technology-industrial-and-media-organizations/ 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 and solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. 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 Thank you. your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com slash security. This type of vulnerability short circuits logins, essentially, it lets the attacker abuse trusted relationships between applications and the servers that are hosting them. That's Jen Miller-Osborne.

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. 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 these internal resources, which typically don't take requests from outside the internal environment, are now accessible because an attacker is able to already be in that internal environment and they can query the internal things directly. It's almost like the internal API now becomes accessible directly

from the internet, 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. And the vulnerability is because of a bug somewhere along the lines? 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 things could not come at them from the internet. So this vulnerability allows that protection be that's that's protection to be removed basically 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. But 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. And so this sort of thing is used for getting data out of a system as opposed to, for example, running code? 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 the 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. Now, one of the things you outlined 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?

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 attacker is 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 a – 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. So how prevalent is this in the scanning that you did? How big an issue are we talking about here? So we found 7,000 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, 7,000 is a lot and they were spread across a number of different public clouds.

And there are patches available. 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. but there's also a separate patch itself. But I guess one of the lessons here is that there's a lot of systems that go unpatched for a variety of reasons. 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 this 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. 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 in the environment at all. 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. I'd like to get inside. What do I do next? How do I execute my evil plans? You need to start trying to send

crafted URLs to the vulnerable devices to see if they work. 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, which is not particularly difficult to exploit, unfortunately. So in terms of protecting yourself against this, what are your recommendations? Upgrade. If you're on one of the cloud providers 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. And they would be presumably running under the radar here? I mean, it wouldn't, it wouldn't, I guess they wouldn't be calling a lot of attention to themselves. 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. I see. Yeah, one of the interesting things 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 this sense that once something's going on 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. 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 this 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. Now, one of the things that you point out in your research here in fact in the title you suggest that it's they're going after some specific industries technology industrial media organizations what in particular makes them vulnerable to this 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. Yeah. So if you're in a particular type of business, there's a particular way that you're likely to set up things and that aligns with this vulnerability, I suppose. Yeah, this was more just it just's a kind of happenstance more so than any targeting. So what are the take-homes here? What do you want people to take away from this research that you're sharing? 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 then 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. That's Jen Miller Osborne from Palo Alto Network's 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. And now, a message from Black Cloak. Did you know the easiest way for cybercriminals to bypass your company's defenses

is by targeting your executives and their families at home? Black Cloak's award-winning digital executive protection platform secures their personal devices, home networks, and connected lives. Because when executives are compromised at home, your company is at risk. Thank you. Learn more at blackcloak.io. The Cyber Wire Research Saturday is proudly produced in Maryland out of the startup studios of Data Tribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing Cyber Wire team is Elliot Peltzman, Puru Prakash, Stefan Vaziri, Kelsey Bond, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Valecki, Gina Johnson, And I'm Dave Bittner.

Thanks for listening.