Since I moved to Italy, my professional life has undergone a radical change. Information security and cybersecurity in Europe are a few years ahead of us in terms of protocol compliance and security standards.
For a while now, I’ve been reporting a vulnerability that doesn’t get much attention. In fact, I find it very strange that BugBounty programs categorize it as a “Medium” vulnerability.
That’s why today I want to talk about one of my favorite vulnerabilities. I think it’s one of the most underrated vulnerabilities by BugBounty programs. It’s very simple and easy to execute, yet it creates serious financial and operational problems. This vulnerability silently attacks, disrupting the logic or functionality of an application.
We’re talking about the “HyperLink Injection” vulnerability.
Disclaimer Message
“ I am not responsible for any misuse of the information presented in this article. Its primary purpose is to help and inform system administrators about the potential problems a vulnerability can cause when proper security controls are not in place”.
Let’s Talk About the Vulnerability
“HyperLink Injection” is a vulnerability that allows an attacker to insert URLs or web addresses with malicious content through the parameters of a form. This vulnerability enables us to interact with the content sent in the “automated responses” from the client’s mail server.
The content of the automated response, being sent by the official sender of the client (domain@domain.com), is received with a high level of “trust” (certified entity) in the users’ inboxes. This allows phishing and malware distribution under the client’s name.
Impact
The impact of this vulnerability allows the use of a client’s mail server to send malicious content to third parties, causing serious financial, operational, and corporate image problems.
Where do we find this vulnerability?
It is important to control all the services that a web application exposes. This is especially true for functions involving a data form. A typical example is when we request information about a service or submit an application. Generally, you are asked to fill out a data form with your name, surname, and email address.
Upon submitting the form, we automatically receive an email with a message that says:
“Fabian, thank you for requesting information. One of our representatives will contact you shortly.”
Upon verifying that the content of the automated response includes the value “Name,” there is a possibility that the client is vulnerable to HyperLink Injection.
Functionality
A user requests information by filling out a client’s data form. In this form, the user enters their first name, last name, and email address.
When the form is submitted, the client’s mail server responds with an automated message. In this message, one of the parameters entered, usually the value “Name,” is included.
Proof of Concept (POC)
Let’s use a case where I reported the vulnerability through a BugBounty program. The vulnerability was identified in the GiveWP plugin for WordPress, which allows you to manage online donations. This vulnerability had not been reported before, and I’ve taken the opportunity to show you the attack in detail.
For privacy reasons and to prevent new inquiries from being sent to the target, I have modified the evidence to conceal the client’s identity.
HyperLink Injection
Original Behavior of the Application:
The WordPress GiveWP plugin is primarily used for managing donations. To identify a HyperLink Injection vulnerability, we need to check which form parameters are reflected in the automated response sent by the client’s server.
For this test, we will make a donation using the application’s form. In the “First Name” and “Last Name” parameters, we will enter the word “test,” and in the “Email Address” parameter, we will enter the email address where we want to receive the automated response.
- Make a donation through the form:
- First Name: test
- Last Name: test
- Email Address: [your email address]
By doing this, we can observe if and how the entered values are included in the automated response from the client’s mail server, helping us determine the presence of the HyperLink Injection vulnerability.
Upon making the donation, you will automatically receive an email from the client.
Analysis of the Automated Response:
The initial impression is that we receive an email from the client with its official sender, indicating it’s not a phishing attempt.
Secondly, the values “First Name” and “Last Name” are reflected in the content of the automated response sent by the server.
Let’s Go to the Attack!
Attacker’s Behavior:
Understanding the behavior of the automated response, we will create a malicious website where every user who clicks will automatically download a malicious file, which could potentially be ransomware. In the “First Name” parameter, we’ll enter a message asking the user to “view their receipt” for the donation made, and in the “Last Name” parameter, we’ll enter our malicious website.
In “First Name,” we enter the message “View the receipt,” and in the “Last Name” value, we input the hyperlink to the malicious website.
Here’s how it looks:
First Name: View the receipt
Last Name: in www.evil.comUpon completing the attack, we enter the target user’s email address to receive the malicious content.
- We enter the message, malicious URL, and the target’s email address.
- We make the donation and receive the automated response via the client’s mail server.
- The target receives the malicious content through the application’s vulnerable automated response. Since the user is unfamiliar with this type of “donation,” they click the hyperlink to view the receipt or detailed information about the transaction.
The donation is made, and we receive the automated response via the client’s mail server.
The final target receives the malicious content through the vulnerable application’s automated response. Unaware of this type of “donation,” the user clicks the hyperlink to view the receipt or detailed transaction information.
Automatically, a malicious file is downloaded (in this case, an .iso file), and when executed, it runs potential ransomware in the background.
A simple, silent, and effective vulnerability. Attackers exploit such behaviors to harm governments, hospitals, factories, competitions, etc., as they utilize third-party mail servers. After all, it’s enough to enter the target’s email address to cause damage.
Why is it one of my favorite vulnerabilities?
1First of all, it’s a vulnerability that’s very easy to exploit because you don’t need extensive technical knowledge to execute it; all you need to do is enter the message to the user in one of the form parameters and add the URL or hyperlink to perform the desired action. Additionally, you don’t need large resources like hosting, domain, certificate, etc., since we use the client’s server.
2Secondly, it’s a vulnerability that’s very easy to find because you only need a functionality in the application that allows you to interact with automated responses from the mail server. These functions are commonly found in inquiry forms, registration, requests, payments, etc.
3Third and most importantly, this vulnerability has a “BRUTAL” impact and risk, for two simple reasons. First, it directly affects the client financially and in their corporate image (obviously because we use their name to send ransomware or phishing to other companies, people, or others). The second reason goes to the title of this article.
Why is it undervalued?
Vulnerabilities like Remote Code Execution (RCE) or SQL Injection are two vulnerabilities with a completely CRITICAL impact since you have total control over access and data. However, exploiting these types of vulnerabilities in updated systems is not an easy task for an average person. On the other hand, this vulnerability is so simple that anyone could exploit it.
Additionally, this is one of the few vulnerabilities with a HIGH impact that attacks “SILENTLY.” The client is unaware of the misuse of their mail server until ransomware has been executed on an internal user or external company.
If we wanted to attack the client’s internal users or their partners, the likelihood of a successful attack is HIGH. Even for people who have conducted “phishing” exercises, it’s difficult to doubt their content, as it’s practically sent from an official domain.
If we talk about companies that have a great SOC (Security Operations Center), well-configured WAFs, Load Balancers, Antivirus, anti-phishing protection, etc., unfortunately for them, the malicious content is accepted without any restrictions, as it’s sent from the client’s server. In other words, if we were to attack the client’s internal users’ email, the malicious content is not verified, as it’s sent from an authorized domain or entity of the client.
Mitigations
The mitigations that should be applied regarding this type of vulnerability are as follows:
- Establish a “whitelist” of allowed characters in each of the forms. If the contact form requests a “Name,” users should not be allowed to enter special characters such as periods, colons, commas, backslashes, etc.
- Implement a properly configured captcha (with validations performed on the server side) in each of the application’s forms and logins. This prevents mass submissions, avoiding Denial of Service (DOS) and brute force attacks.
- Control the activity and volume of emails sent automatically to prevent anomalous behavior.
Conclusion
In Red Team operations, these techniques have a high probability of success. It’s worth noting that compromising an organization requires only one vulnerable device. Attackers prefer these types of vulnerabilities mainly because of their effectiveness and minimal preparation when conducting the attack.
The leakage of the LockBit 3.0 ransomware creator last year has led attackers to abuse the tool to generate new ransomware variants, and unfortunately, this is one of the vulnerabilities that allows its distribution. These types of attacks are becoming more elaborate, bypassing defense protections such as firewalls, antivirus, and causing serious operational problems.
In conclusion, HyperLink Injection is a very simple, silent, and effective vulnerability. It’s mandatory to be aware of these techniques as they don’t trigger any alerts on the server.
It’s important to monitor the activity of our publicly exposed services to prevent the possibility of an attacker using one of our services without authorization and for malicious purposes.
See you next time!!
