CyberWire Daily - VOIP phone system harbors decade-old vulnerability. [Research Saturday]

Episode Date: September 7, 2019

Researchers at McAfee's Advanced Threat Research Team recently published the results of their investigation into a popular VOIP system, where they discovered a well-know, decade-old vulnerability in open source software used on the platform.  Steve Povolny serves as the Head of Advanced Threat Research at McAfee, and he joins us to share their findings. The original research can be found here: https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/avaya-deskphone-decade-old-vulnerability-found-in-phones-firmware/ 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.

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, Thank you. organization with Zscaler, Zero Trust, and AI. Learn more at zscaler.com slash security. This was kind of a fun one, kind of an interesting one, since Avaya and specifically their VoIP phones are so popular and so widely deployed. That's Steve Pavolny. He's the head of advanced threat research at McAfee.

The research we're discussing today is titled Avaya Desk Phone, decade-old vulnerability found in phones firmware. We got interested in this specific platform, one, because obviously it is so ubiquitous and it's used so globally. And two, because it's primarily deployed in businesses and large enterprises as a desk phone. And as a research group, Advanced Research or ATR, we kind of approach new projects from two perspectives. new projects from two perspectives. The first being we're trying to uncover and, you know, quote unquote, burn as many security flaws or vulnerabilities as we can across software and hardware platforms. So from that perspective, being able to make a big impact across this industry of deployed devices was really interesting for us and made for engaging research.

On the flip side, we're a small, dedicated team, so obviously we can't tackle everything. So part of what we do with any piece of research, once we find something that's relevant, is in addition to just getting the flaw or vulnerability fixed, we actually work to build a full end-to-end demo, show what the actual bad guys could do with it, and then really get that awareness out there and make sure that people understand what the impact is.

And it's that level of awareness and insights into the problem space that's almost more important than just fixing individual bugs in the end. So long story short, I guess we kind of got interested in it ultimately because of how widespread it was and because of the areas that it's used primarily in large enterprises. Yeah, I can't help picturing in my mind, you know, someone from your research team sitting there at their desk and, you know, glancing over at the phone and their eyebrows raising and going, hmm. What could you do with this network-connected device that is recording calls and listening to calls, right? Right, right. Exactly, exactly.

Well, I mean, let's dig in here. And for folks who might not be familiar with how these phones work and sort of what's going on with them, can you give us a little overview? Yeah, so these are, of course, network-connected devices, which is why they're called VoIP phones or voice over IP, is all of the data that's transmitted for your calls is going across the network, similar to many phones, but across an IP-based network here. And ultimately, what that means is if someone is able to get onto the same network where these phones are deployed, which is typically an internal business network, or sometimes even a guest network, if they are connected to it, and is able to compromise something in the phones, you know,

they might be able to actually pivot to other devices on the network, control all the phones at once. Or ultimately, what we did with this scenario is leveraging the ultimate vulnerability that was found, and eventually basically using it to tap and record network traffic, including calls. We thought that was probably the most interesting scenario from the threat actor's perspective in terms of being able to not just surreptitiously steal call data or record call data, but also potentially to deploy something like malware to all the devices or ransomware. And in a large organization that heavily relies on their enterprise phones, there's a fairly good chance that that ransom could be effective while they keep users locked out of their phones. So we kind of approached it from that perspective of both delivering a payload of ransomware,

as well as exfiltrating call data, you know, over the Internet. payload of ransomware, as well as exfiltrating call data, you know, over the internet. Yeah, it strikes me too that this is a device, like we said, it sort of sits on someone's desk and in a way it's kind of invisible. It's sort of out of sight, out of mind. As long as it's working, it's not something you really think about very much. People forget that these are just computers, right? And Philippe Lollaret, who is the primary researcher on this one, looked at this thing instantly, and instead of seeing a phone that makes calls,

he sees a computer sitting on his desk that's plugged into the network. And so this is similar to any other type of IoT device now that has become network-based. And, of course, phones have been connected to networks for a very long time now. But you're absolutely right. This is typically an oversight from a security perspective as well as from just a monitoring perspective. So it makes for an enticing target for cyber criminals looking to, you know, pivot and find a way into the network.

It makes for a really ideal type of a target. Well, let's walk through together what your team did here. There's some interesting aspects to it, both hardware and software. Where do you want to begin? So first and foremost, we take the lazy approach whenever possible, or the low-hanging fruit if you want to be politically correct. We're trying to look at the network interfaces. We're trying to see if the software or firmware can be just freely downloaded over the internet. In this case,

we could actually access the firmware just by downloading it on the internet. But with many cases and many of our research projects, you have to be a customer or you have to use some social engineering to get access to the firmware, or maybe it's only delivered sometimes even in physical medium. So in this case, we were able to get the firmware easily, but the researcher wanted to be able to essentially access the underlying operating system and be able to do some interactive testing with it. So instead of just testing the firmware for vulnerabilities or flaws, similar to a normal software project,

he actually opened up the phone, physically opened it up and started working with the actual hardware and the boards inside the phone to see what he could learn. And ultimately, had he not taken this approach, we would not have come across the vulnerability that exists in the phone for over 10 years.

So the process here was open up the phone and do what's called connecting to debug ports. And often there's hardware interfaces on the inside of a computer like this that the developers either leave in there intentionally so that they can debug issues in the field. developers either leave in there intentionally so that they can debug issues in the field, or sometimes they're doing QA or debugging in the manufacturing process and they forget to close them down and they can be accessed later. Long story short, what this means is a researcher, whether a white hat researcher or a black hat researcher, can ultimately access interfaces to the phone and back end system on the phone that they probably shouldn't be able to access. In this case, Philippe was able to directly connect to the phone's hardware and use it to load a root or kind of a system admin level shell on the box

just by soldering some wires on there. And we spent a lot of time kind of in the blog when we released this research talking about and educating people who are interested in this type of research on just how you do that, how you go about connecting to those hardware debugging interfaces, what's interesting, what are you trying to retrieve from them, and ultimately it leads to the fact where you can start to poke around now on the operating system and the file system of the computer, in this case, a phone. And what Philippe was able to do then by having a root shell was do some basic vulnerability scanning and some privileged poking around, I guess, for lack of a better term, to see what he could find. Ultimately, what he found was a piece of code that had not been updated in over 10 years.

He could tell that from the copyright on the banner of the code. And that led him to start to search for, you know, more of an existing vulnerability versus trying to find something new since this was such old code and such unupdated code. And then finally to come full circle, you know, and we're keeping it fairly high level for now, but to come full circle, he was able to find a vulnerability that had been publicly reported in some open source code about 10 and 11 years ago,

which is the DHCP client responsible for providing an IP address to the phone. And Avaya had actually taken that public open source code, forked a version of it, and put it in their product. And unfortunately, the version of the code that they implemented in their product was the one that did not have the patch in it. So there was some oversight from the vendor here in terms of baking in the existing security, the patches that were available, and that went unnoticed for a period of 10 years until Philippe kind of stumbled across this bug.

So this wasn't a matter of me having a 10-year-old phone sitting on my desk. This was an old version of some open-source software that was just still being reused in modern code. Absolutely, yeah. These phones are still sold and widely distributed. I want to say there is an end-of-life plan for them coming up here, but they're still one of the most popular desk phones used across major enterprises, this specific version.

And exactly as you said, this is not an old phone. It's a newer phone with an older code base on it. And had Avaya properly forked the patched version of the DHCP client into their phone, this vulnerability would not have been there. And we would have had been looking for, you know, a new vulnerability or what's called a zero-day vulnerability, something that hadn't been reported to the industry before. So this is kind of a unique scenario where actually, you know, a vulnerability that's quite well known from an industry perspective was completely unknown from a product perspective.

And because of that, you know, there's actually existing exploit code out there already written to take advantage of this exact vulnerability. So for the researcher, it was quite easy to, you know, once he found that, build a proof of concept and take that to the extent of fully compromising the phone. And I'm sure we'll talk a little bit about what the impact of that exploit is. Yeah, absolutely. And before we get to that, I think it's worth pointing out that from a hardware side of things, this was not a matter of needing a significant investment

or spending a lot of money on the gadgets that you needed to sort of hose yourself up to this phone. It was not expensive. Right. No, the expensive part is the time it takes to learn the skills, right? The overhead it takes to become good at, you know, if you look at some of the blog content and how the research actually connected to the phone, you'll see there's some very, very fine

little soldering wires involved there. You have to be able to, you know, analyze the internal components of the hardware and know which chip is what and which board is what and how to connect different pins and pinouts. But from an investment perspective, I think our net investment was, you know, probably in the range of $5 or $10 for some copper wire. And, you know, we did have some additional hardware that kind of facilitated and made the process a lot easier, but not overall necessary to being able to connect

to the internals of a computer and pull useful information. And just like anything else, the more you spend, the easier it gets, generally speaking. But you're absolutely right. This is something that most people can do for pretty low cost. Now, the phone system itself was running a Linux system, which is interesting, certainly not uncommon, but opens up all sorts of avenues for exploration there as well. Absolutely. And this is pretty common for embedded devices and IoT in general, especially phone systems will run Linux or some kind of a version of a Linux kernel here.

phone systems will run Linux or some kind of a version of a Linux kernel here. And, you know, once Philippe had access to the kernel and had elevated privileges on the operating system, you know, there's two approaches at the take. One is to look for existing vulnerabilities, which again, is kind of that low hanging fruit. If you find something that's already out there that hasn't been patched or fixed, in a way that's just as good as finding a zero-day vulnerability that nobody knows about, because in practice, it's exploitable in the exact same way, and a patch still needs to be developed. So that's one approach to take, and something we typically do when we drop into some elevated privileges, like on a Linux kernel here. On the flip side, had that not been successful, there are a number of tools that allow you to test

and penetration tests and look for vulnerabilities and exploit them on both Windows and Linux and other operating systems at the level we're talking about here. What is the range of possible exploits that you all explored here? What sort of things were you able to do when you had that root level? Well, once we had the root shell on what's called the EEPROM, which is one of those hardware interfaces to the operating system, the vulnerability was pretty quickly found. So, you know, again, Philippe just kind of, after looking to the operating system, the vulnerability was pretty quickly found. So, you know, again, Philippe just kind of,

after looking around a little bit and seeing a copyright of 2004 to 2007, kind of got wind of the fact that we were running some, or that the device was running some pretty old code here. And the vulnerability itself, you know, for researchers in the industry, probably already familiar with it. I know Philippe kind of remembered it, just kind of triggered his memory based on having seen it a number of years ago. But either way, you know, at this point, you could run a full end-to-end vulnerability scan, you know, looking for all existing CVEs or vulnerabilities that have been published, see what comes up. We really kind of stopped once we found this vulnerability.

And, you know, the researcher decided, you know, why go any further? We have a root shell on the device. We've got a vulnerability that's unpatched. And we've got a target that's deployed, you know, very widely in our enterprise environment. And we decided then to kind of pivot and start using that to build the demo. Ultimately, as I mentioned earlier, we thought there was two really impactful scenarios here,

and we can go into detail on both of them. The first one was, of course, we built a proof of concept, just to demonstrate the vulnerability. And the, I think he is my face, to load on the startup screen or the splash. And the police, I think he used my face to load on the startup screen or the splash screen of the phone just to show that he had remote code execution and could replace images on the phone. I don't think any realistic attacker is going to be so kind as to tip you off that way, but it was a great proof of concept.

From a realistic perspective, we decided there's two really tangible scenarios that someone would use if they found this vulnerability unpatched. The first, as I mentioned, would be deploying malware or ransomware. And kind of sky's the limit in terms of what you could do here. a backdoor on a number of internal systems, to use it as a device to pivot to more critical systems on the internal network, especially if the phone system is on protected, you know, kind of a non-open, non-guest network where there's other sensitive devices. This becomes a really interesting kind of permanent or semi-permanent backdoor into your network. That's one way that, you know, we see a lot of vulnerabilities and exploits being used is just as

backdoors in the network and kind of maintaining persistence there to attack other targets. From the actual phone perspective, we thought, well, wouldn't it be cool if you could actually enable the internal microphone through the use of this exploit and either call or record or spoof calls outbound. And that's the demo we built and kind of run in our lab here is we exploit the vulnerability to turn on the internal microphone. And essentially, it'll not only capture, of course, call data when a call is being made, but it can just capture ambient room noise or background noise.

So if this thing is deployed on the table of your boardroom for a critical boardroom meeting and the vulnerability is exploited, we can be listening and even exporting all of that data, all of that audio data out of the network back to a server or computer that we control. And we thought that was a really interesting kind of targeted scenario for surveillance and spying activities, as well as gaining kind of privileged information to what should be really kind of

a highly confidential conversation. And those are the two demos that we built. So really, we kind of have a simple demo where Fleet just kind of speaks and talks into the phone. And about a second or two later, you kind of see the call reporting happening in real time and the data being exfiltrated out over the Internet. In order to exploit this phone, to get the access that you got,

was it necessary for you to have access to the hardware itself, or could this have been done remotely? That's a great question, Dave. So we decided to, the answer is no, we did not actually have to have access to the hardware. And that's really important here because obviously it would mitigate the findings significantly if you needed to sneak into a building, open up a phone and tap it. At that point, you might as well just install a tap, right? So this is a network-based attack, meaning you don't have to have any physical access to the phone. You just need to be on the same network. The reason we spent so much time on the hardware side of things is more from an educational perspective. So we want

to be able to teach researchers who are interested in helping secure this space and interested in finding additional vulnerabilities and responsibly disclosing them to be able to build the skill sets and understand the approach that goes into hacking into these kinds of devices. And with that often is the hardware approach. So had we not been able to download the firmware freely over the internet, and if Avaya decides to lock down those firmware downloads in the future, this would be the tactic or the technique that the bad guys would actually use to figure out whether there are vulnerabilities on the system and ultimately how to exploit them.

So really gaining access to the hardware interface is just the means to the end to understanding what the attack surface is and how to pull it off. It makes it easier to get the firmware, the file system, the memory content, to do that kind of research and analysis. But ultimately, as far as exploitation, it's completely unnecessary. You just need to have access to the network that these devices are deployed on. Now, you all did reach out to Avaya, and they were responsive, and they've since published a patch.

Yes. Yeah, they've been a great partner to work with and you know we think that one of the things that sets us apart as a research organization is that McAbee's ATR and Medset Research always always works with the vendor to do what's called responsible disclosure. So when we find a vulnerability and sometimes we've been working with vendors well before we find a vulnerability, and sometimes we've been working with vendors well before we find a vulnerability through partnerships. In this case, we reached out to Avaya just as soon as we found the vulnerable code. And we had a number of ongoing discussions with them over the

next few months while they worked on getting a patch ready and updated. And we have to really commend them for the speed they worked at, way they embrace the research you know kind of the collaboration throughout the whole process really demonstrated what we always hope to achieve which is that strengthening that researcher and manufacturer vendor relationship and to me that's really ultimately one of the most important things that we have the opportunity to change in this industry instead of just throwing the vendor under the bus and reporting bugs and, you know, and making a vendor look bad, what we're actually trying to do is change the paradigm

so that we're now working as a team, as a single unit, and that the White Hat research community comes together with the manufacturers, developers, and vendors, White Hat research community comes together with the manufacturers, developers, and vendors, and ultimately we're doing the research that leads to the development and production of better and safer products. And this was a great example of that end-to-end. I'll just add that the patch was released in late June of 2019. We did do both static and dynamic testing of it to confirm that the patch was effective and that the mitigations that we kind of recommended to Avaya were properly implemented. And, you know, happy to say that that patch is effective. We think it's really important that especially large enterprises prioritize the rollout of this patch. Sometimes devices like this can be an oversight in a large corporate environment.

And as we talked about earlier, phones tend to not be the primary type of computer system that your IT or SOC is actually patching. But you can kind of see from the impact statement, from the demo, and from the conversation we've had that these should be treated as just as sensitive as any other critical server in your environment, whether those are used as an access point or a pivot point or whether they're directly attacked. These, again, are computer systems that allow you to gain privileged access into a privileged network and ultimately to achieve some pretty nefarious purposes. So we're strongly advising that anyone who uses these phones get those patches updated quickly after getting the patch tested.

And I suppose there's a bigger lesson here as well, that even if you have your devices patched and up to date, that there could be things still lurking in there that have yet to be discovered. things still lurking in there that have yet to be discovered? Absolutely. It would be remiss to say that fixing one vulnerability would overall make a product secure. And again, this comes full circle to what we started the call with here, which is the reason, the nature of why we do vulnerability research at McAfee is to push this industry forward as a whole, to encourage researchers to work with vendors, to do analysis of these types of products, to overall harden the attack surface, because we can guarantee that there are others out there, whether they're

individuals, whether they're nation states, whether they're groups of individuals working together that are well-funded, have significant resources and time, that are attacking and looking for these exact types of flaws. So it's kind of a race to see not only who can find them first, but overall, who can be successful in this battle of securing products before vulnerabilities are found. And ultimately, that's our goal in this process. Our thanks to Steve Pavolni from McAfee's Advanced Threat Research Team. The research is titled Avaya Desk Phone, Decade-Old Vulnerability Found in Phones Firmware. We'll have a link in the show notes.

Thank you. 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 deny approach can keep your company safe and compliant. The Cyber Wire 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 Cyber Wire 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, And I'm Dave Bittner. Thanks for listening.