Recent 'MFA Bombing' Attacks Targeting Apple Users(krebsonsecurity.com) |
Recent 'MFA Bombing' Attacks Targeting Apple Users(krebsonsecurity.com) |
(Don't get me wrong, let's go after Google, MS, Sony, et al too!!!)
It's surprising that Krebs chose to omit this little detail in the security blog and instead seemed to confirm that someone could completely give away access to their account while sleeping.
>Assuming the user manages not to fat-finger the wrong button on the umpteenth password reset request, the scammers will then call the victim while spoofing Apple support in the caller ID, saying the user’s account is under attack and that Apple support needs to “verify” a one-time code.
"Assuming the user manages not to fat-finger the wrong button" means "assuming the user clicks Don't Allow". They call on the phone to try and convince the user to say Allow next time.
Of course that's kinda BS too, because the only time "Allow" gives you a six digit code is if you successfully authenticate your apple ID on a new device. If you get the reset password dialog, the result of Allow is not a six digit code, it just allows you to reset the password. Yourself. On your device.
> Ken didn’t know it when all this was happening (and it’s not at all obvious from the Apple prompts), but clicking “Allow” would not have allowed the attackers to change Ken’s password. Rather, clicking “Allow” displays a six digit PIN that must be entered on Ken’s device — allowing Ken to change his password. It appears that these rapid password reset prompts are being used to make a subsequent inbound phone call spoofing Apple more believable.
> Update, March 27, 5:06 p.m. ET: Added perspective on Ken’s experience.
Internet archive confirms that this was the edit: The paragraph you quoted was added to the article the next day.
And even if not, there's a severe annoyance factor here that could be simply removed by Apple rate limiting these requests. Why can they send you hundreds of these in a short time?
This happened to me and my wife (each starting a few days apart) in 2021, or maybe 2022 but no later. It started with a couple requests a day, then ramped up to every hour or something. IIRC we also both got a couple SMS claiming to be from Apple.
As soon as it ramped up I set up both accounts to use recovery keys, which is a move I had planned anyway on grounds that it should not be in Apple's (or someone coercing/subverting Apple, be it law enforcement or a hacker) power to get access to our accounts. This obviously stopped the attackers dead in their track.
For similar reasons I set up advanced data protection as soon as it was available and disabled web access. Only trusted devices get to see our data, and only trusted devices get to enroll a new device.
Then again if it shows on the watch too (and isn't just mirroring a phone notification, since it ignores quiet mode), I can't imagine the idea is you click allow on your watch and then type a password on its keyboard?
This was a lifesaver when my 90 year old mother forget her iMac password (and I forgot that I had created a second admin account on her machine.) After getting locked out of the iMac, we were able to reset it because we were able to get into her iPad (which she forgot the pin to, but fortunately we found it written down.)
Obviously it must be possible to reset ones password, but from the article it's apparently possible to make 30 requests to reset ones password in a short amount of time.
What possible non-malicious reason could there be for that to happen?
Another reason to not to use phone (or the numbers) calls to verify users even with so called 'voice identification or voice ID' which can easily be broken with advanced voice cloning.
This happened to me exactly once, and it was two days after I ordered a new MacBook from the online Apple Store. Since I was expecting a shipment, I almost picked it up. But instead I called Apple Support myself, and asked if they had called me, and they said they had not.
I suppose it could have also been as simple as "it's Christmas shopping time." I remember what was most surprising was seeing the caller ID, which I think was actually "Apple Inc," and which was saved as a contact in my phone.
For example: if a user is requesting a reset password link 10 times a minute you can just send the link one time but display everytime that a reset link was sent by email.
I have changed the password, main mail and in the privacy settings of LinkedIn removed the visibility of the email
How hard is it to just type a code really. In the end to fight against push bombing you end up with push notification that ask you for a code anyway.
"I said I would call them back and hung up," Chris said, demonstrating the proper response to such unbidden solicitations."
We're long-conditioned to assume that calling a large company and reaching a human will be difficult to impossible - and if we succeed, it will be an unpleasant experience. Much more so for a major tech company.
As far as this scam succeeds, it's partially due to intentional business designs.
So why is an inept public responsible for major corps choices to mostly remove phone-to-human cust svc - and not corp poisoning by MBAs?
So... Apple Watch "quiet" is broken??
If you follow that advice, this attack poses no risk other than annoyance. If you do not give your password to the creep who calls you claiming to be apple support, you will be okay.
This really sucks though. It basically means that our current phone system is inherently broken and something that was potentially useful before is no longer useful due to malicious actors.
https://www.yubico.com/product/yubihsm-2-series/yubihsm-2-fi...
Unless you want your users to be SIM swapped, there is no reason to use phone numbers for logins, verification and 2FA.
[0] https://news.ycombinator.com/item?id=36133030
[1] https://news.ycombinator.com/item?id=34447883
[2] https://news.ycombinator.com/item?id=27310112
I mean they already lock my iPhone after too many failed attempts with my passcode and it gets longer each time, I feel like the lock here should be the same.
A better prompt would also go a long way.
It is kind of scary too — lose the key and no one can get you back in to your account.
sounds like a feature
"want to totally restart your entire digital life? just rip up your key :) never worry about something from your past coming back to you ever again!
Incorrect: only Apple cannot.
You can voluntarily declare:
- recovery accounts: these trusted accounts can help you authenticate anytime.
https://support.apple.com/en-us/HT212513
- legacy contacts: these trusted contacts can access your account in the event of your death.
https://support.apple.com/en-us/102631
As for the "lose recovery key" situation is no different than hardware token 2FA + recovery codes. Print multiple copies and spread them to trusted third parties.
That's easy to backup. You can even print it and bury it in a sealed box in the garden or put it in a book or whatever. It depends who you are protecting against.
I also stuck that key in 1Password (sure it's less safe, but if my 1Password was breached I have far bigger problems than this key being retrieved).
Then keep a hard copy in a safe. Been contemplating sending my parents a safe (who live several states away) with keys on a sheet of paper without context that only I have the combination too. But not sure yet.
> However, if you lose your recovery key and can’t access one of your trusted devices, you'll be locked out of your account permanently.
I considered it before but I think it's just too much risk as I rely heavily on iCloud. On the other hand, I don't see the risk with the current method if you're smart enough not to fall for things like MFA bombing tactics.
KrebsOnSecurity tested Ken’s experience, and can confirm that enabling a recovery key does nothing to stop a password reset prompt from being sent to associated Apple devices. "
“ When you use Security Keys for Apple ID, you’ll need a trusted device or a security key to:
Sign in with your Apple ID on a new device or on the web
Reset your Apple ID password or unlock your Apple ID
Add additional security keys or remove a security key”
Yubikeys do nothing except enlarge your attack surface.
ETA: Also from a user experience even once a week between attempts is still enough to deeply annoy a user getting popups on their devices. This is one of those cases where rate limits probably still can't solve the user irritation.
On the official Apple reset form, the "phone number" is one of the id options the hackers can use to MFA bomb the target:
https://iforgot.apple.com/password/verify/appleid
The gp proposes a different "private identification string" that's not public. Public IDs such as "email address" or "phone number" are susceptible to what this article is talking about.
Flatten texts to ASCII-256, blacklists/whitelists, priority tagging, SMS cc'd to an email box, multi-number simul-receive, and so on.
Well, you asked ...
we should also update PCI DSS compliance or whatever relevant security standard to call SMS one time codes totally insecure
we can also reach insurers these companies use and tell them to force removal of SMS one time codes
do a multi pronged assault on SMS one time passcodes
Financial institutions can detect if your phone number has been ported or forwarded.
Bigger threat is phishing and password sharing between accounts. I ran tech at investment firm/ neo bank and never saw an attack on sms 2FA and we had over a million customers. We had email 2FA for a while there was significant number of people who shared passwords between email and their bank.
I'm surprised to see this comment on HN where many readers see how the sausage is made. There's no secret sauce, no matter how far up in FAANG/MANGA you get.
You can't debounce them like you can with a reset password email flow.
With a typical password reset email, the actual password resetting is done by the user after they click the link in the email, only someone with access to the email can proceed, and they can only proceed on the same device that they clicked the email link.
In this flow, there is no further on-device interaction.
But yes I wish you could use one hardware key as backup and one software key for day-to-day usage, or at least the security key in a trusted device (up to you to have a circular dependency to your main device or not).
I thought it was a joke at first. I have no idea what they compare it to??
No reset actually occurs until one prompt is accepted.
I think it’s technically unrelated to the SIM, but rather to create the new Apple ID he used his existing (compromised, lol) phone number for “verification” or something. Which is weird in a way because then Apple must allow multiple accounts per phone number?
Funny thing is you cannot set a passphrase or equivalent recovery code unless you have an apple device. So users who have an apple account for development purposes (I hate apple device UX and wont ever use anything apple again other than to approve releases and manage certificates) and have no apple products are cursed to use ones phone number.
>The gp proposes a different "private identification string" that's not public. Public IDs such as "email address" or "phone number" are susceptible to what this article is talking about.
This is a non-starter for the general public. If they can barely remember their password what are the chances they'll remember a "private identification string" or whatever?
Unions are on board with this, see e.g. https://unitedafa.org/news/2020/5/9/employment-verification-...
However, in this case, the edit is disclosed at the bottom of the article. Do you think this isn't sufficient? Does the edit disclosure need to contain a link to a diff of the changes or does it need to be at the top?
"Unnerved by the idea that he could have rolled over on his watch while sleeping and allowed criminals to take over his Apple account, Ken said ..."
Once the article was updated, the original sentence implying that criminals could take over your account while you are sleeping was completely rewritten to say the 180 degree opposite - completely reversing what the initial sensational content said. In reality it is not possible to accidentally hand over your account to attackers by accidentally tapping Allow on your watch in your sleep.
The update disclosure only says: "Added perspective on Ken’s experience."
It’s a bit confused about what exactly the problem is, so is a little self-contradictory (including elsewhere in the article).
What I find interesting is that Krebs didn't do any legwork to verify the claims before publishing.
I don't think its a matter of being "smart enough". Human error can easily creep in when dismissing 10's or 100's of prompts.
Someone please tell this to fidelity. After 3 wrong password attempts they lock your account.
(This is on top of them not sending any actionable email when changing my contributions to 0 in between pay periods)
I'm rolling my 401k out as often and fast as possible. I hate American banks so much.
Would https://github.com/lwthiker/curl-impersonate help? Haven’t tried with Akamai, but did help with another widely used CDN that shall remain unnamed (but has successfully infused me with burning hate for their products after a couple of years’ worth of using an always-on VPN to bypass Internet censorship and/or a slightly unusual browser).
What’s funny/sad is they probably pat themselves on their back thinking their security is so advanced and awesome. Financial services web integrations are all total clown shows.
Don’t forget the final nail in the coffin, which completes the trifecta: it’s entirely immutable - damage radius = infinite.
Afaict, it drives a stock Chromium instance. I'm not sure how Fidelity is detecting it, but they detect it even in normal headful mode. Idk if there's some JS that notices there's no mouse-move movements.
It's just not worth the headache. I despise bending over backwards for companies like this. But obviously I have no choice since they're my 401k plan facilitator.
Do Apple definitely not retain a key? If they don’t is the encryption quantum secure?
You make posts on twitter, it's not protected the same way.
That means you're one natural disaster away from losing everything.
As much as it can "weaken" security, an electronic backup is still recommended for most
Maybe I'm being dense (probably), but where would you save it?
iCloud? No, that doesn't work - you need the key to access iCloud.
Some other cloud storage service? No, that doesn't work - you need your phone to generate a token for access and your phone was destroyed in the same fire as the paper backup.
Seems like the safe choice is a lock box at a bank or similar. Or a fireproof safe at home.
But safety deposit boxes are a good choice too, just be careful to balance your own convenience. If you can't easily update your backups, you're really unlikely to include new accounts in them
You definitely don't need your phone for access. I use Yubico security keys for everything like this. I have several of them that are on all my accounts and I don't keep them in the same place.
Of course, a code like that can be in multiple places, possibly where it won’t be recognized as such.
The conventional way to do this would be encrypt it with a symmetric cipher keyed from a password or passphrase. I've been using an unconventional approach where the secret you have to memorize is an algorithm rather than a password/phrase. Programmers might find an algorithm easier to memorize than a passphrase.
Here's an example of this general idea. The algorithm is going to be a hash. This one will take a count and a string, and output a hex string. In English the algorithm is:
hash the input string using sha512 giving a hex string
while count > 0
prepend the count and a "." to current hash and apply sha512
I'd pick a count (say 1969) and a string (say "one giant leap for mankind"), actually implement that algorithm, run it on that input and string. That would give me a 512 bit number. I'd take "3FAEAB4D-BA00-4735-8010-ADF45B33B736" and turn it into a number too (by treating at as 36 base 256 digits). I'd xor those two numbers, print the result in hex, and split it into 2 smaller strings so it wouldn't be annoyingly wide.
Then I'd save the input count, input string, and the output:
1969 one giant leap for mankind
ed428dffa23f4f14ae2a7b7e842019fc11b5726d726b96c11ec266758be67cb0
f2a78a320a85df809afe83c6c7840e2d175cceadb455260735405cd047459cc9
I could then do a variety of things with the "1969 one giant leap for mankind" and the two hex strings. Put then in my HN description. Include then in a Reddit comment. Put them on Pastebin. Take a screenshot of them and put it on Imgur.
To recover the code from one of those backups, the procedure is to implement the algorithm from above, run it with the count and string from the backup to get the 512 bit hash, take the 512 bits of hex from the backup, xor them, and then treat the bytes of the result as ASCII.
Then delete the implementation of the algorithm. With this approach the algorithm is the secret, so should never exist outside your head except when you are actually making or restoring from backup.
When picking the algorithm take into account the circumstances you might be in when you need to use it for recovery. Since you'd probably only be needing this if something so bad happened that you most of your devices and things like your fireproof safe, you might want to pick an algorithm that does not require a fancy computer setup or software that would not be in a basic operating system installation.
The algorithm from this example just needs a basic Unix-like system that you have shell access to:
#!/bin/sh
COUNT=$1;
shift;
KEY=`/bin/echo -n $* | shasum -a 512 | cut -d ' ' -f 1`
while [ $COUNT -ge 1 ]; do
KEY=`/bin/echo -n $COUNT.$KEY | shasum -a 512 | cut -d ' ' -f 1`
COUNT=`expr $COUNT - 1`
done
echo $KEYFinding somebody’s will doesn’t give you access to any of their data or funds.
Survives a fire, earthquake. No tornadoes or tsunamis here. Nobody has stolen any such rocks from here.
A friend of mine who was (maybe is? he knows I'm not a fan so we don't talk about it much) big into crypto stores his secrets in similar safes with trusted friends and family around the country. I think it's a good idea for things like this tbh.
I think I might need to look up to see if there is a known pattern to these keys that it could be easily figured out what it is even if it is just on a sheet with no context. Particularly 1Password which I think is a pattern if I remember correctly.
What does that mean?
I don’t doubt that many people do, but it’s still not a solution for the majority of Apple users.
If this is the threat vector you’re worried about, you shouldn’t have had anything in iCloud (or any cloud for that matter) to begin with, rendering this debate completely moot.
I'm imagining this spiraled around somebody's upper thigh... "fakePassw0rdo̶n̶e̶t̶w̶o̶t̶h̶r̶e̶e̶four"
Similar to how a lot of package companies have a certain pattern, length, whatever for their tracking numbers. If there was a somewhat reliable way to say "This is a 1Password key" or "This is an iCloud key" it makes it means even without context it could be an issue.
I guess you'd have bigger problems at that point.
I suppose a phrase works too, and easy to remember.
Also, the idea is simple enough you could DIY your own version with stuff from any hardware store.
> Why can't they offer a last-resort option like showing up in person at an Apple Store with government-issued photo ID?
I'd say a lot of identity problems are there because companies have to identify people without an official ID somehow...
Your data and account ownership interest doesn’t disappear because of failure to possess the right sequence of bytes or a string. Can you imagine if your real estate or securities ownership evaporated because you didn't have the right password? Silliness.
> Your data and account ownership interest doesn’t disappear because of failure to possess the right sequence of bytes or a string.
Somehow you have to establish that you are the owner of the account, in a way that nobody else can do it. This is very much not a trivial problem, and government IDs don't provide any kind of solution to it.
If you need a driver's license, how do you get a driver's license? With a birth certificate? Okay, how do you get a copy of your birth certificate when you don't have a driver's license?
If there is a path to go from your house burning down and you having zero documents to you having a valid ID again without proving you've memorized or otherwise backed up any kind of secrets, an attacker can do the same thing and get an ID in your name. This is why identity theft is a thing in every system that relies on government ID. Requiring all systems to accept government ID is requiring all systems to be subject to identity theft.
> Somehow you have to establish that you are the owner of the account, in a way that nobody else can do it. This is very much not a trivial problem, and government IDs don't provide any kind of solution to it.
This is actually very easy. You can identity proof someone through Stripe Identity [1] for ~$2/transaction. There are of course other private companies who will do this. You bind this identity to the digital identity once, when you have a high identity assurance level (IAL). Account recovery is then trivial.
> If you need a driver's license, how do you get a driver's license? With a birth certificate? Okay, how do you get a copy of your birth certificate when you don't have a driver's license?
This is government's problem luckily, not that of private companies who would need to offer account identity bootstrapping. Does the liquor store or bar care where you got your government ID? The notary? The bank? They do not, because they trust the government to issue these credentials. They simply require the state of federal government credential. Based on the amount of crypto fraud that has occurred (~$72B and counting [2]), government identity web of trust is much more robust than "not your keys, not your crypto" and similar digital only primitives.
NIST 800-63 should answer any questions you might have I have not already answered: https://pages.nist.gov/800-63-3/ (NIST Digital Identity Guidelines)
[1] https://stripe.com/identity
[2] https://www.web3isgoinggreat.com/charts/top
(customer identity is a component of my work in financial services)
E.g. you could make it costly to attempt, require a notarized proof of identity -and- showing up at the Apple store, and enforce a n-day waiting period. A different employee does the unlock (from a customer service queue) than accepts the paperwork.
We don't lock people out of financial accounts forever when they forget a credential. It could definitely be solved for other types of accounts.
I’m not sure you want that to be the absolute best digital security you can get.
Recovery key isn’t susceptible to that - and isn’t susceptible to fake-id-spotting-ability or bribeability of staff either.
The main problem is that walking into an apple store with a government-issued warrant works just as well as walking in with a government-issued ID.
"Pay someone else to do it" is easy in the sense that doing the hard thing is now somebody else's problem, not in the sense that doing it is not hard. That also seems like a compliance service -- you are required to KYC, service provides box-checking for the regulatory requirement -- not something that can actually determine if someone is using a fraudulent ID, e.g. because they breached some DMV or some other company's servers and now have access to their customers' IDs.
> This is government's problem luckily, not that of private companies who would need to offer account identity bootstrapping.
But it's actually the user's problem if it means the government's system has poor security and allows someone else to gain access to their account.
> Based on the amount of crypto fraud that has occurred (~$72B and counting [2]), government identity web of trust is much more robust than "not your keys, not your crypto" and similar digital only primitives.
The vast majority of these are from custodial services, i.e. the things that don't keep the important keys in the hands of the users. Notably this number (which is global) is less than the losses from identity theft in the US alone.
The general problem also stems from "crypto transactions are irreversible" rather than "crypto transactions are secured by secrets". Systems with irreversible transactions are suitable for storing and transferring moderate amounts of value, as for example the amount of ordinary cash a person might keep in their wallet. People storing a hundred million dollars in a crypto wallet and not physically securing the keys like they're a hundred million dollars in gold bars are the fools from the saying about fools and their money.
Using vitalchek, you can order a BC with a notarized document, using two people who have valid IDs as people to vouch for your identity. I've done it for multiple clients.
So if I'm understanding this correctly, if me and one of my friends both have a valid ID, we can get anybody's birth certificate?
Note: The notary will record the ID #s and other info of the two ID holders. So if something goes wrong, the two ID holders will be on the hook as well.
Once the notarized document is submitted to vitalchek, they'll process the request.
Of course, one would still have to know a few details from the BC (parents, location, etc) to get vitalchek to submit the request to the county/city registrar.
Though of course this is a method of fraudulently obtaining an official ID, so you do need to be concerned that the people engaged in that sort of enterprise might already have a couple of them.
> Of course, one would still have to know a few details from the BC (parents, location, etc) to get vitalchek to submit the request to the county/city registrar.
Which is the sort of thing that gets collected in big databases which then get breached and published on the internet.