We believe that they had seen something different: our requests to the API to determine if a serial existed or not. They believed they had detected some of our requests as they weren’t correctly formed, so took action to fix the API. After a bit of to-ing and fro-ing via their PR agency, we had a call from their CTO, which proved really constructive. DisclosureĪs the BBC had contacts at Swann for the previous story, we asked for an introduction to them. 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. So, one could now access arbitrary cameras. We believe the keyspace could be fully enumerated in as little as 3 days, given a distributed set of concurrent requests to the API. Vangelis ( of the Tapplock API vulnerability fame) took a look at the API & realised that it allowed enumeration in the request:ġ.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: The serial is of the form swn then 9 hex chars. However, we already knew the serials, so this isn’t an interesting attack yet. Alan Woodward and Scott Helme also had identical cameras, so between us all, we switched feeds between our cameras. Yes, it was that simple to trick the app into thinking it is talking with another camera. Here’s us accessing Scott’s camera on his desk about 200 miles away. This made a request to deviceWakeup using the modified serial, then the OzVision tunnel to the device was established using the modified serial. We are using Charles here, but Burp or MITMproxy will do it too: At this point the mobile app sees the details of someone else’s camera. We replace the serial number (deviceid) in the response from the server. Normally, these are genuine owned cameras. This returns a response containing the devices associated with the account. When logging into the system, a request is made to userListAssets. The serial is easily found in the mobile app: This is both for the Swann-specific web API and the OzVision peer-to-peer tunnel. Digging through the app and the hardware, it became obvious that it’s a T&W camera and the cloud is provided by Ozvision.Īfter reviewing the API endpoint and APK, I quickly realised that the serial number (swnxxxxxxxxx) is the primary identifier of the camera on the platform. Quite a nice form factor and battery life is pretty good. It’s a battery powered HD camera that can stream video either direct over the local network or via a cloud service. Further, they initially deflected direct questions about the issue back to Swann. 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. However, their cloud service provider Ozvision was a different matter. Yes, there was a bug, but they dealt with it fast. Their CTO was very proactive and had daily calls with us. Swann, in fairness, were really responsive and took quick action to mitigate the attacks. We found a bunch of other interesting issues too. This was an unrelated method to the original story. We successfully switched video feeds from one camera to another through the cloud service, proving arbitrary access to anyone’s camera. 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. It wasn’t clear how this happened, but we were intrigued, so we bought several of the cameras in question to see for ourselves. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |