PENTESTING FOR A FINTECH COMPANY

Pentesting For A FinTech Company

by Case Study

Overview

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.

Scenario

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.
  • The Low-level risks contain Username Enumeration, Outdated JavaScript Library, Allowed HTTP methods (OPTIONS Method), and Missing ‘X-Frame-Options’ header.

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.

We discovered that the attacker can easily enumerate users by exploiting error messages generated by the application. Additionally, we found that the application is utilizing an outdated JavaScript library that is known to have vulnerabilities such as command injection and denial of service attacks.

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.

It is imperative that these vulnerabilities are addressed immediately to prevent any potential attacks. We recommended that the application’s JavaScript library is updated, and the x-frame OPTIONS are implemented to enhance the application’s security. Additionally, the application’s error messages should be reviewed and modified to prevent attackers from gaining access to sensitive information.

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.
Magento case-study thumbnail

Pentesting On A Magento-Based e-Commerce Application

by Case Study

Overview

Penetration testing is a crucial security measure for all e-commerce websites, particularly those developed on the Magento platform. In this case study, we will delve into the process of conducting a pen test on a Magento-based e-commerce website to detect and resolve any potential vulnerabilities. We will discuss the various tools and techniques used during the testing process, as well as the outcomes of the test, and highlight the business risks that we were able to mitigate.

Scenario

To ascertain whether their web application harboured any security flaws or vulnerabilities, we were tasked with conducting a web application penetration test on their Magento-based web application.

Major Magento-based e-commerce website risk

Major e-commerce websites based on Magento are exposed to numerous risks associated with potential cyber-attacks. One of the primary issues is that many Magento sites can be unpatched and susceptible to vulnerabilities, resulting in hackers taking control of systems and stealing customer data. Additionally, weak administrator passwords or easy-to-guess ones give malicious actors an entry point; thus, businesses should ensure that strong passphrases are used. Another major risk is poor website performance due to extensive traffic or malicious bot activity, as this can easily affect the user experience, result in lost sales, and tarnish a company’s reputation with customers. To mitigate these risks, it is paramount for companies utilizing Magento to ensure their systems are secure and properly maintained. Furthermore, best practices should be implemented such as two-factor authentication which strengthens security against threats while also providing IT professionals with the agency they need in safeguarding customer data.

Attack Narrative

Gathering information was the first step in the process. Both passive and active methods were employed to collect data. Afterwards, a comprehensive understanding of the directory structure and mapping of the application was acquired. Additionally, related external sites were identified, HTTP headers were inspected, and information was collected through errors and error pages. The source code was also examined and the documentation was reviewed during this phase. With the information gathered, analysis of the application and its dependencies began, exploring any application vulnerabilities and verifying the security controls in place. Once all the information was gathered and mapped, test cases were prepared according to the flow of the target application. Tools such as Burp Suite Professional, DirSearch, and Nikto were used to identify and exploit vulnerabilities. The suggested test cases were implemented and the report was created.

What we found

We classified the risks we found into three categories I.e., High, Medium, and Low:

  • The High-level risks comprise Insecure Direct Object References (IDOR) on Abandoned Carts, Insecure Direct Object References (IDOR) on Product Catalogue Delete, and Privilege Escalation Vulnerability in Email Log Delete.
  • The Medium-level risks include Privilege Escalation Vulnerability in Product Transfer Catalogue, Privilege Escalation Vulnerability in Manage Order, Privilege Escalation Vulnerability on Abandoned Carts Log Download, Privilege Escalation Vulnerability using Abandoned Cart, and Privilege Escalation Vulnerability on Staff and Admin Configuration.
  • The Low-level risks contain HTTP Strict Transport Header Missing.

Brief about what we found

First, we logged in as both administrators and customer viewers in their respective browsers. We discovered an abandoned cart module when going to the “Sales” tab on the administrator side, which cannot be found on the customer viewer side. When clicking on the “View” option in the “Action” section of the table, all the details regarding the abandoned carts are displayed. We then copied the URL and pasted it on the customer viewer side, finding that the customer user could access the details without permission (Insecure Direct Object References (IDOR) on Abandoned Carts). We also discovered that the customer could delete a product from the catalogue (IDOR on Product Catalogue Delete) by conducting a similar process.

We helped them to mitigate the following risks.

Insecure Direct Object References (IDOR) on Abandoned Carts:

The OWASP guide gives the following description for Insecure Direct Object Reference:

Applications frequently use the actual name or key of an object when generating web pages. Applications do not always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws and code analysis quickly shows whether authorization is properly verified.

Privilege Escalation Vulnerability in Email Log Delete:

Privilege escalation vulnerabilities allow attackers to impersonate other users, or gain permissions they should not have. These vulnerabilities occur when code makes access decisions on the back of untrusted inputs.

HTTP Strict Transport Header Missing:

HTTP Strict Transport Security (also named HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click-through prompts on browsers.


Business Risk we prevented

  • Data Exposure.
  • Unauthorized alteration of data.
  • Price Manipulation.
  • A decline in customer acquisition and retention.
  • Loss of reputation.
  • Financial loss.
PENTESTING FOR A UK-BASED E-COMMERCE START-UP thumbnail-min

Pentesting For A Healthcare Organization

by Case Study

OVERVIEW

The healthcare sector is working relentlessly to offer the best life-critical services to ease patient management with new technologies. However, Cyber attackers are coming up with ways to exploit the vulnerabilities that are associated with these changes. The healthcare industry is afflicted by a mass number of cybersecurity-related issues. The need for cyber security in healthcare industry is essential.

SCENARIO

We were asked to perform a web application penetration testing on their web application to verify if any vulnerability exists on their platform. Also, a Black box testing to test their initial security implementation.

MAJOR HEALTHCARE DIGITAL RISK

Data breach, Data theft, Malware, Exploitation of existing vulnerabilities in the applications. We helped mitigate them all.

WHAT WE FOUND

We classified the risks we found into three categories I.e., High, Medium, and Low:

  • The High-level risks comprise Privilege Escalation Vulnerability, Forced browsing, and User Account takeover via Sensitive Data Exposure.
  • The Medium-level risks include API documentation Expose, Password in HTTP Response, Verbose Error, and Server Version Disclosure Vulnerability.
  • The Low-level risks contain User Enumeration, Full Path Disclosure, and Frameable Response (Clickjacking).

BRIEF ABOUT WHAT WE FOUND

In the application, we were given an admin role. By creating another user and intercepting the requests to view customer data, we discovered that the normal user can access the information that was meant to be accessed by the admin user only. This Vulnerability is known as Privilege Escalation Vulnerability. The entire application was highly affected by this vulnerability.

By conducting an observation, we spotted an end-point that could expose the user details if crafted properly. We also discovered that the .js file had a session cookie that led to the test account takeover. Upon conducting a few tests, we discovered that the API documentation is publicly available.

A known password was found in an HTTP response. As the password was not submitted in the HTTP request initiating the response, the password had likely been stored on the server, or a connected system, in an insecure manner. In this scenario, the application responds with the hashed password that an internal user can use to crack and get the plain text password to impersonate the existing user.

After creating a malformed request and creating numerous requests, we got a verbose error. The server also disclosed the version. The server disclosed the Full Path of the application too. The application was also prone to User enumeration and Frameable Response (Clickjacking) as well.

We helped mitigate the following risks

User Account Takeover via Sensitive Data Exposure:

User account takeover is a vulnerability where an attacker modifies the execution flow of the application resulting in unexpected behavior. Several factors might be responsible for User Account Takeover, including weak access controls, two-step auth bypass, etc. Such vulnerabilities may result in data theft and leakage of sensitive user details, leading to data disruption.

Recommendations we suggested:

  • Implement proper access controls in the application.
  • Implement strong session-based checks for an individual user.

API documentation Exposed:

The most valuable asset an organization owns is its data. Threats to that data have to be identified and, hopefully, eliminated so you don’t put that value at risk. However, with the rise of Application Programming Interfaces (APIs) comes the potential for more security holes, meaning developers need to understand the vulnerabilities to keep corporate and customer data safe. With such an accelerated shift to API-based architectures, it’s important to note that in many ways, APIs provide the easiest access point for a hacker who wants your data. The existing application reveals the API documentation that might be helpful for the attacker to conduct further attacks on the infrastructure.

Recommendations we suggested:
  • Remove the API documentation.

Username Enumeration:

Web applications with password and login authentication typically include several components that interact with the user database such as the login window, the registration form, and the password reset page. If the web developers do not implement these features securely, an attacker may be able to use them to determine if a certain username exists in the database.

Recommendations we suggested:

It is advised to generate a generalized error message to avoid username enumeration. For instance: – “Incorrect Username or Password”.

Frameable Response (Clickjacking):

Clickjacking is a malicious technique of tricking a user into clicking on something different from what the user perceives, thus potentially revealing confidential information or allowing others to take control of their computer while clicking on seemingly innocuous objects, including web pages. The attacker tricks a user into performing undesired actions by clicking on concealed links.

Recommendations we suggested:
  • Implement X-Frame-Options headers in the response.
  • Implement Content Security Policy that implements frame-ancestors directive examples:
# Disallow embedding. All iframes etc. will be blank or contain a Browser-specific error page.

Content-Security-Policy: frame-ancestors 'none'

# Allow embedding of own content only.

Content-Security-Policy: frame-ancestors 'self'

# Allow specific origins to embed this content

Content-Security-Policy: frame-ancestors <host>

BUSINESS RISK WE PREVENTED

  • PII (Personally identifiable information) exposure.
  • Reputation loss.
  • Data breach.
  • Data theft.
  • Possibility of the customer losing their test report.
PENTESTING FOR A UK-BASED E-COMMERCE START-UP 1

Pentesting for a UK-based E-Commerce Start-up

by Case Study

OVERVIEW

A large volume of sensitive data is exchanged on e-commerce websites, making them a popular target for cybercriminals. Penetrating your e-commerce website is the only way you can keep on top of the ever-evolving tactics hackers use to breach your website. In addition to bringing new opportunities for retailers, advances in e-commerce have also led to a growing number of security threats. E-Commerce weaknesses are being exploited more creatively and boldly than ever before.

Scenario

We were asked by the client to perform Web application and Mobile application penetration testing on their e-commerce platform to ensure any vulnerability exists on their e-commerce platform.

Major E-Commerce digital risk

Bots, exploiting known vulnerabilities, Dos attack, spamming, data tempering, malware, brute force attack, MITM. We help them mitigate them all.

What we Found

We found many other risks that are Critical, High, and Medium level risks.

  • The Critical Level Risks include Authentication Bypass by Response Manipulation, User Account Takeover, Contact Full Address Disclosure at Checkout Phase, Privilege Escalation Vulnerability, Laravel Telescope Dashboard Publicly Accessible, Admin Panel Authentication Bypass, Insecure Direct Object References (IDOR), Sensitive Data Exposure by Verbose Error Messages, Forced Browsing.
  • The High-Level Risks include Laravel Horizon Dashboard Publicly Accessible, Cross-Site Request Forgery, Merchant can self verify their account instead of the Admin User leading to Privilege Escalation.
  • The Medium Level Risks include SSL Not Enforced, Outdated Apache Version Used, Weak Password Policy, Sensitive Parameters are susceptible to Brute Force Attack, Email Denial of Service, Host Header Injection, Multiple Registration via Automation, Server Version Disclosure Vulnerability.

Brief about what we found

We discovered the Authentication Bypass by trying to log into the application with the correct mobile number and incorrect password. We manipulated the invalid response with a valid response by stripping off the session_token, token value. Here the main identifiers for an application are the user id and phone number that can be used for authentication bypass.

We also tried logging into the application using our credentials. We changed the user id to any existing user in the application and forwarded the request. It was possible to access another user account. Due to this, we can take over all the user’s accounts existing in the application. This risk is known as User Account Takeover.

We performed mobile application and network penetration testing. By this, we could find the risks which are at Critical, High, and Medium levels.

We helped them to mitigate the following risks.

Privilege Escalation Vulnerability: Privilege escalation vulnerabilities allow attackers to impersonate other users, or gain permissions they should not have. These vulnerabilities occur when code makes access decisions on the back of untrusted inputs.

Recommendations we suggested

There are three possible approaches to prevent this to happen:

1. Keep critical information on the server side, and only send session IDs to the client.

2. Tamper-proof the data sent to the client, by using a digital signature.

3. Encrypt the data sent to the client, so it is opaque to the client.

 

Admin Panel Authentication Bypass: The application has an admin panel vulnerable to authentication bypass. The application allows users to access sensitive areas of the application and bypass authentication controls. A lack of proper authentication exposes sensitive data and operations within the application and prevents the logging and tracking of user activity.

Recommendations we suggested

We in-detail recommended they follow the below steps.

1. Proper authentication mechanisms should be put in place to ensure that users are required to authenticate before accessing sensitive data.

2. Multi-factor authentication should also be used to further enhance authentication strength.

 

Forced Browsing: Forced browsing is an attack where the aim is to enumerate and access resources that are not referenced by the application but are still accessible.

Recommendations we suggested

After testing this risk, we recommended a few steps which are to be followed.

1. Enforce an application URL space allow list and use proper access control.

2. Use proper access control and authorization policies, access is only given to users commensurate with their privileges.

Business Risk we prevented

  • Financial loss
  • Reputation loss
  • Customers being victims of malware
  • Application unavailability due to hacking attempts
  • Supply chain attack