Security researcher, Ibrahim Balic, reported that informed Apple six months before the massive security breach, and informed of a ”brute-force” method that allowed him access to any iCloud account

Fig. 8.2.4/2

Balic also reported the vulnerability through Apple’s online bug submission

Fig. 8.2.4/3

In an email dated May 6, 2014, the reported vulnerability apparently remains unfixed, as an Apple official continues to question Balic over the details of his discovery

Fig. 8.2.4/4

Apple CEO Tim Cook said his company should have done more to alert his customers of security issues

"When I step back from this terrible scenario that happened and say what more could we have done, I think about the awareness piece,” he told the Wall Street Journal. ”I think we have a responsibility to ratchet that up. Thats not really an engineering thing."

Let’s take closer look at the attack which could enabled the leak to happen

• after the incident Hackers realized the proof of concept code
• the code is written in Python and posted on the github.com
• the vulnerability was based on Find My iPhone service API, where apparently the brute-force protection was not implemented (simply it was badly design protocol)
• it suffice to sent a proper packet that it fake iPhone and we could test unlimited number of passwords

Brute Force Attack

• Brute-force attack that can, in theory, be used against any passwords
• The resources required for such attack grow exponentially with password’s size
• Since people mostly using combination of words and digits for their password, the so-called dictionary attack could be performed
• Dictionary attack successively trying all the words in the list called dictionary
• In contrast with a brute-force attack, where all password space is searched, a dictionary attack tries only those passwords that are most likely to occur
• Attackers usually obtain user names of the system and then trying to repeatedly guess passwords in an attempt to discover the correct one
• Notice that it suffice that even one user has weak password and access to the system could be obtain

Brute Force Attack - Countermeasures

• In case of an offline attack, an attacker can try as many password as needed without the risk of discovery
• However, in case of an online attack administrators can take countermeasures for example limiting the number of attempt that a password can be tried
• Apple failed to implement such countermeasures in Find My iPhone API service

Analysis of the code

Fragment of the written in Python posted on the github.com which enabled brute force attack on the iCloud

Fig. 8.2.4/5: id brute.py

• At the beginning of the code the headers of the HTTP request are prepared for forgery
• User-Agent header (specified by HTTP/1.1 Semantics and Content) is changed such that the connection will be identified by iCloud as from iPhone (Apple mobile device)
• Basically further fields are taken from genuine iPhone, which could be easily obtain by programs either WireShark or tcpdump
• Since deviceUDID identify exactly which iPhone device is connected, hackers changed it to a random number (Apple doesn’t check if the number is legit!)
• Then the Authorization field was added (coded in standard base64 encoding)
  
  Now the Brute-Force attack is possible
• We can repeatedly execute the TryPass function with arguments
  • apple id - username account id (i.e. email address)
  • password - taken from dictionary or otherwise generated

To make the system less vulnerable Apple

• Should improved Customer Support
• Should eliminate common vulnerabilities in their protocols
• Improved user identification by introducing two-step authentication

For customers

• It is better to do not trust public cloud storage with sensitive data