How to Protect yourself from Advanced Phishing Scams (HTML injection)

This is a guest post by Ben Chinoy, a talented security engineer. He reached out to us about the security issue outlined below and courteously offered to write up this blog post about it. Enjoy!

The Threat from Scammers:

Scammers are constantly looking for new ways to steal personal, financial, or company data. Since the start of the Ukraine-Russia conflict, scammers have started to send out emails pretending to be humanitarian aid workers or asking for fake help via Cryptocurrency payments. This strategy — where scammers provide links, messages, or emails that are designed to trick unsuspecting users into giving away their information — is called “phishing.”

As internet users become smarter and more adept at identifying scams, these scammers are adapting by creating more and more realistic links to trick users into giving away their information. This is often done by exploiting a vulnerability called HTML injection, in which a malicious user can directly inject HTML code they own into a web page. In this article we will go through a real-world example of HTML injection with ntropy.com and identify what we can do to protect ourselves.

HTML Injection with Parameters

Scammers typically send phishing emails or texts that contain malicious links for users to click on. Realistic links are often created by injecting HTML directly into a web page as a parameter in a URL path. For example: www.ntropy.com/?parameter=<malicious code>or<malicious site>

Websites generally have protection mechanisms that prevent malicious content from being embedded in the site. Parameters passed in the URL or the body of a HTTP request, are often handled and sanitized properly by a server — ensuring any code presented to an unsuspecting user is not malicious. However, some web pages hosting API specifications can be vulnerable to HTML injection if they aren’t configured securely. And attackers will use this vulnerability to “phish” as many people as they can.

SwaggerUI

Ntropy uses SwaggerUI to present a clean, familiar user interface that allows folks to interact directly with the Ntropy API in an easy way. The ntropy.com SwaggerUI API specification (api.ntropy.com/ui) did have an HTML injection vulnerability that has been fixed. Below we will explain both how and why this happened, along with how other companies and individuals can protect their own SwaggerUI instances.

Technical Exploit Details

Out of the box, when SwaggerUI is deployed, the traditional deployment has developers point to an API specification file in the root directory that the SwaggerUI code is running in.

However, SwaggerUI has a lesser known feature that allows for the API specification to actually get passed into the URL path as a parameter. At the Swagger Git repository, the URL parameter is defined as “The URL pointing to API definition (normally swagger.json or swagger.yaml).” What this looks like in practice follows below:

https://api.ntropy.com/ui/?url=api_spec.json

In many cases a URL path may not be defined when the site is published because the specification is in the root directory, as mentioned above. But, the default SwaggerUI code does actually support passing a URL parameter into the page. This is very normal behavior, but it can leave the instance vulnerable to HTML injection.

The reason HTML injection works is because Swagger will override whatever specification is defined in the root directory with what is passed as a parameter to the page.

So, if an API specification is defined with malicious links, the specification will render in the browser as long as the HTML is valid (i.e. has proper tags). The browser doesn’t know whether or not links are malicious. For example, below there is a valid API specification that is being passed in, but the links in the specification are malicious:

https://api.ntropy.com/ui/?url=INSERT_MALICIOUS_HTML_FILE.html

Here is a screenshot of what this looks like.

The risk here is when users visit the malicious URL, the base portion of the URL will show a trusted URL (api.ntropy.com), but the content served on the page is running on an attacker-controlled web page. In this case, it is running at https://evilstrikesagain.github.io/dontclickthis/index.html

So, the question then becomes how can we fix this and protect ourselves.

For Developers: How to Fix Vulnerable SwaggerUI Sites:

SwaggerUI does provide a lot of configuration flexibility for developers deploying a local SwaggerUI instance. The following steps will help prevent HTML injection attacks:

• Ensure the CORS (Cross-Origin Resource Sharing) policy on the site SwaggerUI runs is set to either none or sites that are trusted. Keep in mind anyone can deploy to both github.io and gitlab.com
• Either strip or remove the following URL parameters: url, urls, and spec

For users: How to protect yourself:

When browsing APIs and technical documentation, looking at just the base URL path may not be enough to ensure the content is legitimate. The following steps will help ensure a safe browsing experience

• Click into the address bar in the browser to see if any other untrusted domains or files appear in the URL path. For example, HTML may be embedded in a site via a web page ending in .html instead of .com. For example, the following URL shows an untrusted domain and the content on the page should not be trusted. https://api.ntropy.com/ui/?url=www.evil.html
• Hover over any links to see where they point to before clicking on them on the page

For additional questions, feel free to reach out to security@ntropy.com.

Ben Chinoy

Security Consultant