[HN Gopher] The mechanics of a sophisticated phishing scam and h...
___________________________________________________________________
The mechanics of a sophisticated phishing scam and how we stopped
it
Author : radicalbyte
Score : 55 points
Date : 2022-08-10 11:02 UTC (11 hours ago)
(HTM) web link (blog.cloudflare.com)
(TXT) w3m dump (blog.cloudflare.com)
| cmroanirgo wrote:
| Have a look at their timeline. Very impressive, 3 mins from first
| sign (2 mins from first report), the domain is blocked.
|
| (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
| psanford wrote:
| > we were able to thwart the attack through [...] physical
| security keys issued to every employee that are required to
| access all our applications
|
| I hope you are paying attention, Twilio. WebAuthN tokens are an
| effective phishing mitigation, unlike security/phishing training
| for employees.
| tialaramex wrote:
| Right. Employees hate the training and it isn't very effective.
| WebAuthn should be a no brainer.
| thewebcount wrote:
| > Cloudflare built our secure registrar product in part to be
| able to monitor when domains using the Cloudflare brand were
| registered and get them shut down.
|
| 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.
| sophacles wrote:
| Presumably Cloudflare has trademarked their name, and as such
| has various protections via ICANN:
| https://www.icann.org/resources/pages/trademark-infringement...
|
| 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.
| TechBro8615 wrote:
| I'm not clear how owning a registrar gives them a unique view
| into domain registrations at other registrars. Does being a
| registrar come with special privileges like programmatic
| unmasking of "whois protection?"
|
| 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?
| coderintherye wrote:
| Starting to wonder if this is a continuation attack from the Okta
| breach* a while back
|
| * Whether or not you call it a breach depends on perspective I
| suppose
|
| https://news.ycombinator.com/item?id=30762520
|
| https://news.ycombinator.com/item?id=30769537
| cmroanirgo wrote:
| I was thinking of the twitter breach - just mention CF in your
| tweets or profile and become a target.
|
| 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.
| kurupt213 wrote:
| when they say "scan the web" for Cloudflare targeting websites,
| does that mean they wrote a webcrawler that is constantly
| trolling for new Cloudflare targeting content?
| fjni wrote:
| > We blocked these IPs from accessing any of our services.
|
| > ... 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.
| kurupt213 wrote:
| if it was cloudflare's own VPN, wouldn't they know the IP
| address of the system connecting to the VPN?
| josephcsible wrote:
| > every employee at the company is issued a FIDO2-compliant
| security key from a vendor like YubiKey. Since the hard keys are
| tied to users and implement origin binding, even a sophisticated,
| real-time phishing operation like this cannot gather the
| information necessary to log in to any of our systems.
|
| This is why WebAuthn needs to become way more popular.
| EGreg wrote:
| And yet.
|
| 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!
| mirashii wrote:
| Webauthn does cover the scenario described by associating the
| credentials in the hardware token with the domain name, so
| that you're not entering credentials into a random site or
| iframe; the browser and token are verifying that the URL
| requesting a challenge is the same as the one that generated
| the credentials in the first place.
|
| 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.
| kurupt213 wrote:
| this wouldn't have been caught by the authenticator app
| either, would it?
| kadoban wrote:
| To really do this right, the yubikeys would need to have some
| kind of display to see what action you're confirming.
| Slightly better than nothing, the OS/browser UI could show
| it.
|
| Something like Plaid is unfixable though, that's just a
| garbage heap of insecure patterns. I refuse to use it.
| g_p wrote:
| Something I was disappointed (but not surprised) to never
| see take off outside a few niche areas and closed systems
| like payment card terminals was personal smartcard readers.
|
| 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.
| tialaramex wrote:
| All that the second factor mode of WebAuthn does is "This
| still me". Who? Me. That's all. The token intentionally has
| no idea who "me" is, nothing is preserved from one such
| interaction to another - it only knows that it's still the
| same token as it was before. This makes the technology
| privacy preserving yet is ideal for the specific scenario we
| care about - proving I'm still me. I just typed my username
| or email or whatever into a web site, so the web site already
| _knows_ who I claim to be on that web site, they 're just
| checking that in fact "this is still me" whoever that is.
|
| 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".
| Spivak wrote:
| Which is why it's so unbelievably stupid that the power to make
| unphishable systems is being arbitrarily tied to hardware keys
| and secure enclaves when it could just be an app on your
| system, deployed for free instantly across a whole fleet of
| machines that manages keys behind the password protected full
| disk encrypted systems they already have. "Oh but then someone
| who compromises the user loc... sssh the phishing protection
| alone is worth it."
|
| 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.
| [deleted]
| aetherspawn wrote:
| Is it possible to use a Dell contact smart card reader for web
| 2FA? Preferably in some way that it can be cloned if they lose
| their card.
|
| 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.
| joe_the_user wrote:
| _Since the hard keys are tied to users and implement origin
| binding, even a sophisticated, real-time phishing operation like
| this cannot gather the information necessary to log in to any of
| our systems._
|
| I'm struggling to figure out what this means and how it works. A
| cursory Googling didn't help.
| elchief wrote:
| setup yubikey with domain.com
|
| 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
| mirashii wrote:
| https://webauthn.guide/ has a lot of detail if you want to go
| into it, but what they're referencing here is the "rp" or
| "relying party" field that's used as part of the credential
| setup. This uses browser APIs to share the origin of the
| credentials stored with your hardware token to guarantee that
| your private key is only used when visiting that same service.
| This is as opposed to TOTP as a second factor where you're
| relying on the user to verify that they're not putting it into
| a phishing website.
| kevin_b_er wrote:
| I'm not familiar with FIDO2's changes, but FIDO1/U2F stuff.
|
| 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.
___________________________________________________________________
(page generated 2022-08-10 23:01 UTC)