ばぁどです。 セキュリティに強いWeb屋です。
数年前はDrupalの開発をやっていた会社におり、現在はサイバーセキュリティの知識を蓄えてセキュリティもできるWeb屋になっています。 そんなセキュリティという観点からDrupalの記事を書こうとすると、やはり脆弱性という観点での書き口になってしまう。。。
今回は数年前に起きたDrupageddonというDrupalに存在した大きな脆弱性について書いていこうと思います。
本記事で伝えたいこと
- 脆弱性の放置ダメ、絶対。
Drupageddonって何？
2014年に「巨大隕石が地球に墜落するほど」衝撃的な脆弱性の内容であることから、アルマゲドンを文字ってつけられた脆弱性です。
- https://jvndb.jvn.jp/ja/contents/2014/JVNDB-2014-004862.html
- https://www.drupal.org/forum/newsletters/security-advisories-for-drupal-core/2014-10-15/sa-core-2014-005-drupal-core-sql
DrupalのDBに対してSQLを発行する部分のアルゴリズムに欠陥があり、外部の攻撃者が望むようなクエリを発行できてしまうような脆弱性でした。
下記の徳丸先生の記事や、徳丸さんの記事の中で紹介されている海外のサイトもわかりやすく説明してくれていました。
■徳丸浩の日記 https://blog.tokumaru.org/2014/10/drupal-sql-injection-cve-2014-3704.html
■Drupageddon - SA-CORE-2014-005 - Drupal 7 SQL injection exploit demo http://www.zoubi.me/blog/drupageddon-sa-core-2014-005-drupal-7-sql-injection-exploit-demo
2017年にもDrupageddon2 という脆弱性が見つかっており、こちらも緊急度の高い脆弱性として発表されています。
https://www.drupal.org/sa-core-2018-002
drupageddon2はHTTPリクエスト部分に脆弱性が存在していたようですね。 詳しくは下記。(手前味噌で恐縮です。2年前のアドベントカレンダーの記事を発見したので苦笑) https://qiita.com/UltraBirdTech/items/4c336d34ebff0823176f#sa-core-2018-002
本家大元のアルマゲドンには続編がないにもかかわらず、Drupageddonは2までできてしまっているのが何とも言えぬ・・・
2016年に世界中を震撼させたパナマ文章も？？
2016年に起きたパナマ文書を覚えていますでしょうか。 世界中の富豪達が租税回避地として使用していたパナマのモサック・フォンセカという法律事務所の情報がリークされてしまった事件です。 リークされた情報は世界中のジャーナリストによって解析が進められ、疑惑が浮上した富豪達はバッシングされてしまいました。
■Wikipedia https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%8A%E3%83%9E%E6%96%87%E6%9B%B8
流出元になったモサックフォンセカでは、このDrupageddonを含んだ脆弱性を持つDrupalが3年にわたり脆弱性が放置されたまま運用がされていたそうです。
下記の英語サイトでも同様の記述を発見しました。 https://drupal.sh/drupal-panama-papers-leaks-mossack-fonseca.html
しかし注意点としてDrupageddonが悪用されて情報が流出したという決定的な証拠はありません。
あくまで「モサックフォンセカではDrupageddonの脆弱性を含んだDrupalを2014年の発表から3年もの間更新せずに放置していた」という事実があるだけです。
まぁ、とは言え脆弱性を放置していると、このように攻撃者に攻撃される隙を与えているのですよね。 そう言った脆弱性は確認出来次第すぐに修正していく必要があります。
要するに「脆弱性を放置すると、こういう痛い目に遭う可能性がありますよ」ということですね。
個人的な見解：Drupageddonは再び起こるのか？
絶対とは言い切れませんが、Drupageddonのようなクリティカルな脆弱性の発生頻度は落ちると考えています。
理由はDrupal7 から Drupal8 に移行する際に、内部システムがPHPのWebアプリケーションフレームワークであるSymfonyに書き換えられているからです。
少し話がそれますが、WebアプリケーションフレームワークはWebアプリケーションを開発するためのURLマッピングやDBとの接続部分の実装、ORマッパーの実装などの処理をルールとして提供してくれています。 このことによりDrupageddonのような少しお粗末なSQL発行のスクリプトは、WebアプリフレームワークであるSymfonyのルールに基本的に沿っていれば発生する可能性は低くなります。
しかしSymfonyのDB接続を担当しているORマッパー自体に深刻な脆弱性が見つかったり、もしくはDrupal内でSymfonyのルールに沿った記述ができておらず独自に作り込んでいる場合や、Drupalの拡張モジュールなどまだまだ不安になる要素はたくさんあります。
まぁ実際にDrupageddon2はDrupal8(8.5.0以前)でも発生していますしね。
このことからも決して油断することなく、常に脆弱性には気配りをしていただきたいです。
脆弱性が見つかったその時のために普段から何ができるのか？
脆弱性情報をチェックする
使用しているDrupalのバージョンや、外部モジュールを把握した上で常に下記のようなサイトをチェックしてください。 もし使用しているDrupalのバージョンや外部モジュールに脆弱性が発見された場合は、脆弱性の脅威度を確かめた上で確実に対応をしてください。
脆弱性が発表されたときに即時対応できる体制を整える
また、脆弱性が発表されたおきに即時対応することができる体制を整える必要があります。
企業ページに対して記事の更新などを行うことがCMSの強みですが、サーバー側の設定になると対応できる人が限られたり、場合によっては許可が必要な場合もあるでしょう。 そう言った、脆弱性の更新のためにどう言った手順が必要なのかを事前に確認しておき、有事の際にはしっかりと対応できるようにしておく必要があります。
要は防災訓練ですね。
