パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

iOSのアプリ内課金における課金回避ハック、Mac向けアプリでも同種の穴が見つかる」記事へのコメント

  • つまり、それ以前のバージョンには、まだ穴があるってこと?

    • by epgrec (43527) on 2012年07月24日 18時28分 (#2199272)

      よくわからない流れになってるみたいですけど、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の記事などを見ると攻撃を防ぐことは
      できなかった、とあります。うーん。探し方が足らないのかな?

      いずれにしてもアプリケーション側で対処する必要があるということなんで、書き換えが必要なアプリ
      があるみたいですけどね~。

      親コメント
      • AppとAppStoreがどんなプロトコルで通信しているのか知りませんが
        httpsのようにリクエスト先が正しいか確認する仕組みは無いのでしょうか。

        親コメント
        • 一応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ではやっていなかったのか、それを突破可能なバグがあったのか…

          検証していなかった、の方だとするとお粗末すぎますね。

          親コメント
        • by Anonymous Coward

          それをごまかすために証明書をインストールするんです。認証局証明書としてインストールされてしまったら(何らかのハードコードをしない限り)もう正規のものと区別は不可能です。

      • by Anonymous Coward

        > いずれにしてもアプリケーション側で対処する必要があるということなんで、書き換えが必要なアプリがあるみたいですけどね~。

        しかし、なんだ、書き換えたら公開するまで Apple の審査工程があるわけだが、審査が通るまでの数週間。
        その間はアプリ開発者から見たら取られ損って事?
        # Apple の課金サーバを経由していないと言うことは購買履歴が分からないって事かな。
        # あ、App Store からダウンロードされたと言う事実を追いかければ良いのか。

        取られ損だった場合、公開を停止するって手もあるけど、その他大勢のお客さんを逃すことになるから、痛し痒しか。

        Apple はどのような補償をしてくれるのかが問題。

        • by Anonymous Coward

          公開停止したってアプリ内課金は止められないのでは。

      • by Anonymous Coward

        > 攻撃の方法はDNSのレコードを変更してAppStoreのサーバーに対する
        > リクエストを偽装サーバーにリダイレクトし、偽装サーバーがAppStoreのサーバーの
        > エミュレーションを行うことで

        なんだか、数年前のMO/MMOの後付けプロテクション機構の
        ハックを見ているかのようだ。

        そのときプロテクション機構側がとった対策はFQDN以外に
        IPアドレスも埋め込んで、DNS問い合わせせずアクセスする
        手段を用意したという。

        それもnext hop書き換えてインターネットへ出て行かないように
        してしまえば無意味という間抜けな結果になっていたと思うが、
        さてAppleはどう対応してくるのやら。

        DNSSECに対応していないDNSサーバはiOS6で使えません、とか
        斜め上に行ってくれたら面白いのだけど。

計算機科学者とは、壊れていないものを修理する人々のことである

処理中...