The cybersecurity landscape has become a much more dynamic field in the last decade. Attackers are increasingly sophisticated and turning to complex techniques to infiltrate systems and steal sensitive data. While defensive teams purchase a wider variety of various products to try to stem the flow of security flaws, including vulnerability scanners, the custom nature of applications makes stopping the exploitation difficult without proper identification.

In this article, we explore examples of how manual testing can emulate complex attack methods commonly used by sophisticated attackers. The examples show vulnerabilities that could have led to an attacker gaining the ability to run commands and code on systems to gain control of accounts on web applications and may have caused financial and reputational damage if they had not been identified for remediation through our testing.

Finding high severity vulnerabilities using Attack Chain Analysis

One of the ways manual testing and analysis exceeds that of automated scanning is the ability to link various vulnerabilities, some of which would not appear in typical web application vulnerability scanners’ results.

Code Execution for Energy Company Mobile App

One such chain of vulnerabilities was found in a mobile application for an energy company. The tester discovered a function that allowed the upload of files with executable extensions and content such as Active Server Page Extended files (ASPX) or Windows Executable (EXE) files. The tester bypassed typical checks by using only the file extension (e.g. “aspx”) as the submitted file name, showing the typical ingenuity of our testers.

Successful upload of an ASPX file, which was not intended to be permitted.

Application vulnerability scanners may have missed this vulnerability due to the unique test case needed to discover this vulnerability. Typically, application vulnerability scanners would test for file upload vulnerabilities in the submitted file name by observing the response from the application from a submission of both the base name of the file (e.g. “file1”) and the file extension (e.g. “aspx”). The test case of submitting just the file extension of the file is not a typical test case and would generally be missed by most vulnerability scanners.

List of vulnerabilities found by the scanner does not have the above mentioned vulnerability.

The tester is then chained to this with a path traversal vulnerability to be able to execute code on the running web server. Such a vulnerability would have been missed by a web application vulnerability scanner as well as the vulnerability would only surface by performing multiple steps in a particular sequence – uploading a file, attempting to shift where it was uploaded in the file system and then attempting to access it. Without the contextual understanding through manually testing and exploring the file upload and access functionality, this vulnerability chain would not have been found.

Uploading outside the intended folder could be done through a path traversal vulnerability.

Command Execution for Automotive Client Web App

Another example for a client in the automotive sector, found a similar file upload vulnerability. In this case, manual testing found that there was an error message that disclosed more information than required. While automated scans would have treated that issue as a “low” or “informational” severity vulnerability, the tester was able to use the vulnerability to identify the location of where the file was uploaded to by reading the disclosed code, which was within the error message.

Error message discloses the location of a page containing source code.

With that information, the tester found a function that he could call, that would eventually disclose the location of the uploaded file. By accessing a crafted file that was uploaded, the tester demonstrated that an attacker could run any code of their choosing.

Location of uploaded file found by using function discovered by accessing disclosed code.

The tester demonstrated that OS (Operating System) commands could be run on the web server.

Stopping Tampering Attacks that allow account takeovers

A vulnerability or a series of vulnerabilities can lead to account takeover which provides attackers full access to a chosen user account and all their privileges. One straightforward way for attackers to do so is through credential stuffing, which is using automated scripts to guess the username and password pairs (typically from leaked passwords from a data breach of another site). The deployment of two-factor authentication in many of our clients' systems has reduced the risk of such credential stuffing attacks. However, we have identified several instances where these two-factor authentication implementations are poorly implemented or configured and thus can be bypassed.

Second Factor Authentication Bypass

In our test of an investment firm’s web application, our tester bypassed a two-factor authentication implementation as part of our test cases conducted to check the efficacy of the multifactor authentication function.

During the test, our tester identified the email field sent during the two-factor authentication process as a vector for account takeover. It was observed during the test that a submitted HTTP request contained an email address parameter (see screenshot below). By design, the email address would be the valid user’s email address. However, the tester observed that changing this email address to his own email address (simulating what an attacker would do) would lead to the application sending the two-factor authentication code to his email address.

2FA (2 Factor Authentication) Verification mechanism made decision based on submitted user email address.

Typical web application vulnerability scanners would be unable to detect this vulnerability due to the need to (1) have access to a working email system and (2) understand the logic of the two-factor authentication mechanism to identify that the email address should not be used or requested at this step. The identification and remediation of this vulnerability reduced the risk of account takeover by removing this vector from the application.

For some of our clients that do not have two-factor authentication, our testers have found methods to bypass the authentication requirement entirely and take over the account of other users. A brief description of two such bypasses is provided below, one for a client in the Fintech sector and the other in the energy sector.

Account Takeover via Overwritten Registration

In the case of a Fintech company, our tester discovered a vulnerability that would allow a malicious actor to gain control of an account. The tester demonstrated that an attacker could perform a registration using the same identifier as an existing user.

The following observations were made by the tester during the penetration test of the application:

During the registration process, the application assigned a new registration identifier for each new sign-up.
This registration identifier could be changed when it was sent from the web browser.
The application accepted the changed registration identifier and merged the information of the two records together. An attacker could use this to create a registration associated with their own email address.
There was a check done by the application to reject registrations with the same mobile phone number. This check could be abused to determine if a mobile phone number was valid.
There were no limits on the number of submissions (technically a lack of rate-limiting on HTTP requests and API calls) at each stage of the registration process.

The tester was able to bring together multiple poor security practices and vulnerabilities to demonstrate a critical account takeover flaw:

The system did not have restrictions on the rate at which attempts to determine valid phone numbers could be made, making it easier for an attacker to identify valid numbers through multiple attempts
The application disclosed the registrant identifier to users unnecessarily
The application did not perform any checks or verification if the registrant identifier was already in use before creating the user
The database did not set the registrant identifier as a unique key in the relevant database tables and so creation of multiple records with the same identifier was possible.

Account Takeover Via Tampered Parameter

In another case of account takeover, the tester observed that there was a parameter within the intercepted requests that contained the username field during the login process. By selectively changing the parameter to that of another user for some of the requests, the tester demonstrated that an attacker could gain access to an account of higher privileges. Our Bitdefender tester was able to do this due to his prior experiences with various Single Sign-on implementations and his ability to comprehend which requests to modify and which requests not to.

Conclusion

The examples outlined above highlight some of the security weaknesses that can be identified through offensive security testing. Traditional defensive products such as Web Application Firewalls alone often cannot stop intricate attacks exploiting such weaknesses, emphasizing the importance of comprehensive offensive security testing. In addition to uncovering hidden vulnerabilities for remediation, offensive security testing also shows due diligence through proactive security efforts and supports compliance efforts such as ISO 27001, SOC 2 Type 2, GDPR, PCI-DSS and HIPAA.

Embracing an offensive cybersecurity strategy is not just an option but a necessity for businesses and IT leaders who aim to stay one step ahead of sophisticated adversaries. Thus, integrating offensive measures is crucial for building a robust, dynamic defense capable of thwarting even the most advanced cyber threats.