Twitter / X is vulnerable to a straightforward, yet effective attack that abuses the "Cards" feature, a rich preview for links.

Abusing this security flaw enables the display of a hyperlink (in the form of a Twitter Card) as if it originates from any website, misleading users into thinking they are accessing a legitimate link. In reality, they could be directed to a harmful website. This issue arises from manipulating URL previews in tweets, where the link's actual destination differs from what is shown to the user.

The attack works as follows:

When inserting a link into a tweet, Twitter’s backend servers will make an HTTP request to that link to generate a rich preview of the website being referenced. This preview includes a short description of the website and a preview image. This is meant to create a better user experience and make links appear more appealing and engaging. 

Currently, Twitter’s implementation follows redirects made by any links and generates a preview of the final website their crawler lands in, also referencing the final domain in the preview card, instead of the actual posted domain. It fetches this information using an automated process, and as it is not feasible for the Twitter bot to determine the nature of the redirect when scraping the URL content, it becomes possible to exploit this behavior to create deceptive previews. For example, depending on where the Twitterbot is redirected, legitimate users could be tricked into clicking on links not associated with the generated card.

When generating the preview for the link, Twitter's backend will make an HTTP request using its own, unique "user agent", which is an identifier of the requesting browser. This is shown in the following screenshot:

(This, of course, isn’t related to the flaw itself, but only enables an easy method to identify when Twitter requests a given page)

To abuse this implementation for malicious purposes, an attacker posts a link to a web server but with a twist:

The webserver handling the requests for the "malicious" link must be set up by the attacker to direct traffic based on the provided user agent within the HTTP request. For example, creating a preview for the URL http://[REDACTED].xyz/helloworld and ensuring that the web server redirects requests based on the client's user-agent, results in the following drafted tweet:

This is what happens behind the scenes:

This is how the tweet looks when viewed by other users, despite the URL itself that was posted not being “phishfort.com”:

Now, if a Twitter user were to open this link, their user agent would be that of a normal browser, for example, Chrome. The web server will redirect the request to the malicious site (or just display the phishing content instead of performing a redirect). 

Here’s an overview of the full process:

This method unfortunately works not only in tweets but also in direct messages:

Sending side:

The receiving side, shown from the perspective of the mobile app:

This URL handling behavior is a fundamental (and quite old) flaw in how links are processed in X, and one that opened up the gates for exploitation of its large user base.

This behavior likely exists in the first place to facilitate a better user experience when the link posted is from URL shorteners such as Bit.ly or similar services, which are commonly used by companies tracking clicks and origins. This would show the users the final destination the link would send them to, instead of appearing at the link shortener itself. 

An immediate remediation that could likely prevent a large amount of the abuse would be to whitelist the domains that Twitter will follow redirects from while working on another, more comprehensive solution.

‍

With Twitter's extensive user base and reputation as a legitimate platform, most users trust the previews without realizing the difficulty in validating the associated links, especially within the mobile app. This vulnerability, which would be deemed severe on other platforms, is alarmingly accessible to scammers, leaving users exposed to sophisticated forms of abuse for extended periods.

‍

In uncovering the potential for abuse within Twitter's "Cards" feature, we've highlighted a critical flaw in the implementation that misleads users with deceptive link previews, disguising malicious websites as legitimate ones. This flaw not only compromises the integrity of shared information but also exposes users to potential harm and phishing attacks, which have been observed to be continuing at the time of publishing as well, with the most prominent one being an “ETH gas fee refund” scam that keeps rotating infrastructure and has a vast network of verified Twitter accounts These malicious accounts typically use promoted tweets containing links abusing this flaw leading to a drainer website.

An example of a tweet from this ongoing campaign is included at the end of this article.

To help users mitigate this risk, we’ve added a new feature to our open-sourced browser extension, NightHawk.

It addresses this very loophole, providing an added layer of protection by scrutinizing and validating the authenticity of links while browsing the platform, ensuring that users can navigate Twitter with more confidence and security.

This is how it looks in practice when a user views a card with a deceptive link:

Bonus:

As previously noted, this flaw is not new or unknown and has been around for a while, at least since February of last year. During our research, we’ve scanned links and also discovered that at this point this trick is not only used by malicious threat actors but also by advertising platforms who abuse this vulnerability to appear to be representing another brand or entity:

In this example, Sovrn.com redirects the Twitterbot to Nike.com. However, when the request is made from an end user as below, it redirects to webgains.com. 

‍