Hatena::ブログ(Diary)

hnwの日記 このページをアンテナに追加 RSSフィード

[プロフィール]
 | 

2018年3月21日(水) セキュリティの話題に丸腰で踏み込んでくる人を見た このエントリーを含むブックマーク このエントリーのブックマークコメント

Qiita上で「ゲームでよくされるチート手法とその対策 〜アプリケーションハッキング編〜」という記事がいいね数を集めているようですが、全セクションにツッコミどころがあるような印象です。私はセキュリティ本職というわけではありませんが、素人の私から見てもひどいと思ったところだけ個別にツッコミを入れてみます。


念のため補足しておくと、誰であろうと情報発信すること自体は大変良いことです。ただ、誤りを含んだ文章がウッカリ注目されてしまうとそれを信じてしまう人も出てくるので、大人げないと思いつつツッコミを入れる次第です。


デコンパイル(逆コンパイル)

2.の詳しい解説として、C/C++で記述されたコードをコンパイルすると機械語に変換されます。これを逆コンパイルしても、逆アセンブラまでにしかなりません。そのため、この状態ではソースコードの中身を解析するのは(人間では)非常に困難なため、ネイティブコードで書いた処理というのはデコンパイルへの対策となります。


技術用語の使い方が正確でない点は見なかったフリをするとして、C/C++で記述すれば安全だというのは幻想です。攻撃者の多くは高機能な逆アセンブラ(おそらくIDA Pro)を所有しており、昔に比べると格段に処理を追いやすい環境が整っています。基本的にはネイティブバイナリからでもコードの内容は把握可能だと考えるべきでしょう。


そもそもこのセクションの前半で紹介されている「iOS Reverse Engineeringの操作手順」もARMのアセンブリIDA Pro/Hopperで解析する話題になっており、ネイティブコードなら安全という主張とは反対の内容です。ご自身で紹介している記事なのに読んでいないのかしら?と思ってしまいますね。


話を戻すと、クライアントバイナリの挙動は全て解析される前提でシステム全体を設計すべきです。つまり、解析されて困る内容はサーバ側で実装するのが原則論になるでしょう。


絶対に秘密にしたいロジックをユーザーに配布するバイナリに入れたい場合は、自前での対策はあきらめてアンチデバッギング機能・アンチ逆アセンブル機能を持ったセキュリティ製品を購入した方が良いでしょう。実際の現場ではバレてもクリティカルじゃないけど簡単にバレるのはイヤという程度の状況だったりするため、自前実装で頑張っているところもあれば外部ソリューションに頼っているところもあるといった印象です。


乱数調整

なお、乱数を生成する際、現在時刻を基にして、擬似乱数を生成することが多いので、特定のタイミング(時刻)を狙うとうまくいく、といった都市伝説みたいな論調はあながち間違っているわけではありません。

間違いでしょう。明示的ににひどい実装をしない限りそんなことにはなりません。


引用部からすると乱数シードとして現在時刻を利用している言語・環境が多い、という風に読み取れますが、モバイルアプリ文脈でそんな環境はないはずです。現在のOSは各種割り込みのタイミングから十分なエントロピー(乱雑さ)を蓄積し、それを利用して乱数を生成しているため、十分にセキュアだと言えます(マシンの外部から乱数列を推測することは原則不可能です)。また、各言語の乱数生成の実装はOSに依存しているはずで、これらもセキュアだと言えます。


ネット上には自前実装の乱数生成器が転がっていたりして、そうしたものは時刻を乱数シードに使っているかもしれませんが、それらはセキュリティ知識の無い人が作成した脆弱な実装です。言うまでもありませんがコピペして使うなどは言語道断です。


攻撃者がOSroot権限を持っている場合など、乱数生成器の内部状態にアクセスできるようであれば次に生成される乱数を事前に知ることも可能でしょう。その意味で、重要な抽選はサーバ側で行うべきという主張自体は正しいと思います。ただし、サーバ側で実装するにしても乱数シードのエントロピー確保をOSに任せること、および採用する疑似乱数の性質を把握することの2点は必須です。


ちなみに、乱数シードのエントロピー不足でサーバ上の乱数生成器が攻撃対象になりうるという事例は私が以前会社の技術ブログ記事「PHPのセッションIDは暗号論的に弱い乱数生成器を使っており、セッションハイジャックの危険性がある」で紹介しました。古いPHPで設定がイマイチなときにしか発生しない話題ですが、ご参考まで。


余談

本当はDBトランザクションとロックに関してツッコミを入れようと思ったんですが、長編になりそうだったのでその他のところだけ記事にしました。もちろん私より適任の方が記事を書いてくださってもいいんですよ?(チラッ

RishatangRishatang 2018/03/22 20:04 文字数の都合上書けなかったのですが、私が邪推した理由はブコメの内容だけではなく、本文中の「ご自身で紹介している記事なのに読んでいないのかしら?と思ってしまいますね。」の部分も理由としてあります。

人によって感覚は違うのでhnwさんがどういうつもりで書いたのかはわかりませんが、少なくとも私は「完全な煽り、ないし元記事の筆者を馬鹿にしているな」と思いました。

「誰であろうと情報発信すること自体は大変良い」と思っているのなら自然と元記事の筆者に対して敬意を払った態度になると思うのですが、個人的にそうは見えませんでした。

以上です。

hnwhnw 2018/03/22 21:07 情報発信する姿勢はまず良いと思いますが、正しい情報を発信しようとする姿勢があった方がなお良いと私は思います。

ですから、もし自分が読んでもいない記事を紹介しているのであればそれは正しく非難されるべきでしょう。そして、その疑いを私が持っているということも隠すことではないと思います。

そのような可能性は薄い、文脈として十分に整合性がある、とRishatangさんが思われたのであれば不快に思われるのも当然かもしれません。

hnwhnw 2018/03/22 21:42 もう一点補足しておきますと、私は元記事を書いた方が悪だと思っているわけではありません。自分のメモ書き程度の文章であっても気軽に公開すること自体は悪いことではないし、むしろ良いことだと感じているのは本心です。そうした文書の中に宝が埋もれている可能性もあるわけですから。

一方で、誤りを含んだ文章が多くの人に注目されてしまうと、それを鵜呑みにしてしまう別の技術者が現れてしまうかもしれないという危惧も本心です。そうなってしまったときにその文書の品質が批判されることも当然のことだと思いますが、今回について言えば注目を集めるに至った仕組みの側の問題ではないでしょうか。つまり、技術メディアとしてのQiitaにおいて記事の品質担保の仕組みが機能していない点が一番の問題だと思います。

そもそも編集者がいないようなサイトですから品質担保が難しいのは当然なのですが、現在のQiitaはいいね数だけを基準にしたランキングを提示しているなど、いいねの数を良記事の基準のような使い方をしており、品質担保をあきらめてバズる記事を書いた方が偉い、というような姿勢のサイトに見えます。もう少し何とかできるんじゃないの?というのが私の意見です。

hnwhnw 2018/03/23 00:43 タイトルが煽りっぽくなってしまった感はあるかもしれません。セキュリティ本職の人にかかったらすごい量の添削が来そうだなーと思ったのを深く考えずに記事タイトルにしてしまいました。

taptappuntaptappun 2018/03/25 02:39 記事を書いた本人です。
記事をご覧いただきありがとうございます。
記事を書いた意図や経緯の齟齬があるようなので、この場で述べさせていただきます。
・記事に書いた内容は私がこれまでの実務での経験に基づいたもの
・表現は内容を整理して端的にまとめたもの
・参考記事は基本的に結論として述べるにあたり、裏付けを得るためのもの
この3点を基準として記事を書いています。
記事の内容が絶対正しいと述べる気もこれで十分だと述べる気も全くありません。
ただ、実務に基づいたものであるので、「理論的に考えればおかしい」という内容は大いにあります(理論的には問題があると思ったが、実際に開発、運用した中での最適解は違いました。その最たる例がボタン連打なのですが)
また、もちろん記事を書くまでに考察、調査した過程を省略してのべているものもありますし、プラットホームに依存した話のため、いっぱい注釈をつけなければ正しくないというものもあります。
しかし、それらすべて上記3点の基準に準ずる形になるように変えて書いています。
また、私は学生時代、セキュリティの研究室でしたので、ご指摘のようなことも多く経験しました。その中での経験を通して私の記事もご指摘の内容も結果としては眉唾物でしかない、ということを感じています。(セキュリティというものは問題を提起すると必ず批判があるもので、正解も絶対にありえません。)
そのため、私の記事が正しいのか間違っているのかといった評価はご覧にいただいた方にお任せしたいと思います。

hnwhnw 2018/03/25 16:21 taptappunさん

独り言くらいのつもりの記事でしたので、わざわざ反応いただきありがとうございます。

> 私は学生時代、セキュリティの研究室でしたので

ではセミプロくらいの方なんですね。であれば周囲にCTFやっててアセンブリが友達みたいな人もたくさんいそうな気がしますし、韓国や中国の方が実力が断然上だなーといった感覚値も持たれていそうな気がしますが、その上で今回の記事の内容なんですね。

> ・記事に書いた内容は私がこれまでの実務での経験に基づいたもの

なるほど。乱数調整の章で書かれた下記部分も実務で経験されたんでしょうか?

> 特定のタイミング(時刻)を狙うとうまくいく

私はそのような実装はあまり一般的ではない(乱数実装に関するバグがあるにしても、時刻ベースで攻撃が成立するような状況は珍しい)と感じました。一方、taptappunさんの書き方ではそのような実装がありふれているかのように捉えられかねないと感じたので、この点を抜き出して反論させてもらいました。

引用部の直後で例示しておられるポケモンの件もGameBoyでの事例で、昨今のモバイルOSとは相当違う環境ですので、実務での経験のお話が裏にあるとは全く予想もしませんでした。もしも実務での経験で近いお話があったのであれば、書ける範囲でその話を書いた方が良かったかもしれませんね。

> セキュリティというものは問題を提起すると必ず批判があるもので、正解も絶対にありえません

状況を限定すれば必ず正解はあると思いますよ。そうでなければセキュリティの研究や仕事って何をするんでしょう?

 | 
ページビュー
2569301