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

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

  • by Anonymous Coward on 2012年07月24日 13時43分 (#2199071)

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

    • 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で使えません、とか
        斜め上に行ってくれたら面白いのだけど。

    • by Anonymous Coward

      そもそも「修正」にはアプリ側の対応も必要みたいなんだけどそれを書かないってどうなの? >タレ

      • by Anonymous Coward

        俺は塩が好きだな。

      • by Anonymous Coward

        >そもそも「修正」にはアプリ側の対応も必要みたいなんだけどそれを書かないってどうなの? >タレ

        課金・決済機能はOSやミドルウェアの話であって、アプリはそれに乗ってるだけです。
        あまつさえAppleはApple自身の課金プラットフォームを使うよう独裁を振るっていますしね。

        なので、
        「決済・課金の問題が、OSやミドルウェアの課金プラットフォームの範疇を越えて
         アプリも修正しないと回避できないところまで広がっている」のは論外どころの話ではなく、
        Appleの責任でバッサリ切って捨てていい以外の何者でもありません。

        たとえば有料の動画配信サイトに動画コンテンツを提供している会社

        • プログラム云々とか言うのとは別に
          何か毒を吐いていることは分かるが、
          誰に対して毒を吐いているのかがよく分からんので
          読んでいて気味悪さが先行する。
          もうちょっとデトックスして話して欲しい。

          親コメント
        • by Anonymous Coward

          * 上記が理解できないならプログラムを1年勉強して出直してきてください。

          ごめん日本語が長くてよくわからなかった。
          結局、アプリに修正は必要なのか不要なのかどっち?
          アプリを修正するためには、iOS6 SDKが必要ってこと?

          特に
          >Appleの責任でバッサリ切って捨てていい以外の何者でもありません。
          の意味がわからなかったデス。

        • by Anonymous Coward

          プログラムより上位のロジカルな部分の話だと思うからプログラム勉強しても理解できないと思うけどね・・・

          俺も課金コンテンツ扱ってる人だけど、何言ってるか何が言いたいのか半分くらいわかんない。
          言ってること自体は正しいと思うけどね。

          • by Anonymous Coward

            課金フレームワーク側の例外処理が腐ってて
            カネ払ってなくてもアプリ側に正常に見える結果返すってだけ。
            アプリはその結果にしたがってコンテンツ代金支払い済みとして
            アプリ内機能をアンロックするなり追加コンテンツをダウンロードするなりする。

            フレームワーク自体の修正はiOS6を待て、とかになってるけど
            それまではどうすんだ、どんくらい被害が出てんだ、とか
            アプリが軒並みiOS6専用に移行しちゃってiOS6にいけない初代iPadは死亡ですかそうですか、
            とかどうすんだコレ。

            ちなみに、例外処理はしっかりやれってのは新入社員の研修レベル。

            • by Anonymous Coward

              例外処理?

              • by Anonymous Coward

                もう知ったかしてるのは確定的に明らかなんだからそれくらいにしといてやれよ

              • by Anonymous Coward

                半分くらいわかんないACだけど完全に分からなくなったw 分かってないのはこのACか。
                補償とかどこのだれがタレにしたの?塩なの?

                流石に釣りだと信じたい。

              • by Anonymous Coward

                「確定的に明らか」って日本語?

                # こうやって場の毒を薄める涙ぐましい努力

            • by Anonymous Coward

              お前、用語の使い方が新入社員の研修レベル以下だぞ。

              • by Anonymous Coward

                >お前、用語の使い方が新入社員の研修レベル以下だぞ。

                Apple工作員は具体的な内容も書かず(書けず)頭ごなしに他人を否定するだけだからすぐに見分けがつきますね。

        • by Anonymous Coward

          私にはわかりやすく説明する能力がありません、まで読んだ。

        • by Anonymous Coward

          まあ、言いたい事は理解できるが、言い方にかなりの悪意を感じて、なんか気持ち悪いね。

          そんなに「ダメ」な配信側で公開するかしないかはコンテンツ側が選ぶ事だし。

          > * 上記が理解できないならプログラムを1年勉強して出直してきてください。

          では、あなたは「1年勉強したら、穴のないシステムを構築できる」とでも?

          • by Anonymous Coward on 2012年07月24日 15時02分 (#2199127)

            >では、あなたは「1年勉強したら、穴のないシステムを構築できる」とでも?

            「穴がない(=ゼロ)」の保証は無理だけど
            ミドルウェアでの例外処理でしくってアプリに想定外の結果返して課金トラブル、
            なんてのは論外としか言いようがない、
            というか「言うしかない」。

            これは精神論でもなんでもなく、やったらダメ。
            銀行がバグで他人の口座の残高をメチャクチャにしちゃったら非難されるべきなのと同じ。
            「お前なにやっとんねん」であって擁護のしようがないし、
            開き直る姿勢なんて見せたらそれこそ総スカン。
            それがキモのシステムなんだから守れなかったらそういう批判を受けて当然。

            親コメント
            • by Anonymous Coward

              電気を供給するのが仕事で家庭向けの独占まで認められている会社が電気を供給できなくなったことは信じられないくらい擁護されてるけどね。

              • by Anonymous Coward

                そのうち停電とかもっと増えるんだろうな

              • by Anonymous Coward

                >電気を供給するのが仕事で家庭向けの独占まで認められている会社が電気を供給できなくなったことは
                >信じられないくらい擁護されてるけどね。

                つまりAppleを擁護しているのはApple社員とApple信者である、と。

                まぁ有り余るカネと有り余る信仰心があるからね、AppleとApple信者には。

              • by Anonymous Coward

                そもそもの原因が100年に一度の大地震だからでしょう。
                東電に不手際がなかったとはいいませんが、今回のAppleの不手際とは状況が異なります。
                批判が公平でないと思います。

            • by Anonymous Coward

              > ミドルウェアでの例外処理でしくってアプリに想定外の結果返して課金トラブル、
              そもそも何が起きてるかもわかってないのに「1年勉強して出直せ」とか偉そうな顔してるのはよくわかった。

              • by Anonymous Coward

                「”お前は何も分かってない”と何も分かってない人が言う」ですね。

                頭ごなしに他人を攻撃すればいい、具体的な反論内容も書けないし書かなくていいから短文でいい、
                とても楽なお仕事に従事のようでうらやましい限りです。

            • by Anonymous Coward

              ミドルウェアをプラットフォームか何かと勘違いしていないか?

              • by Anonymous Coward

                >ミドルウェアをプラットフォームか何かと勘違いしていないか?

                別々だと主張するでも同じだと主張するでもどっちでもいいと思いますよ。
                今回の場合、
                「OSや課金プラットフォーム開発主体」であるAppleと
                「アプリ開発主体であるサードパーティアプリベンダ」の責任分界点を示せればどっちでも変わりませんし、
                どっちでも示せるので用語を分ける必要もありません。

                ただ、そこで「とにかくミドルウェアとプラットフォームは違うの!!お前が間違ってるの!!」とかだと
                痛い視線でしか見られないでしょうから気をつけたほうがいいでしょう。

        • by Anonymous Coward

          > Appleの責任でバッサリ切って捨てていい以外の何者でもありません。
          切り捨てるのは勝手だけどコンテンツはタダで垂れ流され続けるよ。
          > 今回の件はそのくらい異常な話です。
          しかし現にAppleはそう言ってるわけで。

        • by Anonymous Coward

          あなたはAppleのことが何もわかっていませんね。
          そんな生やさしいレベルじゃなくて「お前らが自前で認証サーバ立ててAppleの課金サーバーとの通信を中継しろ」と言ってます(本当)。
          あなたの言う「まともな」課金システムだけ相手していたいなら一生ガラパゴスに閉じこもっててください割とマジで。

          • by Anonymous Coward

            何でそこまでしてAppleとかいうクソガラパゴスにわざわざ囚われなきゃいけないんでしょうね。
            心の底から分からない。

            • by Anonymous Coward

              Appleに限った話じゃねえよ。アホ。

              • by Anonymous Coward

                >Appleに限った話じゃねえよ。アホ。

                Apple、Google、MSなどのレベルの話で言えば、
                アプリ内のコンテンツ支払いも含めてアプリ内課金システムをとにかくウチに独占させろ、
                他の利用は許さない、
                を強要するのはAppleだけじゃないでしょうか。

                ※ この辺はAppleとGoogleしかしらないのでMSやMS以外の同レベルの何かがあれば指摘ください。

                今回の場合そこまで言っといてそれが腐ってた上、
                回避したけりゃアプリ開発者側がコストを負え、とか
                ジャイアンの「俺のものは俺のもの、お前のものは俺のもの」すら超えたロジックが
                盛大な笑いと涙と怒りを呼んでるわけです。

              • by Anonymous Coward

                Googleも今やってますよ。

          • by Anonymous Coward

            私の英語力もかなり低いですが、自前で認証サーバを介してAppleの課金サーバに接続している場合も、直接Appleの課金サーバに接続している場合も、等しく影響を受けるって書かれているように読めますね。

            「Appleの課金サーバに直接接続している場合に攻撃が可能だった」
            「中継サーバ使ってる場合も中継サーバを対象に同じ攻撃が可能だけど、その場合中継サーバとのプロトコルには関知しないので自前で何とかしろ」
            「ライブラリ側の実装はiOS6まで放置する」
            「一時的な対策として、Appleの課金サーバに直接接続している場合の回避策はSSL、購入証明の内容、購入証明の署名、購入証明がユニークか否かをアプリで検証すること」
            「検証に必要なAPIとして非public APIを使用したサンプルコードをこのドキュメントに添付した。このAPIは他の用途に使ってはならない」

            がAppleによる説明です。

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

処理中...