Live data from Hacker News

Faking Twitter unfurling to phish you

harrydenley.com

31–40 of 70 posts

Re: Faking Twitter unfurling to phish you

#31
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"

Recent memory tells me Google has an issue and had another issue. You can have a Google.com page like google.com/awesomesite/

And earlier there was a Google redirector that was forgotten about and was being used to redirect to phishing sites.

Re: Faking Twitter unfurling to phish you

#32

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…

> 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

It won't be terribly hard to build a top 50 list of url shorteners etc that cover the vast majority of the traffic.

Re: Faking Twitter unfurling to phish you

#33
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.

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.

Re: Faking Twitter unfurling to phish you

#34

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.

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 add a repo.

I used to strongly dislike curl | sh, and if there’s some looming security risk beyond accidentally trusting bad actors who couldn’t be bothered to go to all the effort of setting up a repo then I’d genuinely like to know.

Re: Faking Twitter unfurling to phish you

#35

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…

All true but the really bogus part IMO is that by default it would unfurl to the actual, bad URL but if you remove the &amp=1 param it unfurls to the good domain. Why is that?

Re: Faking Twitter unfurling to phish you

#36

Earlier quoted context omitted.

> 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.

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.

Re: Faking Twitter unfurling to phish you

#37

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…

All true but the really bogus part IMO is that by default it would unfurl to the actual, bad URL but if you remove the &amp=1 param it unfurls to the good domain. Why is that?

I'm not really sure, ask Twitter since the amp=1 thing is just generated in their mobile website and application. This is definitely a guess, but maybe some websites implement AMP by checking the referrer and redirecting to it, and Twitter interprets that as "let's backtrack to the last page, that's the canonical version" and uses that?

Re: Faking Twitter unfurling to phish you

#38
post #19

Earlier quoted context omitted.

I think it's difficult-to-impossible to do anything secure within a page, because a malicious page can emulate virtually any kind of behaviour within the page. https://textslashplain.com/2017/01/14/the-line-of-death/ (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 verify…

> (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.

Re: Faking Twitter unfurling to phish you

#39

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…

> 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 It won't be terribly hard to build a top 50 list of url shorteners etc that cover the vast majority of the traffic.

I think some URL shorteners allow editing the URL after creating a short link. So you are back to square one

Re: Faking Twitter unfurling to phish you

#40
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.

Most people would not question having to type in their username for a fresh login - Banks sign you out so quickly and their "remember me" is often intentionally gimped. So users are trained to type their username into the field, and the bad site can proxy that to the bank and send back the image just fine.

Okta still includes this "feature" by default, and is among the reasons I will never trust Okta or any client of theirs.

Post reply on HN