CyberWire Daily - Hoping for SOHO security. [Research Saturday]

Episode Date: October 19, 2019

Researchers at Independent Security Evaluators (ISE) recently published a report titled SOHOpelessly Broken 2.0, Security Vulnerabilities in Network Accessible Services. This publication continues and expands previous work they did examining small office/home office (SOHO) routers, network-attached storage devices (NAS), and IP cameras.  Shaun Mirani is a security analyst at ISE, and he joins us to share their findings.  The original research is here: https://www.ise.io/whitepaper/sohopelessly-broken-2/ Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. 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. 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 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. So Hopelessly, Broken 1.0 was actually conducted in 2013. That's Sean Marani. He's a security analyst at Independent Security Evaluators. The research we're discussing today is titled So Hopelessly Broken 2.0. And we looked at a few of the same devices that this research initiative covered, a smaller selection. And we found and published, I believe, 52 vulnerabilities across those devices, many of which allowed remote compromise of the devices. Now, these were all small office, home office, embedded devices, such as routers, network-attached storage devices, or NASs. And we kind of picked up where we left off in 2013, in 2018, with so hopelessly broken

2.0. And this time around, we broadened our scope, we looked at more devices. And what we found is that a lot of the security controls that manufacturers had been implementing in the five years between those two research initiatives were not sufficient to prevent remote compromise in a similar manner that we saw in 2013. Well, before we dig into the most recent research, to continue with the background from what you discovered in 2013. So the initial effort there was to look into these IoT devices and see where the vulnerabilities might be? Yes, that's correct. And as you say, you discovered 52 CVEs back then. Yes. So based on that, you decided it was time for a refresh. What was the methodology as you approached this round of research?

There were a couple of phases. We had to determine which devices to look at first and foremost. And we went with popular consumer grade devices that people were actually using and would probably care about if there were vulnerabilities in them. So once we acquired those devices, our methodology began with scanning, like looking for network services that were running on them and mapping out the exposed attack surface within the web application because most of them feature administrative web applications by default. And so that goes hand in hand with looking at the firmware, because most of these device manufacturers

make their firmware publicly available, either on their websites or through some other means. You can essentially download the firmware, extract it, and look at the entire file system that's going to be loaded onto the device. And that includes the programs that are going to be running. So that's the sort of reconnaissance, information gathering, scanning phase.

After that, we did hands-on testing that involved manually poking at the web applications and their network services that were exposed by default in order to identify any weaknesses, any potential signs of vulnerabilities that we could later go back to and write up and disclose. Let's go through a few of these devices together and sort of walk me through what you discovered and how you went about discovering and also what the implications are. Are there any of the devices that stand out to you that you want to start with? Among these different devices, we found vulnerabilities across each one of them. Some vulnerability classes were more common than

others. In particular, I would like to talk about the TerraMaster F2420 network-attached device, because that one had quite a few vulnerabilities that we identified. So what's interesting about the TerraMaster device is their use of encryption to obfuscate the PHP files that were stored in the file system. So the web application makes use of PHP for server-side dynamically generating pages, for handling requests on the back end. And so in order to hinder reverse engineering attempts, what TerraMaster had done is encrypt each individual PHP file with a static key and an IV of all zeros. Once we figured that out by

looking at the firmware and identifying the script where all that encryption and decryption processes occurred, we decrypted the PHP files themselves, and we're able to identify vulnerabilities within those scripts. And that led us to quite a few findings, including command injection, authentication bypasses, cross-site scripting, cross-site request forgery, I believe. Very common web application vulnerabilities. Yeah. So, I mean, a couple of questions. First of all, what is the TerraMaster device? What is it built to do? It's a network attached storage device. So it allows users to manage files. It has additional applications for accessing those files, like photo applications. It also features a web application where you can administer the device. So what you discovered then, again, from my understanding, is that with the encryption

they were doing on these files, they had basically hard-coded the key in the firmware. Is that right? Exactly. Not that hard for you to reverse engineer it? No. Once we figured out that key, it was fairly trivial to get the command to go back and access all those PHP files in plain text. Interesting. And so that uncovered a range of vulnerabilities. Yes. Let's take a look at some of the other devices. What other ones stood out to you?

The ASUS RT-AC3200 was a SOHO router that was particularly interesting because it was the only router that had a buffer overflow class of vulnerability that we discovered. So this was an authenticated buffer overflow, which means you had to have a valid login and passwords in order to exploit it. However, with authentication bypasses, and we've seen that many of these devices have ways to circumvent authorization authentication, this would be a remotely exploitable remote code execution attack. Now, were there any devices that came up particularly well that tested out as not having very many vulnerabilities, if at all? We found vulnerabilities in all of the devices. The only one that we were not able to gain remote code execution on in the time that we had was the Synology NAS. So we did find fewer high severity security vulnerabilities in the Synology DS218J. security vulnerabilities in the Synology DS218J. So when you compare the results that you got back in 2013 with what you found this round, explain to me what the differences were. How far have we come?

I would say we have not come very far at all. While these manufacturers have made attempts to implement security controls that not only make it harder to reverse engineer the devices, but in some cases are actual legitimate attempts to protect against vulnerability classes. We were still able to exploit remotely most of these devices, 12 out of 13, and get root shells on them. So I would say that the progress that these manufacturers have made is insufficient. I would say that the progress that these manufacturers have made is insufficient. Is it the same sorts of things that you discovered back in 2013? Or have those things been addressed and there are new ways that you can come at these devices? It's essentially the same vulnerabilities.

Command injection is very widespread among these. Where are they coming up short overall? And do you have any insights on to why they may not be doing a better job? What's keeping them from doing a better job? I don't know specifically what's keeping them from doing a better job or and whether or not, in fact, they are now taking steps after the fact, after our publication to improve their security posture. But I think it's a matter of incentive until the companies are incentivized to improve security. It's always going to be on the back burner for them. It's not going to be a priority. Now, you all went through the responsible disclosure process and you got different responses from different companies. What are some of the highlights of what you went through with that part of the process? For the most part, the responsible disclosure process went smoothly. When we reported vulnerabilities, most of the manufacturers we talked to would reply in a reasonable amount of time, and they would acknowledge our vulnerability reports,

and they would fix them. And in some cases, they even asked us to test the mitigations. And we would go ahead, download the new firmware, install it on our devices, and actually see if they fixed the vulnerabilities we reported. Now, a couple of the manufacturers we had some communication problems with, which led to some prolonged difficulties for us in the disclosure process. Notably, one of them was Netgear. When we reported these vulnerabilities to Netgear, so they have a bug bounty program via bug crowd. When we initially reported the vulnerabilities, it took them several months, I believe five months for them to even acknowledge and get back to us and start triaging the vulnerabilities we had reported, let alone fixing and awarding payouts as is part of the program. And NECIR was also a CVE numbering authority, a CNA.

So they're responsible for issuing the identifiers for the vulnerabilities that are used in CVE descriptions. And when we asked Netgear to provide us with CVEs for the issues we identified, it took them three months to get back to us. And they said they were no longer issuing CVEs. So we had to reach out to MITRE, who then was not aware that Netgear was no longer issuing CVEs. So we had to reach out to MITRE, who then was not aware that NETGEAR was no longer issuing CVEs. And there was some back and forth. And eventually we ended up getting CVEs we needed from MITRE instead of NETGEAR, who was supposed to be the original issuer. So initially, you had several months of just radio silence from them. Essentially, yeah.

Yeah. Wow. What are your recommendations here? I want to come at this from two different directions. First of all, from the device manufacturers, what should they be doing to protect their devices from the things that you discovered? There are known mitigations to all of these vulnerabilities. Like these issues have been around for a very long time. It's not like these are new and novel attacks. We did research with existing vulnerabilities with lots of research done on them in mind, and we found them. And it was just a matter of the manufacturers not implementing proper security controls. So all I can say in terms of resolving these vulnerabilities, preventing them in the

future is follow best practices because there's really no magic solution to preventing these vulnerabilities. It's just a matter of being on top of it. And what about from the consumer side of things? If I'm out there buying these sorts of things, how can I protect myself? I would say, first and foremost,

turn off remote management. Do not allow your NAS or your router to be accessed from the WAN. Don't let people on the public internet try to connect to your web application and make login attempts because we've uncovered a lot of issues that are pre-authentication that could compromise your device. So that's a big one. Also, keep your device up to date, of course. I know that's said a lot. And it's easier said than done. Some of the devices make it somewhat easier by offering semi-automatic updates, especially nowadays that's more common. But yeah, pay attention to when firmware upgrades are available so you don't become susceptible to published exploits out there.

It's really interesting to me because you've got this multi-year gap between the work that you did back in 2013 and this year's research. And you would hope that we would have seen more progress. You would think that if I had gone through the process of saying, OK, I've got this router or I've got this NAS and it's over five years old, maybe it's time to update it. And I assume that the security is going to be better on it. I think it's a little discouraging. That's likely not the case. It's extremely discour I think it's a little discouraging. That's likely not the case. It's extremely discouraging and it's a pretty sad state of affairs. But like I said, until the companies are incentivized to actually make security a priority, I don't foresee

things changing anytime soon. We're talking about incentives and how companies aren't properly incentivized to make these sort of changes. What do you think proper incentives would be? Do we need some sort of regulations or standards? How do you think we could come at it from that direction? I don't really know if I'm well-informed enough to comment on that. Yeah. I know there have been some pushes for regulations, especially in the past few years. I don't know enough about it, frankly. Yeah. Okay. Fair enough.

I think a lot of it's going to have to come from consumers themselves, perhaps with research like this, more outreach to the community, especially to the information security community, that consumers are going to start to care and exert pressure on these companies to improve their security. So that's one viable way, I think. I'm curious, when these devices come out of the box, could they be made safer by having their default settings be different from what they are? Yes, because a lot of the times the default settings are such that it's most convenient for the user. Like certain network services that may not be the most secure, but are definitely convenient for the customer are enabled by default. So if those were disabled instead, then the device as a whole might be more secure.

Our thanks to Sean Marani from Independent Security Evaluators for joining us. The research is titled So Hopelessly Broken 2.0. We'll have a link in the show notes. Thank you. Visit ThreatLocker.com today to see how a default-deny approach can keep your cybersecurity teams and technologies. Our amazing CyberWire team is Elliot Peltzman, Puru Prakash, Stefan Vaziri, Kelsey Bond, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Valecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick, Jennifer Iben, Rick Howard, Peter Kilpie, and I'm Dave Bittner. Thanks for listening.