CVE-2023-43336: Privilege Escalation Vulnerability in FreePBX

CVE-2023-43336: Privilege Escalation Vulnerability in FreePBX

by Case Study

FreePBX is a popular open-source web-based graphical user interface that manages Asterisk, a communication server. FreePBX allows users to configure and manage their communication systems easily. However, a security vulnerability was discovered in FreePBX version 16.0.26 that could potentially lead to privilege escalation, enabling unauthorized users to access sensitive information and compromise system integrity. 

About the CVE

CVE-2023-43336 is a high-level privilege escalation vulnerability identified in FreePBX version 16.0.26. It allows least privilege users to access information belonging to other users, violating access controls and potentially leading to authorized data disclosure and system compromise.  

What’s the cause of this vulnerability?

The cause of this vulnerability arose due to the improper access controls and untrusted input handling in the application’s codebase. 

Scenario

In August 2023, our team discovered the CVE-2023-43336 vulnerability in FreePBX version 16.0.26. They uncovered this vulnerability through careful analysis and testing which allowed them to apply series of steps to bypass controls and access sensitive data, such as call history, belonging to other users.    

What we found

Our team identified “Privilege Escalation” Vulnerability where the main motive of the attacker is to gain high-level unauthorized access within a security system.  The attacker typically starts with exploiting vulnerabilities to access a system that has limited privileges.  

Brief about what we found

Our team discovered the vulnerability by analysing the behaviour of the application. By logging in with a non-administrative user account with access to the “Call History” modules, they were able to trigger requests and observe the data exchange.  

Through a series of steps, including adding a specific widget to the dashboard and manipulating requests, our team successfully accessed call history data belonging to other users, circumventing the access restrictions implemented by the application.

We helped them mitigate the following risks

Privilege Escalation Vulnerability:

A Privilege Escalation vulnerability is a vulnerability that allows an attacker to gain higher levels of access or permissions within a system or application than they are authorized to have. This type of vulnerability typically arises due to inadequate access controls or flawed permission management within the software. Once exploited, privilege vulnerabilities can enable attackers to execute malicious actions, access sensitive data, and compromise the security of the system or application.

Business risks we prevented:

  1. Breaches of user privacy.
  2. Unauthorised access to sensitive information.
  3. Data theft.
  4. System integrity.
  5. Reputational damage.
  6. Financial loss.

Conclusion

The privilege escalation vulnerability discovered in FreePBX version 16.0.26 underscored the critical importance of robust security practices in software development. The timely identification and remediation of this vulnerability highlighted the importance of proactive security practices in mitigating risks to sensitive data and system integrity. This case highlighted the ongoing need for proactive security measures, including vulnerability assessments, timely patching, and user education, to defend against the evolving cybersecurity threats and ensure the resilience of communication infrastructure.

References:

https://en.wikipedia.org/wiki/FreePBX

https://medium.com/@janirudransh/security-disclosure-of-vulnerability-cve-2023-23336-4429d416f826

https://www.cynet.com/network-attacks/privilege-escalation/

Zimbra case-study thumbnail

Identifying a vulnerability in Zimbra software

by Case Study

Overview

CVE short for Common Vulnerabilities and Exposures is a globally recognized system managed by MITRE Corporation. It standardizes the identification and cataloging of software vulnerabilities, assigning unique reference numbers to each allowing easy tracking and reference across different platforms. This centralized database plays a crucial role in enhancing cybersecurity practices as it promotes information sharing, collaboration, and awareness of vulnerabilities, facilitating proactive remediation efforts and improving software security across industries.

About the CVE

CVE was listed in Zimbra Security advisories.

The CVE ID is CVE-2023-34193. The CVE was listed in Zimbra’s security advisories.

Scenario

Our team found a vulnerability in Zimbra software where we worked with a vendor to get the CVE listed.

What We Found

We discovered a high-level vulnerability called “Remote Code Execution (RCE)”. RCE vulnerability can provide an attacker with full access to control over a compromised device, making it one of the most dangerous and critical types of vulnerability.

Brief About What We Found

We found a Remote Code Execution vulnerability by logging in with an admin user. Navigated to Tools and Migration, and then Client Upload and Upload the JSP shell.

Navigateing the URL

Later on, we visited to the URL and observed the response with a list of all files. The remediation to this vulnerability is by implementing buffer overflow protection, Implementing WAF (Web Application Firewall), Monitoring your application, Input sanitization, and Access Control.

We Helped Them Mitigate the Following Risk

Remote code execution

Remote code Execution (RCE) is a cyber-attack that allows an attacker to remotely execute commands on a victim’s device. It often occurs via malicious malware downloads regardless of the device’s geographic location. The attacker scans for vulnerabilities, exploits them, gains access, and executes malicious code for various objectives, such as data theft, fund diversion, surveillance or service disruption.

Publications

Several websites published about this critical bug; the links are as follows:

https://cve.report/CVE-2023-34193.pdf

https://www.cvedetails.com/cve/CVE-2023-34193/

https://vulners.com/prion/PRION:CVE-2023-34193

Business Risks We Prevented

  • Initial Access
  • Information Disclosure
  • Information Theft
  • Crytomining
  • Ransomware
Andriod Application

Pentesting On An Android Application

by Case Study

Overview

Android Applications with no exception are prone to cyber threats and attacks. They are the most widely used applications worldwide and these cyber threats and attacks are a growing concern to both consumers and developers.  Malicious actors target these apps as a way to spread malware, steal personal information, and gain unauthorized access to users’ devices. From fake banking apps to social media scams, there is no shortage of ways hackers exploit Android app vulnerabilities. To combat this issue, developers must prioritize security measures during the app creation process by encrypting data, limiting third-party integrations, implementing strong authentication protocols, and conducting regular vulnerability assessments. We were asked to pen test an Android application by a client. In this case study, we’ll discuss the vulnerabilities found and ways used to detect them.

Scenario

We were asked to perform Android Penetration testing on their Android Application to detect possible vulnerabilities.

Major Android Application Risks

Major Android application risks that professionals need to be aware of include security vulnerabilities, data privacy concerns and malware infections.

  • Security vulnerabilities can allow attackers to exploit weaknesses within the application code or hardware to gain unauthorized access to sensitive information or system resources.
  • Data privacy concerns arise when an application accesses or collects user data without permission, or when it sends that data to third parties who may not be trustworthy.
  • Malware infections on Android devices can infiltrate applications, steal sensitive information, and take control of the device to carry out malicious actions without the user’s knowledge.

Professionals must carefully consider these potential risks when developing and deploying Android applications, implementing strong security measures like encryption, secure authentication protocols and frequent security testing throughout the development process.

It is also essential for professionals using Android applications in workplaces or on personal devices to remain vigilant about accessing insecure networks or downloading suspicious applications that could compromise their systems’ security and integrity.

What we found

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

  • The Critical-level risks involve User credentials exposed in the web-socket response.
  • The High-level risks comprise Authorization Bypass Via IDOR- View sensitive information of other users and Application code is not obfuscated.
  • The Medium-level risks include Insecure local storage in shared preferences, Authorization Bypass via IDOR- View group Members of other groups, Unrestricted file upload, App log sensitive information, Session not expired, Insecure communication, and Insecure hash function (MD5 hash Used).
  • The Low-level risks contain Insecure Permissions and Unknown Permissions.

Brief about what we found

During our examination of the application, we discovered several Critical, High, Medium, and Low vulnerabilities.

Firstly, we found “Credentials exposed in WebSocket Response”. To find this vulnerability, we logged in with a valid username and sent a request to the URL to observe that the response had details like a hash password. 

When we logged in with a valid user such as User1, tapped on the “Profile Settings” feature and intercepted the request, it returned the hash password of User 1 on the response side. When the user ID of User1 was changed in the URL to another user ID known as User2, the name and password of User 2 were returned. That’s how we discovered the “Authorization Bypass Via IDOR- View Information of other user” vulnerability.

We’ve discovered that the application code was not obfuscated. This was uncovered by reversing the application, and we’ve discovered that the source code is in a readable and understandable form.

We spun the Android device, accessed the shell and navigated to the shared preference directory. When we opened a particular file, the file contained the “UserAuth” token. We’ve identified “Insecure Local Storage in Shared Preferences” through this.

We unmasked the “Authorization Bypass via IDOR- View Group Members of Other Group” vulnerability when we logged in as a valid user and tapped on to any existing group. When we tapped on a particular group to access group information, it came to light that the URL on the response side exposed the entire information of group members of the particular group. Later, we logged in with another User, clicked on another group, noted the ID of Channel 1 (channel id1) and logged out. We changed the value of the parameter from “channelid1” to “channelid2” and observed that the “channel name” and data are different on the response side.

We’ve also discovered “Unrestricted file upload”. Where the malicious user could upload an image. The attacker selected an image file and changed the extension of the file from “.jpeg” to “.exe”.  The attacker then sent a success message indicating that the file had been uploaded successfully and sent the URL to the victim. If the victim clicks on the URL, a file will be downloaded and their system might get compromised.

During the application assessment, we found that sensitive information could be logged. The “Authorization” token is not terminated after the logout feature.

We’ve also discovered that the app communicates with servers using “cleartext network traffic”, such as HTTP. And the traffic risks are being eavesdropped upon and tampered with by third parties. This can lead to information leakage and unauthorized content or exploits being injected into the app.

The hash function used in the application is old and insecure, allowing an attacker to conduct a hash collision attack without changing the hash. Additionally, the application uses the MD5 hashing algorithm for passwords.

Finally, we discovered that the app was insecure and gave unknown permissions.

We helped them mitigate the following risks

  1. User credentials exposed in the web-socket response:

Sensitive data is confidential information that must be kept safe and out of reach from all outsiders unless they have permission to access it. Access to sensitive data should be limited through sufficient data security and information security practices designed to prevent data leaks and data breaches.

Sensitive data is defined as any information that is protected against unwarranted disclosure. Protection of data may be required for legal or ethical reasons, for issues about personal privacy, or for proprietary considerations.

The risks of exposed user credentials are that threat actors can access additional hosts, install malware, steal data, and disable or modify security controls.

  1. Application Code is not obfuscated:

Unprotected Android apps increase the risk of exposing your businesses to IP theft, loss of revenue, or reputation damage. App providers must actively protect their apps against emerging threats with a strong layer of defence to safeguard critical code from attackers. Obfuscation is a series of code transformations that turn application code into a modified version that is hard to understand and reverse-engineer.

This way you ensure that your product’s intellectual property is protected against security threats, the discovery of app vulnerabilities and unauthorized access.

In the current scenario, the Android application was not obfuscated and hence revealed the source code of the application.

  1. Unrestricted File Upload:

Many web applications allow users to upload files that will either be stored or processed by the receiving web server.

It was possible to identify a form which allows files with arbitrary content and extension to be uploaded to the remote server and then stores the uploaded file to a guessable path in the server’s Webroot.

This could be used by a cyber-criminal to host content from the vulnerable server for phishing and Cross-Site Scripting attacks. In cases where the server is configured to execute scripts (PHP, Ruby, etc.) this vulnerability can be used to gain remote code execution on the server.

During the assessment of the application, it was discovered that any file can be uploaded while updating the “Display Picture”.

  1. App Log Sensitive Information:

The mobile platform provides capabilities for an app to output logging information and obtain log output. There are many legitimate reasons to create log files on a mobile device, such as keeping track of crashes, errors, and usage statistics.

Log files can be stored locally when the app is offline and sent to the endpoint once the app is online. However, logging sensitive data may expose the data to attackers or malicious applications, and it might also violate user confidentiality.

We discovered the application logs, firebase token, meeting ID, user credentials, and User-id AuthKey in the application.

  1. Unknown Permissions:

Unknown permissions should not be part of the application. The attacker may leverage this permission to manipulate the file system in the device.

During the assessment of the application, it was discovered that unknown permissions were given which might be vulnerable and may lead to accessing of the application by other applications.

Business Risks We Prevented

  • Data Breach
  • Malware
  • Spoofing
  • Unauthorized access to data
  • Decline in App Downloads
  • Financial Loss
  • Decline in Reputation
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