...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.
https://wp.josh.com/2019/05/06/breaking-news-google-adwords-...
They just fire off a request to google.com/url?... to track the click before letting you on your merry way.
Sigh
It really sucks that it seems like we've built the most important infrastructure of our generation effectively on quicksand.
Telephone charity calls are exactly the same way in my world, and started me down that handling path. If I look your org up and you look legit, and I'm interested, we'll see. You having called me isn't always strike one, but it often is.
Personally, I prefer to follow the OP's advice, and only provide information if I initiate the call. Or, more specifically, I'm willing to provide only the information you could find in a phone book, such as name, phone number, and address, and if they truly want my donation, they can mail me something for the request. Still, it could result in mail fraud, but the likelihood is pretty low at that point.
It's ok for the initial pull to be an ad, but only buy from the source.
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.
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?
"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 ;)
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.
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.
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.
I don't understand how Google/Facebook/etc can allow this to happen, let alone encourage it. I'm just baffled.
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).
You have to fail at several steps if you're entering your credentials in this scenario.
I must say that it was a pretty clever scheme.
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.
oAuth outside a browser is just training people to be phished.
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.
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 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...)
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.
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.”
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.
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 ?
I don't get involved in ad buys.
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".
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.
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'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 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.
Why couldn't a web site have stolen his credentials in the same way?
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.
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.
The TikTok promotional program is actually a real thing that does give around that amount of ad credit, and they have been promoting it very aggressively on Facebook with for a long while now, so it makes sense that OP would've not had any mental red flags triggered by the designs and creatives used by the scammers. The real killer is that PayPal is actually well within their rights to process this transaction (as part of the billing agreement generated when you link PayPal to Facebook Ads Manager: there actually was real ad spend in a real Facebook ad auction), so it's down to Facebook itself to refund the ad spend. (As an aside, I'm actually impressed that OP managed to reach Facebook support at all, and that they acknowledged or even understood what the problem was. I have had worse experiences in the past with FB...). What's really amazing to me is that the scammers managed to get on Google Play with thousands of obviously fake reviews, and get through Facebook ad review at all.
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.
I suppose the real lesson to be learned is to simply avoid installing native applications when you can help it. OP didn't screenshot the login screen in app, so I can only assume it was a real Facebook oauth flow, 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.