tl;dr: Hikvisions cloud services (hik-connect.com) rely on a cookie value to determine with what user you are logged in.Changing the user id cookie value with another users id results into you being logged in as that user.While the user id is a hashed key we found a way to find out the user id of another user just by knowing the email,phone or username they used while registering, after that you can view the live feed of the cam/DVR, manipulate the DVR, change that user’s email/phone and password and effectively lock the user out without leaving him an option to reuse that device with hik-connect even after a factory reset of the device.
What to do on a slow Friday…
After reading cybergibbons tweet about having 13 of the same camera model I remembered that I have a DVR on my home that I have never played around with and it was a REALLY SLOW Friday so I pinged my friend (and regular partner in all thing cyber) George Lavdanis and started tinkering stuff :). We are both mostly web guys so reversing the firmware was probably our last resort.
I found out that my DVR wanted to update to a new firmware and that update was introducing a new cloud service (hik-connect.com) that would help you access your camera without port forwarding on your router.As a friend says: “don’t look at the individual devices when you can look at the backend and pwn everyone”.
Identifying the bug
Creating a user on hik-connect.com and playing around none of the usual suspects (DAO or some logic flow error) stand out until we looked at the cookie. There we saw that there was a LOT OF DATA. Username , user id and more stuff. We tried changing the username (AS_Username) and after a refresh we found the new (changed) value on the page. Ok no harm there is not a chance that this is the case with the user id (just trust the cookie without actually checking the session first).
Created a new user to verify that.After creating the new user we used the first users userid as the cookie value on AS_UserID and…F**K, we can see the users devices.
So we have confirmed that we can login as any user given that we know his/her user id. User id seems to be a hash (probably a salted md5) and not a sequential number so there is a danger but not that big. We spent quite some time trying to reverse it but seems that its either an md5 with a pretty good salt, a random string or an md5 of a random string that is assigned to the user upon registration. We quit trying to reverse it as it seemed to be a dead end.
User id hunting
We then tried to find a user list or something that would give us a way to find a user id by providing some user info. Password reset could enumerate users by email, share device could also enumerate users existence by email or phone but was just returning a status code and nothing meaningful. We were pretty disappointed as we had a pretty nice bug that we couldn’t really use. At that point George found out that our existing credentials were also working on ezvizlife.com . Ezviz is a different (older?) cloud service for hikvision which is mostly active x so it needed internet explorer and windows (and no chrome or firefox tools).
So lets fire up a virtual machine and explore it! It’s mostly the same functionality BUT it also has another feature , you can mark a user as a friend with no interaction needed by the other user just by knowing the email or phone that the other user used upon registration (searching was using the endpoint queryByMobile.json and was returning the same status codes as the the search on hik-connect.com site).
After befriending the user we saw an md5 hash in the url and started celebrating but that was wrong (bummer…).
After that, we explored a couple more ways of obtaining user ids but everything was a dead end. After everything we retried queryByMobile.json and it was returning WAY more than the usual status code (WTF just happened?). Re-validating and yes we have user ids…
It seems that after you mark a user as a friend you can query him and you get a userDTO which also has the (wanted) user id! So now we can login as any user as long as we have his email, phone number or username (endpoint was also returning data for username although there was no UI for it) and impersonate him. That is highly critical so we wrote a small report and send it to Hikvision.
Exploitation of the bug
After that and while waiting for Hikvision lets see WHAT can we do from hik-connect and ezviz:
- We can (obviously) see the devices of the user, live video and playback from the device.
- We can change the user email and phone number and effectively take over his account after resetting his password (in order to do that we will need to logout and click on forget password AFTER changing email/phone and input a new password).After that even factory reseting the device will not unbound it from our account.The victim will have to contact hikvision to do that.
- If we change the password we can use the devices menu on the hik-connect android app and manage the device (update firmware and brick it or do whatever we want) without any password given.
- We could be more silent and just add a share on our own account and the user will never know that we are watching if he is not checking the sharing tab in his app regularly.
- Enumerating users with existing email, phone, user lists and then exploiting could lead to a HUGE data leak
- Enumerating users with known hikvision employees emails and then using their elevated accounts (NOT verified as this would be highly illegal).
- When sending feedback via the hik-connect iphone/android app you get assigned a WishlistResponsiblelist that seems to be a Hikvision employee.Guess what ? A userid also exists in there. (NOT verified if we can login with that user id though)
- 20/4/2018: Reached out to hikvision for guidance on proper disclosure procedure
- 21/4/2018: Hikvision responded.
- 21/4/2018: Vulnerability report sent.
- 23/4/2018: Hikvision responds that this will be fixed “by this week”.
- 24/4/2018: Hikvision released a fix on the issue at 2 p.m. and notified us.
- 24/4/2018: Verifying that Hikvision has nothing else to release before we publish this article.
If you are a developer never EVER trust anything from the users. Filter, check and sanitize external input.
If you are an end user try to keep your devices updated and limit your IoT devices via network segmentation.This vulnerability is a nice example of how a service that was developed to help towards extra security (no port forwarding and no IoT exposed on internet) backfired spectacularly. We don’t know of any way to protect against these kind of attack other than use only products from well known vendors (which may also have issues of course but would have better monitoring and will respond -and not ignore everything like trackmageddon vendors-) or not use those devices at all.