Traditionally, closed circuit tv (CCTV) cameras and digital video recorders (DVRs) have been stand-alone, self-contained systems. If the ability to access these systems remotely was required it was most commonly achieved by opening a port on a firewall and allowing access from the Internet to the DVR or camera directly. Although effective, that method of access left what was in many cases a potentially vulnerable device exposed to the Internet and your internal network. Case in point: our previous blog post on Dahua DVRs.
Cloud services seemingly provide a much better access option for these devices. Instead of allowing inbound access into your own network from the Internet, you could simply enable what is typically a proprietary cloud service for your flavor of device. That configuration would allow the DVR or CCTV camera to communicate to the cloud service on the Internet. Any remote access or monitoring would occur by accessing the cloud service. There would be no inbound access through your firewall and even a vulnerable device would not be exposed to the Internet at large.
Cloud services can certainly provide security benefits such as not having to expose your CCTV DVR to the internet to view cameras remotely. But there’s a yin to that yang. If an attacker finds a flaw in the cloud, there is no need to scan the internet for DVRs because there’s now one place of access to all of them. For those of you who are already done reading, here’s a synopsis of the rest:
- I got a new FLIR/Lorex DVR in hopes of viewing it through the FLIR cloud without exposing it to the internet.
- The device I received was a Dahua-manufactured DVR.
- I found a flaw in the FLIR Cloud that allows anyone build a tunnel to any port on any FLIR Cloud-connected DVR, so long as they have the device ID.
- I found device IDs on the internet, picked one, tunneled into it, and was able to gain unauthorized access by exploiting a known Dahua issue. These devices support a maximum of 6 character passwords.
- You should care because an attacker who has guessed or happened to view your device ID can build tunnels into your private network to attack weaknesses in your DVR’s various interfaces.
I’ve owned 3 home CCTV systems, the most recent two both being DVRs manufactured by Dahua. I’ve always marveled at the features provided by these consumer-level DVRs at such a low price point. I’ve also been stunned as to how much of an afterthought security seems to be for a product that is, by its definition, a security appliance.
I had to take my first Dahua system off the public internet because I found that Dahua’s proprietary binary protocol did not perform authentication or authorization. I wrote a proof of concept Metasploit module that was later added to the main branch after some work by others in the security community. It allows you to just send the command to say, change the admin’s password. When working with Dahua on that issue, they stopped responding so I had to just disclose it. I told myself I’d never poke a hole through my firewall to a DVR again. Earlier this year another researcher published another means of gaining unauthorized access to Dahua DVRs but this one used their janky web interface on HTTP/80. Default or predictable root telnet passwords are another issue that has plagued these devices in the past.
Last year I noticed the company FLIR, most noteworthy for the “Forward-Looking InfraRed” cameras they sell to law enforcement/military, had acquired Lorex Technologies, a consumer CCTV company. Lorex by FLIR was offering cloud-enabled DVRs that supported 1080p resolution using my existing coax. “Nice,” I thought, “Now I can check my cams from anywhere without publicly exposing them on the internet.” I bought a system, booted up the DVR, and found it was Dahua. “Oh well. FLIR Cloud! No inbound ports!” I naively told myself.
Connecting to the system is easy but made complicated by the sheer number of client applications. You have the FLIR Cloud CMS available in Windows or MacOS. There are also Android and iOS versions of FLIR Cloud. Then there’s the FLIR Secure mobile apps that seems to access the video in a different way. The DVRs have web interfaces that require special browser plugins as well. After a little research, the problems I discovered resided in the FLIR Cloud itself and the way Windows and MacOS Cloud Client software connected to users’ DVRs.
When I first connected my DVR to FLIR Cloud I noticed all I had to do was enter the device ID as well as a username/password to my DVR. The device ID was fuzzable: a model-specific three-letter prefix followed by 9 hex digits (MMMHHHHHHHHH). The device was brand new so the username was admin and the password was 000000. FLIR Cloud did make me change the default password but it still enforced a max length of six characters. It seemed like all I needed to access a new DVR was its device ID and default creds.
At this point I started to get concerned that something in the FLIR Cloud software was building a tunnel to the DVR based strictly on the device ID as a means of authentication. It sure looks like if if you watch their setup videos:
I ran a packet capture while adding my DVR in FLIR Cloud. I saw a DNS request go out to resolve an A-record that is: DEVICE_ID.INT.OZVISION.OZSN.NET. Then I saw UDP traffic to whatever that resolves too. Among all that was a STUN negotiation. After this, the FLIR Cloud Client app started to communicate directly to…. my home IP address. So much for not exposing the DVR to the internet. Maybe it used UPNP to open the port or something I thought.
But wait. After the DNS resolution, the first UDP packet appeared to authenticate with whatever service the DNS resolved to. What is Ozvision? Who is Ronny Weiser? Apparently Ozvision is a cloud-based video service partnered with Dahua.
The response looked like an authentication success message.
I took a look in the Windows FLIR Cloud folder structure and found this. A private key and cert for Ronny Weiser.
Then I found this binary, “P2PClientAPP” in the MacOS “FLIR Cloud Client.” I ran it with no arguments and it basically took a device ID, and optionally some local/remote port arguments, and built a tunnel to the device from there. That’s pretty bad. Considering how vulnerable Dahua DVRs have been in the past, that a new auth bypass was released just recently, that they only take six character passwords at a maximum, and that we were tunneling through people’s firewalls into a potential internal pivot point, I didn’t really want this device on my network all of a sudden.
Both of these seemed to be affected by the same issue.
People had posted images of their DVR device IDs on the web. Many of these were tutorials from resellers who didn’t know the significance of the ID and then possibly resold them unwittingly.
I wondered, were any of these things affected by the recent Dahua auth bypass through port 80? FLIR seemed to have issued firmware updates but claimed in their security advisory that the FLIR Cloud would prevent compromise. This is one of the benefits I heavily considered when I decided to buy the system. Unfortunately, that all breaks down when FLIR packages the key and tool to tunnel into DVRs based only on their device IDs.
I connected to a DVR at random on port 80.
Alright, there’s the web interface on it.
I’ll try and retrieve the hash using the public PoC for that recent auth bypass.
Dang, this one was vulnerable. JTR has a hash type for Dahuas. The password to this DVR ended up being an old default Dahua password. Cracking these is always a forgone conclusion with a max password length of 6 characters.
Now I can just make a new tunnel to the video feed port, 35000.
So there’s the video. This one was at a major restaurant chain. What is more concerning for me is that there may very well be some RCE issues in these devices. We’ve already seen these things used in DDoS attacks. Given the right vuln, could one script this up and compromise the entirety of the FLIR Cloud in a night or two? I’m also worried about them being used as initial pivot points in more advanced attacks. These devices won’t show up on enterprises’ external network port/vuln scans.
The way I saw it, there were at least two things wrong here:
- Some FLIR Cloud-enabled DVRs were prone to the recent Dahua vulnerability. Dahua seemed aware of it so I wondered if the device I connected to was not patched, or possibly some version that FLIR didn’t know was still vulnerable.
- There is essentially no authentication to tunnel into any FLIR Cloud-joined device. The MacOS and Windows Cloud Client software were bundled with a certificate and contained CLI tools to create tunnels to arbitrary internal TCP ports on the devices.
At this point I began the disclosure process. I wish I could report that in 2017, that this is always a routine and smooth process, and that the affected vendor is willing to quickly implement a fix. I have one of these things at home so I take zero pleasure in dropping this before they’ve fixed the insecure FLIR Cloud access. It wasn’t easy even finding a disclosure contact at FLIR/Lorex. I disclosed this on 5/9/2017 and then agreed not to publish it more than 90 days from the disclosure date at FLIR’s request. They purport to have resolved item #1 but apparently had no intention of fixing their insecure cloud access by that date. So here we are, over 150 days later.
If you don’t want anyone with your device ID being able to bang against your DVR’s various Dahua DVR interfaces, consider shutting it down. I’ve tried disabling UPNP on my network and I can still tunnel to my DVR with just a device ID. I’m not sure exactly how their cloud works and they weren’t exactly candid when dealing with me. Somehow they build STUNNELS on demand. I imagine someone with more time may take this farther.
Disclosure Timeline:
- 5/9/2017: Discovered FLIR Cloud unauthorized access issue
- 5/9/2017: Initial contact to support@flir.com, support@lorextechnology.com, sales@flir.com, & sales@lorextechnology.com; received no response
- 5/9/2017: Could not find appropriate incident response contact at FLIR/Lorex
- 5/9/2017: Reached out to a FLIR security contact on LinkedIn, who forwarded the message to Vlad Kardashov (VP of Engineering)
- 5/10/2017: FLIR responded asking details.
- 5/10/2017: Sent FLIR the details of what I found.
- 5/12/2017: FLIR acknowledged the details and asked for our disclosure timelines.
- 5/16/2017: I responded and told him 90 days.
- 6/20/2017: I asked for a status update.
- 7/6/2017: FLIR responded confirming the issue with no detailed information, and asked if we could target August for public disclosure
- 7/6/2017: I agreed to target August.
- 8/30/2017: After noticing a firmware push to my DVR, I again asked for a status update.
- 8/30/2017: FLIR responded explaining that the firmware should have fixed the issue.
- 8/31/2017: I told FLIR the network access was still vulnerable but the recent Dahua vulnerability appeared patched. I specifically asked for FLIR’s plans on fixing the insecure Cloud access issue.
- 9/6/2017: FLIR responded with new information about a two-phase remediation plan he had never mentioned. The first phase was fix the Dahua issue and within a few weeks they would fix the insecure Cloud access.
- 9/16/2017: I asked FLIR the following questions:
- “When are you fixing the tunneling authentication issue?
- How do you plan on fixing the tunnel authentication issue?
- When are you going to update your advisory, (http://www.flir.com/securityinfo/) to include the models that you rolled out the patch for, like mine?
- Which models did you roll that out for?
- Do you intend to issue an advisory when you fix the tunneling authentication issue?”
- 9/18/2017: Last response from FLIR: “Let me discuss internally, I’ll get back to you by end of the week.”