Ransomware

HOW HAS RANSOMWARE EVOLVED OVER TIME?

Overall, there is 53% increase in Ransomware incidents reported in 2022 Year over Year.

               -CERTIN(India Ransomware reports)

Ransomware has become one of the most significant cybersecurity threats facing individuals, businesses, and organizations around the world. It is a type of malware that encrypts data and demands payment in exchange for a decryption key. While ransomware attacks have been around for decades, they have evolved significantly over time, becoming more sophisticated and prevalent. In this article, we will explore the history and evolution of ransomware, from its humble beginnings to the modern era, and examine the impact it has on individuals and organizations. We will also discuss strategies for preventing and responding to ransomware attacks and look at what the future may hold for this dangerous threat.

Introduction To Ransomware

Ransomware has become a popular tool for cybercriminals seeking financial gain, as victims often feel compelled to pay a ransom in order to regain access to their data.

2 (1)

What is Ransomware?

Ransomware is a type of malware that takes control of a victim’s computer system and demands payment in exchange for releasing the data. It can be delivered through malicious email attachments, infected software downloads, or compromised websites. There are two main types of Ransomware: locker ransomware, which locks the user out of their system or certain files; and crypto-ransomware, which encrypts the victim’s files.

How Ransomware Works

Once the ransomware has infected the victim’s system, it will typically display a message demanding payment in exchange for restoring access to the encrypted files. This message will often include a countdown timer, adding a sense of urgency to the situation. Payment is typically demanded in Bitcoin or other cryptocurrencies, making it difficult to trace the identity of the cybercriminals.

Early Forms of Ransomware

3

The First Recorded Ransomware Attack

Message Displayed After Activation of AIDS (Source: Wikipedia)

The first recorded instance of ransomware was the “AIDS Trojan” in 1989, which was distributed via floppy disks and targeted AIDS researchers. The malicious code targeted filenames instead of the contents of the files as we know today causing major disruptions and downtime. This proves that even simple encryption can have disastrous consequences.

Example of Early Ransomware

Other early forms of ransomware examples included the “Gpcode” ransomware in 2004, which used weak RSA encryption that was subsequently cracked by security researchers. And “Archiveus” trojan encrypted the entire files in the “My Documents” folder.

Both of these early examples utilized simple encryption methods and were relatively easy to decrypt without paying a ransom. However, they laid the groundwork for more sophisticated attacks that we see today. The evolution of ransomware has made it increasingly complex, using advanced encryption algorithms and bypassing traditional security measures to extort money from victims by exploiting their data as leverage to achieve financial gain.

Evolution Of Ransomware Tactics

2005-2009: Early Ransomware Tactics

4

Early ransomware attacks were relatively simple, displaying a message that would prevent the user from accessing their system until a ransom was paid. These attacks were often easy to circumvent, and victims could restore their systems by removing the infected files or using anti-malware software.

2009-2016: Encryption-based Ransomware Tactics

5

Encryption-based ransomware is the most common type of ransomware seen today. It uses advanced encryption algorithms to lock files on a system, making them inaccessible to the user. This type of ransomware has become increasingly sophisticated, with some variants even encrypting the filenames themselves. In recent times, Ransomware builders are focusing on speed and performance. Instead of encrypting the whole file, a portion of a file is being targeted for encryption to save time. Multithreading is getting leveraged for faster encryption. A few notable attacks include “Vundo”, and “WinLock”.

2016-2018: Ransomware-as-a-Service (RaaS)

6

Ransomware-as-a-Service (RaaS) is a model in which cybercriminals create and distribute ransomware to other criminals, who then use it to target victims. The original creators of the ransomware typically take a percentage of the profits earned by the secondary criminals. The emergence of RaaS has made it easier than ever for cybercriminals to launch ransomware attacks, leading to a proliferation of providers offering these services on the dark web. Some of the most notorious RaaS providers include “Hive” and “Darkside”. As ransomware continues to evolve, it remains a potent threat to individuals and businesses alike.

2019-2022: Double Extortion

8

Double extortion is a tactic some ransomware groups use to increase the pressure on their victims to pay the ransom. In addition to encrypting files, they also exfiltrate sensitive data and threaten to publish it unless the ransom is paid. This tactic has become increasingly popular in recent years, with several high-profile attacks leveraging this technique.

Today’s Ransomware Landscape:

9 (1)

Common Ransomware Delivery Methods

In today’s landscape, common ransomware delivery methods include phishing emails, malvertising, and exploit kits. Phishing emails trick victims into clicking on a malicious link or attachment to an email, while malvertising involves planting malicious code in online advertisements. Exploit kits take advantage of software vulnerabilities to infect the victim’s device without their knowledge.

Ransomware Targeted Industries and Sectors

Ransomware is now a global problem affecting individuals, businesses, and even government entities. Any organization that relies on computers to carry out its operations is at risk of a ransomware attack. However, some sectors, such as healthcare, finance, and education, are particularly vulnerable due to the sensitive nature of their data.

Impact of Ransomware on Business and Individuals

The impact of ransomware can be devastating for both businesses and individuals alike.

The Financial Cost of Ransomware

12

A report Published by IBM states that “The average cost of a ransomware attack, not including the cost of the ransom is $4.54 million“. However, The financial cost of ransomware extends beyond the ransom payment. It can include lost revenue due to system downtime, data recovery costs, legal fees, and damage to the organization’s reputation. In some cases, victims may choose to pay the ransom to avoid these costs altogether.

Psychological Effects of Ransomware

14

Ransomware can also have psychological effects on victims. The fear and uncertainty caused by the attack can lead to stress, anxiety, and even depression. Individuals feel violated, and businesses experience a loss of trust from their customers and employees.

Strategies for Preventing and Responding to Ransomware Attacks

Business Plan-bro (1)

Prevention and response are the keys to minimizing the impact of ransomware attacks.

Preventing Ransomware Attacks

Preventing ransomware attacks involves implementing security best practices such as penetration testing, regularly backing up data, keeping software up-to-date, using antivirus software, and training employees to identify and avoid phishing emails.

Responding to a Ransomware Attack

If a ransomware attack does occur, the organization should first isolate the infected devices, shut down the network if necessary, and contact law enforcement. They should also assess their backup data and determine if paying the ransom is the best course of action.

Future Of Ransomware: Predictions and Trends

16

As technology continues to evolve, so too does ransomware. Understanding future trends and potential threats is essential for organizations to stay ahead of the curve.

The Increasing Sophistication of Ransomware

Ransomware is becoming more sophisticated, with some variants now capable of evading detection and spreading laterally across networks. This makes it challenging for organizations to detect, prevent, and respond to ransomware attacks.

New and Emerging Ransomware Threats

Emerging ransomware threats include targeting industrial control systems (ICS), as well as the use of artificial intelligence (AI) and machine learning (ML) to enhance ransomware capabilities. As such threats continue to emerge, organizations must remain vigilant and proactive in protecting their critical data and assets.

Conclusion

Ransomware has undergone significant changes throughout its history, from early forms that were relatively simple to today’s sophisticated attacks. While the threat of ransomware is likely to continue to evolve and persist, there are steps that individuals and organizations can take to reduce the risk of falling victim to an attack. By staying vigilant, implementing best practices for cybersecurity, and preparing for the worst-case scenario, it is possible to mitigate the impact of ransomware and other types of malware.

PENTESTING FOR A FINTECH COMPANY

Pentesting For A FinTech Company

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

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

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.
jpg_20230225_220654_0000

Automating Sql Injection By Bypassing Client-Side Encryption

SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with an application’s queries that makes to its database. It generally allows an attacker to view data that they are not normally able to retrieve. This might include data belonging to the other users, or any other data that the application itself can access. In many cases, an attacker can modify or delete this data causing persistent changes to the application’s content or behavior.

It is one of the most common vulnerabilities in web penetration testing. The tools that we used to exploit SQLi are SQLMap, Burp Suite, and online tools. Here, we tried to automated the injection and came across a few problems on the journey. Before addressing the problems, let’s look at the scenario.

About The Application:

The application that we are up against is a portal to deal with suppliers and vendors. Which has various functionalities such as details of suppliers/vendors. Additionally, the creation, modification, deletion, approval, and rejection of tickets generated by other users over an issue, they(supplier/vendors) face during the course of action.

SCENARIO:

A web application has a table displaying the issues raised by the other users and it has search functionality. Hence, we begin with searching for the issues raised by a specific user’s SSOID that contains 175, and the issues raised by that particular user are returned (Figure 1).

 

Figure 1

To test, we entered 175’ and it returned no result. Concerning this, we now suspect a possible SQL injection. Subsequently, we tried to balance the query with a “- -” (double-dashed comment) i.e., 175’- –. Due to this, we successfully got the result of the user. Out of all this, we identified that SQL injection is possible.

For further confirmation, we injected a Boolean-based payload. First, we injected a query that returns ‘FALSE’ i.e., 175’ AND 1=2–. The data is not returned (indicating that the web application is vulnerable to SQL injection) as shown in Figure 2.

 

Figure 2

 

Later, we injected a query that returns ‘TRUE’ i.e., 175’ AND 1=1–. Thence, we got the result of the user (Figure 3).

Figure 3

To automate the exploitation, we are going to use SQLmap. With the help of Burp Suit, we intercepted the request and figured that the request body is getting encrypted. As the request body is encrypted, we can’t just use SQLmap. To achieve this, we need to decrypt the encryption. As encryption is done on the client side, we looked for the key in the .js file and we found the key in the aes.js file. Looking at the internet, we realized that the developer must have replicated the publicly available code from the internet and didn’t change the key. To make SQLmap work explicitly, we’ve added a parameter. (e.g., itest=QWERTYUIOP==)

As we now have the key. We decrypted the encryption using an online tool and we got the request body in plain text.

 

To get SQLmap to work, we need to decrypt and then encrypt the request body as the server only understands the encrypted data. Now to analyze the response which is again encrypted, we need to decrypt it. Hence, we came up with an optimized solution! we created a tamper script that crafts the query with a payload from an already decrypted query and encrypts the whole request body.

 

We explicitly told SQLmap to use only Time-Based Queries to analyze the received data. By this, the complexity of the decryption of the response body reduces. After SQLmap encrypts the request body it looks like this “itest=QWERTYUIOP==”. Since the server only understands this form “QWERTYUIOP==” we made Burp Suite a middleman and removed “itest=” using its feature Match & Replace.

In the above scenario, the problems faced during the process are addressed below:

A. Request Body gets encrypted so can’t use tools like SQLmap directly for the exploitation of SQLi. Need to find the key as encryption is done on the client side.

To decrypt the encrypted data, a key is required. We analyzed all the .js files. We found out they are using AES with EBC cipher mode. We found the key but it was encoded in Base64 format. With the help of online tools or Burp suit’s Decoder, we’ve attained the cipher key.

B. Request format for SQLmap differs from the Server acceptance format.

The legitimate request body format for a server is (e.g., QMBCIIOJKLMNBVCZAQWER==). However, SQLmap only understands parameter value (e.g., Q=” Ownux”) to execute the SQL injection. Hence, we need to explicitly add “Q=” before it.

C. We Need to decrypt the request body before sending it to SQLmap.

Theoretically, for successful exploitation, we need to decrypt the data and send it to the SQLmap. Later, SQLmap will insert payload and we need to encrypt the data before sending it to the server. For SQLmap to analyze the response, we must decrypt the encrypted response again.

D. Need to Encrypt the data with a payload before sending it to the server.

An optimized solution has been found. Instead of decrypting the request and response, we wrote a script that crafts the query with payload from an already decrypted query and then encrypted it using the SQLmap’s Tamper functionality. Now comes the data exfiltration which also requires decryption, instead we explicitly told the SQLmap to run only Time-Based queries.

E. Make the request in a server-acceptable format.

Now after the request data is encrypted using SQLmap which is in the format of (e.g., Q=QMBCIIOJKLMNBVCZAQWER==). On the other hand, the server only accepts encrypted data (e.g., QMBCIIOJKLMNBVCZAQWER==). To convert the request, we used Burp suite’s match & replace functionality where we defined the rule like this:

Find: “Q=”

Replace: <none>

by this, the request would look from this “Q=QMBCIIOJKLMNBVCZAQWER==” to this “QMBCIIOJKLMNBVCZAQWER==” which is in a server acceptable format.

TO SUM UP:

A few of the problems faced through the process are encryption of the request body which makes the process of exploiting SQLi harder, and so on. In a quest to find the solutions to the problems, we found out that SQL injection is possible and retrieved the data of the user using a Boolean-based payload injection. To automate this, we wrote a tamper script that is compatible with the application’s environment. And that’s how we were able to automate the SQL injection by bypassing client-side encryption.