I'm unable to send emails from addresses created using "Hide My Email," so I have to use an alias instead. I also understand that it's possible for someone to log in using just the alias.
I posted my concern in post #72
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Warning: Apple Users Targeted in Phishing Attack Involving Rapid Password Reset Requests
- Thread starter MacRumors
- Start date
- Sort by reaction score
I'm unable to send emails from addresses created using "Hide My Email," so I have to use an alias instead. I also understand that it's possible for someone to log in using just the alias.
I posted my concern in post #72
If I understand correctly the attacker provides this victim's email/phone number on the official password reset site. After that the victim get the password reset approval popup on any trusted device. If the victim click allows, the attacker may continue the password reset process on the apple web site.
Is the above the correct procedure?
What happens when 2FA enabled?
Turning on the recovery key really helps? What if you have a trusted device, will a trusted device skip using the recovery key?
Is the above the correct procedure?
What happens when 2FA enabled?
Turning on the recovery key really helps? What if you have a trusted device, will a trusted device skip using the recovery key?
2FA doesn’t prevent the attack. Otherwise you could never reset your password if you have 2FA enabled.
Apple explicitly states that a recovery key turns off the standard account recovery process on their website. There should be no confusion about this.
It’s not an “encryption flaw”, it’s a side channel in the style of Meltdown and Spectre, which has plagued many recent CPUs and are difficult to completely prevent. Depending on the crypto software, it can allow other programs on the machine to statistically infer key material over time. Note that this will not work for device crypto, which is done on a different CPU, the Secure Enclave.
I wonder if this prompt is an attempt to get the 2FA via a phone call and sign into another device. Accessing your backup, passwords, etc. While using the bombardment to get you spooked.
They bombard the user with reset requests knowing that alone won't work. So the second stage of the attack is calling you and asking for the code. They might already know you password or have a list from a leak. They then try to use that code on a sign in request using one of the passwords they think might work. If that works, they now have a device with access to your data.
This also makes me question a typical Banks fraud department. An authorized charge gets flagged and denied. They then call the account holder and immediately ask to verify their information and if they approved the flagged charge or not... I've had this call several times and it given me a sense of security. Thinking back on it... If I saw a charge popup that got flagged. I'd expect a call within seconds from my bank and also expect to provide some form of verification immediately with little thought. A scammer could easily do a charge, see it was denied, and immediately call the number spoofing the bank. Act like they're the fraud department and immediately be given some form of answer to a question they can then turn around and use themselves.
"It is not clear how the attackers are abusing the system to send multiple messages to Apple users, but it appears to be a bug that is being exploited"
Does anyone know what bug/security flaw that's used?
Is this flaw patched in the latest 17.4.1 or 16.7.7 release?
I'm guessing now but SDP enabled should be able to create some sort of protection for end users. At least buys them some time if they click yes without thinking.
Does anyone know what bug/security flaw that's used?
Is this flaw patched in the latest 17.4.1 or 16.7.7 release?
I'm guessing now but SDP enabled should be able to create some sort of protection for end users. At least buys them some time if they click yes without thinking.
In that Krebs article it refers to the goal of the scammers, to remote wipe your device, this would be impossible for anyone to do if you don't have that feature enabled, correct?
Technology, 2FA, hardware keys etc. That's all a false sense of security. If you want TRUE security, get off the internet and go live off the grid.
We're constantly hearing about how great [insert new "security" feature/hardware] is and how it protects your data etc. Only for a few months or a few years later find out it was all a lie, it was hacked, the company themselves had access etc etc etc.
If you want something to be a secret, don't materialize it. Assume whatever you put out into the internet is going to be exposed in some way. Best you can do is be educated and prepared to quickly react to all your accounts being exposed in some massive leak. Have a contingency plan to recover and deal with the fallout.
Word of the day infallible
No entity, whether it's a company or a practice, can guarantee absolute infallibility when it comes to digital privacy and security.
We're constantly hearing about how great [insert new "security" feature/hardware] is and how it protects your data etc. Only for a few months or a few years later find out it was all a lie, it was hacked, the company themselves had access etc etc etc.
If you want something to be a secret, don't materialize it. Assume whatever you put out into the internet is going to be exposed in some way. Best you can do is be educated and prepared to quickly react to all your accounts being exposed in some massive leak. Have a contingency plan to recover and deal with the fallout.
Word of the day infallible
No entity, whether it's a company or a practice, can guarantee absolute infallibility when it comes to digital privacy and security.
Hope Apple can do something quickly for this issue.
Except in the Krebs article it details a user who has that recovery key enabled and is still getting these phishing attempts.
Going to the website that reported the issue it seems to me that to initiate a password recovery notification someone has to be at Apple's password recovery entering in email addresses and phone numbers. AI bots have been able to get around CAPTCHA for years thus all a hacker/phiser has to do is create a bot that will keep on entering email addresses and phone numbers into the password recovery webpage. What is not looking good for Apple is if hundreds of requests are being sent to people's iphone's how come nobody at Apple has picked it up that someone is entering multiple requests on it's webpage? Does it mean there is an Apple webpage/server admin not doing their job properly because these sort of webpage requests should have been stopped ages ago. Even if the hackers/phisers are using VPN's to hide their location, Apple can still go after the VPN's.
I therefore would not call this a bug, I would call this an Apple server admin falling asleep on the job and not picking up server logs that would have indicated multiple password recovery requests are being made and the admin did nothing about it.
I therefore would not call this a bug, I would call this an Apple server admin falling asleep on the job and not picking up server logs that would have indicated multiple password recovery requests are being made and the admin did nothing about it.
Unless whatever is allowing this to happen is outside of Apple. If this reset request is somehow being spoofed and then pushed to a device without going through whatever monitoring practice Apple has in place when actions are taken through their website/servers.
Only thing I would try is seeing if someone can send multiple reset request the legitimate way. If there is a limit already in place then they should reach it fairly quickly. Confirming if it's an issue on the website itself or if something worse is happening.
Edite::VPN issue. I was able to do it 4 times before the website stopped working. I was given a prompt "Action Could not be Completed"
So either that is Apple working the issue with a new placeholder, or the limit has always been 4 attempts in quick succession. Which would mean this bombardment being reported is outside of "conventional" means.
Last edited:
I got this for weeks and weeks, eventually called Apple about it and a very helpful tech there said they know about it but there isn't a lot they can do but you can stop it happening by getting a burner SIM card and just changing the account telephone number to the burner SIM number. If you never use that number for anything apart from this they no longer can scrape your number to initiate the reset process - instantly solved my problem, just keep the SIM somewhere safe in case you do ever need to reset your account.
Yeah, I just tried it and the alert is displayed, unfortunately. However, I sure hope that changing the password will be impossible without the recovery key - which is the whole point of it!
This is trivially avoidable as the key information which is used to identify you is your email address.
I never use my principal iCloud identity address as something which is publicly available or used on other sites. Therefore there is no way of discovering it to use this attack.
My configuration is:
1. I have a principal address which is almightykang@icloud.com (that is not it so don't even bother)
2. I have an iCloud+ custom domain set up as user@almightykang.com which is an alias of the above.
You can't do a reset from the custom domain and no one knows the principal address because it is never shared.
However Apple's MFA is broken here. There should be a rate limit of a maximum of 2-3 outstanding MFA requests with an exponential holdoff time.
Edit: I'm interested to see if anyone who is getting this shows up in this leak DB: https://haveibeenpwned.com/
I never use my principal iCloud identity address as something which is publicly available or used on other sites. Therefore there is no way of discovering it to use this attack.
My configuration is:
1. I have a principal address which is almightykang@icloud.com (that is not it so don't even bother)
2. I have an iCloud+ custom domain set up as user@almightykang.com which is an alias of the above.
You can't do a reset from the custom domain and no one knows the principal address because it is never shared.
However Apple's MFA is broken here. There should be a rate limit of a maximum of 2-3 outstanding MFA requests with an exponential holdoff time.
Edit: I'm interested to see if anyone who is getting this shows up in this leak DB: https://haveibeenpwned.com/
Last edited:
I think you'll find, that while they are excellent wrestlers, the Diminutive Orange Juice and the Encephalopathic Unicorn had nothing to do with this problem.
Yes but with their involvement we can expect more holes for hackers to exploit
You are wrong. The key is the phone number. In the krebsonsecurity Article the victim created a brand new apple id account with a new e-mail adress and immediately got the reset prompts. The only information linking the two accounts was the phone number.
Thats another reason to believe there is a bug on apples end that is exploited.
Holes don't have anything to do with this either. This is all working as designed by Apple. But if you'd rather talk about wrestling, that's fine too.
Does Apple allow 2FA vis 1Password one-time passwords or Google authenticator? It works extremely well with companies that support it as an authentication tool.
I find 2FA to be difficult because I use Apple IDs from multiple countries I’ve lived in and they don’t always come up on the device in use. I did start using my Google Voice number so I receive an email for many of my 2FA pings. My phone numbers change from country to country too and even with multiple sim support they are often set to roaming being turned off while a specific sim is abroad.
I find 2FA to be difficult because I use Apple IDs from multiple countries I’ve lived in and they don’t always come up on the device in use. I did start using my Google Voice number so I receive an email for many of my 2FA pings. My phone numbers change from country to country too and even with multiple sim support they are often set to roaming being turned off while a specific sim is abroad.
If that is the case then it would imply that the hackers have built their own password reset webpage by copying the webpage source code and all the javascript files off Apple's servers because the iphone will not display the recovery popup unless it see's genuine instruction code from Apple's servers. This would be why pressing 'Allow' is dangerous because it would return the user back to the website the hackers created to fill out the rest of the recovery process.
Again, Apple would know something is going on because server logs would show if someone is accessing the password recover page and saving all the necessary code and java script files associated with it, I believe the server logs would show something that has GET instructions/commands on them. That is why server admins are responsible for checking server logs daily so they can spot for any unusual activity happening on their servers.
This would not have gone unnoticed if someone at Apple was doing their job properly. Maybe a server admin did notice it and reported it to their boss but the boss dismissed it out of hand. Only Apple knows.
It could be either if that is the case.
Phone number is discoverable as well. Harder to hide!
I don't think the recovery key is needed and I don't think that's precisely the point of the recovery key.
The purpose of recovery key is to allow you to disable standard account recovery. Standard account recovery seems to include a number of ways to recover account in the event you lose all your devices. When you enable recovery key these routes are removed and you need either a trusted device OR your recovery key to recover an account (recovery key is now the only backup option in case you lose all your trusted devices). But recovery key doesn't protect you from account takeover in the event that someone has one of your trusted devices (with means to login to that device) or is able to trick you into acting on an approval request on a trusted device in your possession.
Note, I haven't systematically tested the above. This is just my take on the relevant support articles.
I'm not sure if it does, but even if it does I don't think it would help in this case. The issue in this case is I don't think you can disable a trusted Apple device from being a factor used to authenticate account ownership.
Last edited: