Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

2014年2月25日火曜日

マイナビのセミナーにて講演します

マイナビ主催のセミナー「2014年版! 標的型攻撃対策セミナー~最近の事件から学ぶ、攻撃手口と運用留意点~」で、辻伸弘さんと共に講演します。

日時:2014年2月28日(金)13:30~16:30(徳丸の出番は15:50~16:30)
場所:マイナビルーム2F-T(東京都千代田区)
費用:無料(申し込みはこちら
講演タイトル:加害者にならないためのWebサイト保護施策~最新の動向を踏まえて~

講演の中ではWebサイトが「加害者」になるシナリオを3種類ほどデモする予定です。
Webサイトが外部から攻撃を受けて、自サイトが「被害者」になるだけでなく、他社への「加害者」になってしまうシナリオは多数ありますが、最近の動向を踏まえて、某大手レンタルサーバー事業者で発生したと推測されているシンボリックリンク攻撃のデモをする予定です。但し、詳細のシナリオは公表されていないため、徳丸の創作によるものです。

シナリオをこっそりお教えしましょうw
  • 某レンタルサーバーにタナカとスズキがサイトを構築している
  • スズキは人気サイトであり攻撃者が狙っているが、こちらは外部から侵入できる脆弱性はない
  • スズキの方はWordPressを利用している
  • タナカの方では古いphpMyAdminを使っていて、外部から任意のスクリプトが実行できる
  • 攻撃者はタナカ側に攻撃をしかけ、スズキサイト側にシンボリックリンクを貼る
  • 攻撃者は上記シンボリックリンクを閲覧して、スズキのWordPress設定ファイルからMySQLのIDとパスワードを得る
  • 攻撃者はタナカのphpMyAdminに対して、スズキ側のMySQLのIDとパスワードを使ってログインする
  • 攻撃者はphpMyAdminを操作して、スズキ側コンテンツを書き換える
  • これ以降、スズキ側コンテンツを閲覧した利用者はマルウェアに感染する
うーん、ややこしい手順なので、理解しやすい説明を工夫しなければ…上記の「タナカ」は外部からの侵入を許した結果、自サイトは直接の被害がなく、スズキ側への攻撃に荷担してしまったため「加害者」になったという想定です。

それでは、よろしくお願いいたします。

2014年2月8日土曜日

【速報】Joomla3.2.2以前にSQLインジェクション脆弱性

Joomlaの最新版(3.2.2)にSQLインジェクション脆弱性が報告されていますので速報します。

概要

Joomla3.2.1のSQLインジェクション脆弱性がexploit-dbに報告されました。こちらで追試した結果、Joomlaの最新版である3.2.2にも同じ問題があります。再現条件は下記の通りです。
  • Joomla 3.2.1 および 3.2.2 (他のバージョンでは検査していません)
  • サンプルデータとして「テスト英語(GB)」を導入していること
  • データベース MySQL(他のデータベースでは検査していません)
この条件で http://examle.jp/joomla/index.php/weblinks-categories?id=\ にアクセスすると、下記の表示になります。


これは 500 Internal Errorのエラー画面ですが、画面最下部に以下のエラーメッセージが表示されています。
1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\)' at line 3 SQL=SELECT `t`.`id` FROM `xxxxx_tags` AS t INNER JOIN `xxxxx_contentitem_tag_map` AS m ON `m`.`tag_id` = `t`.`id` AND `m`.`type_alias` = 'com_weblinks.categories' AND `m`.`content_item_id` IN ( \) 
SQLの詳細エラーメッセージが表示されており、IN句の中身が、外部から指定した「\」がそのまま入っています。この段階で、SQLインジェクション脆弱性があることが分かります。
http://example.jp/joomla/index.php/weblinks-categories?id=0)union+select+concat(username,password)+from+xxxxx_users+%23


上図の赤い囲みに「admin$P$DVZwwcGTspL434pDfmJOOUPZU8Dtf7/」と表示されていますが、これは管理者のIDとパスワードハッシュ値を連結したものです。

影響を受けるサイト

再現条件はまだはっきりしていません。前述のように、以下の両方を満たす場合に脆弱性が発現することを確認しています。
  • Joomla 3.2.1 および 3.2.2
  • サンプルデータとして「テスト英語(GB)」を導入していること
念のため、他のサンプルデータを全て試してみましたが、上記の形ではSQLインジェクション攻撃はできませんでした。
また、Joomla2.5.18では上記は再現していません。

対応

本稿執筆時点でのJoomla最新版3.2.2に脆弱性があるため、脆弱性が該当する場合は回避策を検討してください。回避策としては、以下が考えられます。
  • Joomlaの対応版が導入できるまでサイトを停止する
  • Web Application Firewall(WAF)を導入する
  • index.php/weblinks-categories へのアクセスを禁止する(可能な場合)
  • 詳細エラーメッセージの表示を抑止する
  • Joomla2.5.18にダウングレードする
このうち、詳細メッセージの抑止方法については、以下の方法があります。現在選択中のテンプレートのディレクトリ中のerror.phpを編集します。上記の例では、templates/protostar/error.phpです。ここで、$this->error->getMessage() を表示している箇所(複数)を削除するかコメントアウトすると、エラーメッセージから機密情報が漏えいすることを防止できます。
ただし、他の方法で攻撃は可能です。たとえば、MySQLのsleep()関数を用いたブラインドSQLの可能性があります。
今後のこの脆弱性に関する情報が公表されると予想されるため、Joomla利用者はセキュリティ情報に注意することをお勧めします。

追記(2014/3/9)

Joomla 3.2.3がリリースされました。確認したところ、上記のSQLインジェクションがこのバージョンで修正されています。Joomlaをお使いの方は、3.2.3へのバージョンアップをお勧めします。
Joomlaの管理コンソールにログインすると、下記のボタンが表示されるはずです。


ここで、「Update now」というボタンをクリックすると、アップデートが開始されます。

免責

このセキュリティ情報は予告なしに改訂される場合があります。このセキュリティ情報を適用した結果について徳丸浩およびHASHコンサルティング株式会社は一切の責任を負わず、利用者の利益のために、あるがままの状態で公開するものとします。

PR

HASHコンサルティング株式会社では、Webサイトを安全に守るためのセキュリティサービスを提供しています。WAF(Web Application Firewall)による効果的な脆弱性対策(SQLインジェクションを含む)や、リスクの評価、対策方法の策定、セキュリティの教育などを提供します。詳しくはお気軽にお問い合わせ下さい



2014年2月6日木曜日

JALの不正ログイン事件について徳丸さんに聞いてみた

高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、JALの不正ログイン事件についてお話を伺います。徳丸さん、よろしくお願いします。

徳丸: 徳丸です。よろしくお願いします。

高橋: まず、事件の概要を説明します。日本航空のホームページに不正アクセスがあり、JALマイレージバンク(JMB)のマイルが、Amazonのギフト券に勝手に交換される被害がありました。日本航空の発表では、1月31日から2月2日にかけて、身に覚えがないマイル交換がされているという問い合わせが複数ありました。調査の結果、40人の利用者のマイルがアマゾンのギフト券、数百万円相当と交換されていたというものです。

徳丸: ここで問題となるのは、パスワードは数字6桁ということなんですよね。

高橋: やはりそこですか。パスワードが数字6桁だとどのような攻撃ができるのでしょうか?


ブルートフォース攻撃

徳丸: まず、ブルートフォース攻撃の可能性がありますね。下図のように、ユーザIDを適当に固定して、パスワードの全てのパータンを試す攻撃のことです。

高橋: ちょっと待ってください。前回のお話では、オンラインのブルートフォース攻撃は現実的ではないとのことでしたが。

徳丸: それは、パスワードの桁数が十分な場合のことです。数字6桁のパスワードだと、オンライン・ブルートフォース攻撃が現実の脅威となります。

高橋: なぜでしょうか?

徳丸: 数字6桁のパスワード場合、パスワードのパターン数は100万通りですよね。

高橋: 結構大きな数字にも思えますが。

徳丸: そうでもないのです。1時間は3600秒ですから、1秒あたり10個のパスワードを試したとすると、1時間では36,000通り試せます。100万個のパスワードの試行には28時間弱で終わる計算です。

高橋: 一日ちょっとですか。確かに現実性がありますね。そうなると、今回の事件はブルートフォース攻撃なのでしょうか。

徳丸: いえ、それは違います。

高橋: あれれ、違いますか。

徳丸: はい。JALのログイン機能にはアカウントロックの機能があります。パスワードの間違いが一定回数続くと、アカウントがロックされ、パスワードを試すことができなくなります。

高橋: 一定回数とは何回くらいでしょうか。

徳丸: 数字6桁のパスワードだと5回くらいではないですかね。

高橋: ブルートフォース攻撃が駄目となると、どのような方法がありますか?


辞書攻撃

徳丸: 次に検討すべきは辞書攻撃ですね。パスワードを総当たりに試すのではなく、利用者がつけそうなパスワードの一覧(辞書)を用いて攻撃します(下図)。

高橋: でも、アカウントロックに引っかかりませんか?

徳丸: そうなんです。アカウントロックの閾値が5回のパスワード間違いだとすると、辞書攻撃に使う辞書には4種類のパスワードしか載せられません。

高橋: では、辞書攻撃ではない?

徳丸: いや、そうでもないのですが、いったん次の攻撃方法を説明しましょう。

高橋: はい、お願いします。


リバースブルートフォース攻撃

徳丸: 次に考えられるのは、リバースブルートフォースアタック(攻撃)です。

高橋: なんだかプロレスの必殺ワザみたいな名前ですね。

徳丸: これは、パスワードを適当に固定して、ユーザIDの方を変えながらログインできるか試す方法です(下図)。

高橋: 数字6桁というと、例の「123456」とかですか?

徳丸: よく知っていますね。123456は各種のパスワード統計でもっとも人気のあるパスワードですが、JALの場合は違います。

高橋: なぜでしょうか?

徳丸: 禁止されているからですよ。こちらをご覧下さい。

高橋: あーー、そうすると、123123くらいですか。

徳丸: いい線ですね。そうしておいて、ユーザID(お得意様番号)の方を変えていきます。

高橋: お得意様番号は分かるのですか?

徳丸: 具体的な番号の一覧が公開されている訳ではありませんが、ある程度の規則性はあるようですね。あとは、総当たり的に試すのでしょう。

高橋: 成功確率が低いのではありませんか?

徳丸: そうでもないです。こちらの記事によると、JMBの会員数は2700万人ということですから、100万で割ると、1つのパスワードあたり平均では27人の利用者がいることになります。

高橋: 根気よく試すと、平均27人の認証が通ってしまうのですか。

徳丸: 123123のように設定率の高いパスワードだと、もっといくでしょうね。

高橋: それは困りますね。JALは対抗策を講じていなかったのでしょうか?

徳丸: 特に対策していなかった可能性が高いですね。

高橋: なぜ分かりますか?

徳丸: こちらの記事アーカイブ)によると、被害にあった利用者の被害者はすべて同一のIPアドレスからアクセスされたようです。ということは、IPアドレス毎に連続したログイン試行の監視やロックをしていなかったと思われます。

高橋: そうか! リバースブルートフォース攻撃の対策は、IPアドレス毎にログインを見張っていて大量の試行があればロックすればよいのですね。

徳丸: それが、そう単純でもないのです。

高橋: なぜでしょうか。

徳丸: 対策が完全ではないと言うことと、副作用があるということの2つの理由からです。

高橋: 完全ではないのですか?

徳丸: はい。攻撃者側がIPアドレスを変えながら攻撃する場合が多いです。GitHubに対する不正ログインの事例が典型的ですね(参考:GitHubに大規模な不正ログイン試行)。そうなると、IPアドレス単位でのロックは掛けにくいです。

高橋: 安全を見て、少ない回数でロックしてしまえば…

徳丸: そうしたいところですが、複数の利用者が同じIPアドレスを共有している可能性を考慮する必要があります。企業からのアクセスはプロキシによりIPアドレスを共有している場合が多いですし、最近はスマートフォンからの3GアクセスはNATですので、IPアドレス単位でロックすると、「道連れ」が大量に出る可能性があります。

高橋: そうなると、閾値をゆるめに設定しておかないと支障がでてきますね。

徳丸: はい。そうすると、閾値に達するまでに、被害に遭う可能性が高くて調整が難しいことと、GitHubのようにIPアドレスをこま目に変えられると対策としては不十分です。

高橋: 完全でないのと副作用というのは、これを指しているのですね。

徳丸: そうです。

高橋: でも、JALが何も対策してなかったとまでは言い切れないのでは?

徳丸: そうですね。しかし、今回の場合、攻撃元のIPアドレスが1つだったにも関わらず、利用者からの指摘で発覚しているので、監視も特にしていなかったと思われます。

高橋: JAL以外のサイトは、リバースブルートフォース攻撃は心配ないのですか?

徳丸: JAL以外のサイトでも一定の脅威ではありますが、JAL程ではありません。

高橋: なぜでしょうか?

徳丸: 利用者が安全なパスワードをつけられるからです。リバースブルートフォース攻撃はパスワードを固定するので、攻撃に使うパスワードは「ありがちなパスワード」使うと効率的です。

高橋: 例の「123456」などですね。

徳丸: そうです。123456やpasswordなど安易なパスワードを設定している利用者には脅威ですが、それは自己責任というか、自業自得の感があります。一方、JALの場合は、利用者が安全なパスワードをつけたくてもつけられないので、利用者の責任とは言えません。

高橋: その違いは大きいですね。

徳丸: そうです。


パスワードリスト攻撃

高橋: パスワードリスト攻撃についてはどうでしょうか? 最近被害が多いようですが。

徳丸: JALの場合は、パスワードリスト攻撃ではないと考えられますね。

高橋: なぜでしょうか?

徳丸: パスワードリスト攻撃は、別のサイトから漏えいしたIDとパスワードの一覧を用意して、攻撃対象のサイトで試すという方法です。ですので、IDとパスワードが一定確率で共通のものがないと、攻撃が成立しません。

高橋: あっ、そっか。

徳丸: JALの場合、IDは利用者がつけるものではなく、JALが割り当てた独自のものです。この時点でパスワードリスト攻撃の対象にはなりません。

高橋: 言い換えれば、パスワードリスト攻撃の対象は、利用者が好きなIDをつけられるか、メールアドレスをログインIDとして使用する場合、ということですね。

徳丸: そうです。加えて、JALの場合、パスワードの仕様が数字6桁ですが、多くのサイトで数字だけのパスワードはチェックで弾いています。これらの理由から、パスワードリスト攻撃ではないと考えられます。


再び辞書攻撃について

高橋: ところで、辞書攻撃については保留状態でしたが、どうなんでしょうか?

徳丸: そうでした。辞書攻撃の可能性もあると私は見ています。

高橋: 4~5回しか試せないのに攻撃が成立しますか?

徳丸: 辞書攻撃とリバースブルートフォース攻撃のハイブリッド攻撃という可能性があります。これは、先に紹介したGitHubに対する攻撃パターンです(注: 2018年以降この攻撃方式はパスワードスプレイ攻撃と呼ばれるようになりました)。

高橋: なるほど、リバースブルートフォースのようにパスワードを1つに固定しなければならないわけではないのですね。

徳丸: そうです。JALの場合は、IPアドレスが固定でしたからIPアドレスをキーに監視やロックができた可能性がありますが、IPアドレスまで変えられると、従来から取られてきた対策では防御できないのです。

高橋: 困りましたね。JALはどうすればよいでしょう?


対策

徳丸: 対策を検討する上で、パスワードに対する攻撃でどの程度の被害があり得るかを検討しましょう。

高橋: お願いします。

徳丸: アカウントロックに引っかからない前提で、1ユーザあたりパスワード4個まで試せると仮定すると、パスワードが的中してしまう確率は100万分の4です。JMBの利用者が2700万人いるので、かけ算すると、108人が被害にあう計算です。

高橋: あー、利用者数が多いことで、被害者も増えるのですか。

徳丸: そうです。しかも、パスワードをランダムに試すのではなく、人気のありそうなものにすれば、この数倍になるでしょう。

高橋: そういえば、ANAのパスワードは数字4桁だから、単純計算で1万人が被害にあう計算ですね。

徳丸: こちらの記事によると「ANAマイレージクラブ」は、2013年6月末時点で2,500万人の会員数を有している」ということなので、計算上はちょうど1万人ですね。

高橋: それは大変です。はやく対策を教えてください。

徳丸: 二要素認証を使う方法があります。ポイントの交換や個人情報の閲覧の際には、パスワード以外の情報を求める、というものです。

高橋: 具体的には何が使えますか?

徳丸: 登録したメールアドレス宛にトークン(6桁程度の乱数)を送るという方法がありますが、登録済みメールアドレスが使えるとは限らないのですよね。

高橋: 私も今回の件で、数年ぶりにJALのサイトにログインしました。そういう方だと、メールアドレスが変わっているという人も多そうです。

徳丸: ということなので、生年月日を使う方法が考えられます。

高橋: わざと嘘の生年月日を登録する人もいるそうですが…

徳丸: そうなのですが、航空会社の場合は、航空券の発券のために生年月日が必要だし、正しい情報を入れている人が多いのではないでしょうか?

高橋: でも、生年月日は秘密情報とまでは言えないですよね。

徳丸: はい。しかし、今回のような「不特定多数を狙った」攻撃には効果があります。特定ユーザを狙った攻撃など一般的な対策については、こちらの記事をご覧下さい。

高橋: わかりましたが、いちいち生年月日を入力するのも面倒ですね。

徳丸: そうでもないんじゃないですか? 自分の情報をしょっちゅう確認・変更する人はいないでしょうし、ポイントの交換もそんなにはないでしょう。

高橋: 頻繁に飛行機に乗る人は面倒だと思いますが…

徳丸: そうですね。だから、パスワードの制限を緩めて、安全なパスワードをつけられるようにすることが、総合的には安全性と利便性を両立できるのだと思います。

高橋: そもそも、なぜ数字のパスワードにこだわるのでしょうか?

徳丸: テレフォンサービスでも同じパスワードを使っているからでしょう。

高橋: あぁ、電話だと英字や記号は使えませんね。

徳丸: 電話の場合は、リバースブルートフォース攻撃などはできないので数字のままでもそれほど危険ではないでしょうしね。だから、Web用とテレフォンサービスとでは、パスワードを別にするしかないでしょう。

高橋: 利用者が2種類のパスワードを管理できないという意見もありそうですが。

徳丸: その辺が難しいところですね。ですが、数字6桁のパスワードでは一定の被害が出てしまうことは避けがたいので、Webが不要な利用者は数字のパスワードだけだがWebは使えなくするなど、きめ細かい施策を打つしかないでしょう。

高橋: そう言えば、対策に高額な費用が掛かるのであれば、対策は保留して金銭的な補償で対応するという経営判断もある、という記事を読みましたが。

徳丸: リスクの受容、あるいは俗に「サイバーノーガード戦法」と呼ばれるものですね。

高橋: 「ノーガード」はかわいそうな気もしますが…

徳丸: 金銭で片が付く問題であれば、一般論としては成立する話ですが、コンシューマー向けサービスでは、金銭補償は最後の手段として考えるべきでしょう。

高橋: なぜでしょうか?

徳丸: 不正ログインで被害にあうと、金銭的な損失もさることながら、精神的なショックが大きいですし、個人情報がいったん漏えいすると、回収は不可能です。これらは、金銭で補償できるという種類のものではありません。

高橋: 確かにそうですね。

徳丸: はい。なので、サイト運営者には、せめて常識的なラインまでは対策を行う義務があると私は考えます。

高橋: 数字6桁のパスワードは、常識的なラインを下回っている、と。

徳丸: その通りです。

高橋: ありがとうございました。これで、JALの不正ログインに関する徳丸さんへのインタビューは終わりです。みなさま、ごきげんよう~

※注: このエントリはインタビュー仕立ての記事であり、文責はすべて徳丸にあります。高橋は架空の人物です。


追記(2014/2/11)

奥一穂さんから、「(実質的な)パスワードリスト攻撃の可能性もあるのでは?」という指摘をいただきました。レンターカーの会社などでJMBのマイレージと連動するためにJMB番号を収集している企業があり、同時に住所や生年月日を申し込みのために集めているサイトがあるので、これらの情報が仮に漏れた場合、JMB番号と、生年月日や住所、電話番号からのパスワード推測を組み合わせた攻撃の可能性です。確かに、そのよう攻撃はあり得ると考えます。
上で指摘しているのは狭義のパスワードリスト攻撃の可能性を否定するものであり、奥さんの指摘のような攻撃の可能性を否定するものではありません。ご指摘ありがとうごさいました。

フォロワー

ブログ アーカイブ