Discovering a New Vulnerability Type: False Interaction Feedback (FIF) and Its Implications

Intro

As a cybersecurity researcher since 2017 and having worked at Pinterest on the security team for the past two years, I’ve spent some time on both sides of the vulnerability management process by finding, reporting, triaging, investigating, and remediating vulnerabilities.

A common class of vulnerabilities is those that allow an attacker to take advantage of the trust a user has in the system they’re interacting with. These often help aid social engineering attacks such as phishing, and are challenging to combat as they often take place client-side.

Open redirects are a classic example of this, where an attacker finds a flaw in the target platform that allows them to redirect a user (without user-interaction) to their own malicious website. An attacker could then use this in various ways depending on what they’re trying to achieve, such as:

• A download link that appears legitimate but redirects to the attacker’s malicious executable
• A redirection to a typosquatted (similar name) domain that presents itself as the initial website in order to acquire information from the victim

Discovery

Recently, I’ve discovered an attack vector that isn’t well defined by any current CWE and appears to be untapped (as seen through basic Google Dorking). This vulnerability capitalizes on the feedback mechanism within many applications, and how it can be abused when the flow at hand follows poor development practices.

I’m calling this attack vector the False-Interaction Feedback Vulnerability. Essentially, this involves an application presenting feedback to the end-user that suggests some action/interaction has taken place, yet the user hasn’t actually initiated that action. This is accessible to the end-user because the application does not secure the sequence of the action->feedback flow. This illegitimate feedback creates a false sense of security between the user and platform which makes them susceptible to deceptive campaigns or social engineering tactics from attackers.

Relation to Existing CWEs

Mentioned earlier, this attack vector is in the class of social engineering weaknesses and tangentially related to open redirects CWE-601(Open Redirect).

With an open redirect, an attacker abuses the trust a user has in the target platform’s domain to send them to a malicious site under the guise of a legitimate one.

With a FIF, an attacker leverages the trust a user has in the platform’s feedback to reinforce the initial deception on the malicious site/program. Unlike an open redirect, where the victim is tricked into leaving the trusted domain, the FIF sustains the user’s trust in the malicious site by using misleading feedback to support the false narrative.

Similarly, there is some parallel with CWE-451(User Interface (UI) Misrepresentation of Critical Information), which focuses on situations where the UI displays incorrect or misleading data. This CWE addresses vulnerabilities where the user interface presents erroneous information, causing users to make decisions based on faulty data. These issues often arise from improper handling of user input or erroneous feedback within the UI, such as misleading messages or incorrect icons.

In contrast, the False-Interaction Feedback (FIF) vulnerability does not involve erroneous data being displayed within the UI. Instead, FIF involves the UI providing accurate and expected feedback, but this feedback is presented outside its intended sequence or context within the application. The issue arises because this feedback, while accurate, is used inappropriately to create a misleading narrative for the malicious site/program. This can only be caused by a developer failing to secure feedback flows or ensure proper sequencing.

How It Works

Consider a scenario where a website has the following flow for a password reset:

1. The user navigates to good.com/password/reset/.

2. The front-end page displays fields for entering the old and new passwords. Upon submission, the form sends a POST request to api.good.com/v2/change-password.

3. If the password change is successful, the server responds with a redirection header that directs the user to good.com/password/change-success/, where they see a confirmation message on the screen: “Your password has been changed!”

If good.com/password/change-success/ is accessible to any end-user by simply visiting the page without actually resetting their password, then this flow is vulnerable to FIF.

Attack Scenario

In this scenario, an attacker could set up a malicious site that mimics the legitimate password reset process and then redirects users to good.com/password/change-success/. Because the feedback page appears to be part of the trusted platform, users will not see any warning signs or inconsistencies that would otherwise prompt them to verify their password change on the legitimate site.

Other Examples

• Download Confirmation Pages: An attacker could create a malicious site posing as a tool, and may include text such as “Requires GoodSoftware - Download Here”. Because GoodSoftware doesn’t prompt the download on their “Thank you for downloading!” page (FIF vulnerable), the attacker’s website would download their own malware to the client but redirect to GoodSoftware’s feedback page.
• Payment Confirmation Pages: An attacker might fake an e-commerce order process and redirect users to a “Thank You for Your Purchase!” page on the legitimate website.
• File Upload Confirmation Pages: After a file upload, users could be redirected to a “File Uploaded Successfully!” page.

While the examples provided focus on using FIF at the end of an attack, FIF can be leveraged at any stage to reinforce the attacker’s narrative. For instance, a malicious site could use an iFrame+FIF to display a legitimate-looking notice, possibly linked to a logged-in session, midway through the attack, further deceiving the end-user.

FIF is not limited to websites, as many programs and mobile applications utilize custom URL Protocols or deeplinking.

Mitigations

To prevent FIF vulnerabilities, ensure that feedback or confirmation pages are only accessible through the intended sequence of actions. This will vary depending on the platform at hand, and can be achieved through different means such as conditional rendering, anti-CSRF tokens, referrer checks, server-side validation, etc.

Ultimately, the best way to prevent FIF vulnerabilities is to address them during the design phase, ensuring that feedback or confirmation pages are securely integrated into the application’s flow.

Finding FIFs

While I prefer not to disclose the most effective methods I’ve discovered for identifying FIF vulnerabilities, the internet is certainly not lacking in them. Simple Google searches with terms like “Thank you for your purchase!” often reveal exposed feedback pages that can be exploited. However, it’s crucial to approach this with responsibility and ethical intent, ensuring that any findings are only used to enhance security.

Additional Considerations: Chaining FIF with Other Vulnerabilities

This vulnerability can be dangerously chained with other vulnerabilites to expand its impact. As an example, if good.com has an open-redirect vulnerability as well as a FIF vulnerability, it’s possible for an attacker to craft a link such that:

1. User visits good.com/some-page?nxtZXZpbC5jb20vZXZpbC1kb3dubG9hZA==
2. The open redirect vulnerability causes the user to be redirected to the Base64 decoded nxt param, evil.com/evil-download
3. evil.com/evil-download prompts the malware download, then redirects the user to good.com/thank-you-for-downloading
4. User sees the thank you page from the legitimate website

To the eyes of the end-user, they clicked good.com which they believe to be safe, witnessed the software download to their computer, then saw the legitimate good.com page thanking them for their download despite actually downloading evil.com’s malware.