Slashdot Mirror


iMessage Bug Allows Attackers to Decrypt Photos and Videos

Researchers at John Hopkins University have found a bug in the instant messaging client iMessage which, if exploited, could allow an attacker to decrypt photos and videos sent as secured messages. "Even Apple, with all their skills -- and they have terrific cryptographers -- wasn't able to quite get this right," said Matthew D. Green, whose team of graduate students at the aforementioned university found the bug. "So it scares me that we're having this conversation about adding back doors to encryption when we can't even get basic encryption right." Apple acknowledged the bug to The Washington Post, adding that it had "partially" fixed the glitch with iOS 9 software update last year. The company assures that it will be offering a complete patch for the bug with iOS 9.3, which will be released on Monday.

5 of 27 comments (clear)

  1. Re: Tim Cook by UnknowingFool · · Score: 4, Interesting

    Except that Apple deprecated OpenSSL in favor of open source CDSA in their own OS 3 years before HeartBleed was found. Also, Apple using standards is something you are against?

    --
    Well, there's spam egg sausage and spam, that's not got much spam in it.
  2. Re:all devices, software, networks, etc. by AchilleTalon · · Score: 2

    But all bugs are not born equal.

    --
    Achille Talon
    Hop!
  3. Re:So what was the actual flaw? by Anonymous Coward · · Score: 4, Interesting

    Came here to post this. I am sick of articles on encryption that talk "about" the flaw, instead of saying what it actually was. This is a tech site, so articles that say "Using high-speed computing, researchers were able to do some scary math and break the encryption." If it doesn't link to CERT, or say "A timing attack was used to guess digits of the key" then it doesn't belong on Slashdot.

    That said, here is a guess, based on the limited information in the article:

    To intercept a file, the researchers wrote software to mimic an Apple server. The encrypted transmission they targeted contained a link to the photo stored in Apple’s iCloud server as well as a 64-digit key to decrypt the photo.

    So they got the network traffic, but without Apple's private keys all they could do is see the encrypted data. 64 hex digits = 256 bits. The whole part about mimicking an Apple server us unclear. It sounds like they did a MITM, which shouldn't be possible if Apple is checking the certificates. But if the MITM was successful, why didn't they get the key? No matter...

    Although the students could not see the key’s digits, they guessed at them by a repetitive process of changing a digit or a letter in the key and sending it back to the target phone. Each time they guessed a digit correctly, the phone accepted it. They probed the phone in this way thousands of times.

    So they used a timing attack against the phone to guess at the key, by changing one hex digit (or maybe one bit) at a time. Timing attacks are known to work this way, and many crypto libraries randomize the time it takes to decrypt to fix this.

    To prevent the attack from working, users should update their devices to iOS 9.3.

    So the bug is already known and fixed. I wonder if the fix was the certs to prevent the MITM, or the fix to the timing attack, or both.

  4. Re: Oh sure by UnknowingFool · · Score: 3, Insightful

    Well if you read the article, the method of attack requires thousands of messages to be sent and the researchers stated it would require the resources of a nation state to implement. So for the average person, it is reasonably safe from hackers and criminals.

    --
    Well, there's spam egg sausage and spam, that's not got much spam in it.
  5. sounds like a padding oracle ala POODLE by raymorris · · Score: 2

    One byte at a time and see if the other end "accepts" it sounds like a padding oracle attack. Those are in vogue now also.

    The padding oracle works with cbc ciphers where there is a padding check before the actual decryption. You change on byte and see whether you get a padding error. If the byte is correct, you don't get the padding error. When you've found one byte, move on to the next byte.