Skip to main content

How password reset module compromised all accounts within the mobile application

Illustration of How password reset module compromised all accounts within the mobile application
Marcin Zięba

Password reset security

Every mobile or web application should allow user to reset his/her password. The cause could be as simple as forgotten password, but such mechanism could also save hijacked account (of course if attacker is not able to change user’s email).

The secure design of password reset module should focus on best security practices like:

• Preventing from user/email enumeration, • Preventing from token guessing, • Preventing from token reuse, • Token should have limited lifetime, • Making sure that account is not locked when password reset has been initiated, • Password change logging, • Passkeys correlation*

*If application utilizes passkeys, password reset should be considered as an additional attack vector. This, however, could be a topic for another article).

Where all seemed normal

During most recent mobile application pentest another point to consider came out, which was a big surprise.

The password reset flow was as normal as in every other application.

Have you forgot your password? Please provide an email which was used during the registration

After the button was clicked, as usual, user was taken to login page where another usual information was provided:

According to prompted information, user has received an email with password reset link:

Then what’s wrong?

But what happens if we intercept mobile traffic and check client-server communication?

The request below is sent when the initial reset password button was clicked:

The below response contains the surprise – the same token which was delivered to provided email address is provided in the response body:

Screenshot below presents a page which is displayed after clicking the link above:

Such behavior opens a possibility to provide any email corresponding to existing application user and then simply open a password reset link from a response in order to set a new password for the selected account.

Lesson should be learned

Such behavior may result with catastrophic effects from technical and legal (GDPR) perspective, if persists on the production system.

Make sure that the mobile application is subject to regular security audits in order to discover vulnerabilities in the APIs before attackers exploit that in the wild.

Additional security countermeasures such as SSL Certificate Pinning should be in place – this should not be treated as a main defense, but more like an extra layer (same as WAF) which could deter attackers by forcing to allocate additional time to for analysis.

Other Insights

Illustration of The Legacy of VB6 and the ClientSide Auth Bypass

The Legacy of VB6 and the ClientSide Auth Bypass

Robert Kruczek

In the modern era of microservices and single page applications, we sometimes forget the „old times” of desktop development. Recently, we had the pleasure of testing a legacy desktop application written in Visual Basic 6 (VB6). What started as a routine assessment ended with us dusting off our reverse engineering skills to write a classic “crack”, proving that client side logic is never to be trusted.

READ article
Illustration of Don’t forget to track your vendors’ security advisories

Don’t forget to track your vendors’ security advisories

Adam Borczyk

Every now and then a new critical vulnerability emerges, that has a worldwide impact and is easy to exploit. We’ve all seen Log4Shell, Spring4Shell… and now React2Shell. Despite media coverage, application teams often miss the importance of security patches. This particular vulnerability was found during a recent pentest in a production environment of our client, and it does not require any authentication. Global public disclosure of React2Shell happened just 5 weeks before this pentest.

READ article
Illustration of Active Directory Killchain: How three misconfigurations led to a Domain Compromise

Active Directory Killchain: How three misconfigurations led to a Domain Compromise

Marek Rzepecki

In the world of Active Directory (AD), an administrator needs to keep an eye on countless factors: keeping servers up to date, disabling redundant services, and managing privilege granulation across user groups. However, sometimes, to take over the whole domain (and log into all machines as any user), an attacker doesn't need to exploit technical vulnerabilities or search for CVE’s. It is often enough if an administrator makes a few small mistakes in configuring the relations between different objects in AD. The killchain presented below is a textbook example of such exploitation, where three separate issues were chained together to achieve a critical impact.

READ article
A professional cybersecurity consultant ready to assist with your inquiry.

Any questions?

Happy to get a call or email
and help!