03 Жов, 2023

Cracking the Safe: Insights from a Bank Penetration Test

Guardians of Financial Fortresses – The Role of Penetration Testing

In today’s digital world, where the constant danger of data breaches and cyberattacks looms large, the urgency of strengthening cybersecurity defenses cannot be overemphasized. As technology continuously evolves, so too do the tactics and techniques cunningly employed by cybercriminals. In response to these relentless threats, organizations, particularly those operating in the financial sector, find themselves in a perpetual battle to assess and fortify their security measures.

Financial institutions, including banks, represent prime targets for cybercriminals owing to the vast troves of sensitive financial and personal data they hold within their digital vaults. The ramifications of a single security breach within such institutions can be catastrophic, ranging from crippling financial losses and severe reputational damage to punitive regulatory penalties. Consequently, financial entities are compelled to adopt a proactive stance when it comes to securing their systems and safeguarding the treasure trove of data they steward.

Within the confines of this article, we will embark on a journey into the realm of penetration testing, with a specific lens on its application within the financial sector. Our objective is to illuminate the significance of this practice and explore how it serves as an essential safeguard for financial institutions against the ever-evolving landscape of cyber threats.

Moreover, we will shine a spotlight on a compelling case study — a successful bank penetration test. In this particular engagement, critical vulnerabilities of both technical and business logic natures were unearthed. It’s worth noting that for the sake of client confidentiality and security, all identifiable data and the bank’s name have been anonymized. This underscores the paramount importance of Non-Disclosure Agreements (NDAs) and the mutual trust between the client and the penetration testing team.

Defining the Battlefield – Scope of the Penetration Test

Recently, XYZ Bank, a prominent financial institution known for its commitment to security and innovation, approached our CQR company seeking assistance in fortifying their digital defenses. The objective was clear: a comprehensive penetration test and security assessment aimed at evaluating the robustness of their web application.

In this collaborative endeavor, the client entrusted us with two accounts meticulously designed to mirror real bank clients’ profiles. These accounts were endowed with a certain amount of currency to facilitate the execution of financial transactions during the test.

Operating within the parameters of a gray box testing approach, our mission was to uncover vulnerabilities, both technical and within the realm of business logic, that could potentially pose a threat to the bank’s security.
Time was of the essence in this project, with a strict timeline of 1.5 months allotted for the actual penetration testing activities. As for the size of our penetration testing team, it was left to our discretion, and we opted to engage four highly skilled and experienced specialists. Their expertise spanned various facets of cybersecurity, ensuring a thorough and diverse examination of the bank’s digital infrastructure.

During the penetration test, we had a multifaceted strategy in place. It encompassed vulnerability assessment, brute force attacks, exploitation testing, deep reconnaissance, and extensive data gathering. Each facet played a vital role in simulating real-world threats and providing a holistic evaluation of the bank’s security posture.

Exploring Identified Security Weaknesses:

Vulnerability # 1
2FA Bypass and Unauthorized Account Takeover

In our evaluation of the bank’s web application multiple vulnerabilities were identified that, when chained together, led to an account takeover. These vulnerabilities included:

– The application returning an “Incorrect password” error instead of “Invalid credentials” upon login attempts, which allowed for the discovery of existing accounts through brute force methods.

– The absence of rate limiting, enabling attacks on unknown parameters such as OTP via brute force.

– Lack of cookie validation in the application, allowing password changes to be initiated on another user’s account by manipulating a single parameter (which was relatively easy to obtain).

To reproduce this attack, we followed these steps:

Visit the site and navigate to the “Forgot Password?” section.
Enter an email, enable Intercept, and enter any SMS code, capturing the request containing the code.

				
					POST /api/client/pwd/recovery?otp=1234&refid=XEqVyp6j7zLSVANzrVkGUrw6JwR67T
				
			

We observed that the “refid” parameter did not change with each new request, allowing us to brute force all possible code combinations (10,000) without rate limiting constraints. Fortunately, on the 1,567th attempt, we found a matching “otp” value (1567), and the server responded with a 200 OK, granting us access to bypass 2FA.2.

With this knowledge in hand, we decided to explore further. Knowing that the server did not validate cookies and understanding how to identify any account (in our case, the login was admin@xyz_bank.com), we attempted to change the password using the Password Recovery feature.

We intercepted a request, changing the password for our account through Password Recovery:

				
					PATCH /api/client/pwd/recovery?update_password=Test12345&refid=XEqVyp6j7zLSVANzrVkGUrw6JwR67T
				
			

Where “refid” was the identifier for our account and “update_password” was set to “Test12345“.

Subsequently, we tried to log in with the login “admin@xyz_bank.com” using an incorrect password. The server returned an error of “Incorrect password.” This confirmed that the account “admin@xyz_bank.com” existed in the system; we just didn’t know the password yet. By using this request, we managed to capture the account identifier “refid=LXkpt0k2RaiTI0dB1KydDHUmRDwv6x.”

We then used the account identifier and set a new password for the account:

				
					PATCH /api/client/pwd/recovery?update_password=Hackers_PASSWORD&refid=LXkpt0k2RaiTI0dB1KydDHUmRDwv6x
				
			

We verified that the password for another user’s account had indeed been successfully changed. We logged in using the login “admin@xyz_bank.com” and our new password, “Hackers_PASSWORD“. We then brute-forced the 2FA code on the “otp” parameter, which we fortunately succeeded in on the 2,143rd request.

				
					POST /api/client/pwd/recovery?otp=2143&refid=LXkpt0k2RaiTI0dB1KydDHUmRDwv6x
				
			

With this, we successfully authorized ourselves into another user’s account.

We promptly reported this critical vulnerability to the bank, as required by the pentesting protocol. Additionally, we recommended implementing strict credential validation, introducing rate limiting for authentication attempts, especially for sensitive operations like OTP verification, and implementing proper cookie validation to enhance security and prevent unauthorized actions. These measures aim to strengthen the security of the bank’s web application and mitigate the risk of similar vulnerabilities in the future.

Vulnerability # 2
Currency Exchange Manipulation – Profiting from Rounding Errors

Imagine a scenario where, during a currency exchange from LocalCoin to NewCoin, one could swiftly acquire 1.00 NewCoin for just 1474.50 LocalCoin, while the bank’s officially established Selling Rate stood at 1482.00 LocalCoin for 1.00 NewCoin. This significant discrepancy of 7.50 LocalCoin per NewCoin allowed users to exponentially increase their balances with ease.

The essence of this vulnerability lay in the improper rounding of fractional numbers within the system, a seemingly minor oversight that had profound implications.

To mitigate this vulnerability, it was recommended to properly configure the currency exchange transaction processing. Specifically, steps needed to be taken to prevent users from executing transactions when the user-entered LocalCoin amount was less than 1.00 unit of foreign currency based on the bank’s exchange rate at the time of the transaction. By implementing this corrective measure, which includes not only the adjustment of transaction processing but also the proper validation of rounding within the system, the bank could effectively prevent users from exploiting the discrepancy and maintain the integrity of its currency exchange operations.

Vulnerability # 3
Currency Rate Manipulation Vulnerability

During our penetration testing of XYZ Bank’s web application, we uncovered a significant vulnerability that allowed users to manipulate currency exchange rates to their advantage. This flaw enabled users to perform NewCoin to ForeignCoin exchanges at the bank’s buying rate rather than the intended selling rate.

Furthermore, within this transaction, users had the opportunity to not only exchange their ForeignCoin back to NewCoin but also do so at a rate lower than the bank’s selling rate, thus generating a profit. By exploiting this vulnerability through two consecutive transactions, users could maintain their ForeignCoin balance while accumulating additional NewCoin.

This vulnerability was rooted in improper rounding of fractional numbers within the system, leading to discrepancies between official exchange rates and those effectively applied during transactions.

In summary, this vulnerability allowed users to exchange currency at advantageous rates, ultimately resulting in an unfair financial gain. To address this issue, we recommended implementing a strict currency exchange policy to prevent users from altering rates on the client side. Additionally, a review of the system’s rounding rules was advised to ensure clients cannot exploit currency transfers between their accounts to accrue additional funds.

This vulnerability exposed XYZ Bank to potential financial losses due to the improper calculation of exchange rates, highlighting the importance of robust security measures in the financial sector.

Vulnerability # 4
Default Credentials Exploitation Issue

Also, in a course of penetration testing of XYZ Bank’s web application, we stumbled upon a vulnerability of grave significance—a portal that granted users elevated privileges with the entry of generic login credentials “admin” and “admin.” This unsuspecting entry point opened the door to an administrator’s domain, bestowing users with potent capabilities that could potentially disrupt and damage the application’s core structure.

This vulnerability underscored the inherent risks associated with default settings and predictable paths for administrative access. The use of common default login credentials and easily guessable paths provided unauthorized users with an unintended gateway to sensitive functionalities that should have been rigorously protected.

To reproduce this vulnerability, a malicious actor could follow these straightforward steps:

1. Visit the following link: https://XYZ_Bank.com/admin/login

2. Log in to the account using the default login credentials “admin” and “admin”.

The successful login would grant the user with unfettered access to the administrator’s dashboard, enabling potentially malicious actions under the role of an administrator. This vulnerability posed a significant risk to the application’s security and confidentiality.

Firstly, we advised changing default login credentials to unique and complex ones to prevent unauthorized access. Secondly, we suggested customizing login paths to eliminate predictability. Additionally, we proposed the implementation of Two-Factor Authentication (2FA) for an added layer of security, alongside deploying CAPTCHA challenges on login pages to counter automated attacks. Lastly, rate limiting was recommended to deter brute-force attempts, collectively enhancing XYZ Bank’s security posture.

Vulnerability # 5
Insecure Direct Object Reference (IDOR) –
The Unrestricted Data Access Vulnerability

During our comprehensive penetration test of the bank’s web application, we uncovered a critical vulnerability known as Insecure Direct Object Reference (IDOR). This vulnerability, closely related to access control, arises when an application uses user-input data to directly access objects, leading to unauthorized access to sensitive information.

To replicate this vulnerability, two user accounts are required: User1 and User2. The following steps expose the issue:

1. Log in to the application as User1 and submit a support request to the bank through the “Information” > “User Support” > “Submit a Request to the Bank” section.

2. Intercept the request and upload a document to the support request.

3. Send the request and note the path where the document was originally stored, specifically the “absolutePath” parameter.

4. Now, open the URL in a browser with the “absolutePath” parameter and add a Bearer token to the request: https://XYZ_Bank.com/api/blobs/security/{{User1RandomString}}?token={{User1’s Bearer Token}}. Observe that the document is downloaded.

5. Next, log in to the application using User2’s credentials and create a support request following the same steps as before. Find the “absolutePath” of the document for User2.

6. Now, change the random string in the “absolutePath” of User1 to match the “absolutePath” of User2’s document. Open the URL: https://XYZ_Bank.com/api/blobs/security/{{User2RandomString}}?token={{User1’s Bearer Token}}. You’ll notice that User2’s document is downloaded using User1’s Bearer token.

This vulnerability was identified on 11 endpoints within the web application across multiple bank services.

The potential impact of this vulnerability is profound, as it allows any user to manipulate “absolutePath” strings to access, download, or manipulate another user’s data. To address this issue, we strongly recommended implementing rigorous validation of user identification and authorization processes using all predefined parameters, rather than relying solely on a single parameter. By doing so, the bank could mitigate the risk of unauthorized data access and protect the confidentiality of user information.

Vulnerability # 6
Cross-Site Scripting (XSS) – Uncontrolled User Input Threat

During our assessment of the bank’s web application, we detected a critical vulnerability known as Cross-Site Scripting (XSS). This flaw occurs when the application fails to properly validate user input, leading to potential scripting attacks that can compromise user data and application security.

In this case, the application did not adequately validate user-provided data, allowing malicious actors to inject specially crafted URLs or upload malicious files. These attacks can result in various threats, including open redirection, session hijacking, and more. To replicate the attack, a threat actor only needed to visit a manipulated URL, such as:

				
					https://XYZ_Bank.com/searching.html?keywords=%3Cscript%3Ealert(document.cookie)%3C/script%3E
				
			


This URL (decoded value: https://XYZ_Bank.com/searching.html?keywords=<script>alert(document.cookie)</script>) triggers a pop-up displaying the user’s session cookies, revealing sensitive information. This vulnerability could potentially expose user data and lead to various security risks.

The impact of this XSS vulnerability is significant, as it enables attackers to execute arbitrary code within a user’s browser. To mitigate this risk, we recommended implementing robust firewall configurations and thorough input validation before executing user-provided data. The use of a “nonce” value can prevent the execution of external JavaScript. Additionally, it’s advisable to restrict the storage of malicious and unauthorized file extensions, enhancing overall application security.

By addressing these recommendations, the bank could protect its users from potential script-based attacks and maintain the integrity of its web application.

Classification of Bank Penetration Test Results

Our security assessment of the bank’s systems resulted in the following categorization by severity:
10 findings classified as Critical / High, 11 as Medium, 13 as Low, and 1 as Informational.

This classification offers a comprehensive insight into the bank’s security landscape:

Висновок

Our penetration test of the bank’s systems revealed not only the expected Medium and Low-severity vulnerabilities, but also critically severe issues, such as the “2FA Bypass and Unauthorized Account Takeover”, which we highlighted earlier. These findings underscore the imperative need for regular penetration testing in financial institutions. The identified vulnerabilities, ranging from 2FA bypass to currency rate manipulation and XSS threats, illustrate the diverse attack vectors that malicious actors can exploit. Defining the battlefield, understanding the scope of such penetration tests, and addressing these vulnerabilities promptly are paramount in safeguarding the integrity of financial institutions.

By exposing these vulnerabilities, we emphasize the significance of robust security protocols and the continuous vigilance necessary in an era where cyber threats evolve rapidly. Conducting rigorous penetration tests is not just a best practice; it’s an essential safeguard to protect not only the institution itself but, more importantly, the sensitive financial information of its clients.

Інші Послуги

Готові до безпеки?

зв'язатися з нами