オンラインゲームのセキュリティ

オンラインゲームは攻撃者にとって収入に繋がる可能性が高く、かつセキュリティも(銀行などと比べて)それほど厳しくないので、ターゲットとしては狙いやすいのかもしれません。ゲーム会社としてはユーザが遊びやすいように利便性を求める必要があるし、利便性を優先するとセキュリティが甘くなってしまいます。

攻撃者としてオンラインゲームから利益を得ようと考えた場合、まず他人のアカウントでログインしてアイテムやゲーム内のお金をRMT(リアルマネートレード)で現金に換える方法がありますが、そうすると他人のアカウントを盗むのが第一の目的となります。アカウントを盗む為の方法として考えられる方法は３つあって、以下の通り脆弱性さえあればアカウント情報を盗むことも容易です。

• ホストの脆弱性を利用したアカウントの漏洩

• Webアプリの脆弱性を利用したアカウントの漏洩

• ゲームシステムの脆弱性を利用したアカウント情報の漏洩

その他にも、認証が必要なサービスなので、総当たり攻撃という手もありますが、よっぽど推測の容易なパスワードを設定していない限りなかなか容易にログインに成功することはありません(管理会社側で総当たり攻撃に対する対策やログの調査をまったく行っていない場合は別ですが)。攻撃者が容易にアカウント情報を収集する為には、多数あるオンラインゲームのうち、１つでもアカウント情報の漏洩につながる脆弱性があるゲームがあれば、そこから取得した情報をもとにその他のゲームにもログインを試行することによってログインできてしまう可能性があります。なぜなら、オンラインゲームのユーザはいくつものゲームにアカウントを作成している可能性があり、それぞれ異なるパスワードを設定していない可能性も非常に高いからです。

オンラインゲームに脆弱性が見つからなくても、攻撃者がゲームの情報サイトを作成すればゲーム好きなユーザはアカウントを作成するかもしれません。攻撃者はユーザが入力したパスワードを暗号化することなくDBに登録することによって、オンラインゲームにログインできる可能性のあるアカウント情報の一覧が自動的に集まってくるはずです。

個々のゲームで異なる認証方式を実装するとか、オンラインゲームの運用におけるセキュリティのスタンダードをもう少し厳しく定める必要もあるように思います。

iPhone3.0から3.0.1へのバージョンアップに失敗(1604エラー)

iPhoneのSMSに関する脆弱性対策の含まれる最新バージョン3.0.1をインストールする際、エラーでなかなか上手く更新できなかったので、対策方法のメモです。

1. iPhoneをUSB(USB HUBとかでなく、PC本体のUSBインターフェイス)に接続
2. iTuneを起動し、復元を実行しiPhoneの画面はブラックアウト(1604エラーが発生)
3. iTuneを再起動し、再度復元を実行
4. その後問題なく復元完了

PC本体のUSBインターフェイスに接続してないと、エラーになるし、いまいち原因がわかりません。なんとなく、復元の段階で何度かデバイスを再認識してるっぽいので、USB HUB等につないでると再認識が上手くできてないんじゃないかと思いますが、まぁ上手くいったので一段落。

それにしても、SMSの脆弱性ってどんな内容だったんだろ。今度調べてみよう。

Packer memo

バイナリファイルを圧縮する為、または逆コンパイルできないようにパッカーというプログラムが利用されます。これは、ウィルスがアンチウィルスソフトに検出されないよう難読化する為にも利用される為、ウィルス解析等の分野においてはパッキングされたプログラムをアンパックする技術も必要になります。

Packer

UPX	一番一般的なパッカー
burneye	Unpackerはこちら
shiva
tElock
ASPack
その他	http://www.softpedia.com/get/Programming/Packers-Crypters-Protectors/

Reference

• Attacking Obfuscated Code with IDA Pro

Unpacking技術

• Hacking the Packer
• Manual Unpacking FAQ

XSS対策としてサニタイズだけで十分？

XSSに対する対策として、入力パラメータに対するサニタイズ処理を行うのは一般的です。例えば、入力文字列をに含まれる＆を＆amp;に、ダブルクォートは＆quot;に、<は＆lt;、>は＆gt;に変換するといった処理を行うことによって、HTMLの一部として扱われる文字列を無害な文字に変換します。但し、ある条件によってはサニタイズされていたとしても悪用される恐れのある場合があります。

例えば、以下のようにイベントハンドラーのparam部分にGET/POSTのパラメータが挿入される場合、入力文字列がサニタイズされていれば大丈夫でしょうか？

<input VALUE=”実行” onclick="escape(‘param’)" type="button" />

文字列として「’),alert(document.cookie);//」を挿入すると、シングルクォーテーションがサニタイズされて＆＃３９；となり、以下のように表示されるはずです。サニタイズしてるからJavascriptは動かないはず・・・でも、ボタンを押すとJavascriptが実行されてポップアップが上がってきます。

<input VALUE=”実行” onclick="escape(‘param&#39;),alert(document.cookie);//’)" type="button" />

シングルクォーテーションをマニュアル通りにサニタイズしているのであれば、上記のようなイベントハンドラーに埋め込まれたXSSの問題を回避することができません。場合によって様々なサニタイズパターン(上記の場合はシングルクォーテーションを全角に変換するとか)を作ることも対策としては有効ですが、複雑になってしまい逆に対策漏れが生じてしまう危険性がある為、パラメータにシングルクォーテーション等の不正な文字列が挿入された場合はエラー画面を表示する等の対策が一番無難な対策になります。
他にもいろいろとパターンがあるかもしれませんが、エラー画面を表示することによって大体対策できるように思います。みなさんのWebアプリケーションはいかがでしょう？

XSSって危ないの？

少し前になりますが、XSS(クロスサイトスクリプティング)の危険性に関する記事を見ました。内容は、XSSの問題について過敏に反応しすぎなのでは？という内容ですが、いままでにない見解で非常に面白く拝見させて頂いたことを記憶してます。

理由としては、以下のような内容が述べられていました。

世間の認識と脅威レベルのギャップ――XSSは本当に危ないか？

「XSSなんてバグなんだから存在してはならない」 →当たり前だが、バグのないシステムなんかあるのか？ 「過去にはこんなワームなどで悪用された」 →5年間で10件程度もない頻度で、 SQLインジェクションと比べたら微々たるもの 「こうやったらCookieが漏れる」 →それでどれくらい事件になったか？ これが経営者の投資意欲につながる数字なのか？

たしかに、SQLインジェクションと比較すると、XSSが事件となった事例は比較にならないくらい少ないんですよね(ないということではありません・・)。実際に問題の存在するサイトの数としては、SQLインジェクションの存在するサイトよりもXSSの存在するサイトの方が多く、XSSを使って攻撃することは容易だと思いますが、なぜ大きな事件にならないのでしょうか？

XSSが事件にならない理由

これは個人的な推測ですが、XSSによる攻撃を受けた場合、その痕跡の残らない可能性が高いという点があります。例えば、GETのパラメータとしてXSSを悪用する文字列が送信された場合はWebサーバのログに残りますが、POSTで送信された場合はログにすら残りません。また、XSSの問題が悪用されたことを後から追跡することも(ログが存在しない場合は)困難な為、もし情報が漏洩していたとしてもXSSを悪用されたことが発覚することはありません。

SQLインジェクションの問題についてもそうですが、セキュリティインシデントというのは発覚しなければ事件にはなりません。私もいろんなサイトにメールアドレスを登録してますが、いつしかスパムメールがいろんなところから届くようになりました。どこかでメールアドレスが漏洩してるはずなんですが、過去に登録したサイトで情報が漏洩したなんてニュースを見た記憶(あったけど見てないだけかもしれませんが)はありません。きっと、管理者の知らないうちに脆弱性を利用して情報を盗んでいる攻撃者がいるはずで、事件となって取り上げられている事例は氷山の一角にすぎないはずです。

攻撃者はXSSの問題をどうとらえる？

攻撃者の視点からXSSの問題をどう悪用しようか考えた場合、まず一番に考えられるのは罠を仕掛けて不特定多数の人を罠に誘導することによって行う攻撃です。ただし、記事にもありましたが、不特定多数を対象とし、罠を仕掛けて誘導するのであればクライアントアプリケーションの脆弱性を利用してボットを仕込む方が効率的です。

では、どういった場合にXSSを悪用するのかと考えた場合、スピア方攻撃によるXSSの悪用が挙げられます。企業のシステムや端末では、OSのパッチ適用やアンチウィルスのインストールがポリシーとして定められており、既知の脆弱性については早期に対策されていることもあります。その場合はボットを仕込むことは難しくなりますが、XSSであればアプリケーション側で対策しない限り悪用することができます。さらに、社内で使われているメールアドレスを偽装してXSSの罠に誘導することはそれ程難しいことではありません(管理部から、次のURLを参照してインフルエンザ対策を実施するようにといった内容のメールが届くとみんなURLを開いてしまうかもしれません)。

つまり、XSSは悪用することができないのではなく、また効率的ではないので悪用されないのでもなく、場合によっては攻撃手段として非常に有効な脆弱性であり、攻撃者もその点は理解しているはずです。不特定多数を対象とした攻撃としては効率的ではない為、数は多く検出されないだけなのかもしれません。

対策はどうすればいい？

XSSの対策をとる為には、Webアプリケーションに対するセキュリティ検査や改修費用等、かなりコストがかかるのが一般的です。前述の記事では、XSSによるリスクを以下のように分析していました。つまり、このようなリスクに対して対策が必要だと感じる場合は対策した方が良いとの考え方です。でも、以下の内容はネット上でビジネスを展開しているほとんどの企業が該当するように思います。うちはまったく問題ないぞ～なんて企業あるんでしょうか？

社会的信用のある企業・サービスが被害を受ける 銀行、クレジットカード決済、公共サービスなど社会的に信用が必要なサイトは狙われる可能性も高く、被害が発生した場合の存在も大きくなります。 痛くもない腹を探られる XSSの脆弱性があるだけで「おたくのサービスは大丈夫か？」「ほかのサービスも危ないのでは？」と疑われるきっかけを生みます。 いちゃもんをつけられる “正義の味方”的な人に「ここは脆弱性があるぞ」とさらされます。見方によっては脆弱性の存在をタダで教えてくれる便利な人かもしれません。

対策としては、Webアプリケーションを開発するたびにセキュリティ検査の実施や改修を行うのではコストがかかるため、WAF(Wab Application Firewall)を導入することを検討するという手もあると思います。コストはかかりますが、セキュリティ検査と改修費用を考えると、同じくらいか、もしくは安くすむのではないでしょうか。また、WebサーバとしてApacheの利用が一般的であるように、mod_security等の無料のWAFも使って当たり前という考え方があればWebアプリケーションの脆弱性も少なくなるはずです。なかなかシステムを動かす為に必須ではない為、そこまでやってる開発会社は少ないのが現状です。

やはり一般的な対策としてはセキュリティ検査会社に頼んで問題箇所を特定し、開発会社に改修を依頼するのが一般的ですが、うちにWeb開発を依頼すればWAFも導入しますよ！なんて開発会社があれば今後は注目されるのかもしれません。

ブログ開始

技術関連のブログはhatenaが多いようですが、やはりデザインも重要だってことでbloggerにブログを開設。

セキュリティ関連のメモとして情報を更新するつもりです。