Update: Apple has provided me with the following statement, which should close the door on speculation surrounding this purported exploit:
"The recent report about a passcode bypass on iPhone was in error, and a result of incorrect testing"
Yesterday, a security researcher reported on a possible brute-force passcode attack that affected iPhone and iPad. The researcher seems to have disclosed the discovery to Apple, though it's unclear whether he waited for Apple to confirm and fix it — or refute it — before going public.
ZDNet summed it up this way:
An attacker can send all the passcodes in one go by enumerating each code from 0000 to 9999 in one string with no spaces. Because this doesn't give the software any breaks, the keyboard input routine takes priority over the device's data-erasing feature, he explained. That means the attack works only after the device is booted up, said Hickey, because there are more routines running.
When stories come out about "hackers" and Apple getting "black eyes", it should give us all pause. Security is seldom simple and sensationalism is ultimately a attention-exploit, even and especially when it's used to report on vulnerabilities.
In this specific case, it looks like the pause was well warranted. Turns out, the "hack" might not have been what it first seemed.
The original reseacher, on Twitter:
It seems @i0n1c maybe right, the pins don't always goto the SEP in some instances (due to pocket dialing / overly fast inputs) so although it "looks" like pins are being tested they aren't always sent and so they don't count, the devices register less counts than visible @AppleIt seems @i0n1c maybe right, the pins don't always goto the SEP in some instances (due to pocket dialing / overly fast inputs) so although it "looks" like pins are being tested they aren't always sent and so they don't count, the devices register less counts than visible @Apple— Hacker Fantastic (@hackerfantastic) June 23, 2018June 23, 2018
In other words, iOS might have been treating the no-space strings as single attempts rather than serial attempts, and thus not counting them towards the usual brute force mitigations (including forced delays and device deletion, if enabled.)
And because they're being treated that way, they may not have any advantage over single string attempts anyway.
Long story slightly less long: It's still being looked into by the original researcher, others in the information security space, and no doubt Apple as well.
Right now, as far as I can tell, no one has been able to reproduce it, internally or externally, but we'll have to wait and see what the actual facts are when everything has been tested and all the infosec dust has settled.
In the meantime, stay informed but don't let anyone make you afraid.
