Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Faking Twitter unfurling to phish you

harrydenley.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Faking Twitter unfurling to phish you

#51

Post by dannyw »

zinekeller wrote: post #21

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 sit…

Security > marketers.

Whoever made this decision at Twitter should have a think about themselves.

Re: Faking Twitter unfurling to phish you

#53

Post by pornel »

habosa wrote: post #47
zinekeller wrote: post #21

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 sit…

So could Twitter make two requests, one as TwitterBot and one anonymously, and then add a warning if they don't go to the same place?

The attacker doesn't need to detect whether the TwitterBot is making a request. They can redirect every request to the spoofed site after posting the link, until the preview is generated.

Re: Faking Twitter unfurling to phish you

#54

Post by ec109685 »

Thorrez wrote: post #15
recursive wrote: post #12

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?

> Ok, but what's unfurling? I've never heard the term before now, but I interpreted it to mean following redirects to get the end page. > But if you clicked the link, you could just see the link though right. How is this fooling anyone? It fools you before you click the link. After you do, you're no longer fooled, as long as you pay attention to the URL bar. The obvious problem is people who don't pay attention the t…

Unfurling is showing the preview of the link within the tweet.

Re: Faking Twitter unfurling to phish you

#56

Post by [deleted] »

habosa wrote: post #47
zinekeller wrote: post #21

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 sit…

So could Twitter make two requests, one as TwitterBot and one anonymously, and then add a warning if they don't go to the same place?

[deleted]

Re: Faking Twitter unfurling to phish you

#57

Post by eyelidlessness »

dpwm wrote: post #34
eyelidlessness wrote: post #26

Earlier quoted context omitted.

Also this is much less sophisticated than fooling curl | sh, but people continue to insist that’s perfectly fine.

I don’t think I’ve seen anybody insist curl | sh is fine from untrusted sources. In many contexts, curl | sh is an alternative to adding some kind of additional repository to install a third party package — and in most package managers this is done as root anyway, with arbitrary pre-install and post-install scripts. I’m not really sold on how curl | sh (with https) is any less secure than blindly following steps to a…

You can detect curl | sh server-side and respond with different content than the inspectable source. The link I typically cite isn’t loading for me but you should be able to find more info if you’re curious.

Re: Faking Twitter unfurling to phish you

#59

Post by gitgud »

voussoir wrote: post #20
gitgud wrote: post #18

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"

I don't agree with your analysis. There are three domains at play: twitter-unfurl-faker.herokuapp.com, uniswap.org, and harrydenly.com. The first is the real link, the second is what Twitter's link previewer gets redirected to, and the third is where the user gets redirected to. It seems to me that the author does not need control over the second domain, just the first and third. But the user will never see the first…

As I understand it, the webserver at twitter-unfurl-faker.herokuapp.com just dynamically redirects based on the user-agent.

The attacker doesn't need control over uniswap.org or harrydenly.com to make this work.

They only need control of harrydenly if they want to serve a phishing page. But as I said above this is redundant and they could just use this domain to also serve the redirection. Example below:

* (Twitter bot) phishing.com -> redirects -> fishtanks.com

Twitter bot makes shortened link t.co/aaa (but the preview shows fishtanks.com)

* (User) t.co/aaa -> phishing.com

Re: Faking Twitter unfurling to phish you

#60

Post by reginold »

lmm wrote: post #38
reginold wrote: post #30

Earlier quoted context omitted.

> (For example, if you had some sort of "signed iframe", the page would probably find a way to show the part from twitter that says "verified" but cover up the part that it's supposed to be actually verifying with something else). This is the part where I imagined having a custom client side image. That way the server doesn't know what the "verified" image actually looks like. Could be a picture of my face, for examp…

> That way the server doesn't know what the "verified" image actually looks like. Right, but it doesn't need to - it just has to construct a page that has the "verified" image on the left and the malicious URL on the right. Which is very difficult to rule out.

How would it construct a page that has the verified image if it doesn't know what the image looks like?
Post reply on HN