Hacker News Reader

> I suppose the real lesson to be learned is to

...never, ever buy or even take anything from anyone who approaches you without you being the original initiator of the communication. Simple rule that applies to both online and real world and makes your life simpler and safer.

Also works nicely against advertising too, a good principle ;)

Really nice guideline for work. Should spread it around.

This is my strategy as well. If I want something I initiate a search. Incoming sales attempts do not exist in my universe.

Be careful which search result you click:

https://wp.josh.com/2019/05/06/breaking-news-google-adwords-...

If you want to see where Google search results really point to, you can right click it and then hover over it to get the real destination... it's been like this for 15+ years (google changes the destination on-click).

Thanks, I'll be sure to explain this to all my friends and family, right after I teach them what onclick, "real destination", "hover", etc. mean.

I think that it is pretty screwed up that browsers allow this "feature"...

Just checked; and while they did indeed use to change the URL (on mousedown (!) - which was infuriating, because right-clicking to copy URLs produced a mess I'd then have to pass to data:text/plain,... in a new tab to extract the URL-encoded... agh), they currently really do just leave the link alone now.

They just fire off a request to google.com/url?... to track the click before letting you on your merry way.

Sigh

Same with phone calls or mail. Look them up on the web and go through their web site for numbers/email addresses

Great point. When the IRS phone call scam first came around it scared the crap out of me for a second but a quick search revealed the truth.

That used to be my strategy until a salesman knocked on my door offering heavily discounted ceiling insulation, which is something I had half-heartedly always wanted but never got round to buying. He said my address was one chosen by the government to give a subsidy to but funds were limited so it was first come first served or risk missing out. Sounded suspicious so I checked with the government who confirmed everything the salesman said was true. I got a 2nd quote from another installer but the door-knocker was cheaper so I bought his. I wouldn't have known the subsidy was available without him and would have missed out on a genuine rare high-value giveaway.

This is an old tip my father gave me 40+ years ago that applies to banking, mortgages, insurance, investing, credit cards, and all personal finance.

Also a very good rule of thumb for recreational drugs and other illicit activities.

meh, he calls out the exact mistake he made. If I see an ad and like the product, I go to the domain. If the domain is legit (e.g. not developgameonline@gmail.com), you can start to feel pretty good about it. We run ads. If you google my companies name ("seekwell"), the entire first page is properties that we've owned for years. This includes podcasts and youtube videos.

It's ok for the initial pull to be an ad, but only buy from the source.

Not at all fool-proof.

What if they can register a very similar / regional domain that you didn’t set up already?

Normal rules don’t apply when you’re a criminal so spoofing SSL cert names is something you might as well do too. It’s just not practical to examine and confirm the cert manually of every company you interact with online.

These internets are dangerous, even if you know what you’re doing.

> Normal rules don’t apply when you’re a criminal so spoofing SSL cert names is something you might as well do too

SAN dnsNames in certificates in the Web PKI are verified by the issuer - these days using one of the Ten Blessed Methods. It would certainly be possible to obtain certificates for a name you don't actually own, but it's a bit beyond the usual casual crooks that run scams like this. We see what appear to be nation state adversaries doing it, as part of wider targetted hijack schemes (e.g. to intercept IMAP credentials for a foreign government agency) but it's definitely not something you see an ad scammer doing.

Any vaguely competent modern browser checks the certificate is trusted in the Web PKI and that it matches the SAN dnsNames to the FQDN in the URL exactly so there's no room for any funny business there.

And human readable names in end entity certificates are largely irrelevant. Nobody looks at them, who cares?

You are replying to a point that the GP didn't make. This was the precursor for the might-as-well-go-for-letsencrypt statement:

"What if they can register a very similar / regional domain that you didn’t set up already?"

In other words, they register fakebook.com and then just go get a TLS cert for it. If you're not looking carefully, you might not notice the difference.

Whether the CA system, with fungible, interchangeable certificates that can be issued by dozens of CA's (pinning excepted), is worth sinking lots of trust into is an entirely different matter ;)

The Web PKI does a pretty good job of making the web browser do what lay people assume it did anyway. Surely this is news.ycombinator.com or else why does it says so in the URL bar? Without the Web PKI there was no assurance of that whatsoever, which is not intuitively obvious.

But a very similar domain is the wrong domain. This is not a great novelty, people are aware that a ROJEX watch isn't the real deal, no surprise Fakebook isn't the social media site you actually wanted either.

In terms of authentication, this is where WebAuthn shines because it's tied to that actual domain name. Even if you're 100% dead certain this is really Facebook, your WebAuthn authenticator can't help you. There is no "Look, I know the URL says Fakebook, but ignore that, I am 100% sure this is really Facebook, just shut up and take my money" button.

So my point was that having news.ycombimator.com in the title and address bar is not going to flag anything if they both match and have a SSL cert that's been signed by an authority.

Probably more relevant is that if I have registered luxowatch.com to sell my lovely watches, but am a small store, I certainly won't have registered (as yet) a bunch of global domains. There's nothing stopping you registering luxowatch.co.uk or luxowatch.net with a valid SSL cert to scam my potential customers. Cloning my site to one of those domains (with cert) can be done almost instantly for close to zero cost.

The people here posting about how clever/careful they are, which is why they haven't been scammed, are the ones I see as most likely to get scammed (if they haven't been already without realizing). You're best protection against being tricked is realizing that you can be tricked.

*your. This was the last straw. I've finally had enough of my OnePlus autoincorrecting me all the time.

You're proving my point, Google the companies name. I'd like to see an example of a fake company you can Google and get good results on.

There's a current scam going on right now where people are getting calls to get in on the ground floor of the "Stripe IPO"...

The sad thing is, this is simultaneously the only way to stay safe AND also the underpinning of almost the entire ad industry - and in turn about half of the money that funds what we think of as "the internet" today.

It really sucks that it seems like we've built the most important infrastructure of our generation effectively on quicksand.

> OP didn't screenshot the login screen in app, so I can only assume it was a real Facebook oauth flow

My guess would be that it was an in-app phishing page. Many legitimate login flows result in the official login page opening in a web view and asking for a password, which is indistinguishable from a phishing page.

> but honestly at that point it's already too late. If anything OP should be grateful that the native app running on what was presumably his personal device didn't do anything worse.

On phones, sandboxing significantly reduces the risk. Yes, it is possible to break out of the sandboxes if you have an exploit for that device, but it's a lot harder than on desktop where by default anything you install has full control over everything and could just steal all the users' passwords.

> Many legitimate login flows result in the official login page opening in a web view and asking for a password, which is indistinguishable from a phishing page.

I don't understand how Google/Facebook/etc can allow this to happen, let alone encourage it. I'm just baffled.

How could they prevent it?

Ban apps that do that.

And how are they supposed to do that? If it's a fake login (aka phishing) page facebook wouldn't even know about it. The only effective way is dissuade consumers from entering their login credentials in-app, but even that's tricky because if it's a malicious app they could "fake" a web browser complete with a fake "address bar".

This is why "with a password manager" is a crucial part of the puzzle.

You have to fail at several steps if you're entering your credentials in this scenario.

They're supposed to ban the legitimate apps, so as to not normalize the interface that leads to phishing attempts. Right now, it's totally encouraged by google to enter your login credentials by clicking "log in with google" at a random site and just typing into the fields presented to you.

AFAIK Google doesn't encourage it and made some efforts to block it: https://auth0.com/blog/google-blocks-oauth-requests-from-emb...

Hasn't been 100% effective unfortunately, and even if it was, it's really hard to make users understand that this flow is incredibly dangerous.

And while Google on Android can simply go through system libraries, Facebook doesn't have the option if the app is not installed. They have to open something that will allow the user to log in (usually a browser), which is something the app can fake (in the case of the browser, just fake the whole browser UI, fake address bar included).

I misunerstood the part I quoted, I thought it was about web pages asking you to log in via Google/Facebook. So the problem I was thinking of is more generally entering Google credentials into logins provided to us by a third party. The "don't use the link in your email to log into google, go to gmail.com instead" advice has been seriously degraded by this. It should always be that if you aren't already logged in, you have to go yourself to gmail/facebook/etc and log in there.

It wasn't oauth, it was a normal facebook login. The application didn't fake anything, but simply extracted the session cookie after login.

I'm curious if the oAuth flow requested a specific scope to have permission to remove the user from their Ads account. If so, did Facebook make it clear that the permission was be requested.

I must say that it was a pretty clever scheme.

Permissions scoping is a really under-utilized tool.

I see this most often with extensions, which usually want to act on all domains when they should really need an allow list of just 1-2 domains. There are also many app integrations that use an API token that just straight bypasses login with NO security restrictions.

I would use a lot more app integrations if I knew I could trust the host platform to keep the apps honest.

I think we're missing a lot of innovation because we lack secure and reliable integration points between commodity services. Banking and Health are the most obvious issues. It should be trivial for me to authorize a third-party app to download transaction history from any bank without giving it the ability to change anything. I should be able to assemble my entire medical history by pulling from any medical office I interact with, and push that to any provider I choose to use.

There are lots of industry incentives to prevent this though. It's just like the Cable Card saga. You need strong, un-captured, technically-literate regulators to fix this stuff and unleash broader innovation.

It's possible that the attack didn't happen through the regular oauth credential request flow — if the OP logged in to Facebook inside of an app-controlled webview, the app could have just exfiltrated the user's login cookie and performed the change using "first-party" Facebook APIs.

This is what I think too. WebView doesn't show the domain of the page, and it is not possible to see if you are really in Facebook login page, or somewhere the attacker controls. Unless the attacker was using Yubikey or some sort of hardware token, the victim would have entered the TOTP code too, which the attacker can ask and pass to authenticate successfully.

How does a YubiKey prevent that kind of relay attack? If those keys blindly sign whatever's given to them, there's got to be a way to trick a user into signing something malicious.

This [1] says that U2F avoids phishing by having the browser tell the 2FA device the domain, but that seems a bit weak to me. The same site even has an app where the info is relayed via a browser plugin, so literally relaying the data that's supposed to be trusted. The only way I can see that actually working is if the security key knew to only sign challenges for a specific domain.

1. https://krypt.co/blog/posts/prevent-phishing-on-the-web-with...

The security of the browser implementation is important. It provides the origin for the security hardware to sign, and the authenticating server ("relying party") verifies it. If your browser tells the key it's google.com when it's really evil.com, then sure, you can log into google.com if the user signs the request.

The WebAuthn spec says: "Direct communication between client and authenticator means the client can enforce the scope restrictions for credentials. By contrast, if the communication between client and authenticator is mediated by some third party, then the client has to trust the third party to enforce the scope restrictions and control access to the authenticator. Failure to do either could result in a malicious Relying Party receiving authentication assertions valid for other Relying Parties, or in a malicious user gaining access to authentication assertions for other users."

(https://w3c.github.io/webauthn/#sctn-client-authenticator-pr...)

If you click further into the older FIDO spec, they cover this more explicitly: "Malicious software on the FIDO user device is able to read, tamper with, or spoof the endpoint of inter-process communication channels between the FIDO Client and browser or Relying Party application. Consequences: Adversary is able to subvert [SA-2].

Mitigations: On platforms where [SA-2] is not strong the security of the system may depend on preventing malicious applications from being loaded onto the FIDO user device. Such protections, e.g. app store policing, are outside the scope of FIDO."

(https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-se...)

I learned a lot from that. Thanks!

The problem with many attacks is we've now been trained to do dumb things - like putting our password into webviews inside 3rd party apps - by reputable companies. So it doesn't feel as insane as it should do.

Yes. A thousand times yes.

oAuth outside a browser is just training people to be phished.

It's not just limited to webview's and tech companies.

When my bank calls me up about an issue with my account, they won't talk to me unless I give them my date of birth and email address for 'data protection' purposes.

They're always really confused when I say I will have to call them back.

When you do a login with Facebook, does the popup show you what permissions are being requested? I know I've seen that before.

I fell to a (now) very obvious scam on Instagram. It seems to me that it's really easy to bypass their checks. It was a fake ad for a real product. They accepted PayPal and it took forever to get PayPal to refund me. Worst yet, even after multiple escalations PayPal continued to be on the website. Instagram continued to show me ads for the exact same product from different domains. I realized that PayPal is next to useless if you're a victim of fraud. It's much better to use a credit card directly (esp Amex or Discover) and challenge fraud than PayPal.

I recently made a purchase that turned out to be fraudulent on paypal, and somehow had no trouble getting my money back relatively promptly. Maybe have taken about a week from when I filed "I never got the product, I think the whole website was fraud".

Be careful, you can still get scammed here. I got hit for a $75 scam product that I bought with my CC, mistakenly thinking I would be protected. The scammers knew what they were doing though. They ship you a super super super cheap version of the product from china, taking advantage of those low low China -> US shipping rates, so that they have certificate of delivery. So you can't say you never got the product. And in that case, both paypal and the CC company require that you send the item back. Shipping the item back to china costs more than the item itself. So there's no point. Scammers won.

I use PayPal as a front to my bank account via SEPA Direct Debit, which has an 8-week no questions asked refund policy. If PayPal doesn’t cooperate when I raise the issue I can easily get my money back through my bank. But I still like to dispute just so the business goes on record for fraudulent transaction.

In the US, debit cards do not have the same consumer protections that credit cards do. If you’ve gotten refunds from your bank for debit card fraud, you are lucky.

https://www.investopedia.com/articles/personal-finance/05021...

“ But if the item was bought with a debit card, it cannot be reversed unless the merchant is willing to do so. What is more, debit card theft victims do not get their refund until an investigation has been completed. Credit card holders, on the other hand, are not assessed the disputed charges; the amount is usually deducted immediately and restored only if the dispute is withdrawn or settled in the merchant's favor. While some credit and debit card providers offer zero-liability protection to their customers, the law is much more forgiving for credit card holders.”

Direct debit is not a debit card. It's an authorisation to pull funds from your debit account as needed.

If that’s what he’s doing, that’s even worse than a debit card in terms of risk and lack of protection.

It might help to read a little about how SEPA Direct Debit works. To begin, it's a European scheme, not American. Not every merchant can sign up for SEPA Direct Debit. They need another bank to be their guarantor (called your SEPA Direct Debit Creditor). When I have issues with a transaction and order a refund within 8 weeks of the transaction, I get my money back, no questions asked. I've used this to recover money from all sorts of businesses and government agencies.

The business can only dispute if I requested for my money back _after_ the 8 weeks. That's when the evidence and back-and-forth with the business comes in.

You should be careful relying on that. While many Direct Debit systems have some sort of quick refund guarantee, they don't guarantee that you get to keep the money.

The normal flow will be your bank reimburses you from their own pocket. Then goes after the merchant to recover the funds, however if the merchant can present evidence that the charge is valid then the your bank will attempt to claw the money back from you.

Now the important question is here is what is a "valid" payment. Normally the direct debit scheme will outline that that is, and it probably some very simple like there's evidence that you requested the funds are removed from your account. With something like PayPal they can probably claim that the request was valid, at least the bit between PayPal and the bank was, and that the onwards movement of money is a separate issue that doesn't fall under the direct debit guarantee.

It's worth really digging through the small print on these things, they're frequently a lot less helpful than you think, and PayPal has managed to exploit these little holes to their benefit.

Personally I avoid using PayPal where possible and stick to debit/credit card where you have a very simple relationship between you, your bank and the merchant. Which makes disputes much easier, and places the law very much on your side. All this comes from experience dealing with disputes from the banks perspective, and trying to get the right result for the customer, while dealing with payment schemes, and regulatory obligations.

Good call. I was referring to SEPA Direct Debit. I should have been clearer. With SEPA Direct Debit, I get an 8-week no questions asked refund, regardless of the nature of the business. In fact, I've used it to recover money from government agencies and businesses that auto-renewed annual contracts without my consent.

Maybe it's because the banks are all pretty good and modern in Canada, but I honestly just don't get PayPal. My credit cards are all very easy to pay with, fraud detected quickly and easy to dispute, and many purchase types insured.

"If anything OP should be grateful that the native app running on what was presumably his personal device didn't do anything worse."

I don't understand why any of these actions would be taken with a mobile phone ...

What I mean is, managing advertising campaigns and budgets and managing assets and spend, etc., is kind of a complicated workflow ... further, it's a fairly critical business process involving a lot of money.

I can see ordering some workroom supplies or paying a hosting bill with my phone ... but creating and managing ad campaigns ? That seems very unwieldy and inefficient. Google adwords, through the web based interface, is very complex and there's a lot of functions there. I can't imagine trying to do this on a phone.

So what am I missing here ?

It's not that unreasonable. When I am on the road, it can be days between sitting at a desktop. If I can do something on my mobile, I'll do it, or try.

I don't get involved in ad buys.

Laptops exist as a very efficient middle way between a desktop and a mobile phone: all the desktop functionality and the benefit of mobility. This is not an add :p

Yeah, except I cannot always carry around my laptop, as my small mobile is already heavy enough.

I don't understand the need for snark here on your part, do you not think I have already considered it?

By "desktop" I meant "desktop environment".

> so I can only assume it was a real Facebook oauth flow,

another reason why we should be training users to only do oAuth in a browser with a password manager.

It's one last solid line of defence.

OAuth in a native app is a security risk.

That's not a silver bullet though. If the password manager does a poor job of domain matching, the user gets accustomed to having to manually search for logins once in a while.

Agreed. Not perfect but much better than nothing.

> The scammer silently removing OP as an admin from their own ad account, preventing them from noticing or stopping the fraudulent ad campaign is just icing.

This hints of not having 2 factor authentication anywhere in the chain?

Would definitely advise to setup 2 factor authentication on anything managing 5 figure sums.

I was surprised too since OP's writeup indicates that he has 2FA on everything. You would think that you'd at least get an email or push notification if you get removed from an ad account/notification settings get changed, so it seems like an oversight by FB.

Hardly anybody does the "when changing an email address on an account send an email to the old address to allow them to revert the change and temporarily lock the account". It seems like such an obvious thing to do.

Maybe the oauth scope requested edit access to the FB business manager? That way the scammer can remove OP from the business and add himself via the API

How would that help? They were removed via the API, no passwords were stolen.

2FA is how you protect your credentials from being stolen and used. This wasn't a case of credentials being stolen, this is a case of someone being tricked into authorizing a separate account to take action. They hacker didn't change his credentials to lock him out, it literally revoked access from him Facebook login to the ad account.

I'm using "login" and "account" specifically here to highlight the difference. On systems where there are likely to be multiple people that need access, there's a distinction between the "service account" and "logins or user accounts" that can control it. Generally, when the service account is created by a login, that login is added implicitly as a controlling user account with full privileges, and other user accounts (logins) can be added with varying levels of control. This situation appears to have been along the lines of the following:

1. User "real_user" create facebook ads account id 123456, and real_user is the admin of the ads account id 123456.

2. At some point real_user adds "scam_user" to the facebook ads account id 123456 with full admin permissions.

3. scam_user uses the full admin permissions it has for facebook ads account 123456 to remove access for real_user.

Note that is is a fully legitimate and common action to take in systems like this. If you are a business and pay someone to manage your facebook ads, they are likely the admin on the account (and you may be too), and if they leave and you hire a new person to manage it, you would want to revoke the old employee's account access and add access to the new employee's account.

This is how you handle it on Google Suite, Zoom's business accounts, Active Directory in Windows domains, etc. The real problem here is that the scammer got enough permissions to revoke the original user, and the original user did not get an email notification. I'm not sure if facebook ads allows adding accounts with limited permissions so only certain actions can be taken and part of the scam was making the permissions asked for non-obvious, or if that's a permissions distinction facebook ads doesn't support.

> I suppose the real lesson to be learned is to simply avoid installing native applications when you can help it.

I looked at the playstore page and it immediately raised many red flags. The app isn't by Tiktok or Bytedance.

It's like clicking on a similar looking domain link in your email.

> avoid installing native applications when you can help it

Why couldn't a web site have stolen his credentials in the same way?

I guess you’ll have a better chance to spot the URL is fake than in an app where you won’t see it

And notice that you're logged out which is unusual in many cases.

And a bunch of other potential signals that would be missing in a native app.

It's not foolproof but it's a step forward.

The real lesson is to install ublock origin and be done with deceptive advertising.

Last time I tried to find nvidia drivers for windows 1st result was an obvious scam/crapware. This is not acceptable that big tech companies are making money while not taking responsibility for advertisements.

Is this something that could have just as easily happened through Apple's app store? This sounds like exactly the type of thing that those 30% app store cuts should be going towards to prevent (regardless of the platform).

To me the lesson is the same old basic web security practice: don't click links, navigate to pages yourself. When he saw the ad that interested him he should have googled the offer instead of clicking on the ad.

Tiktok is giving away $3K in ad credit per customer? And the regular price isn't massively overpriced?