Apple disputes claims of iOS 'vulnerability' to brute force passcode hack

2

Comments

  • Reply 21 of 42
    mac_dogmac_dog Posts: 1,022member
    i'm not sure how this security protect citizens from governments that don't provide them the same protections as the U.S.  In many of those countries they can just torture you to get your pass code. No fancy equipment required. :)
    We’re getting there, don’t worry. /s
  • Reply 22 of 42
    dewmedewme Posts: 4,643member
    This is a lesson learned for me. The original article headline read:

    Simple hack bypasses iOS passcode entry limit, opens door to brute force hacks

    If the above article proves to be wrong then all of the sites that presented the original story as fact and without “claims” or some other similar caveat terminology have done a great disservice to their readership and Apple. 

    This is very unsettling to me and gives me pause about taking explosive headlines at face value. I originally felt that Apple had failed in their DfS approach but now I am more inclined to believe that the person making the assertion of such a serious security vulnerability without concrete proof is guilty of serious negligence and poor methodology and demonstrates a severe lack of credibility. 

    Who do we believe? 
    watto_cobra
  • Reply 23 of 42
    dewmedewme Posts: 4,643member
    so much for the folks on the other thread that decried, “Apple is getting lazy! Sloppy design!” etc. 
    You are technically correct. But those of us who deemed that Apple had flubbed did not realize the article in question was not to be believed. AI technically should have verified the veracity of the story but I doubt they have the staffing, resources, or discipline to do so and risk missing the news cycle. 
    watto_cobra
  • Reply 24 of 42
    mac_128mac_128 Posts: 3,454member
    dewme said:
    This is a lesson learned for me. The original article headline read:

    Simple hack bypasses iOS passcode entry limit, opens door to brute force hacks

    If the above article proves to be wrong then all of the sites that presented the original story as fact and without “claims” or some other similar caveat terminology have done a great disservice to their readership and Apple. 

    This is very unsettling to me and gives me pause about taking explosive headlines at face value. I originally felt that Apple had failed in their DfS approach but now I am more inclined to believe that the person making the assertion of such a serious security vulnerability without concrete proof is guilty of serious negligence and poor methodology and demonstrates a severe lack of credibility. 

    Who do we believe? 
    Yes, AI evidently fell into the worst trap imaginable for a new service. I re-read the article, and never once does AI use the words: allegedly, may, might, could, appears, etc. To state the story as fact, and the claims as incontrovertible, without anything more than the guys word, and video demonstration. A simple “weasel” word would have saved them. That’s the definition of fake news. Mistakes do happen in reporting,  but a news site should be limited to typos, or sources who conspire to manipulate them. A story like this should not rely on a sole claim as fact, without qualifying it, thus validating the source claim without review. MacRumors made the same mistake, so AI is in the same company.
    edited June 2018 anantksundaramwatto_cobra
  • Reply 25 of 42
    charlitunacharlituna Posts: 7,217member
    backstab said:
    Kind of confusing. Is Apple suggesting that the guy is lying? Or was he, in fact, able to break into the phone; or not?
    Which is it?
    in regards to the notion that he found a bug etc, there was no suggestion. they flat out said he was lying. they just said it very politely. 
    muthuk_vanalingamwatto_cobra
  • Reply 26 of 42
    dewmedewme Posts: 4,643member
    mac_128 said:
    dewme said:
    This is a lesson learned for me. The original article headline read:

    Simple hack bypasses iOS passcode entry limit, opens door to brute force hacks

    If the above article proves to be wrong then all of the sites that presented the original story as fact and without “claims” or some other similar caveat terminology have done a great disservice to their readership and Apple. 

    This is very unsettling to me and gives me pause about taking explosive headlines at face value. I originally felt that Apple had failed in their DfS approach but now I am more inclined to believe that the person making the assertion of such a serious security vulnerability without concrete proof is guilty of serious negligence and poor methodology and demonstrates a severe lack of credibility. 

    Who do we believe? 
    Yes, AI evidently fell into the worst trap imaginable for a new service. I re-read the article, and never once does AI use the words: allegedly, may, might, could, appears, etc. To state the story as fact, and the claims as incontrovertible, without anything more than the guys word, and video demonstration. A simple “weasel” word would have saved them. That’s the definition of fake news. Mistakes do happen in reporting,  but a news site should be limited to typos, or sources who conspire to manipulate them. A story like this should not rely on a sole claim as fact, without qualifying it, thus validating the source claim without review. MacRumors made the same mistake, so AI is in the same company.
    Too harsh. It’s a gray area. AppleInsider plays an important role in helping Apple enthusiasts stay connected with all things Apple. They are doing their best to keep the information flowing and whetting our insatiable appetite for inside information about our favorite company. They are not a vetting authority for information obtained from other sources and passed along for our consumption.

    Sure, for articles, topics, and stories that do originate within AI they should be held to a higher standard by AI staffers. AI could add caveats to all non-AI sourced content but doing so would quickly fade into background noise by constantly repeating the same set of stock disclaimers. The learning aspect for me was the realization that information passed along from other sources through AI has to be vetted at the source/originator, not the intermediate messenger, despite the article headline.

    The potential failure in this case occurred at the source with the security researcher who made a claim against Apple with insufficient verification and validation of his discovery/hypothesis. 


    Solimuthuk_vanalingamwatto_cobra
  • Reply 27 of 42
    flydogflydog Posts: 1,097member
    backstab said:
    Kind of confusing. Is Apple suggesting that the guy is lying? Or was he, in fact, able to break into the phone; or not?
    Which is it?
    "The recent report about a passcode bypass on iPhone was in error, and a result of incorrect testing," Apple said.
    watto_cobra
  • Reply 28 of 42
    rob53rob53 Posts: 3,090member
    Will a developer or security professional explain how you can send text through a lightning connector? I know data can be written and read through this port because iTunes does it when backing up an iPhone. What does it take for a peripheral to take over a locked iPhone? Typically, iTunes requires the unlock code to be entered before backing up. Just trying to get a technical understanding on the plausibility of this attempted hack. Be specific and show examples so all of us are more educated. Thanks
    Soliwatto_cobra
  • Reply 29 of 42
    Rayz2016Rayz2016 Posts: 6,957member
    dewme said:
    This is a lesson learned for me. The original article headline read:

    Simple hack bypasses iOS passcode entry limit, opens door to brute force hacks

    If the above article proves to be wrong then all of the sites that presented the original story as fact and without “claims” or some other similar caveat terminology have done a great disservice to their readership and Apple. 

    This is very unsettling to me and gives me pause about taking explosive headlines at face value. I originally felt that Apple had failed in their DfS approach but now I am more inclined to believe that the person making the assertion of such a serious security vulnerability without concrete proof is guilty of serious negligence and poor methodology and demonstrates a severe lack of credibility. 

    Who do we believe? 

    Well, first of all, you need to remember that AI isn't a news site; it's a news aggregator site. They basically pull stories from other sources and stick them here. So do not take anything they say at face value without checking the original source first. As we have seen in the past, they do interpret what they have read incorrectly through misunderstanding the technicalities of what they've read, or their own particular bias.

    Who do we believe? Well I tend to veer towards sites with more technical chops, such as ArsTechnica, but even they get it wrong. In this case, I simply waited to hear what Apple had to say before commenting. 

    Yes, the headline turned out to be incorrect because the researcher didn't have his work reviewed, but AI did point out that the hack opened  a door to brute force attacks; they did not say that this method in itself compromised the phone. So the first part of the headline was wrong, the second part was correct.

    edited June 2018 muthuk_vanalingamwatto_cobra
  • Reply 30 of 42
    Rayz2016Rayz2016 Posts: 6,957member

    backstab said:
    Kind of confusing. Is Apple suggesting that the guy is lying? Or was he, in fact, able to break into the phone; or not?
    Which is it?
    in regards to the notion that he found a bug etc, there was no suggestion. they flat out said he was lying. they just said it very politely. 

    They didn't say he was lying; they said he got it wrong. 

    When you say something you know not to be true, then that's lying.

    He said something he believed to be true: he made a mistake. An amateurish mistake, but a mistake nonetheless.

    Apple will not falsely accuse him of lying because, quite rightly, they do not want to be in a situation where hackers are afraid of submitting vulnerability reports in case they're lambasted by the company and its followers if/when they get it wrong. In this situation, Apple's response was measured and correct.

    Anyway, the bloke corrected his original findings as soon as Apple contacted him. 
    edited June 2018 muthuk_vanalingamwatto_cobra
  • Reply 31 of 42
    Rayz2016Rayz2016 Posts: 6,957member
    entropys said:
    No he wasn’t lying. He was just trashing his credibility.  
    Let this be a lesson to you all, folks. If conducting experiments, make sure you test your results and conclusions, including by a critical peer, not your mates at the next university.  And don’t ever rush to the social media sewer with untested results and conclusions.

    This.

    foggyhill said:

    The best thing is to test you are actually testing what you think you are testing. 

    Getting result X means nothing if you don't even know what you actually tested.

    For example,
    If you give poison to a test subject, make sure they actually swallowed it before declaring it can't kill the subject  (in this case it is "kill it" :-), but the principle is the same).

    And  of course, this.

    Now that sites are so obsessed with chasing page views, time taken for proper verification has gone out the window. I hope this trend isn't spreading to scientific research.

    Look at Theranos.

    https://www.theguardian.com/commentisfree/2018/jun/03/theranos-elizabeth-holmes-media-emperors-new-startup

    The tech press should have realised on day one that this woman was selling snake oil.

    Why didn't they? Simple. She used  the terms 'disruption' and 'iPod of healthcare' in her brochure and wore black turtlenecks to interviews. That's all it took.
    watto_cobra
  • Reply 32 of 42
    this should be relatively easy to test

    parts list
    IBM PC AT or compatible w/ 16550 Uarts
    a copy of procomm plus 2.42
    Serial To HID Keyboard Converter Cable ($99 - HIDMDB9USBA-3E )
    usb gender changer ( F to F )
    usb to lightning cable 

    you don't want to use a modern desktop pc , because you want to be retro
    going off the usb port probably be like software emulation of a serial port etc , you want to be as pure as possible 

    wikipedia says that a ps/2 keyboard operates between 7 to 12kbps , so 9600 should be okay



    the 16550 uart is mandatory , if you use an older computer with a 8 bit uart, you might have problems sending/ receiving at 9600 baud
    going over 9600 on an older uart might drop characters 

    9600 baud is the fastest that this particular cable will support. you might be able to find that is 128k bps or better yet parallel but i wouldnt know how off hand to send characters down the printer port

    so what you do is when you load up procomm  and whatever DOS you have, and you either upload an ascii file of 0000 to 9999 to the adapter using 9600 N 8 1 to the iPhone with 4 digit pin numbers, and if this person's claim is true, then you should be able to replicate his claim. you could also use any number of terminate and stay resident programs or word processors  to make your own keyboard macros as well. 

    i believe a keyboard macro would be faster then sending an ascii file. 


    something else to test

    if this persons claim that a keystrokes cause the iPhone to stop doing all over tasks is true. then holding down a key on an external keyboard should also cause the iPhone to completely STOP what its doing. because thats how it was on the ibm clones. 

    back in the old days we had 8 interrupts max. when the pc at came out we had 16 , we now have 255 ??? i highly doubt the iPhone has a low number of interrupts. 


    regardless if you send it 10000 keystrokes all at once , or hold one key down for infinity, if the persons claim is true about interrupts , then the iPhone should come to a complete stop and not do any other tasks at all

    edited June 2018 watto_cobra
  • Reply 33 of 42
    Rayz2016Rayz2016 Posts: 6,957member
    backstab said:

    Rayz2016 said:
    backstab said:
    Kind of confusing. Is Apple suggesting that the guy is lying? Or was he, in fact, able to break into the phone; or not?
    Which is it?

    My apologies. I didn't actually answer your second question.

    In a word, no.

    No article I've read (including the one here), has said that he actually broken into the phone. What he has done is demonstrate that the iOS's data erasure function can be bypassed, which could, in theory, lead to the development of an exploit that could be used to break into the phone. If you can stop the phone from erasing itself then you have more chances to break into it.

    Unfortunately, this may not be the case because the reason the experimental phone did not erase itself is because it had not, as he first believed, received the ten password tries that triggers the function.



    Thank you. That actually does answer my question.
    I'm still seeing 'newly published' headlines on this subject that make it sound like, indeed, the iPhone "has been hacked" with this method.
    ...infuriating.
    No, even if his method was correct, he had not managed to weaponise the exploit to break into the phone. So what thought he found was a vulnerability: a possible attack vector. 

    That is what the vast majority of these exploits turn out to be.
    watto_cobra
  • Reply 34 of 42
    Rayz2016Rayz2016 Posts: 6,957member

    backstab said:
    tmay said:
    backstab said:
    Kind of confusing. Is Apple suggesting that the guy is lying? Or was he, in fact, able to break into the phone; or not?
    Which is it?
    From the article, my reading comprehension has that the guy isn't lying, just that the result "was in error, and a result of incorrect testing" according to Apple. The fact that the initial findings havn't been able to be replicated or validated by a third party indicates that Apple appears to be correct.
    Then I just don't understand whet the "result" was. I had thought the "result" was that this guy had, indeed, brute-forced his way into an iPhone with this method (?)

    The 'result' he thought he had was that on the 11th password attempt the phone did not erase itself. What actually happened was that he only sent four passwords. 

    He never said that on the 11th attempt he gained access to the phone. If that had happened then he would've hacked the phone.

    Now that they know what he was trying to do, my guess is that Apple ran the same experiment again, but actually made sure that eleven passwords are tested by the security algorithm.  

    But!

    One should bear in mind that this is a good reason why a four number passcode is something that should be avoided. 

    I'd also like to highlight @Soli's idea about allowing emojis to be used as password characters. I've noticed a few people online have tried this on MacOS and managed to lock themselves out of their system. I think Apple should support the use of emojis as password characters. 

    If this ever does come to pass, then please don't use any length variation of

    💩💩💩💩

    as a password, because that is the emoji equivalent of using 'passw0rd' as your password. It's the first thing a hacking algorithm will try out.

    edited June 2018 muthuk_vanalingamwatto_cobra
  • Reply 35 of 42
    Rayz2016Rayz2016 Posts: 6,957member
    Another good reason for allowing emoji passwords: it'll stop banks doing insecure checks like asking for the second and fourth character of your code:

    "Yes, it's a long distance runner followed by a pile of sh*t."

    (No points will be given for a Paula Radcliffe joke or comments about this guy: https://metro.co.uk/2018/05/17/neighbour-catches-jogger-that-keeps-leaving-dirty-surprises-outside-his-house-7554405/).
    edited June 2018 welshdog
  • Reply 36 of 42
    welshdogwelshdog Posts: 1,855member
    Rayz2016 said:
    Another good reason for allowing emoji passwords: it'll stop banks doing insecure checks like asking for the second and fourth character of your code:

    "Yes, it's a long distance runner followed by a pile of sh*t."
    How would that work? Does an emoji appear to the OS as just a string of numbers, or is it something else? Seems like a great idea as long as emojis themselves don't have (or open up) some sort of unexpected vulnerability.
    watto_cobra
  • Reply 37 of 42
    SoliSoli Posts: 10,033member
    welshdog said:
    Rayz2016 said:
    Another good reason for allowing emoji passwords: it'll stop banks doing insecure checks like asking for the second and fourth character of your code:

    "Yes, it's a long distance runner followed by a pile of sh*t."
    How would that work? Does an emoji appear to the OS as just a string of numbers, or is it something else? Seems like a great idea as long as emojis themselves don't have (or open up) some sort of unexpected vulnerability.
    They are Unicode characters just like all the other characters we use today. For Apple to implement this in their OSes would be a cakewalk, but there are potenial pitfalls.

    One universal issue is that some characters look very similar. Sure, the same can be applied to letters, numbers, and punctuation, but the detail of certain faces in pictograms, for example, could lead to confusion. The solution is to exclude any that are too close in appearance.*

    The other issue is more of when this moves to websites, which means being cross platform. These pictpgrams are designed indeprently by the OS and device vendors. While the hamburger emoji may not be confusing despite looking radically different across platforms, others might. Specifically certain faces.

    What if you only used Windows and Android and had the gun emoji in your passcode? Could anyone reasonably jump onto an Apple device and realize they need to use the toy gun? I think that’s well known on Apple forums, and you could probably search by name to find what you're looking for, but that may have to be excluded if it’s not deemed universal enough in appearance and having to search for a character does reduce efficiency.

    The bottom line is that additional characters adds to the complexity of the passcode so even a few dozen emoji—not all 800-ish—is  a huge boon for security.


    * Right now in iOS and macOS you can create a passcode with a hyphen (-), en dash (–), or em dash (—). Visually they are close in appearance if you aren't looking at them side-by-side. Not a huge deal for an OS passcode, but if you were to make that an option for a website that could be a problem if you have to read it back, especially how different fonts can affect how these look. Because of that, I'd also remove all but the hyphen when it came to the passcode and make the use of the other two default to the hyphen automatically. I think many emoji would fall into that category, like the "confused face" 😕 (Unicode: U+1F615) v "slightly frowning face" 🙁 (Unicode: U+1F641) to name but two of many, many possibilities.
    edited June 2018 welshdogRayz2016
  • Reply 38 of 42
    welshdogwelshdog Posts: 1,855member
    Thanks Soli.
    Soliwatto_cobra
  • Reply 39 of 42
    Captain MidnightCaptain Midnight Posts: 1unconfirmed, member
    Jesus, I already told you how they do it. The copy the encrypted ROM from the phone they are trying to hack and flash it onto a new emulated chip. Try 10 pass codes and re flash the chip and try another 10. As long as they only allow 6 digit pass codes , most codes will take a couple hours to 3 days max to crack.
  • Reply 40 of 42
    tallest skiltallest skil Posts: 43,388member
    As long as they only allow 6 digit pass codes
    Good thing they’ve had alphanumeric for nearly a decade, then.
    Soliwatto_cobra
Sign In or Register to comment.