Faking Twitter unfurling to phish you

  • Judging from the comments, some are really confused on what's happening here.

    The real trick is that TwitterBot and you see different pages. For TwitterBot, which always clearly identifies itself (and some other signs like whether it is from Twitter's network infrastructure), the flow is t.co -> attacker.site -> legitimate.site, and so shows in the card (technically called unfurling) the details of the legitimate site, including the coveted legitimate domain name. For you, the attacker.site detects that you're not TwitterBot and do whatever phishing attempt they need to do. Of course, if you do check the domain name on your browser, it won't work... but let's be honest, that's just a fraction of people here, not even including the general public.

    Others ask why TwitterBot does redirections, and it seems that everyone here forgot that marketers love their Bit.ly and Sprinklr links so much that Twitter needs to have a concession here (and no, you can't just whitelist them because some companies uses their own different shortlinks like t.co, fb.me, g.co, msft.it, redd.it, and youtu.be).

    Why not just directly serve the redirection as seen by TwitterBot? Because a) marketers and analytics and b) because services like Branch (app.link) and Adjust does redirect users differently depending on their specific device (like Windows vs macOS vs Linux (or even a specific distro!) vs iOS vs Android).

  • This reminds me of a little joke link shortener I built[0] that allows you to set the various opengraph tags to the shortened url. This lets you completely fake the link preview generated by most platforms that show you one. Even though I originally built it as a joke, I find myself using it pretty often to make links 'self-explanatory'.

    [0] https://github.com/radiantly/the-redirector

  • Why does this require the extra step of using a burner account? Why not tweet https://twitter-unfurl-faker.herokuapp.com/ from your main account and that's it?

    Does Twitter only unfurl t.co URLs? If so, why would they write separate code for unfurling t.co with ?amp=1 vs without ?amp=1 ? And why would Twitter unfurl a t.co link past the first non-t.co URL? I guess that's the vuln, right, that they don't stop after the first non-t.co URL?

  • Is there any sort of within-a-page HTTPS "secured" function?

    Like how banks have that "only type your password if we show your correct profile picture". Almost like if embedded tweets could be "signed" by twitter in a way that would register in my browser in a graphical way that would not be known to the server itself (ie putting the twitter logo next to a tweet is easily faked). But if content appearing to be from twitter was verified instead, and had my custom chosen avatar next to each showing both my key and twitter's key had signed the text.

    Maybe not making sense, if anyone wants to play this back clearer go for it :)

  • They can add "redirected from xyz" to the card perhaps.

  • And also don't trust this link: https://t.co/MPesRJdK5y

  • Ok, but what's unfurling? As far as I can tell, this is just tricking the thing that tells you the target domain of a shortened link? But if you clicked the link, you could just see the link though right. How is this fooling anyone?

  • Why would twitter trust the Location header and not just parse the URL given to them? This seems like a strange choice to rely on their backend lookup just to display the URL...

  • Trick’s on me, someone finally got me to look up what the heck some cryptocurrency thing is because this article made no sense otherwise.

  • You can do the same with VirusTotal. Check the UA, if it's Virus Total, serve a legit page, if it's non VT, serve the malicious one. Simple 301 redirects will be detected and presented to the analyst, URL rewrites wont.

  • This doesn’t make sense. Why doesn’t the Twitter bot serve the final site location after following all the redirects.

    Then since the bot sees the correct site it redirects to the correct site

  • Why not do it the other way around? Serve a page without a redirect to the twitter-bot and detect if the header does NOT contain twitter to serve a redirect?

  • Firefox is doing a horrendous job of rendering the text on this site for me, on Arch Linux. Is it just me?

    https://i.imgur.com/ZP9wC85.png

  • This is pretty dumb.

    It's like writing `[google.com](notgoogle.com)` and making out like its a significant security flaw or new idea.

  • Not really a logical phishing strategy, if the first domain looks safe and the attacker controls it, why wouldn't they just use that to serve a phishing page? Instead of needlessly redirecting...

    A better example would be to show "google.com" and somehow redirect to "phishing.com"... but that's not really possible without control of "google.com"