The mechanics of a sophisticated phishing scam and how we stopped it
blog.cloudflare.com
blog.cloudflare.com
That sounds to me like a very healthy culture. I wonder how many other organizations are similar?
As regards reprimands - it does sound like a healthy culture, and I've seen and worked in thoroughly rotten environments with an equally rotten security culture.
One example that sticks out, I worked in a utility company where IT would install a laptop desk lock and tie it to your desk. Then security would come by at night a few weeks later, lift the desk and remove the lock and laptop. The kicker was then they would issue a reprimand to the person who owned the laptop for failing to secure it. This was pure security theatre so people could justify their role.
If you want people to fix their mistakes and change, you need to encourage them to do so. If you want people to try to hide their mistakes, punish them.
(If you discover that IT has permanently reserved a backup laptop for a particular employee who is perpetually in need of a fresh image, it's time to talk to their manager about why they fall for these things and what other mistakes they might be making.)
* Whether or not you call it a breach depends on perspective I suppose
It should be a simple matter for CF to figure out which is the case.
It would be nice to know if CF customers were also targeted.
(Edited a bit for brevity & mobiles)
> 22:49 UTC Attacker sends out 100+ SMS messages...
> 22:50 UTC Employees begin reporting SMS messages...
> 22:52 UTC Verify that the attacker's domain is blocked in Cloudflare Gateway for corporate devices.
> 22:58 UTC Warning communication sent to all employees across chat and email.
etc
As it is I reported the two that didn’t use spoofed numbers to the owner of the number (onvoy/inteliquent as usual). Response time from them is basically infinite, as abuse reports basically go into a black hole.
I hope you are paying attention, Twilio. WebAuthN tokens are an effective phishing mitigation, unlike security/phishing training for employees.
Per the article, only three of 76 targetted employees were fooled by what can reasonably be described as a best-in-class phishing attack. That's actually pretty good[1], and implies that someone trained them pretty well.
[1] Though surely Cloudflare employees are, by the nature of their business area, going to be a ton more sophisticated about this than median corporate folks.
My lingering question however is still how come the phishers knew so much about cloudflare, yet missed the critical key (no pun intended): they had 76 phone numbers of CF employees and a plausible call-to-action, plus knowledge about okta usage, but missed the crucial fact that CF uses hardware tokens??
You can see some of the other victims in public CT logs: https://search.censys.io/certificates?q=%28%28Okta.com%29+AN...
This type of attack just can't work on targets which are properly secured with FIDO authenticators. So it's not really "slightly different". The minimum adjustment the attackers can make is probably something like "Hire motorcycle couriers, add a step where the user is told their token needs replacing, a courier comes out and takes it, we get the token". Which is a very different ball game from "Make some web sites and install this off-the-shelf phishing toolkit".
Think of it like a bank robber showing up to a job to crack a safe with an autodialer. He will have no problems on 9/10 banks that use dial safes, but this one has an electronic keypad. The electronic keypad being better or worse is irrelevant, it protected the bank because the robber brought the wrong tool.
This seems to me like a credential harvesting campaign. Most likeli there is a trojan app that was used which used a list of contacts to spread.
It noted that the employee's families were also contacted, this tells me CF does BYOD for mobile phones.
I make a point out of not using my personal phone for anything work related because of this and many other reasons. Not only should companies pay for and manage employee's work phones, using a personal phone for work reasoms should be disallowed. Work phones can be restricted to not have unapproved apps.
While yubikeys are phish proof, the attackers could habe instead asked users to download an authentication app which would steal cookies to bypass yubikeys by letting them login to the right CF portal but in a trojanized in-app browser.
> ... we’re tightening up our Access implementation to prevent any logins from unknown VPNs
This requires clarification. I think this means cloudflare is completely blocking some of mullvad's ip addresses for their internal tools (or third-party services they use?) But "all services" could also mean if I run my service on cloudflare, this will affect some of my customers who happen to be using these mullvad nodes.
If it's the latter, I understand the immediate concern is the phishing attack, but on a larger level this is concerning since I can't see how this response would mirror to cloudflare's own vpn offering. If an actor were to use cloudflare's vpn offering for nefarious purposes (directed at cloudflare or someone else,) I don't see cloudflare implementing this policy aimed at their own offering.
Was almost waiting for a dox of the attacker :-)
This is why WebAuthn needs to become way more popular.
I am shocked to see that all the "two-factor authentication" approaches don't bother to mention the action that is being authenticated.
People often are conditioned to simply enter their passwords and their two-factor authentication into a window just because they think they are dealing with an official representative.
If you think you're immune, think of how many times you've entered your information into Plaid, which was displayed as a mere iframe on a website! How did you know it was Plaid? Because you trusted the enclosing website? And for that matter, why do you trust Plaid?
People get phished all the time by having a "bank rep" call them on their phone and have them read back these numbers, claiming that a different action is about to take place than the one being confirmed. All that could be EASILY stopped by the banks if they just added the action that's about to be confirmed. But somehow this hasn't happened in any of the incarnations.
PS: I think some places in Europe do mandate it but not USA at all!
Showing the action as part of the dialog doesn't really solve the threat posed here, because if you're not validating where you're answering a challenge from, then you also don't really have a way to know they're not lying about the action presented.
You can leverage this technology to do more, including your "action that is being authenticated" stuff, but this adds complexity we mostly don't need. It turns out we can get a really long way with just absolute certainty that "This is still me".
Something like Plaid is unfixable though, that's just a garbage heap of insecure patterns. I refuse to use it.
Even reasonably affordable ones commonly have a 16x2 or 16x4 LCD screen. While today's protocols and drivers don't inherently tie together the data being signed with a string shown on the screen, appropriate design of protocols could enable this - then you'd have a hardware reader with PIN pad, where your PIN isn't seen by the computer, and with a screen showing you exactly what domain you are logging into, or which action you're approving.
You can implement webauthn on a smartcard just fine as well (there are open source applets for it I believe) - just a shame that hardware readers with trusted displays never really took off on desktop PC! Then again for "just login" like in webauthn, really the domain is the only thing seen. A rogue local browser app can prompt you to authenticate for an arbitrary domain, but it's challenge/response based so the attack needs to happen in real-time.
I know I'm talking about software authenticators, but the whole "movement" if you wanna call it that seems to be openly hostile to them to the point of implementing DRM via attestation because there's money to be made in selling new disposable plastic thing.
Its not though. First of all, windows, android, macos and ios all support being used as platform authenticators. No need to use an external hardware key to get the benefit. This is what most people should use (really most people should use passkeys tied to your phone once those become widely available).
I don't really understand your complaint that those implementations are tied to secure enclaves and TPMs. Every laptop issued by your company already has one of these in them. Why not use them?
I get that there's a fear that TPMs somehow enable DRM. Given that TPMs have been around for 20 years and haven't been used for DRM applications I think thats a bit overblown. But even if you do believe that, I don't see how you can conclude that using webauthn with a key protected by your TPM somehow enables DRM.
If you are really morally opposed to using a FIDO device that stores keys in protected hardware, go ahead and run a soft FIDO token! I wrote a software authenticator for linux that uses the TPM[1], but it also has a mode where it just uses keys stored in memory. There are other good software FIDO implementations[2]. These authenticators work on basically* every site that supports webauthn. Use them, they are still going to be much better than using SMS or TOTP factors.
*It used to not work on vanguard.com but that changed when they upgraded from the old u2f APIs to the webauthn API. It also doesn't work for one enterprise site I use for my job, which checks attestation certs to ensure the key is one that was issued by the company and is FIPS compliant.
[1]: https://github.com/psanford/tpm-fido [2]: https://github.com/danstiner/rust-u2f
In theory they do. In practice, a lot of websites will reject them for the reason you've already seen:
> It also doesn't work for one enterprise site I use for my job, which checks attestation certs
If standards bodies actually cared at all about our freedom, remote attestation would have never made it into the standard.
That's pretty disturbing. What about fair use? What if someone wants to register cloudflaresucks.com, for example? Or what if they have a name that happens to have "cloudflare" in it (such as oortcloudflares.com, where one would presumably have information about flares of ... something... in the oort cloud)?
I get wanting to stop attacks like this one, but I'd hope they don't have the power to just indiscriminately take down other people's web site just because the name is one they don't like.
Whether you like it or think it's unfair, this was litigated long ago, and Cloudflare's actions are no different than any other big brand hiring a company to search registrars for thier name.
It's worth noting that cloudflaresucks.com and similer *sucks.com names have been protected by the courts in the US as non-infringing. Names like Cloudfare.com or C1oudflare.com probably can be taken down, particularly if they represent themselves as actually being cloudflare.
Second, trademarking a name doesn't give complete ownership of that word to the trademark owner. WordPress can still exist, even though Microsoft owns the trademark for Word as a word processing application. The example I gave of oortcloudflares.com (or maybe less ridiculously something like micloudflares.com where it's about loud flares of sound coming from microphones) shouldn't infringe on their trademark in any way since they have nothing to do with networking. But again, all of that is irrelevant if they can just throw their weight around and crash any website with a name they don't like. Many individuals and small businesses wouldn't even have the money to take them to court.
[1] Just to be clear i do not mean this as an insult, just a reference point, these discussions were common on Slashdot back then as all the things you mention either happened or were hypothesized by various "governing bodies" or "agitators" like eff.
Yes, I felt an eyebrow raise a bit when I read about Cloudflare getting the site taken down. It is a minor super-power.
That said, any power can be abused, but that does not mean that it will be abused, or that the potential for abuse means that we should eliminate that power.
In the case of CloudFlare, they so far seem like a responsible infrastructure provider, with a business model that aligns their incentives with being trustworthy, so I'm OK with it.
In contrast, I wouldn't even consider trusting any Meta/FB org with anything like this power, as their obvious behavior has been massively untrustworthy, and their business model makes it easiest to be untrustworthy.
The question is whether we are at risk of such power being extended beyond ICANN Cloudflare, etc. and to the likes of untrustworthy players like Meta, Alphabet, etc., and if so, what to do about it?
They also already have a source of DNS traffic to mine for new registrations. Surely a phishing site would show up there fairly soon after registration. So does being a registrar come with more benefits than just timing?
If it does, then shouldn’t the worry be more broadly about Cloudflare potentially abusing this system to deanonymize the owner of _any_ domain, not just those they deem trademark infringing?
In addition to that, controlling the registrar also allowed us to take advantage of features like registrar and registry locks managed by policies we had full control of. Auditing the policies of other registrars, even the supposedly secure ones, freaked us out enough to spend the money to build our own.
I’m still not clear though, does that feed include Whois protection, or is the real identity of each registrant available to you even if the domain was registered elsewhere?
The intent of the attacker in this case was extremely evident- the page served at that domain clearly used cloudflare’s trademarked logo in an attempt to fool the user into thinking this was an official cloudflare page. The intent to deceive is clear.
In your case, I would imagine your page would avoid making itself appear as official cloudflare marketing material. In fact, I would imagine you would take pains not to be confused with the official cloudflare site. So it would be pretty clear the intent is not to deceive and you would have a very good leg to stand on if they tried to take down your domain.
If there were grey areas (e.g. the cloudflaresucks.com example given above, or a parody), I would get the concern. But this seems pretty cut and dry
I'm struggling to figure out what this means and how it works. A cursory Googling didn't help.
login to domain.com
enter username/password to domain.com, it then demands domain.com yubikey authn token. yubikey provides only if on domain.com
login to fakedomain.com
enter username/password to fakedomain.com, it then demands domain.com yubikey authn token. yubikey does not provide because not on domain.com. or it demands fakedomain.com token, but yubikey doesn't have it
so, in that way, yubikeys (and similar) are immune to phishing, unlike say google authenticator
What happens is the browser signs the request to the security token with the website URL. The security token's response based on the secret includes this as a result. So if you try to login to d0main.com instead of domain.com and get a U2F 2nd factor auth, the browser will generate a request based on d0main.com. Even if the malicious site, d0main.com, copied/repeated the public key info for the second factor auth request from domain.com, the browser would hash and sign the request as coming from d0main.com as a result. The resulting login token would not match up with what domain.com expected. The login would fail.
So the beauty of this protocol is that, by having the browser be a trusted intermediary, you have to login to the correct website for the 2-factor U2F token to create the right response. You cannot be phished unless you can trick the browser as well into signing your malicious site's request with the real domain/url.
This does not work with 'enter a code', sms, or those apps that prompt you to say you approve of the login. All of those are subject to an attack where the legitimate login system gets proxied by an attacker.
Unsure how FIDO2 stuff changes this.
With FIDO1 nothing lives on the authenticator. If I drop my authenticator on the subway, and you find it, unless you somehow guess my identity and try to log in as me, the authenticator gives you no clue (I mean if I wrote my name on it in Sharpie that would tell you, but the technology itself doesn't) and you can just use that authenticator, might as well, free authenticator. Probably a bad idea if you're Edward Snowden but for Mr Average it's safe.
But with FIDO2 your actual credentials can live on the authenticator, which means it knows (in some sense) who you are. On the other hand this mode should be protected with a second factor (since the authenticator itself is no longer the second factor) such as a fingerprint sensor, or maybe a PIN lock.
You got the effect of FIDO1 right, but the mechanism is a bit cleverer. On a cheap device this is relying on Authenticated Encryption. When a site says "Prove you're still you" to a FIDO1 authenticator it needs to provide a huge "Identifier". Well, for the cheap devices (maybe not an iPhone, but say a Yubikey) that "identifier" isn't really just a very large index into a table, they've only got a tiny amount of flash. Instead it's actually your private key for that website encrypted by the authenticator using its own symmetric key, and the AE is used to confirm it is the correct website. If it wasn't the key doesn't decrypt and that's exactly the same scenario as if you plugged in the wrong authenticator, a thing people do all the time.
From the authenticator's point of view, suppose you've got a nice red authenticator and also a blue one. You have enrolled the blue one at Facebook but not the red. Let's see three scenarios
1a. You forget and try to use the red authenticator to sign in to the real Facebook
1b. Facebook says prove you're still some-huge-ID-made-by-the-blue-token-for-Facebook
1c. Your red token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for facebook.com, the Authentication Encryption says... No.
1d. Your browser says nope, try a different token?
2a. You are being phished and try to use the blue authenticator to sign in to Fakebook
2b. Fakebook sends over the identifier from the real Facebook site, some-huge-ID-made-by-the-blue-token-for-Facebook
2c. Your blue token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for fakebook.com, the Authentication Encryption says... No.
2d. Your browser says nope, try a different token?
3a. This time you remembered to use the blue authenticator to sign in to the real Facebook
3b. Facebook says prove you're still some-huge-ID-made-by-the-blue-token-for-Facebook
3c. Your blue token tries to decrypt the ID, using its own symmetric key, and the knowledge this is for facebook.com, the Authentication Encryption says... Yes.
3d. Your token can sign an "I'm still me" message for Facebook using the Private Key it got back with the Authenticated Encryption. You get into Facebook.
To support all this, the remote sites should keep a list of up to say half a dozen authenticators you've enrolled, and it should hand over the full list on each sign-in. "Do you have any of these?". Your browser polls each authenticator with each ID, "Hey, authenticator, is this one yours?" if any of them say Yes, we're done, proof provided. Otherwise, tell the user none of the tokens worked, do they have others?
For enrollment a similar strategy is used. The site hands over all the IDs it already has and the browser says "Hey, do you recognise these IDs?" if an authenticator recognises one of the IDs then we enrolled that one already, look for one that doesn't recognise any IDs, that one should be enrolled.
Origin binding -- When you visit a site you used before, the site sends you the encrypted blob offloaded private key. Your token verifies it and decrypts it, and signs a challenge using the key and sends that back to the server as a response, to be verified using the stored public key. Part of this unsealing process ties it to the domain, protocol and port of the origin site making the request, so if a phishing site acts as a relay, your token won't generate a valid response, since the phishing site origin differs and the offloaded private key won't decrypt.
If you look at the threat model here, if your token and its implantations of crypto are secure, you really need to get rogue software onto the client device, which can send arbitrary requests over USB to your security token device, and trick the user into proceeding. At that point it's "game over" as you have code execution on the endpoint and there's other ways to achieve your goals from there.
The crucial trick in WebAuthn is there isn't an override button. There is no "fall for the phishing scam" button, so there's no way to push it.
We’ve got contact readers in all the laptops, and our door systems can read them too, but not sure how to deploy them for websites and such.
You want to implement security for even the least technical role (ie reception), but you also don’t want to give everyone a keychain full of dongles or install half a dozen computer plugins.
You could also use PIV/PKCS11 client certificates if it's for internal systems you run - there is reasonably good support for using client certificates in popular browsers from a smartcard, as this is used for DOD CACs.
They should’ve not cooperated. Instead, cloudflare should have had to contact verisign - the actual owner of .com.
"Cloudflare Area 1 is a cloud-native email security platform. It crawls the Internet to stop phishing"
and also
"Proactively hunt for attacker infrastructure and campaigns with our massive-scale phish indexing."
and also
"Scans the Internet for attacker infrastructure, sources, and delivery mechanisms to stop phishing attacks days before they hit the inbox."