ClickToPray eRosary Account Takeover

Exploiting the eRosary Application

In this post we’re going to cover a trivial full account takeover vulnerability our team identified within the new eRosary application, whilst placing an order for the watch!

The ClickToPray eRosary beads are advertised as ‘an interactive, smart and app-driven device that serves as a tool for learning how to pray the rosary.’ and with that it also includes fitness tracker like functionality.

There appears to be three ways to login to the app:

• Google Authentication
• Facebook Authentication
• Traditional e-mail login – this is the problematic setting which does not permit for a password, but rather a 4 digit pin.

The 4 digit PIN controls access to the application and upon resetting a user account, is sent to the registered e-mail.

When the application requests a PIN to be sent it calls “resend_pin”, which sends the pin to the email but catastrophically also returns the PIN the API’s response; making it possible for anybody to obtain the 4 digit PIN being sent WITHOUT e-mail access.

An example of the POST request being made for the user account can be seen below:

The API response which is returned to the user containing the PIN (which is also sent to the registered e-mail) can be seen below:

 

Armed with this, we can simply log in to the application with the provided pin compromising the account with minimal effort. The account contained: Avatars, phone numbers, height, weight, gender and DOB’s.

The application’s choice to use a 4 digit PIN authentication is interesting, as even without this oversight it would be relativity easy to access an account due to a lack of rate-limiting on the API. Although, the application does limit users to one attempt every 60 seconds.

Our proof of concept used for this exploit can be found on our GitHub account.

Fix

The fix was released within 36 hours of the issue being reported. Interestingly, it is still possible to utilise the above vulnerability to retrieve a PIN, albeit the response from the API now gives 8 digits whereas the e-mail from the application provides a correct 4 digit PIN.

There doesn’t seem to be any direct correlation between the new 8 digit PIN and the correct 4 digit PIN which is sent via e-mail. It is likely the data returned is not random but rather is obfuscated although it has not been possible to reverse engineer the algorithm used… yet.

Disclosure

[*] Vulnerability Identified – 17/10/2019

[*] Vulnerability Reported – 17/10/2019

[*] Vulnerability Acknowledged – 17/10/2019

[*] Patch Released – 18/10/2019

[*] Blog Released – 18/10/2019