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/