When adding a “Password Reset” function to your application it is especially important to ensure this has the same security considerations as any other critical function within the application. Due to the nature of resetting a user’s password, along with many security considerations being overlooked, it is not uncommon for attackers to spend extra time trying to bend these types of functions to their will to try and gain unauthorised access.
There are some key considerations that must take place when implementing this functionality to ensure it cannot be abused by attackers:
Let’s take a look in the case of an application Alchemy Security tested recently.
Problem one – static password reset tokens
For each user a password reset token was created at time of account creation and stored in the database as part of the credentials. This meant the account had a single reset token valid for the lifetime of the account, independent of how many times the user forgot their password.
As the token was not invalidated after a period of time or once used, this meant that even if the legitimate user reset their password, an attacker still had access to the token and in turn the account, another weakness detailed in problem two. It also appeared likely that the token could not be invalidated without deleting and re-creating the account.
The token was returned in a ‘HTTP 200 OK’ response from the API endpoint, so while not visible within the web page itself, was still easily obtainable by an attacker simply using an interception proxy such as Burp Suite. This meant that an attacker could easily write a script to test a list of usernames and obtain the token for each by parsing the resulting response.
To make matters worse, all of the above actions do not require any user authentication. Allowing an un-authenticated attacker to easily enumerate both usernames and their associated reset tokens without restriction or valid credentials.
Problem two – excessive token permissions & incorrect authorisation checks
The biggest problem was the token itself had excessive permissions and was able to perform almost any action for which the user already had permissions. For example, the token could be used to update the user’s profile (which then leaked the user’s password hash, another big issue!) or perform search functions to access data for which the user had access to.
These two issues meant that the application was prone to two critical security issues:
These issues can be easily be avoided in the following manner:
The Conti group have been featured across many news outlets lately both inside and outside the cyber security community. It is well known that this specific threat actor is mainly operated from within Russia, and with the recent events within Russia and Ukraine we thought it would be a good idea to do a recap […]Read More
Modern environments are in a constant state of flux; new systems are being commissioned, and old systems decommissioned, to meet new requirements and increase efficiency in all sectors. Managing those changes takes strategy and labour, and every change has an overhead in both of those resources. What do you do when your users want new […]Read More
Part of performing an effective and successful penetration test requires gathering as much information about the target as possible. The more information you have on your target, the more likely you are to discover an exploitable service or land a successful phish. For example, through OSINT you may discover that the target is openly advertising […]Read More
Recently in the news it was revealed that a member of an “APT” group that utilises the “Conti” ransomware became disgruntled at the state of their relationship with the group and leaked a large majority of the groups “Tools, Techniques and Procedures” documents. Conti was first discovered in 2020 and is used primarily by the […]Read More
Advanced persistent threats come in many forms ranging from your crime groups, activists all the way through to your state sponsored groups. While some of these threat actors such as crime groups are seen on a regular (if not daily..) basis, state sponsored attacks are less common and more sophisticated. While most state sponsored groups […]Read More
The Windows Name Resolution Flow You may be under the impression that turning host names into IP addresses is simple. You check: The Hosts file; then Your system’s DNS (Domain Name System) resolver That’s it right? If you don’t get a response from your local file or DNS, then the system doesn’t exist. Well, no; the name resolution flow in Windows looks something like this: Well, that’s a […]Read More
Red teaming is not a new concept within the cyber security community. However in Australia, Red Teaming is a relatively new term for most organisations. In this blog post we'll take a dive into: What differentiates a Red Team engagement from a Penetration Test. Why you shouldn't consider a red team engagement (You totally should.) […]Read More
When adding a “Password Reset” function to your application it is especially important to ensure this has the same security considerations as any other critical function within the application. Due to the nature of resetting a user’s password, along with many security considerations being overlooked, it is not uncommon for attackers to spend extra time […]Read More