CyberWire Daily - A firewall wake up call. [Research Saturday]

Episode Date: November 9, 2024

Enjoy this special encore episode, where we are joined by Jon Williams from Bishop Fox, as he is sharing their research on "It’s 2024 and Over 178,000 SonicWall Firewalls are Publicly Exploitable." SonicWall published advisories for CVE-2022-22274 and CVE-2023-0656 a year apart after finding that NGFW series 6 and 7 devices are affected by two unauthenticated denial-of-service vulnerabilities. The research states "Our research found that the two issues are fundamentally the same but exploitable at different HTTP URI paths due to reuse of a vulnerable code pattern." They also found that when they scanned SonicWall firewalls with management interfaces exposed to the internet, they found that 76% are vulnerable to one or both issues. The research can be found here: It’s 2024 and Over 178,000 SonicWall Firewalls are Publicly Exploitable Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. Air Transat presents two friends traveling in Europe for the first time and feeling some pretty big emotions. This coffee is so good. How do they make it so rich and tasty? Those paintings we saw today weren't prints. They were the actual paintings. I have never seen tomatoes like this. How are they so red? With flight deals starting at just $589, it's time for you to see what Europe has to offer.

Don't worry. You can handle it. Visit airtransat.com for details. Conditions apply. AirTransat. Travel moves us. Hey, everybody. Dave here.

Have you ever wondered where your personal information is lurking online? Like many 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 private by signing up for Delete.me.

Now at a special discount for our listeners. private by signing up for Delete Me. Now at a special discount for our listeners, today get 20% off your Delete Me plan when you go to 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 CyberWires 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. We're diving into this because we're interested in getting more familiar with the SonicWall Next Generation firewall platform, SonicOS. It's been the subject of a lot of vulnerabilities in the past, and we wanted to be prepared to be able to research in the platform whenever anything new came out. That's John Williams, Senior security engineer at Bishop Fox. The research we're discussing today is titled, Sonic Wall Firewalls Are Publicly Exploitable. And so in order to do that, I went back and looked through the history of all the different advisories that had been released, looking for things that were unauthenticated, had a potential

for remote code execution, and didn't have a known proof of concept. And the one bug that jumped out at me was this one from 2022, which met all those criteria. So I figured it was a good research target and dove in to see if we could exploit it. And we're pretty successful in the end. Now, looking through your research here, I guess there was some stuff from the folks over at Watchtower Labs that originally caught your eye? Yeah, just a couple months back, Watchtower put out a blog post detailing how they found a whole raft of new vulnerabilities in it. They all required authentication, which was less interesting to us. And, you know, so we wanted to see what we could find that might not require authentication. Well, let's walk through this together. I mean, how do you get

your start when you're digging into something like this? And what's the process like? Well, in a case like this, where we had very little to go on in terms of understanding the nature of the bug, SonicWall's advisory was pretty terse. We knew that it affected the web management interface, but didn't have much background knowledge beyond that. So the typical approach for something like that is to start with patch diffing, right? We acquire software before and after the patch. We extract the files that are relevant for the bug. We analyze them using Ghidra or some other engine like that to decompile the code.

And then we compare the code and see if we can identify what has changed and of those changed functions, which one is relevant to the bug we're trying to exploit. And if we're successful at finding that, then it's a reverse engineering effort to understand what the code is doing, how to reach the vulnerable code, and then ultimately how to trigger the bug. And our end goal in this case was to get the crash, although the bug

certainly caught our attention because it had a potential for remote code execution as well. And indeed, you did find the difference in the code here. What did that difference reveal? Well, it was pretty interesting because there was a code pattern, which was essentially they were using an SN printf check function, which takes a string and copies it into a buffer, and then it returns a value, you know, which is usually the number of characters

that were written into the buffer. Not always, though, and that was kind of at the heart of it. But the issue was that the developers were using this function two times in sequence, and they were passing the return value from the first call into a parameter for the second call. And so this ended up creating the possibility to pass in a string to the first call that would result in an unexpected output,

which would then cause a buffer overflow the second time it was called. And what was fascinating about it was that the snprintf check function is designed to be buffer overflow safe. So if you pass it in a string that is bigger than the buffer that you're trying to write it to, it won't do it. But the thing is, it will copy what it can, and then it will return the length of the string that it was asked to

copy. And that was key. Not the value it actually copied, but the length of the string you gave it, even if it didn't copy the whole thing. And the developers in this case assumed incorrectly that they would only get back the length of the string that was copied. So when I pass that to the second function, the second function uses it in such a way that it requests a much longer string to be copied than they were expecting, and it ends up overriding the buffer anyways because they've used it in a way that was inappropriate. So even though the function itself protects against an overflow, they used it in a way that was insecure. Well, help me understand here.

I mean, is that function behaving as designed or not? It is, yes. It's just a lack of clear understanding about how it's supposed to be used. And what we're realizing, one of the things we learned from this research is that it's a very common mistake. And it's easy to understand why, right? I mean, you would expect if you're copying a string and it tells you it'll give you the length of the string copied, that that's what you'll get. You have to read the fine print on the function definition to understand that there are edge cases where that may not be true. Pretty common mistake.

And, you know, we're going to be looking for this type of vulnerable code pattern in other places as we go forward because it does seem like something developers do often. Yeah, that's a really interesting insight. So you discover what is at the root of this. What do you do next? Well, in this case, we did two things. One, we wrote an exploit for it and confirmed that it worked, so we were able to crash our test target. We, of course, checked the patched version too

and confirmed that it didn't work against that, so the developers did patch it effectively. But then once we really understood the nature of the bug, we also looked elsewhere in the code to see if they had made the same mistake in other places. And it turns out that they had. Now, the way that this particular bug is exploited is through an HTTP request

that uses a URI path that is way too long. And the original bug, the 2022 bug, had three different paths where you could send that request and crash the server. And they were all fixed in the same place. But what we found by looking elsewhere in the code is that there were actually two other paths where the same bug could trigger the crash. And those two paths were not fixed in the 2022 patch. So we got really excited at that point and thought we had found a zero day. But as we continued digging into it, realized that if we were testing against one of the most recent firmware versions, those paths weren't exploitable. And so we were like, oh, did somebody already catch this and fix it? Was it unreported?

But no, it turns out it was reported in 2023. So a year after the initial patch, SSD Labs found and reported the vulnerability on the other two paths. And they had published their exploit, but we had overlooked it because we were specifically looking for things that didn't have proof of concepts available. Once we'd figured out that these two vulnerabilities

were in essence the same bug, we were able to realize that the exploit was already out there, but nobody had publicized the paths from the 2022 bug that had been exploitable all this time. So we were able to establish a link between the two vulnerabilities, publish our exploit for both of them, and then use what we had learned about testing it to release a tool that could be used to identify both bugs without crashing the target server.

Do you know the status of your compliance controls right now? Like, right now. We know that real-time visibility is critical for security, but when it comes to our GRC programs, we rely on point-in-time checks. But get this. More than 8,000 companies like Atlassian and Quora have continuous visibility into their controls with Vanta. Here's the gist. Vanta brings automation to evidence collection across 30 frameworks, like SOC 2 and ISO 27001.

They also centralize key workflows like policies, access reviews, and reporting, and helps you get security questionnaires done five times faster with AI. Now that's a new way to GRC. Get $1,000 off Vanta when you go to vanta.com slash cyber. That's vanta.com slash cyber for $1,000 off. I want to highlight that point here. As I was reading through your research, I actually laughed out loud. I'm going to quote it here. It says, being able to crash a target is all well and good, but what about identifying vulnerable devices without knocking them offline?

Right. Well, that's the thing. I mean, just that it's great to be able to exploit something, but if you have a customer base who's relying on you to help secure their infrastructure, you need to be able to give them proof that they're vulnerable without causing an impact yourself. And so having dug into the bug as deep as we had, we found a way where we could actually exploit part of it, just enough to know whether or not it was hitting the vulnerable code, but not actually go so far as to cause the crash. And take us through that. I mean, what went into developing that? It was a long time of staring at the code trying to understand what on earth was happening.

But what it came down to, it was that the two SNPRNF check functions that were being called essentially had the end result of copying the HTTP request string into a buffer in two parts, right? So with any HTTP request, there are three pieces. There's the HTTP request method, which is like get, post, put, delete, you know. The second part of it is the URI path, which starts with a slash, tells you where you're sending the request to, and then it may also have query parameters. And then the third part of that string is an HTTP version, which is 1.0, 1.1, 2.0. You know, it's really short. These two functions were copying the second two pieces of that request. So the first function copied the request path into the buffer, and then the second

part copied the HTTP version into the same buffer And then the second part copied the HTTP version into the same buffer. And this is where it ended up being problematic because the return value from the first function call would be used as an offset into the buffer where they were going to write the second part. And so if you ended up getting a much larger return value than you expected, it would advance that pointer out of your buffer and somewhere else on the stack. So that was the first part of the problem. The second part was that when it copied the HTTP version, it was using the input from the previous function to determine the length,

like how many characters it should copy. And so again, if you got the wrong length back, And so again, if you got the wrong version, or if you got the wrong length back, it would actually underflow and it would copy a huge amount from your input, you know, in when it should just be a few characters for that HTTP version. And so the difference there is that by changing the length of the URI pass that you're sending in your request, you can trigger the first part of it, which is getting a return value that's too big. And by sending an HTTP version in your request that's too long, then you can copy data into the buffer when it overflows. But if you only do the first part of that, then it doesn't crash. But it will trigger the patch protection that they added. then it doesn't crash. But it will trigger the patch protection that they added.

And the result of triggering their patch protection is that the request just gets dropped. So you don't get a response from the server at all. So by sending a request that has a URI path that's too long, but not an HTTP version that's too long, and then looking at the response you get back from the server, you can tell whether or not it's been patched. And you all set about doing this. I mean, you went out and were set out to find out how many devices out there were potentially vulnerable, and you came up with some interesting

results. Yeah, well, once we had that safe test and we were confident that we could look, you know, interrogate different servers without causing any negative impacts. It occurred to us to scan the internet. You know, how bad is this really? Of course, we notified our customers first, but then we did some research. We went to Binary Edge to build a target set because these firewalls aren't hard to identify online. They have a server response header that uniquely identifies them. So if they're exposed to the internet, Binary Edge will pick them up. And then we did some filtering to make sure that our target set was accurate and the targets were actually reachable online. So we had a final set of about just over 230,000

of these exposed devices that we were testing. We ran the test against all of them and found out that about 76% of them were vulnerable to one or the other of the two bugs, which was kind of mind-blowing. We expected a lot of them to be vulnerable, but not necessarily that many. Wow. What has SonicWall's response been to your work? Well, we gave them a heads up before publishing our research, but this was a case where we didn't really need to do a full responsible disclosure because both bugs were already published. We weren't really exposing anything that was unknown.

All we were doing was establishing a link between these two vulnerabilities. So we did give them a heads up, but we didn't have to do a full disclosure. And they acknowledged and just wanted to know some more details about it. But from their end, at least as far as I'm concerned, there really isn't much more they can do. I mean, they put out patches for these bugs two years

and then almost one year ago for the latter one. So really, at this point, it's just on the consumers to upgrade their devices. That's the real problem here. SonicWall has mostly done their due diligence at addressing this already. What happens if you use this procedure to crash a device? What does the recovery look like? Well, typically, when you crash a SonicWall device, it has a watchdog, it'll just reboot it.

And that takes a couple minutes, so you'll knock it offline briefly. But what I found in my testing was that, at least in its default configuration, if you do this three times within a brief period of time, you know, like within, I don't know exactly what it is, 10 or 15 minutes, maybe, it'll reboot into maintenance mode. And so it'll be completely inaccessible until an administrator comes in and resets the device. So that could be potentially catastrophic,

you know, depending on what the firewall's role is, you know, who is deploying it for what purpose. depending on what the firewall's role is, you know, who is deploying it for what purpose, if you have the ability to completely knock it offline, it could cause some real serious interference. So what are your recommendations then? I mean, what should folks do to best protect themselves here? Well, there are two things that they can do to mitigate it.

The obvious one is to patch. You know, if you install the upgrade, you're fine. You're protected. But of course, in enterprise environments, sometimes there are reasons why that's difficult to do. The other mitigation step, of course, is to remove the web management interface from public access. Honestly, the fact that there are 230,000 plus of these exposed on the internet is a problem in itself. The web management interface should not be publicly accessible. It should be only accessible to administrators, either on an internal network or through a VPN or some type of secure connection.

The best protection, of course, is to do both things. You know, take it off the public internet and make sure it's patched. And that way, it just won't be exploitable at all. But one or the other is good enough. Does the system default to having that interface accessible to the web? Well, so it is a web-based interface, but by default, it only exposes it on the internal network, the LAN, not the WAN.

So yeah, it all comes down to how you configure it as an administrator. Our thanks to John Williams from Bishop Fox for joining us. The research is titled SonicWall Firewalls Are Publicly Exploitable. We'll have a link in the show notes. And now a message from Black Cloak. Did you know the easiest way for cyber criminals 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. In fact, over one-third of new members discover they've already been

breached. Protect your executives and their families 24-7, 365, with Black Cloak. Learn more at blackcloak.io. The Cyber Wire Research Saturday podcast is a production of N2K Networks. N2K Strategic Workforce Intelligence optimizes the value of your biggest investment, your people. We make you smarter about your team while making your team smarter. Learn more at n2k.com. This episode was produced by Liz Stokes. Our mixer is Elliot Peltzman. Our executive producers are Jennifer Iben and Brandon Karp. Our executive editor is Peter Kilpie. I'm Dave Bittner. Thanks for listening.

Your business needs AI solutions that are not only ambitious, but also practical and adaptable. Thank you. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com.