Live data from Hacker News

Faking Twitter unfurling to phish you

harrydenley.com

41–50 of 70 posts

Re: Faking Twitter unfurling to phish you

#41
post #36

Earlier quoted context omitted.

Some still do. I don't see the point though - a determined attacker could just make http requests to your bank and substitute the parts they want to. Would be on the attack domain still so still technically phishing... But if the image is an anti phish measure it's not a great one. I suppose it could raise the bar to a successful attack a bit but certainly doesn't make it impossible.

Isnt't that what CORS/same-origin policies prevent? The attacker domain can be prevented from loading the bank resources within the same context by the browser. If the request is made by the attacker domain instead and proxied to you, then it doesn't have your cookies to display the private identification. In either case, the "correct profile picture" would not load.

You can keep iterating on this if you like, and some banks did, but ultimately the bad guy has the exact same information you've presented to the bank to get this "correct profile picture". Cookies. CORS headers. None of that matters. If you get the "correct profile picture" so does the bad guy and then they just forward it to you.

We already know how to actually solve this problem. WebAuthn.

Re: Faking Twitter unfurling to phish you

#43
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

Re: Faking Twitter unfurling to phish you

#45

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?

Because my domain evil.com cannot serve a page from uniswap.org (because it's a different domain).

Re: Faking Twitter unfurling to phish you

#46
post #36

Earlier quoted context omitted.

Some still do. I don't see the point though - a determined attacker could just make http requests to your bank and substitute the parts they want to. Would be on the attack domain still so still technically phishing... But if the image is an anti phish measure it's not a great one. I suppose it could raise the bar to a successful attack a bit but certainly doesn't make it impossible.

Isnt't that what CORS/same-origin policies prevent? The attacker domain can be prevented from loading the bank resources within the same context by the browser. If the request is made by the attacker domain instead and proxied to you, then it doesn't have your cookies to display the private identification. In either case, the "correct profile picture" would not load.

> If the request is made by the attacker domain instead and proxied to you, then it doesn't have your cookies to display the private identification.

Why is that a concern? You try to log in on a phishing site. The phishing site tries to log in as you at your bank's actual website. Your bank sends the phishing site your picture. The phishing site displays your picture to you.

Re: Faking Twitter unfurling to phish you

#47

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?

Re: Faking Twitter unfurling to phish you

#48
post #47

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?

That's what Google does sometimes - but it's sometimes considered rude. Plus, anti-bot software may accidentally thwart Twitter's checking bot.

Re: Faking Twitter unfurling to phish you

#49

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

Not the blog author, but practically speaking, faking OpenGraph tags would result in same phishing capability (considering that most people don't check the cards carefully), but it'll still show that the link was not from that site. But again, most people would still click paypal-not-really.com or coinbase-is-not-controlling-this-site.com

Re: Faking Twitter unfurling to phish you

#50
post #3

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

> Like how banks have that "only type your password if we show your correct profile picture". Do they? My banks did that years ago, and they also stopped doing it years ago.

They are ineffective.

>Of the 63 participants whose responses to prior tasks had been verified, we were able to corroborate 60 participants’ responses to the removal of their site-authentication images. 58 of the 60 participants (97%) entered their passwords, de-spite the removal of the site-authentication image

See https://security.stackexchange.com/a/19801 which summarises https://sites.google.com/site/ianfischercv/emperor.pdf

Post reply on HN