A look behind the lens.

[ Music ]

Dave Bittner: Hello, everyone, and welcome to the CyberWire's "Research Saturday." I am 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 our rapidly evolving cyberspace. Thanks for joining us. [ Music ]

 

Noam Moshe: So, essentially, we looked at Axis, one of the major and leading brands in the world of camera surveillance. And the reason why we started looking for vulnerabilities in the Axis product line was because we noticed a very common trend of banning Chinese manufactured and made product lines and, essentially, leaving organizations with less options to pick from.

 

Dave Bittner: That's Noam Moshe, Claroty's Vulnerability Research Team lead. The research we're discussing today is titled "Turning Camera Surveillance on its Axis." [ Music ]

 

Noam Moshe: And this very like not saturated market of video surveillance and after the world of banning most, if not all, Chinese vendors, basically, left two, three, maybe four big players in the field. And, because of that, finding one critical vulnerability or vulnerability chain in one of these major vendors could lead to devastating effects affecting thousands of different companies.

 

Dave Bittner: Well, for folks who might not be familiar with Axis Communications and their camera systems, where are they from? Where are these products made?

 

Noam Moshe: So Axis is a Swedish company at its core, I believe. And we mainly see it in U.S. market. Now, it's important to say that Axis is not a home user camera, meaning it's not a camera I will set up in my home office or at my perimeter. Instead, it is more enterprise-grade, enterprise-ready essentially allowing organizations and big organizations to have up to like a few thousands of cameras as part of their camera fleet. So you will see them in big companies, like medium to big companies, and medical and educational institutions, governments, all sorts of locations.

 

Dave Bittner: I see. Well, help paint a picture for us here. My understanding is there is an Axis Device Manager and a camera station that play a critical role in managing this surveillance infrastructure. Is my understanding correct here? And why do those components matter?

 

Noam Moshe: So, essentially, when you have more than one camera, you need to have one centralized way to control, manage and consume the actual video feed of your cameras. And because we are talking about organizations that could have like fleets of thousands and tens of thousands of devices, they cannot control, manage and consume the feed from each camera directly. And, instead, Axis implemented like a centralized solution that allows them and allow users to control and manage and actually see the video feed of your entire camera fleet in one centralized location. And this is exactly what Axis Device Manager and Axis camera stations are. These are centralized servers that you install and, basically, through them, you are able to modify, backup, restore, control configuration and actually view the camera feed of all of your cameras in one location.

 

Dave Bittner: Well, describe for us what happened when you all went looking at their protocols here. What did you discover?

 

Noam Moshe: So, in our research, we wanted to see what kind of communications and what kinds of protocols we will see in the Axis ecosystem. And, soon enough, we discovered that Axis implemented their own custom proprietary protocol that we call Axis Remoting that allows a client and a server to connect and communicate with one another. Essentially, it's a closed source protocol, meaning there's no documentation, no open-source tools, no nothing about how this actually proto - how this protocol actually looks under the hood. It allows a client application to connect to these centralized servers and do - use the functionalities they expose. So, for example, if we're talking about Axis Device Manager, it allows that CIS administrators to control, configure, see the status of all the cameras. Now, while this protocol is fully encrypted, fully authenticated, essentially, giving users the impression that is fully secure and fully okay to expose it to the internet, we discovered a few vulnerabilities that when chained together could allow an attacker to, essentially, gain pre-auth remote code execution on these centralized servers. Now, this, essentially, allows the attacker without any prior knowledge, without credentials, without anything, just the ability to connect to the server, it allows them to execute arbitrary code and fully control the server itself and, thus, gaining two things. First, they gain pivot point and leverage into someone's network, an organization's network that actually deploys the Axis cameras. And not only do they control the server, they also control the cameras themselves. Because, at the end of the day, the use case, the business logic of this server is to control the cameras and manage them. And, because of that, once this server is compromised, you are able to move laterally and fully control all the different cameras and all the different fleets that this server manages, giving you access to both the networks and the cameras themselves, meaning the camera feeds and anything they are accessible to.

 

Dave Bittner: Now, you all uncovered a pass the challenge vulnerability. Can you explain to us what exactly that means?

 

Noam Moshe: Yes. So, essentially, we discovered four or five vulnerabilities. One of them was a pass the challenge vulnerability. And, essentially, what this vulnerability means is that it allows a user with a man in the middle setup, essentially, like an attacker that is sitting inside like in the middle of a client and a server's connection to intervene and, basically, take control over the connection. By using this man in the middle server, you expose your own server and, essentially, pass the requests from the client to the server and the responses from the server to the client. Now, one of the first thing that happen in this proprietary protocol is that the client must authenticate. And to authenticate users and make sure there are valid users, Axis chose to use NTLM SSP or NTLM challenge response. Essentially, it's a very common protocol in Windows-based networks and it allows a server to identify users as legitimate. The drawback of it is that it is susceptible to pass the challenge, pass the request attacks. So this means that if you achieve man in the middle between a Axis client and a server, you can allow the client to authenticate and pass authentication requirement for the server even though you are sitting in the middle and are able to fully inject and change and alter any response and requests whatsoever. So, that way, after the client authenticates, you are able to inject your own messages and responses from the client and the server and invoke different vulnerabilities in both that give you remote code execution on both sides. Essentially, allowing you to execute code on the client and on the server just by having this man in the middle position and passing the challenge that the server sends to the client and the response - essentially, the authentication response sent by the client. [ Music ]

 

Dave Bittner: We'll be right back. [ Music ] Now, another one of the issues that you highlight in the research is a deserialization issue. Can you unpack that for us?

 

Noam Moshe: Of course. So this is the core vulnerability and this is the core findings that allows attackers to execute arbitrary code on the client, the server. And, because they control the server, also on the cameras. Now deserialization is a concept, it's a development concept where, essentially, you need to take a class. First of all, deserialization is the opposite of serialization and both of them are the process of taking a class that is represented in memory. Essentially, you have your backend and you have this class and you want to send it over the wire, for example. And, to do that, you need to take the class and transform it into a way to actually send it over the wire because you can't send like memory address. You need to have like a representation. So, for example, you will take the class and represent it via textual text and, that way, you are able to send this text that actually represents the class over the wire. Now, the process of deserialization is exactly the opposite. You take something and you construct an in-memory class inside your memory space of that class. So, essentially, you take a string from the network and you construct a class from it. Now, in.NET, this is very dangerous if the user is allowed to control what type of class is created because serialization and deserialization are almost arbitrary approach that allows like the creation of multiple classes. So, if in a case, a user is able to control what kind of classes will be created on the server endpoint, then they could use what's called gadgets, which are dangerous classes, that could be used to gain full remote code execution. And this is exactly what happened in Axis Remoting. Essentially, this protocol relies on RPC and, in it, the client and the server send to one another serialized classes over the wire to allow them to invoke different functionalities in the other side. And, because we discovered that any side of this talk is able to fully control what types of classes will be created on the other side, you are able to inject malicious classes that will lead to code execution. So, essentially, if you exploit the man in the middle, for example, you are able to inject malicious classes to both endpoints and cause code execution on both the client and the server.

 

Dave Bittner: Now, in addition to that, you all discovered there was a fallback HTTP protocol that had anonymous access. Am I getting that right?

 

Noam Moshe: Yeah, exactly. So, while we did gain full remote code execution, we, at that point at least, still required man in the middle position, essentially, making the vulnerability not fully exploitable in real-life scenario because we want full pre-auth remote code execution without needing to be able to man in the middle connection from a legitimate client, which is, of course, less realistic when trying to attack internet-exposed services. And, because of that, we wanted to be able to bypass the authentication requirement altogether. And, to do that, we used, exactly like you've said, a fallback mechanism in the Axis Remoting protocol that allowed a client that is not accessible to the main server of the management server, the main like port of the management server to communicate with it on a different port. And, in that different port, there was a different protocol that still had the same vulnerabilities of the Axis Remoting protocol, the same deserialization vulnerability. However, the only difference is that we found an additional vulnerability in that fallback protocol that allowed us to bypass the authentication requirement altogether. Essentially, allowing us to chain these two vulnerabilities together. We use the fallback protocol to bypass the authentication and begin speaking in Axis Remoting. And, once we do that, we are able to send serialized classes that are malicious and exploit the decentralization vulnerability in the Axis Remoting, giving us full remote code execution that is fully pre-auth, no requirements are needed whatsoever. No prior knowledge, no nothing.

 

Dave Bittner: Wow. Now, help me understand here, once you all got remote code execution on the server, you use the Axis SDK to move laterally and, ultimately, get to the cameras?

 

Noam Moshe: Exactly. At the end of the day, the server's main purpose is to control the cameras. Through the server, CIS domains are able to connect, control, modify their cameras. And to - because we managed to fully exploit the server, we wanted to move laterally to the cameras. So we used legitimate functions, the legitimate functionality of Axis to be able to implement your own packages. Essentially, Axis offers users and CIS admins to be able to modify their camera's behavior by adding a package to the set to the camera. And, through this package, you are able to modify its behavior, change how it reacts, what it does, anything that you want. And, to do that, Axis offers their own packages and they actually allow users to build their own packages through an open-source SDK. So, once we gain - we were able to exploit our vulnerability chain to gain control over the Axis management servers, we built our own malicious package that we infected all the cameras that are managed by this server. Essentially, giving us roam-like capabilities allowing us to move laterally from the server to all the cameras it manages. And, once we did that, we have - we gain two things. First, we gain network accessibility. At the end of the day, this gives us full control over all the devices and all the IP cameras that this server manages. We are sitting in many different networks, many different LANs and many different physical locations. So we are able to move laterally, we are able to attack, do ransomware, anything that we want. However, in addition to that, because, at the end of the day, this is an IP camera, we are able to even control, consume and abuse and confuse this - the camera feed. Originally, when we started the research, my main goal was to implement a James Bond or Mr. Robot style of attack where you are able to actually interfere with the camera feed. So, once you control the camera, you are able to, A, access the feed, giving you full espionage capabilities and, B, you are able to control it. You can close the camera, you can rotate it, you can change the actual feed and replay an old video, whatever you want. So it gives you full control over the cameras.

 

Dave Bittner: Well, how widespread do you think these vulnerabilities are? I mean, did you get a sense for how many organizations might be affected by this?

 

Noam Moshe: So, once again, the main issue is that - not actually an issue, but the main thing is that Axis is one of the leading brands and leading manufacturers of IP cameras. And, because of that, they are seen in many, many different organizations, going all the way from big companies, medical, health and even government agencies. Now, currently, we are observing around 6,500 different servers that are sitting worldwide with almost 4,000 specifically in the U.S. However, it's important to remember that these servers are not standalone servers. They are actually managing different cameras that could be numbered in the thousands as well. So, essentially, behind every one of these servers, there could be a fleet of cameras that is up to like a few thousands or tens of thousands of cameras. And, by exploiting these vulnerabilities and these open services online, you are able to gain initial foothold and full control over the video surveillance of all of these organizations.

 

Dave Bittner: Now, I know you and your colleagues responsibly disclosed this to Axis. What was their response?

 

Noam Moshe: So we worked with Axis in collaboration and we responsibly disclosed this vulnerability to them. Meaning, once we discovered the vulnerabilities, we immediately contacted them, gave them the full technical report and worked with them to make sure that their client are protected. And I can tell you that after doing probably over 100 different disclosures over the last four years, Axis were one of the better ones. They were super professional, super prompt to action and their main goal was to make sure that all of their clients and their users are protected and not exploited. And we work with them and our goal, and we had a shared goal, was to make sure that these vulnerabilities are patched as soon as possible. And, once we reported these vulnerabilities to them, it took between a few weeks, a month or two to all the vulnerabilities to be fixed, depending on the technical difficulties of implementing a patch.

 

Dave Bittner: So, based on your research here, what are your recommendations for organizations who may have these kinds of cameras or perhaps another brand as well? And any words of wisdom here?

 

Noam Moshe: So the first thing I believe CIS admins and IT admins and users in general should take is that having fully encrypted, fully authenticated protocol does not mean full security. At the end of the day, everything has vulnerabilities in it. The only question is how exposed it is and how much effort a threat actor puts into breaking them and finding vulnerabilities. And just because a service is fully encrypted does not mean that you immediately can expose it to the internet and say, "Yeah, I mean, no one can see what's going on here, it's encrypted and they need proper credentials so they can't connect to it." Just by having an encrypted service does not mean it is more secure because you are not aware of what's going on under the hood and what kind of vulnerabilities could lie down deep under the protocol. So encryption, while it's good, it's important, is not - does not mean security. A service can be encrypted with the most up-to-date standard, but still have vulnerabilities in it. So know what you exposed, have good network hygiene, meaning know what you have in your networks, what kind of services, what kind of attack surface you expose online and what are the risks and how you take them into account then manage them responsibly. [ Music ]

 

Dave Bittner: Our thanks to Noam Moshe from Claroty for joining us. The research is titled "Turning Camera Surveillance on its Axis." We'll have a link in the show notes. And that's "Research Saturday" brought to you by N2K CyberWire. We'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you a step ahead in the rapidly changing world of cybersecurity. If you like our show, please share a rating and review in your favorite podcast app. Please also fill out the survey in the show notes or send an email to cyberwire@n2k.com. This episode was produced by Liz Stokes. We're mixed by Elliot Peltzman and Tré Hester. Our executive producer is Jennifer Eiben. Peter Kilpe is our publisher. And I am Dave Bittner. Thanks for listening. We'll see you back here next time. [ Music ]