2017年5月12日金曜日

ECセキュリティ対策セミナー（大阪）開催します

HASHコンサルティング株式会社は、本日からEGセキュアソリューションズ株式会社に社名変更いたしました。

新しいオフィシャルサイト: 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日火曜日

「危険な脆弱性にいかに対処するか実践的ウェブサイト防衛セミナー」開催します

4月26日（水）HASHコンサルティング株式会社は、株式会社ジェイピー・セキュアと共催にて標記セミナーを開催いたします。

日時：2017年4月26日（水） 14時～17時
場所：ラーニングスクエア新橋　会議室４ーＢ（東京都港区新橋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にコーポレートサイトをリニューアルしています。

https://www.hash-c.co.jp/

そして、リニューアルされたコーポレートサイトでは ~~皆様の人柱となるために~~ 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サイトのセキュリティ強化支援サービス

https://www.hash-c.co.jp/service/wordpress_security/

2016年10月26日水曜日

WordPressとセキュリティ「ゆりかごから墓場まで」

こんにちは。HASHコンサルティングの松本隆則です。
今回は弊社のWordPressに対する取り組みについてお話させていただきます。

KUSANAGI Ready プロジェクト

HASHコンサルティングは、プライム・ストラテジー株式会社（https://www.prime-strategy.co.jp/）と共に、WordPressの主要なプラグインやテーマを検証し、一定の水準をクリアしているプラグインやテーマを公表する「KUSANAGI Ready プロジェクト」の運営を開始いたしました。

本プロジェクトの詳細については、以下のサイトをご参照ください。

http://ready.kusanagi.tokyo/

WordPressセキュリティ強化サービス

ところで、弊社徳丸は、ブログ執筆やイベントでの登壇などの様々な場面で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との関わり、および、「KUSANAGI Ready プロジェクト」の共同運営開始を発表したことを受けて、WordPressで構築されたサイトに特化したセキュリティ関連サービスをご案内いたします。

WordPressとセキュリティ

WordPressは非常に使い勝手の良いCMS（コンテンツ・マネジメント・システム）のため、世界中で普及していて日本でも人気が高いです。しかし、WordPressをセキュアに構築・運用するための知見は広く普及しているとは言えません。

また、WordPressは、製品のコア部分だけではなく、テーマやプラグインに対しても、セキュリティ向上のために継続的な対応が必要です。

そのため、一般的な脆弱性診断を受けての対症療法だけでは、セキュアなサイトの構築や運用を効果的に進めることができません。

WordPressサイトのセキュリティを強化する

そこで、HASHコンサルティングは、多くのセキュリティ対策の実績に裏打ちされた経験を活かして、お客様のご要望にマッチするカスタムメイドの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コンサルティングでエンジニアをしている松本隆則と申します。

弊社一ノ瀬に続き、私もHASHコンサルティング株式会社公式ブログを更新していくことになりましたので、よろしくお願いいたします。

というわけで、従業員の投稿第2弾はHASHコンサルティングの新サービスの話です。

新サービスについて

HASHコンサルティング株式会社は、2016年8月24日に「脆弱性検査ハンズオンセミナー with OWASP ZAP」というサービスの開始を発表いたしました。

本サービスは、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コンサルティングのサービス案内ページをご参照ください。

脆弱性検査ハンズオンセミナー with OWASP ZAP

脆弱性診断研究会

私は、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年以上経っている脆弱性が今だに検出され続ける原因を、ウェブアプリケーション開発エンジニアの不勉強さに求めるのは簡単ですが、本当に開発エンジニア「だけ」の責任なのでしょうか。

正直、明確な答えは出ないままなのですが、ふとしたきっかけで、脆弱性診断会社やセキュリティエンジニアは、ウェブアプリケーションを開発・運営するお客様に対して、今までと異なるアプローチをかける必要があるのではないか、と思うようになりました。

または私は如何にして心配するのを止めてハンズオンセミナーを愛するようになったか

ふとしたきっかけというのは、「もくもく会」への参加です。

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コンサルティングは現在も積極的にセキュリティエンジニアを募集しています。従業員も少しずつ増えてきましたので、今回の投稿から弊社の代表である徳丸と共に従業員もHASHコンサルティング株式会社公式ブログを更新していくことになりましたので、よろしくお願いいたします。
というわけで、従業員の投稿第1弾は2016/7/19に公開され話題となったhttpoxyの話です。

httpoxyは警視庁による注意喚起もされており、非常に注目を集めています。

“[PDF] CGI 等を利用するウェブサーバの脆弱性（httpoxy）を標的としたアクセスの観測について - 警察庁 (平成28年７月20日)” https://t.co/DE7LG7MwQC
— 徳丸浩 (@ockeghem) 2016年7月20日

　まずは脆弱性の内容を簡単に整理してみたいと思います。 httpoxyの根本的な原因はCGIの仕様と一般的に利用される環境変数との名前空間の衝突です。そのため、CGIやCGIライクな環境を利用している場合にhttpoxyの影響を受ける可能性があります。

具体的な動作

　CGIはクライアントが送信したHTTP リクエストヘッダの情報を環境変数に設定する際に次の処理を行うようにRFC3875にて規定されています。

大文字に変換
ハイフン"-"をアンダースコア"_"に変換
名前の先頭に"HTTP_"を付与

その結果として、ProxyというHTTPリクエストヘッダが付与されていた場合に環境変数HTTP_PROXYが設定されることとなります。

例えば次のリクエストがあった場合、

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コンサルティングの入社試験ではウェブ健康診断実技を実施しています

HASHコンサルティング株式会社では、一緒に働く仲間を募集しています。弊社はウェブアプリケーションのセキュリティを専門分野にしていますので、ウェブアプリケーションの開発経験のある方を歓迎いたします。セキュリティの専門知識や経験は、入社いただく時点では必須とはしておりません。

セキュリティの業務経験がない方に対する適性試験として、弊社ではウェブ健康診断仕様にもとづく脆弱性診断の実技体験をしていただいています。実務経験がない方が対象ですので、脆弱性診断のやり方は弊社代表の徳丸が説明いたします。下記は、実技体験に用いるソフトウェアが動いている画面のイメージです。

ウェブ健康診断仕様記載の脆弱性「全部入り」のWebアプリケーション(VMware)
ブラウザ(Firefox)
Burp Suite Professional

　上記はログイン画面でSQLインジェクション検査をしているところで、なにやらエラーメッセージが表示されています。

　実技体験では、徳丸の説明の後、実際に脆弱性診断をしていただきます。その様子を観察することで、実技試験としています。
　その際、手が早く動くことが高ポイントであるとは限りません。脆弱性診断は、ブラックボックスの中身を推測できることが重要であり、その際に、ウェブアプリケーションの開発経験が役に立ちます。そのため、診断中に表示されるさまざまなエラーメッセージに対して、徳丸が質問をしますので、その受け答えが重要な判断材料になります。以下の様な感じです。架空の応募者を高橋と表記します。

徳丸: それでは高橋さん、このパラメータについてSQLインジェクション検査をしてください。
高橋: 分かりました…あっ、なんかエラーがでました
徳丸: 先ほどのエラーと同じですか?
高橋: 違いますね。File not foundと出ていますので。
徳丸: 中で何が起こっているか、推測できますか?
高橋: …シングルクォートをファイル名としてファイルオープンしたが、そのようなファイルはなかったのかと…
徳丸: 素晴らしい! それでは…

　その際、脆弱性の名前を正答することが重要なのではありません。エラーメッセージから、アプリケーション内部で起こっていることを推測できることを重視いたします。セキュリティの知識は、入社してからいくらでも学習できますが、デバッグの勘所のようなものは、セキュリティ実務だけでは習得が難しいからです。

　徳丸が自らテストをするということで、「お腹が痛くなりそう」と言った方もおられますが、脆弱性診断の基礎の基礎が習える機会とでも考えていただいて、気楽にご応募下さい。ただし、冷やかしでは困りますが（笑）。

　入社試験は面接と実技試験あわせて1.5時間程度かかります。時間の余裕のある日時を指定いただくか、2回に分けて受験いただいても構いません。

皆様の積極的な応募をお待ちしています。応募を希望される方は、こちらの問い合わせフォームから入社希望の旨ご連絡ください。人材募集については、こちらの記事もご参照ください。

登録: 投稿 (Atom)

2017年5月12日金曜日

2017年4月18日火曜日

2016年11月16日水曜日

HASHコンサルティングで採用している施策

基本的な施策

OS・ミドルウェアからセキュリティを強化する

SELinuxのすすめ

SELinuxの導入で何ができるか

SELinuxの副作用

WAF

改ざん検知

HASHコンサルティングのミッション

2016年10月26日水曜日

KUSANAGI Ready プロジェクト

WordPressセキュリティ強化サービス

WordPressとセキュリティ

WordPressサイトのセキュリティを強化する

HASHコンサルティングのミッション

2016年9月6日火曜日

弊社一ノ瀬に続き、私もHASHコンサルティング株式会社公式ブログを更新していくことになりましたので、よろしくお願いいたします。 というわけで、従業員の投稿第2弾はHASHコンサルティングの新サービスの話です。

新サービスについて

HASHコンサルティング株式会社は、2016年8月24日に「脆弱性検査ハンズオンセミナー with OWASP ZAP」というサービスの開始を発表いたしました。

「ウェブ健康診断 with OWASP ZAP」コース

「OWASP ZAP Maniacs」コース

それぞれのコースの具体的な内容については、HASHコンサルティングのサービス案内ページをご参照ください。 脆弱性検査ハンズオンセミナー with OWASP ZAP

脆弱性診断研究会

セキュリティエンジニアとしての悩み

または私は如何にして心配するのを止めてハンズオンセミナーを愛するようになったか

脆弱性検査ハンズオンセミナーのススメ

2016年7月23日土曜日

具体的な動作

本脆弱性への対処

再現試験をしてみる

環境

まとめ

2016年3月3日木曜日

フォロワー

ブログ アーカイブ

弊社一ノ瀬に続き、私もHASHコンサルティング株式会社公式ブログを更新していくことになりましたので、よろしくお願いいたします。

というわけで、従業員の投稿第2弾はHASHコンサルティングの新サービスの話です。

それぞれのコースの具体的な内容については、HASHコンサルティングのサービス案内ページをご参照ください。

脆弱性検査ハンズオンセミナー with OWASP ZAP

ブログアーカイブ