There's an important omission in the article and the top comments here don't mention it either: Accidentally tapping "Allow" does not allow the attacker to change the password on their web browser. When you tap Allow on your device, you are shown the 6-digit pin on your device and you can use it to change your password on your device. The final part of the attack is that the attacker calls you using a spoofed Apple phone number and asks you to read out the 6-digit pin to them. If you choose to give out the 6-digit pin to the attacker over an incoming phone call, then they can use it in their browser to reset your password.
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.
He describes this in the very first paragraph of the article:
>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.
That seems to be an entirely different point. Krebs suggests repeatedly that all you need to do to get hacked is click "Allow" in the push notification. This is demonstrably false.
"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.
Fair, and good to know, but I could still easily see reasonable people (not just 80 yr olds with their Obamaphone) falling for this.
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.
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.
> A recovery key is an randomly generated 28-character code
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.
You can setup a recovery contact incase you do loose the key. I just set that up with my partner and the chance of loosing the key and both of us losing all of our apple devices I think is fairly slim.
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.
> When you set up a recovery key, you turn off Apple's standard account recovery process.
> 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.
“ If you use Advanced Data Protection and set up both a recovery key and a recovery contact, you can use either your recovery key or recovery contact to regain access to your account.”
Such a high risk of being locked out permanently is more than most people can stomach. Why can't they offer a last-resort option like showing up in person at an Apple Store with government-issued photo ID?
Interesting that using the recovery key stopped the issue for you, but does not seem to do its job now.
From the article "Ken said he enabled a recovery key for his account as instructed, but that it hasn’t stopped the unbidden system alerts from appearing on all of his devices every few days.
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. "
A password reset prompt is sent to the devices, but unfortunately the article leaves out that the prompt only enables you to reset the password on the device that receives the prompt. So it is not a security issue, just an annoyance.
It's not a recent approach, but this is a recent campaign using it against many people. Someone likely got a list of hacked passwords from some recent dump and is going through the apple accounts from it.
I ventured as much. Given the amount of messages and the personal details gathered, I also guess attacker tools have significantly been improved or streamlined.
But is it the case that the Yubikey is essentially treated the same as a trusted device? What if I want to untrust my devices and only trust ubikeys (without removing the device from my icloud account?)
Wow! You'd think they'd rate limit these! Once you've done it twice, go to once every 15 minutes, then hour, then 4 hours, than day, etc. Like bad logins.
Krebs notes that the recovery form does have some form of CAPTCHA on them, which mostly just goes to show that CAPTCHA systems are a poor and increasingly deficient rate limiter.
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.
That message is horribly designed if it allows a password reset to happen on any other device after you click allow. It specifically says "Use this iPhone to reset". I'd have assumed it asks the person who clicked allow to set a new password, on the same device they clicked allow.
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?
I don't think there's any danger in clicking "allow." There's still a 2FA step after that, and then you have to choose a new password. All of the danger comes from the phone call, where they presumably try to wheedle the 2FA code from you.
> That message is horribly designed if it allows a password reset to happen on any other device after you click allow
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.)
At some point the ability to trigger these prompts (or ones like them, like the Bluetooth-based setup new device prompts that were in the news last year) on Apple devices is itself the problem right?
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?
None, it's just that they haven't bothered adding a check for them. This isn't necessarily an indictment of them. It make sense in hindsight, but between sprints, OKRs/KPIs, and promotion packets, it's easy to let non-sexy functionality like these slip through the cracks.
It's distressing and sad that we've come to expect so little from the trillion-dollar market cap companies to which we are beholden to participate in modernity.
There is already a variant where they try to get someone to say „yes“ and just use a recording of it to use as „proof“ that you agreed to some contract.
I actually don’t answer unknown callers with “hello” or any words actually. I simply just say “mmmhhmm” or make a dumb sound if it is automated it will trigger the automatic message. Someone asked why and I said voice cloning software they said wtf you have nothing to steal. Just feels risky idk why.
You probably not going to get a voice clone from someone saying "hello?" 100 times. However, you don't really need to "MFA Bomb" people to clone their voice, just call them with a plausible sounding reason that will cause them to engage in an extended conversation (eg. "hey this is your uber/doordash driver/doctor/school/daycare).
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.
Recently I was baffled how far we've come with this. It doesn't work perfectly, but could be enough to fool someone. Just one pip install and a short voice sample away: https://github.com/coqui-ai/TTS
I am confused. What does happen after clicking allow? Does Apple just provide a password reset form to the person on the iForgot website or does it show up only on the device?
> he received a call on his iPhone that said it was from Apple Support (the number displayed was 1-800-275-2273, Apple’s real customer support line)
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.
It was in December 2020, so maybe? I can't remember. I had just incorporated an Inc. (and received seed funds, but those weren't publicly available or announced), so maybe some of that info was a trigger. But it was surprisingly well-timed, for sure. It was within three days of placing the order.
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.
The problem with adding rate limits, at least a global per user rate limit, is that you then create a new denial of service issue, preventing people from being able to recover their account.
If you’re getting DOSed by identical prompts you already can’t recover your account since you’ll likely hit the wrong prompt. There’s no protection here against an MFA fatigue attack attempt.
Why? You can rate limit the business logic but still show the user the default flow.
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.
You're telling me Facebook, with its billions of dollars and leetcode interviews, can't figure this out? That is outside the realm of computable functions?
it wouldn't be hard to add to the app though. obviously if you get a flood it's bullshit and more than a couple can be ignored. It's not rocket surgery
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.
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. "
https://support.apple.com/en-gb/HT213154
“ 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.
Deleted Comment
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.
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.