Businesses of all sizes have increasingly been developing and deploying complex internet-facing web applications to provide consumers with richer experiences. While richer web experiences represent an opportunity for businesses to interact with and provide value to consumers in new and exciting ways, they also represent new attack surface for hackers. Many applications today exist to facilitate the storage, processing, and presentation of some variety of data, which is often compartmentalized through the use of roles and user accounts. Unauthorized access to web applications can often provide hackers with valuable information to sell on the darkweb or to use in future attacks against the organization or that organization’s users/clients. It’s important for developers building web applications to understand common web application attacks, their implications, and corresponding defences to architect robust and secure web applications that consumers can trust to keep their data secure.

In this article we’ll explore three authentication-related vulnerabilities we discovered in the PlexTrac platform (now described by CVE-2022-37144 through CVE-2022-37146), outline how these vulnerabilities could be combined to potentially bypass each step of the authentication process to gain access to sensitive data, and discuss how to build web applications that defend against such vulnerabilities.

What Is PlexTrac?

PlexTrac is a penetration testing reporting and workflow management platform designed to improve and centralize cybersecurity teams’ processes by offering rich features to facilitate planning and conducting proactive assessments, analyzing resulting findings, reporting, prioritizing issues for remediation, collaborating, and communicating with stakeholders. A primary function of the platform is to allow customers to add, import and organize engagement findings (vulnerabilities and weaknesses) that reference assets and include screenshots and code samples. These findings can then be categorized by severity and tracked for remediation. Additionally, one of the platform’s selling points is that it can go beyond a traditional report by providing customers with a web portal and associated access controls that their customer’s users and clients can use to review findings, collaborate on, and track remediation efforts. This “Findings” view on this web portal is pictured below:

PlexTrac-1-1: Screenshot of the findings summary page from a penetration test of fictitious company, taken from Control Gap's PlexTrac instance.

PlexTrac has been rapidly gaining traction with cybersecurity teams across North America and is currently being used by multiple Fortune 500 companies and well-known cybersecurity firms, as well as our own Offensive Security team here at Control Gap. Organizations that use the PlexTrac platform will have access to an instance hosted in either PlexTrac’s multi-tenant cloud platform, a PlexTrac-managed private instance, or in their own environment. PlexTrac has support for multiple single-sign-on methods (available to users after they have created a regular user account that can be accessed with an email address and password) and multi-factor authentication (MFA).

Due to the nature of the platform, all PlexTrac instances are almost guaranteed to store data pertaining to the cybersecurity shortcomings of one or more organizations. From an attacker’s perspective, the data available through PlexTrac represents actionable intelligence that could be leveraged to gain a foothold in corporate environments. Given the significant number of internet-facing PlexTrac instances associated with prominent organizations, any vulnerability related to PlexTrac that could lead to the compromise of the data stored within would represent a critical business risk

Now that we’ve briefly covered what PlexTrac is and why it’s important to both business and hackers, let’s talk about the three vulnerabilities we discovered in the PlexTrac authentication mechanism and how they can be combined.

Username Enumeration

The first vulnerability we discovered in PlexTrac was username enumeration. Username enumeration (sometimes called account enumeration) is when it is possible for a hacker to confirm whether a given username is valid for a system. Before we explain what mistakes were made in PlexTrac, let’s quickly address why username enumeration can be a concern.

Potential Impact of Username Enumeration

The impact of username enumeration varies because every application will have a slightly different threat model. Some applications, like adult sites designed to facilitate infidelity, will be designed to closely safeguard usernames, while others, like Gmail, expose valid usernames by design. Typically, being able to gather valid usernames for a platform will facilitate bruteforce attacks such as credential stuffing or guessing to compromise associated application accounts. In cases where the username is a personal identifier like an email address or phone number, attackers can target gathered usernames in social engineering attacks.

Bruteforce

The first issue with username enumeration is that it makes it considerably easier for attackers to bruteforce valid credentials to gain access to a system. Most web applications today are secured by a set of credentials, which typically consist of two components: a username and a password. When both of these components are kept secret, attackers seeking to gain access to the application must bruteforce both at the same time. Bruteforcing both usernames and passwords is typically so difficult it is considered infeasible. When it is possible for an attacker to bruteforce the username and password independently, however, it doesn’t just become half as difficult, it becomes orders of magnitude less difficult. We’ll explain why through the example below:

• Imagine a system (or a web application) that has one user.
• Let’s say that both the username and the password for that user were made up of 6 numeric digits.
• The number of possibilities that exist for that user’s username is 10⁶ or 1 million. As the password is made up of the same number of numeric digits, the number of possibilities for the password is also 1 million.
• An attacker bruteforcing both the username and the password at the same time would be faced with 1 trillion (10⁶ * 10⁶ = 10¹²) possible combinations.
• If the system told the attacker when they got the username right, then it would be possible for the attacker to bruteforce the username to get the right one, and then the password, instead of doing them at the same time.
• An attacker bruteforcing the username and then the password would, at most, have 2 million (10⁶ + 10⁶ = 2*10⁶) combinations to try instead of 1 trillion.

Being able to bruteforce usernames and passwords independently, which is made possible by username enumeration, is orders of magnitude less difficult than bruteforcing them at the same time.

Credential Stuffing

In the real world, systems usually have more than one user, and a significant portion of those users will have usernames and passwords that are more complex than 6 numeric digits. Even if a username is known, bruteforcing long, complex passwords should be infeasible. This is where credential stuffing comes in.

In the real world, systems and applications are breached regularly and sometimes plaintext or weakly protected passwords can be recovered from those system’s databases. Hackers will use these compromised plaintext credentials in attempts to gain access to other systems. This kind of attack is called a credential stuffing attack, and, at scale, it is often quite successful due to people’s tendency to reuse passwords across applications.

There are currently billions of leaked credentials freely available on forums and websites. When an attacker performs credential stuffing, they will typically take a subset of those credentials, often from one or more recent breaches (ideally from a service where there is likely user overlap), which would amount to some millions of usernames, usually with somewhere from 1 – 6 passwords associated with a given username, to try against the target system. When username enumeration is possible, the whole process can be accelerated: instead of trying passwords for every username they have, the attacker can perform a simple check to see if the username they’re trying belongs to a valid user of the platform, and, if not, discard it so that passwords are only attempted for valid users.

Credential stuffing is particularly difficult to respond to because unlike bruteforce attacks where speed is essential to make the attack feasible, credential stuffing can be slow, taking place over weeks with different IP addresses due to the lower number of guesses. Furthermore, at an individual account level, credential stuffing can often appear like regular account activity: a couple of incorrect passwords followed by the correct one a short time later, all from different IP addresses. Sometimes the correct one is the attacker gaining access, and sometimes it is the legitimate user coincidentally logging in.

One famous credential stuffing attack took place in 2019 against the newly launched Disney+ streaming service. Shortly after the service launched, users began reporting that they had lost access to the accounts they had paid for, and those accounts began appearing for sale on the darkweb for a fraction of what the users paid for a full-year subscription. Despite the outcry, Disney could not find evidence of a security breach, leading the broader security community to conclude that a credential stuffing attack had taken place.

To check how many of your accounts and passwords have been compromised, check out havibeenpwned.

Social Engineering

Modern web applications commonly use email addresses and sometimes even phone numbers as usernames. When this is the case, determining if a username corresponds to a valid account can often provide attackers with actionable information about an individual for use in future social engineering attacks. For example, if an attacker could quickly test for valid emails (usernames) on a PlexTrac instance, they could quickly build a list of people to send targeted phishing emails pretending to be PlexTrac (colors, fonts, everything). The email could inform users that their password had been reset and instruct them to click the included password reset link to regain access to their account. Of course, when the users click the link to reset their password, they’d visit the attacker’s website designed to harvest credentials instead of their real PlexTrac instance.

Credential harvesting for the purpose of compromising users accounts (both web applications and email) is a common goal for cybercriminals for the following reasons:

• Compromised accounts often contain personal data.
• Access to compromised accounts with a balance or a service attached to them (like Disney+) can be sold on the darkweb.
• Email compromise can be leveraged to perform identity theft, wire fraud, further account compromises (think password reset functionality on other websites), data exfiltration, extortion, and further phishing attacks against that user’s contacts.

In their 2021 Internet Crime Report, the FBI reported that business email compromise (which includes email account compromise) schemes resulted in losses of approximately $2.4 billion USD. Email-related cybercrime is becoming more prevalent and more costly.

Finally, as we mentioned earlier, on some websites like those that facilitate extramarital affairs, just the fact that an email belongs to a valid user on a site could be all an attacker needs to potentially contact and extort users. For examples of such fallout, look no further than the 2015 breach of the extramarital affairs site Ashley Madison.

Username Enumeration in PlexTrac

Now that we understand how and why username enumeration can be a problem, let’s explore CVE-2022-37146 and how usernames (emails) could be enumerated from PlexTrac.

Control Gap’s Vishal Tomar recently published an article exploring how visual error messages and UI flows designed to help users can be used to perform username enumeration by providing attackers with a way to distinguish between valid and invalid users. Common functionalities affected include login, password reset, and sign up. If you aren’t familiar with the most common ways developers accidentally introduce username enumeration, please give that article a read before continuing.

The first check we can perform to see if an application is vulnerable to username enumeration is submitting a request (typically a login, password reset, or signup request) using first a valid user, followed by another request for an invalid user and comparing the two responses for differences. Remember, any difference in responses could allow an attacker to perform username enumeration. Using one of our own PlexTrac staging instances for testing, we verified that PlexTrac returned generic responses for both valid and invalid users on both the login and password reset forms. These forms are pictured below with the responses to invalid user attempts:

PlexTrac-1-2: Screenshots of a failed login attempt (left) and failed password reset attempt (right). Note there is no way to tell the username was wrong.

Visually, PlexTrac did not seem to be vulnerable to username enumeration thanks to its generic, unhelpful responses. Checking the associated HTTP responses for these form actions confirms that they are just as generic as the displayed errors. Note that some applications that do not seem to allow for username enumeration on the frontend will sometimes have distinct HTTP responses that negate all of their error precautions and allow attackers to perform username enumeration: this is not the case with PlexTrac.

Timing Is Everything

To truly protect against username enumeration, an application must return responses with no measurable difference, in all aspects, for valid and invalid users. One common oversight made by developers is in the response time of certain requests. Consider how a typical authentication request is handled by the application server:

1. Receive login POST request, parse out username and password.
2. Query database to check if user exists. If does not exist, return error.
3. If exists, query database again to check if passwords match, which likely requires a resource-heavy hash and compare (think functions like BCrypt, SCrypt, or Argon2). If does not match, return error.
4. If matches, return success.

Note that the application server is doing more processing for a valid user (two database queries and a resource-heavy hash and compare) than for the invalid user (one database query), which means that the time it takes for the server to respond with an error will be significantly longer for the valid user. The application’s efficiency in returning a response as soon as possible provides attackers with a discrepancy that can be used to determine if a user is valid or not.

To check if username enumeration is possible on PlexTrac via the HTTP response times of authentication requests, we could craft a script to measure the response times of login requests for a set of valid users, login requests for a set of invalid users, and then plot those times on a graph. The chart below shows a plot of authentication failure response times for 50 user accounts, 45 of which are randomly generated and not valid users on the tested PlexTrac instance. The five labeled (and redacted) points on the chart represent valid users which, as pictured below, were found to take significantly longer to return responses for authentication requests:

PlexTrac-1-3: Graph of HTTP response times for authentication requests for valid (labeled) and invalid usernames.

The response time for authentication attempts using valid usernames was found to be significantly longer than for invalid usernames. Notably, this method of username enumeration would not have alerted users as, at time of discovery, there was no lockout functionality implemented and no limit on the number of consecutive failed authentication attempts that could be made.

The real-world feasibility of performing username enumeration using HTTP response timings would depend highly on the stability of the target web server and the internet connection between the attacker and that host. Unexpected latency could disrupt results, making this a challenging attack to execute at scale; it may be necessary for attackers to take the average of multiple attempts for a given username to eliminate any network anomalies when attempting this in a real-world scenario, which would slow down enumeration efforts.

To avoid revealing valid users through HTTP response times, developers could introduce a random delay on all login requests for users. Alternatively, depending on the application, it may be feasible to determine what extra computation is happening for valid users and simulating that for invalid users. For example, if hashing and comparing a valid user’s password is what creates the time difference, then developers could consider implementing a “fake” hash for invalid users using a random value to feed a hash compare function and discard the result before returning a generic “invalid credentials” error.

PlexTrac fixed this username enumeration via HTTP response times vulnerability in version 1.28.0, where they added a random delay to responses.

Does PlexTrac Prevent Bruteforce Attacks?

Moving down the authentication procedure, we discovered that PlexTrac did not properly restrict excessive authentication attempts (authentication bruteforce attacks), which is now described by CVE-2022-37145. Essentially, we found that the application allowed for an unlimited number of authentication attempts for a single account with no rate-limiting or account lockout. Worse yet, the application was written to handle authentication efficiently, so it was possible to send thousands of authentication requests per minute without relying on multi-threading. With unlimited attempts and the ability to send thousands of authentication requests per minute, it is probable that an attacker would be able to recover valid credentials to a PlexTrac instance through persistent bruteforce efforts, which are made easier because the platform is vulnerable to username enumeration.

To protect against bruteforce attacks developers should implement some combination of the following:

• Multi-factor authentication: in addition to the password, applications can request a user to present another piece of evidence to prove they are a legitimate account holder. This could be something they know, have, are, or based on their geolocation. When implemented correctly, MFA can protect against a wide range of automated sign-in attacks including traditional bruteforce and credential stuffing attacks. Over the last 5 years many major organizations have begun recommending the enforcement of MFA to protect against automated attacks. Be aware that MFA should not be considered a defense against social engineering attacks, which can prompt a user to complete their MFA step and test it in real time.
• Account lockouts: after a number of consecutive failed login attempts over a period of time the application can disable the account in question for a period of time or indefinitely. A key consideration with this approach is to ensure that users can recover their accounts after being locked out to prevent attackers from being able to launch denial of service attacks against users of the application by locking everyone out.
• Authentication delays: the faster an application responds to authentication requests, the faster attackers can test credentials. Request taking seconds instead of millisecond significantly slow down bruteforce attempts while not impacting the user experience too negatively. Authentication delays can make traditional bruteforce attacks more difficult to execute but offer minimal protection against credential stuffing attacks.
• CAPTCHA mechanisms: a CAPTCHA is a computational challenge that is difficult for computers to perform but easy for humans. These challenges serve as mechanisms that can greatly hinder or prevent automated attacks. If implemented correctly on an application’s authentication mechanism, it can be very computationally expensive or impossible for an attacker to bypass the puzzles to submit valid authentication requests, discouraging and even preventing large scale attacks.

To read more about the options available to developers and special security considerations associated with each please review the relevant OWASP cheat sheet.
PlexTrac fixed their improper restriction of excessive authentication attempts vulnerability in version 1.17.0 by implementing an account lockout after 5 consecutive authentication failures.

Multi-Factor Authentication (MFA) Bruteforce

Even if an attacker was able to obtain valid credentials to a given PlexTrac instance, as long as that user account has multi-factor authentication (MFA) enabled, that should stop them, right? As outlined in CVE-2022-37144, we found that the PlexTrac MFA implementation would only act as a minor speedbump for attackers.

In theory, a user would set up PlexTrac MFA on a device that an attacker does not have access to, like a smartphone. Whenever a user logs in successfully and is enrolled in MFA, PlexTrac would present a prompt for the user to enter their time-based one-time-password (TOTP), which is 6 digits long.

PlexTrac-1-4: Control Gap's PlexTrac instance prompting for a TOTP token code.

Once prompted for their MFA token code, users would have a couple minutes to enter the correct TOTP before the login request becomes invalidated. The TOTP that is generated periodically based on a seed value that is assigned to the user when they first configure MFA. To learn more about the technical implementation of TOTP MFA solutions, please read this article.

In PlexTrac, once a valid set of credentials are submitted for an account with MFA enabled, the user has up to two (2) minutes to submit a valid TOTP. Once the two minutes is over, the MFA token returned by successful authentication expires and authentication is again required to obtain a new one. During testing it was found that within that two-minute window, PlexTrac did not restrict the number of failed attempts to submit a valid TOTP, allowing an attacker to bruteforce the MFA mechanism. During testing, a virtual machine with a single network interface was found to be able to submit TOTPs at a rate of approximately 10,000 per minute.

Probability of Bypass

At this point, a skeptical reader may be thinking, “if a TOTP code is 6 digits long, and you can guess 10,000 TOTPs a minute, you would still have to be pretty lucky to get in…”.

We know that a six-digit numeric TOTP code has one million (10⁶) combinations, so 10,000 requests (the rate we can achieve in a minute) is 1% of the TOTP key space. This means that every minute we have a 1% chance of guessing the right TOTP code. If we have a 1% chance of guessing the right TOTP code in a given minute of effort, that means that PlexTrac MFA has a 99% chance of keeping us out in a given minute. This may seem like a pretty high probability, but if we test our 1% chance repeatedly, the odds quickly fall in our favor because probability is multiplicative, which means that while PlexTrac has a 99% chance of stopping us once, it only has a 98% (0.99*0.99=0.9801) chance of keeping us out twice (or two minutes) in a row. Following this logic, the chances of PlexTrac stopping us 10 times in a row, or stopping us for 10 minutes straight, would be about 90% (0.99¹⁰=0.904). It is possible for an attacker to continuously bruteforce the MFA implementation if they possess a set of valid credentials that they can use to repeatedly authenticate to get a new MFA request token to submit alongside their TOTP.

We can therefore calculate how long it would take to bypass this MFA implementation using the following equation:

The equation allows us to determine that, given a request rate of 10,000/minute, it would take approximately 70 minutes for an attacker to have a 50% chance of successfully bruteforcing their way past MFA, which represents the average time it would take to do so. This is a trivial amount of time considering that PlexTrac offers the legitimate account owner no indication that a bruteforce attack is happening and does not offer any way of showing which user sessions are active for a given account. Given the same rate, an attacker would have a 99% chance of bruteforcing their way past MFA in an 8-hour day.

The table below illustrates the relationship between time spent bruteforcing and the chance of bypassing MFA:

MFA is typically seen as a significant obstacle for attackers who gain valid user information via credential stuffing or bruteforcing attacks, but as demonstrated above, the PlexTrac MFA implementation is barely a speedbump.

It is important to note that it is not the size of the two-minute MFA window that is responsible for this vulnerability, but rather that the TOTP submissions are unlimited, which is compounded by the fact they can be submitted at such a high rate. Currently, to achieve a 50% chance of bruteforcing MFA, an attacker would have to make 35 authentications(one authentication every 2-minutes), which would take approximately 70 minutes. If we reduced the MFA window to 30 seconds, it would still take an attacker approximately 70 minutes to achieve the same 50% chance of bruteforcing MFA, but instead of 35 authentications, it would take 140 authentications (one authentication every 30 seconds).

In order to prevent an attacker from bruteforcing their way past the MFA mechanism, developers should ensure their applications limit the number of consecutive MFA authentication failures. After a small number of consecutive failures, the application can prompt users to use a different form of MFA, prompt them to reset their MFA, or lock the account.

PlexTrac fixed their improper restriction of excessive MFA TOTP submissions vulnerability in version 1.17.0 by implementing an account lockout after 5 consecutive MFA submission failures.

Putting It All Together

The vulnerabilities we discovered in PlexTrac are especially interesting because they can be chained together by an attacker to completely bypass authentication (with some bruteforcing luck.

PlexTrac-1-5: High-level process of obtaining access to a secured PlexTrac instance.

An attacker attempting to gain access to a securely configured PlexTrac instance will need to first obtain a valid username, then the corresponding password, and finally an MFA token code to access that instance and plunder the sensitive information stored within. If the authentication mechanism was properly implemented, these obstacles would be insurmountable even to skilled and motivated attackers. The vulnerabilities discovered in these components allow the most mediocre adversaries to perform basic research and launch simple bruteforce attacks to bypass these security mechanisms.

Usernames, or more specifically email addresses, could likely be harvested from social media and websites belonging to the organization that owns the targeted PlexTrac instance. The username enumeration vulnerability could be exploited to verify which emails correspond to valid users. Those emails could then be targeted in credential stuffing and bruteforce attacks. Should the attacker succeed in discovering the user’s password, they could then exploit the last vulnerability to bruteforce their way past the MFA mechanism and gain access to the user’s account without alerting them. As discussed at the beginning of this article, PlexTrac instances can contain considerable amounts of actionable intelligence that threat actors could use in further attacks.

PlexTrac Is Not Alone

It is important to note that while PlexTrac was the platform being dissected in this article, it is far from the only web application to suffer from these vulnerabilities. PlexTrac is simply the application we found to be vulnerable and chose to use as a case study for these kinds of vulnerabilities and their corresponding mitigations. Cybersecurity is a constantly evolving space which requires developers and organizations to continuously develop increasingly robust and secure functions to keep up with emerging risks. In a world where so much of our infrastructure relies on third-party applications and code it can be tempting to blindly trust those third parties to secure their applications to your own organization’s security standards. When possible, organizations should be routinely testing all of their infrastructure, dedicating extra time and effort to their most critical systems, even if those systems are third-party components. Here at Control Gap, we conduct routine penetration testing activities targeting the full scope of our IT assets, including our third-party applications. It was during one of these internal tests that we discovered the aforementioned vulnerabilities in PlexTrac.

We’re happy to report that PlexTrac was a pleasure to work with through the initial disclosure, remediation, and publication process. PlexTrac has the benefit of being used by multiple well-known cybersecurity firms, many of which will likely review the platform as part of their own internal penetration tests, as we did. We look forward to reading about any vulnerabilities those firms discover in the platform.

Disclosure Timeline