There’s no denying the fact that cyber threats pose a significant risk to the financial industry. With the increasing use of digital platforms and advanced technologies, cybercriminals have found new ways to exploit vulnerabilities in established systems, leading to data breaches and network intrusions. Threat actors may attempt to infiltrate an LEI company’s networks to steal sensitive information, disrupt operations for personal gain, or simply for malicious intent. We were asked to pentest a client’s website and found vulnerabilities. In this case study, we will discuss the vulnerabilities detected and the approaches used to identify them.
We were asked to perform web penetration testing on their .NET web application to detect possible vulnerabilities.
Major LEI-service-based website risks
- Major risks associated with LEI-service-based web applications include data breaches, cyber-attacks, and system failures.
- These risks can arise due to different factors such as inadequate security measures, vulnerability in the application code or third-party software, and lack of resources for maintaining the platform.
- Hackers can exploit these vulnerabilities to access sensitive information related to the organization’s finances, customer data, or other critical assets.
- Furthermore, system failures can lead to operational disruptions that can cause significant financial losses or compliance violations.
To mitigate these risks, it is crucial to implement robust security controls such as regular vulnerability assessments, continuous monitoring of network activity, multi-factor authentication protocols for accessing sensitive information and secure program coding practices.
Additionally, businesses should have comprehensive disaster recovery plans and monitor the availability of the systems with failover mechanisms in place.
What we found
We classified the risks we found into three categories I.e., Critical, High, Medium, and Low:
- The Critical-level risks involve Blind SQL injection.
- The High-level risks comprise Price Manipulation, Firebase Misconfiguration.
- The Medium-level risks include Weak Password Policy, Denial of Service, User Registration Via Automation, Server Version Disclosure Vulnerability, and No Email Verification During the Registration Process.
Brief about what we found
During our investigation, we uncovered several critical vulnerabilities in the application. Firstly, we discovered Blind SQL injection. To test for SQL injection, we intercepted the Upload Reference Documents request and inserted a quote (‘) at the end of the file name. However, this resulted in an error. To confirm the vulnerability, we injected a time-based SQL injection payload that caused the application to sleep for a specific time as defined in the payload. Since the SQL injection was Blind, we created a script tailored to the company to exploit the vulnerability. We then developed an exploit to automate the data exfiltration process, which allowed us to fetch the database name.
In the payment processing section of the web application, we intercepted the “Pay now” request and were able to manipulate the price. After conducting initial reconnaissance, we discovered that the API keys were exposed in the URL. By researching the Google APIs, we found that we could gain complete access to the database, allowing us to READ, WRITE, UPDATE, and DELETE every element. We created a new collection called “Hacked” and retrieved its contents. Additionally, we discovered that weak passwords could be used to register into the portal, which we successfully exploited.
We flooded the admin’s mailbox with redundant emails by automating the Send Email Functionality request. By intercepting the Sign-up request to register in the portal, we repeated the request with multiple sets of payloads containing unique email addresses, allowing us to register multiple users into the application. We also discovered that the server’s version was disclosed in the application response. Upon registering into the application, the user was automatically directed to the dashboard without receiving any email verification links.
Furthermore, we identified that the application’s “OPTIONS” method is enabled, and the x-frame options are missing from the application response. This oversight could potentially allow an attacker to gain unauthorized access to sensitive information.
Moreover, the application’s verbose error messages provide attackers with valuable insights into the application’s backend, making it easier for them to construct malicious payloads to exploit the application.
Overall, our team identified and exploited several vulnerabilities in the web application, highlighting the importance of thorough security testing and implementation.
We helped them to mitigate the following risks.
1. Blind SQL Injection:
Blind SQL injection is an attack technique commonly used by hackers to exploit web applications. It involves injecting malicious code into a vulnerable web application to bypass the security controls and gain unauthorized access to sensitive data or resources.
Blind SQL injection is considered more challenging than classic SQL injection because it generates no visible error messages or responses from the targeted application. Attackers use various techniques, including conditional statements and time delays, to extract data from the database without triggering any alarms.
The consequences of a successful blind SQL injection are severe as it can result in the loss of proprietary information, financial losses, and reputational damage for affected organizations.
The injection was detected as it was possible to inject specific SQL queries, which, if vulnerable, result in different responses for each injection. This is known as a blind SQL injection vulnerability.
To prevent blind SQL injection attacks, developers must implement adequate security measures such as input validation and sanitization, error handling mechanisms, and secure coding practices.
2. Price Manipulation:
Price manipulation attacks are most common on custom shopping cart platforms or smaller shopping cart platforms. Larger and more popular off-the-shelf programs don’t have this vulnerability. However, because the vulnerability isn’t on the server level and is relatively unknown outside of eCommerce, many programmers just don’t know to look out for it.
Shopping carts will often pass on price data in HTTP headers or through cookies. For example, the header might say something like “price=59&ordered=555319&custname=jamesbenyon”. The first variable being passed along is price.
In the application, we were able to still change the price and renew the subscription.
3. Firebase Misconfiguration:
Firebase Misconfiguration is a Vulnerability that can provide direct access to the application via Google APIs. This does not require any type of sign-up functionality to let users register in the application but it is possible to generate a new user and login into the application to access its internal functionality. Firebase applications cannot prevent new users to sign-up unless the application owner disables the whole authentication service.
In the existing scenario, we were able to take over the entire database where we were able to READ, WRITE, UPDATE, and DELETE anything and everything. The fun Fact is, this was possible without having prior credentials or any dummy logins to carry out this attack.
4. Denial of Service:
Denial of Service Vulnerability allows an attacker to send a large number of requests when the APIs don’t have the rate limiting implemented thereby slowing down the server.
Using this vulnerability, the attacker can consume the organization’s and users’ limited resources, which may lead to a denial-of-service scenario. This can also lead to monetary loss.
In the application, due to the absence of the rate-limiting, the attacker can flood the admin’s mailbox with redundant mail using the “Contact us” functionality.
5. Missing ‘X-Frame-Options’ header:
The “Missing ‘X-Frame-Options’ header” vulnerability is an issue that arises when a website does not include the X-Frame-Options header in its HTTP response. This header informs the web browser whether or not it should display the website within an iframe.
Business Risk we prevented
- Data breach.
- Price Manipulation.
- Unauthorized alteration of data.
- Weak Data security.
- Exposure of sensitive user information.
- Lack of trust.
- Financial loss.
- Decline in Reputation.