Hacking Swann & FLIR/Lorex home security camera video

A few weeks back we read a story on the BBC web site about a BBC employee seeing someone else’s video footage on the mobile app for their home security camera.

It wasn’t clear how this happened, but we were intrigued, so we bought several of the cameras in question to see for ourselves. We put a team together to work on this, made up of me, Chris Wade and Ken Munro from PTP, plus the awesome Alan Woodward, Scott Helme and Vangelis Stykas.

TL;DR?

We successfully switched video feeds from one camera to another through the cloud service, proving arbitrary access to anyone’s camera. This was an unrelated method to the original story.

We found a bunch of other interesting issues too.

Swann, in fairness, were really responsive and took quick action to mitigate the attacks.  Their CTO was very proactive and had daily calls with us. Yes, there was a bug, but they dealt with it fast.

However, their cloud service provider Ozvision was a different matter. We suspect they knew about this issue for about 9 months, only fixed it when pressured by Swann and we are confident the vulnerability was present in at least one other major camera brand to which they provide a cloud service. Further, they initially deflected direct questions about the issue back to Swann.

The camera

It’s a battery powered HD camera that can stream video either direct over the local network or via a cloud service. Quite a nice form factor and battery life is pretty good. Digging through the app and the hardware, it became obvious that it’s a T&W camera and the cloud is provided by Ozvision.

AND

After reviewing the API endpoint and APK, I quickly realised that the serial number (swnxxxxxxxxx) is the primary identifier of the camera on the platform. This is both for the Swann-specific web API and the OzVision peer-to-peer tunnel. The serial is easily found in the mobile app:

When logging into the system, a request is made to userListAssets. This returns a response containing the devices associated with the account. Normally, these are genuine owned cameras.

We replace the serial number (deviceid) in the response from the server. At this point the mobile app sees the details of someone else’s camera. We are using Charles here, but Burp or MITMproxy will do it too:

In the app, one simply presses ‘play’. This made a request to deviceWakeup using the modified serial, then the OzVision tunnel to the device was established using the modified serial. We could then watch the camera live.

Here’s us accessing Scott’s camera on his desk about 200 miles away. Lego envy!

Yes, it was that simple to trick the app into thinking it is talking with another camera.

Finding camera serial numbers

We were only working on our own cameras. Alan Woodward and Scott Helme also had identical cameras, so between us all, we switched feeds between our cameras.  However, we already knew the serials, so this isn’t an interesting attack yet.

The serial is of the form swn then 9 hex chars. That’s a big keyspace, but not THAT big. Vangelis (@evstykas of the Tapplock API vulnerability fame) took a look at the API & realised that it allowed enumeration in the request:

1.1/osn/deviceIsOwned

1.1/osn/AccountAddDevice – this will throw an error if the camera is already paired, hence allowing one to determine if a camera serial exists or not, as displayed here in the mobile app:

We believe the keyspace could be fully enumerated in as little as 3 days, given a distributed set of concurrent requests to the API.

So, one could now access arbitrary cameras. We didn’t access cameras other than the ones our group owned, as that wouldn’t be ethical without permission from every owner, but the point was proved.

Disclosure

As the BBC had contacts at Swann for the previous story, we asked for an introduction to them. After a bit of to-ing and fro-ing via their PR agency, we had a call from their CTO, which proved really constructive.

They believed they had detected some of our requests as they weren’t correctly formed, so took action to fix the API. We believe that they had seen something different: our requests to the API to determine if a serial existed or not. We believe it would be very difficult to detect if a video stream had been switched, as it was part of normal operation of the API and mobile app.

A fix had already been put in place by Ozvision several days prior, they claimed. We checked again that evening and successfully switched serials and accessed each others video feeds again.

Hi Alan’s desk!

The next morning however, the technique no longer worked. Whilst we dispute the exact date of the fix, at least it had been resolved.

This shouldn’t have been possible, but it was quickly fixed before public disclosure. A good result in our opinion and a positive reflection on Swann. Yes, it would have been much better if the issue wasn’t there in the first place, but they did the right thing in responding fast.

More findings

We found a weird issue with one of our cameras. Occasionally, when de-authenticating it over Wi-Fi, it appeared to reset the camera and force it in to access point mode. From there, one could recover the Wi-Fi PSK. Not great, as someone outside the house could recover the key and join your Wi-Fi network. Very similar to the Ring Doorbell hack we published a while back.

However, it only affected one of our cameras at an earlier firmware version and was a really unreliable attack. We can’t replicate it consistently and Swann couldn’t verify our findings. We’ll park that one as interesting but very low risk.

Local attacks were very interesting. The camera can be mounted outside the house to detect intruders. It’s easily removed owing to the magnetic mount, allowing an attacker to factory reset it. Once this was done, my colleague Chris Wade discovered a number of issues:

Factory reset ineffective: we noticed that whilst the manual states that factory resetting the camera will remove the wireless configuration, it leaves the PSK in logs. Yes, the wpa_supplicant.conf is overwritten, as indicated in the user manual, but device logs contain the SSID and PSK! This is fixed in later firmware.

Once reset, the camera enters soft AP mode, so anyone can connect to it without a PSK. From here, one can recover the PSK from the logs discussed above and join the home Wi-Fi network:

Root FTP shell and persistence?

Once connected to the soft AP, we found FTP open and located the firmware update file “electra_upgrade.7z”, which contained a squashfs file.

This filesystem contained the /etc/shadow file with a root password set using MD5Crypt (the weakest hashing algorithm you can use really), we ran this hash through john the ripper and in minutes discovered that the password was “twipc”, allowing a root FTP shell on the device.

From here, one could probably push rogue firmware and create a persistent shell.

Whilst the serial switching issue has been fixed, we think it’s more of a patch than a full fix. The camera now clicks audibly when rogue wake up requests are sent, which we think could be used to drain the battery. Maybe a better fix is coming soon?

Whilst researching around the subject after our initial findings, we found this that suggested a similar-ish attack was possible for a related Ozvision cloud service for FLIR-FX cameras. This suggested to us that Ozvision knew or at least should have known about this vulnerability for nearly a year. It was the first hit on Google for us when searching ‘Lorex’ + ‘Ozvision’!

Deeper cloud service problems

We also have our own FLIR-FX / Lorex branded cameras here, so double checked the findings from Depth Security on these.

Depressingly, we found the same serial switching problem with these.

That means that, despite this blog having been in the public domain since October 2017 and FLIR having acknowledged the vulnerability (read the end of the blog), neither Ozvision nor Lorex has remediated the issue. It’s worth noting that FLIR sold Lorex to Dahua in February 2018, so maybe the vulnerability was lost in the acquisition? That’s still no excuse though.

Remediation

The serial switching issue has been fixed.

More recent firmware will resolve the factory reset/PSK persisting issue.

Coming firmware will resolve the root password issue.

Advice

As a consumer, I would be pretty bothered by the potential for someone else accessing my home video feed. Swann acted promptly and resolved the issue as soon as they became aware of it.

However, the deeper Ozvision cloud service issue is more concerning. It appears to be a known issue that has gone unfixed for months. I’m disappointed that only after attention from the media was the issue addressed.

Conclusion

IoT vendors: if you’re integrating third party services, you have a responsibility for assuring their security.

Imagine if a malicious hacker had discovered this vulnerability and not gone through a disclosure process with the vendor? Your customer data and sensitive video feeds could have been splattered all over the internet. That could have been a PR and maybe GDPR disaster.

Don’t just take your suppliers word for it: get it checked thoroughly.

IoT cloud service providers: don’t confuse authentication with authorisation, it’s critical that the user can only see the content that’s intended for them. Ensure that your developers understand and practice a secure development lifecycle, point them at www.owasp.org for starters.

Consumers: Swann products should become a lot more secure after this incident, though these aren’t the only security flaws we found. It sounds counter-intuitive but, in my experience, products from significant brands that have had vulnerabilities found in them usually end up becoming much more secure as a result. The business doesn’t want to go through the pain of a security incident again, so invests in- and improves its security processes.

Update your mobile app and firmware in your Swann cameras to the latest version. You’ll be a whole lot more secure then.