One common pattern in password resets is sending a one-time password to the user to enable them to reset their password. The flow usually looks like:

1. User Requests a password reset
2. The user enters an e-mail address or phone number that is already registered with the application
3. The application may ask for a password reset question
4. The user now receives a random code that is entered into the password reset page
5. finally, the user can reset their password

Overall, this approach is not terrible. It is similar to sending a one-time password reset link via email but avoids the issue of the user having to click on a link (which may be difficult with some mobile applications). This reset method tends to work better with users using mobile phones as they may be able to receive the code via SMS. Or, if they use a "fat" email client on a desktop, they can easily type the code into the mobile device.

But there is a critical issue that is often overlooked:

The page verifying the code MUST implement some basic brute force protection. Otherwise, it tends to be easy to brute force the code, which is often just a five or six-digit number. Of course, this assumes that the code is random! More about this later.

This has been an issue a few times already. Facebook, for example, suffered from this weakness last year. Only a limited number of attempts should be allowed to implement some brute force protection, and the time the code is valid should be constrained. In my opinion, for an "average" site, five attempts and 30 minutes seem reasonable.

One reminder that this is still an issue came today from our "First Seen URLs" page. While not an actual "First Seen" URL, the URL

/PSIA/Custom/HIK/userCheck

had a bit of a breakout with more users than normal reporting honeypot hits for this URL.

An exploit for the Hikvision issue has been available since 2018 when Rasmus Moorats published a blog with some code showing how to exploit the vulnerability [1]. Rasmus even went a significant step further. With access to the firmware, he could decompile it, and reverse engineer the function used to create the reset code. Turns out that the code was not random at all, but instead derived from the UPNP data. This data can be retrieved without authentication. You do not necessarily have to be on the same network, but an HTTP request for /upnpdevicedesc.xml is all it takes.

[1] https://nns.ee/blog/2018/08/01/hikvision-keygen.html

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|