Brian Krebs (MacRumors, Hacker News):
Several Apple customers recently reported being targeted in elaborate phishing attacks that involve what appears to be a bug in Apple’s password reset feature. In this scenario, a target’s Apple devices are forced to display dozens of system-level prompts that prevent the devices from being used until the recipient responds “Allow” or “Don’t Allow” to each prompt. 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.
[…]
Some people confronted with such a deluge may eventually click “Allow” to the incessant password reset prompts — just so they can use their phone again. Others may inadvertently approve one of these prompts, which will also appear on a user’s Apple watch if they have one.
[…]
“I pick up the phone and I’m super suspicious,” Patel recalled. “So I ask them if they can verify some information about me, and after hearing some aggressive typing on his end he gives me all this information about me and it’s totally accurate.”
[…]
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.
I wonder why this isn’t rate limited.
Previously:
Bug iOS iOS 17 Passwords Phishing Two-Factor Authentication (2FA)
Cabel Sasser:
PSA: 1Password uses “1Password.co” for email links — instead of their usual “1Password.com” domain.
Craig Hockenberry:
So the “phishing link” with the .co domain was a valid link and documented as such.
But I still find it inexcusable.
That link caused 30 minutes of complete panic. I know enough about how phishing works to know how absolutely fucked I’d be if that link hadn’t just been to track my click in the email.
Which brings up another question: why is a company I pay to protect my private information using tracking links in the emails it sends me?
Cabel Sasser:
Craig isn’t an idiot; it 100% feels like phishing. If you ask me, tracking link clicks and opens in emails is simply not worth the potential freak-out when you think you’ve been phished[…]
Sam Schmitt:
Another way of looking at this: [it’s] best practice to use a different domain for stuff like this. If the marketing tool gets compromised, you don’t want it to have the ability to send actual phishing domains on the real domain. You’ll see it with other stuff, like Microsoft logins being on “microsoftonline.com”. I agree it does mean you do some double takes.
Hex Batch:
best practice is using subdomains and not cousin domains.
Troy Hunt:
What makes this situation so ridiculous is that while we’re all watching for scammers attempting to imitate legitimate organisations, FedEx is out there imitating scammers! Here we are in the era of burgeoning AI-driven scams that are becoming increasingly hard for humans to identify, and FedEx is like “here, hold my beer” as they one-up the scammers at their own game and do a perfect job of being completely indistinguishable from them.
Previously:
1Password E-mail Phishing Privacy
Ben Cohen:
Non-copyable generics aren’t for every-day code – but we’ve put a lot of care into making them stay out of your way until you need them, and then keeping them usable once you do. They will allow libraries to unlock more performance and safety for end users.
[…]
To help tie all these pieces together, I wrote up some code that uses all these proposals in order to build a basic singly-linked list type.
[…]
This is a struct that opts out of the default Copyable conformance via : ~Copyable. This allows it to have a deinit, like a class. This type uses no reference counting to know when to destroy the box. The type cannot be copied, so when it goes out of scope, the deinit is called by the compiler.
[…]
The generic placeholder Wrapped, which can stand in for the type of anything you want to put in the box, is also marked ~Copyable. This means that the Box type cannot make any copies of its wrapped type. […] What this ~Copyable annotation means is just that the Box type doesn’t know if the type it holds is copyable, which means it can safely hold both copyable and non-copyable types.
[…]
Sequence, and therefore for…in, does not yet support non-copyable types. Sequence could be made to support it today by marking the protocol up as ~Copyable and having makeIterator() be consuming. However this is probably not desirable. Mostly, you want iteration to be a borrowing operation. Accomplishing this needs more language features.
Previously:
Language Design Optimization Programming Swift Programming Language
