その後の報道によると、Appleはこの攻撃を防ぐことはできなかった、ようで 現時点では http://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_Rece... [apple.com] の My app performs validation by connecting to the App Store server directly. How am I affected? に書かれているような方法で対処しなさい、ということみたいですね。 つまりiOS6より前では攻撃の穴は塞がれていないが、対処方法はある、ということでしょう。 で、iOS6ではDNSの偽装に対応する、つまり完全に穴を塞ぐとしているようです。
If your app connects to the App Store server directly from the device, your app may be affected by this vulnerability. You can address this vulnerability as follows: ・Check that the SSL certificate used to connect to the App Store server is an EV certificate. ・Check that the information returned from validation matches the information in the SKPayment object. ・Check that the receipt has a valid signature. ・Check that new transactions have a unique transaction ID.
しかし、なんだ、書き換えたら公開するまで Apple の審査工程があるわけだが、審査が通るまでの数週間。 その間はアプリ開発者から見たら取られ損って事? # Apple の課金サーバを経由していないと言うことは購買履歴が分からないって事かな。 # あ、App Store からダウンロードされたと言う事実を追いかければ良いのか。
iOS 6では"完全"に修正? (スコア:0)
つまり、それ以前のバージョンには、まだ穴があるってこと?
Re:iOS 6では"完全"に修正? (スコア:5, 参考になる)
よくわからない流れになってるみたいですけど、iOSとは縁がないものの
興味があったのでちょこっと調べた感じだと
攻撃の方法はDNSのレコードを変更してAppStoreのサーバーに対する
リクエストを偽装サーバーにリダイレクトし、偽装サーバーがAppStoreのサーバーの
エミュレーションを行うことで支払ったかのように見せることができる、というものの
ようですね。
その後の報道によると、Appleはこの攻撃を防ぐことはできなかった、ようで
現時点では
http://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_Rece... [apple.com]
の
My app performs validation by connecting to the App Store server directly. How am I affected?
に書かれているような方法で対処しなさい、ということみたいですね。
つまりiOS6より前では攻撃の穴は塞がれていないが、対処方法はある、ということでしょう。
で、iOS6ではDNSの偽装に対応する、つまり完全に穴を塞ぐとしているようです。
本件のたれこみは
>この問題はすでに修正され
とありますが、それはざっと調べた限り見当たらず、ZDnetの記事などを見ると攻撃を防ぐことは
できなかった、とあります。うーん。探し方が足らないのかな?
いずれにしてもアプリケーション側で対処する必要があるということなんで、書き換えが必要なアプリ
があるみたいですけどね~。
Re:iOS 6では"完全"に修正? (スコア:2)
AppとAppStoreがどんなプロトコルで通信しているのか知りませんが
httpsのようにリクエスト先が正しいか確認する仕組みは無いのでしょうか。
Re:iOS 6では"完全"に修正? (スコア:1)
一応HTTP系っぽいです。
HTTPS使ってたけどライブラリ/APIではロクに検証してなかったか、この件を受けてHTTPからHTTPSに切り替えたのかは知りませんが、今回はそのチェックをアプリ側でやってくれれば対策になるって話のようです。
(#2199150) [srad.jp]が紹介している公式の対策を見ると
If your app connects to the App Store server directly from the device, your app may be affected by this vulnerability. You can address this vulnerability as follows:
・Check that the SSL certificate used to connect to the App Store server is an EV certificate.
・Check that the information returned from validation matches the information in the SKPayment object.
・Check that the receipt has a valid signature.
・Check that new transactions have a unique transaction ID.
・SSLのEV証明書でつながってることを検証しろ。(後述されているが非公開APIをこの用途限定で使えとの突貫対応)
・得られた購買情報が要求と矛盾していないか確認しろ。(SDKでは確認していない?)
・署名が有効か確認しろ。(SDKでは確認していない?)
・トランザクションIDがユニークか確認しろ。(複数回検証しろということか?)
ということで、これらの対策を行った課金チェックAPIのラッパーが提供されています。
この対策と攻撃の大雑把な解説記事を読む限り
・HTTPで購入情報の取得をしてしまうケースがあったか、ライブラリ/APIではHTTPSの証明書を検証していなかった(または回避可能だった)。
・多くのアプリ開発者の実装では、購買情報のBool値しか読んでおらず、ライブラリ/APIもそれを検証していなかった(または回避可能だった)。
・購買情報自体にも署名がついているらしいが、ライブラリ/APIはそれも検証していなかった(または回避可能だった)。
・今回の攻撃では何らかの理由でトランザクションIDが固定だった。
という状況のようです。
検証項目から察するに、今回の攻撃では「素のHTTP」または「異常なHTTPS」で検証接続を行わせて、「購買情報の署名が間違っている偽造購入情報」または「別のアプリ・利用者の購買情報」を食わせることで、それらの検証をおこなっていないアプリの課金情報を突破していた、ということになりそうです。
これらのチェックをライブラリ/APIではやっていなかったのか、それを突破可能なバグがあったのか…
検証していなかった、の方だとするとお粗末すぎますね。
Re: (スコア:0)
それをごまかすために証明書をインストールするんです。認証局証明書としてインストールされてしまったら(何らかのハードコードをしない限り)もう正規のものと区別は不可能です。
Re: (スコア:0)
> いずれにしてもアプリケーション側で対処する必要があるということなんで、書き換えが必要なアプリがあるみたいですけどね~。
しかし、なんだ、書き換えたら公開するまで Apple の審査工程があるわけだが、審査が通るまでの数週間。
その間はアプリ開発者から見たら取られ損って事?
# Apple の課金サーバを経由していないと言うことは購買履歴が分からないって事かな。
# あ、App Store からダウンロードされたと言う事実を追いかければ良いのか。
取られ損だった場合、公開を停止するって手もあるけど、その他大勢のお客さんを逃すことになるから、痛し痒しか。
Apple はどのような補償をしてくれるのかが問題。
Re: (スコア:0)
公開停止したってアプリ内課金は止められないのでは。
Re: (スコア:0)
> 攻撃の方法はDNSのレコードを変更してAppStoreのサーバーに対する
> リクエストを偽装サーバーにリダイレクトし、偽装サーバーがAppStoreのサーバーの
> エミュレーションを行うことで
なんだか、数年前のMO/MMOの後付けプロテクション機構の
ハックを見ているかのようだ。
そのときプロテクション機構側がとった対策はFQDN以外に
IPアドレスも埋め込んで、DNS問い合わせせずアクセスする
手段を用意したという。
それもnext hop書き換えてインターネットへ出て行かないように
してしまえば無意味という間抜けな結果になっていたと思うが、
さてAppleはどう対応してくるのやら。
DNSSECに対応していないDNSサーバはiOS6で使えません、とか
斜め上に行ってくれたら面白いのだけど。