2017年11月24日金曜日

OWASP Top 10 2017に対する弊社脆弱性診断の対応

先日OWASP Top 10の最新リリースである2017版が正式に公開されました。

OWASP Top 10 - 2017 [PDF]

OWASP Top 10 2017の公開に向けては、RC1が公開された際に議論百出した後いったん破棄されるなど波乱の幕開けとなりましたが、その後別メンバーにて作成されたRC2の内容で正式版として公開されたようです。

OWASP Top 10は多く企業にてガイドラインとして使われていると思いますし、PCI DSSなどの別の標準から参照されていますので、脆弱性診断サービスの内容がOWASP Top 10 2017にどのように対応するかは関心のある方が多いと思います。本稿では、弊社脆弱性診断サービスがOWASP Top 10 2017にどのように対応するかについて説明します。弊社診断サービスには、簡易なものから順に以下のものがあります。詳しくは弊社ウェブサイトを参照下さい。

  • ウェブ健康診断
  • ライト診断
  • スタンダード診断(標準的・網羅的なリモート診断)
  • プレミアム診断(スタンダードに加えてソースコード診断を併用する)

なお、以下の説明では、OWASP Top 10 2017の各項目の日本語訳として、以下のNTTデータ先端技術株式会社の記事で使われている翻訳に従いました。記してお礼申し上げます。

A1 インジェクション

インジェクションは、SQLインジェクションやOSコマンドインジェクション等の総称で、旧版である2013年版からの据え置きです。弊社の脆弱性診断サービスはすべてのサービスで標準的に対応しています。IPA ウェブ健康診断仕様では下記の項目が該当しますが、弊社のスタンダート以上のサービスではより詳細の試験を行います。以下の項目についても同様です。
  • (A) SQLインジェクション
  • (D) OSコマンドインジェクション

A2 認証の不備

文字通り認証処理における脆弱性です。2013年版は「認証とセッション管理の不備」となっていてタイトル上は2017年版にてセッション管理が外れました。しかし、2017年版も内容としてはセッション管理を含んでおり、ほぼ同じ内容をカバーしています。弊社の脆弱性診断サービスはすべてのサービスで標準的に対応しています。IPA ウェブ健康診断仕様では下記の項目が該当します。
  • (J) 認証
  • (K) セッション管理の不備

A3 機密データの露出

この項目は2013年版ではA6でしたが、A3に昇格しました。
「露出」はExposureの訳ですが、データが「見ようと思えば見られる状態」であることを指します。2000年代初頭の情報漏えい事件の多くが、機密データがドキュメントルート下に置かれていて、そのURLが2ch等に投稿されて騒ぎになるというパターンが多かったのですが、これがExposureです。弊社の脆弱性診断サービスはすべてのサービスで標準的に対応しています。IPA ウェブ健康診断仕様では下記の項目が該当します。
  • (E) ディレクトリ・リスティング
ただし、OWASP Top 10の解説を読むと、データの暗号化やハッシュ値による保存が強調されています。リモート診断(スタンダード)では、HTTPSによる保護は診断できますが、サーバー内部で暗号化保存されているかどうかは原理的に診断できません。これに対して、ソースコード含めて確認するプレミアム診断では、サーバー内部でのデータ暗号化についても確認できます。

A4 XML外部実体参照(XXE)

XML外部実体参照(XML External Entities; XXE)とは、XMLの外部実体参照の機能を悪用した攻撃および脆弱性であり、2017版でTop 10初お目見えとなりました。XXEに関する日本語ドキュメントはあまり多くありませんが、例えば海老原昂輔氏の下記のスライドが参考になります。

XML と PHP のイケナイ関係 (セキュリティ的な意味で) -Introduction of XXE attack and XML Bomb…

以下、簡単なサンプルを用いてXXEを説明します。以下は、POSTデータとしてXMLデータを受取り、その中から<data>タグを持つ最初の要素をとりだし、その要素内容をXMLとして返す簡単なPHPスクリプトです。

<?php
  header('Content-Type: text/xml; charset=utf-8');
  $doc = new DOMDocument();
  $doc->loadXML(file_get_contents('php://input'));
  $data1 = $doc->getElementsByTagName('data')->item(0)->textContent;
  echo "<data>". htmlspecialchars($data1). "</data>";
このスクリプトに以下のXMLデータを与えます。
<?xml version="1.0"?>
<!DOCTYPE str [
<!ENTITY wget SYSTEM "http://192.168.0.2/">
]>
<str><data>&wget;</data></str>
すると、上記3行目で定義される外部実体が処理され、http://192.168.0.2/を参照した結果がXMLとして返されます。外部からは参照できないプライベートアドレスの内容が外部に漏洩することになります。
この種の攻撃は、XXE脆弱性を悪用したSSRF(Server Side Request Forgery)攻撃と呼ばれます。SSRF攻撃とは、ウェブサーバー等を中継して、外部からは到達できない別のサーバーやネットワーク機器等に攻撃することを指します。
また、URLではなくサーバー内のローカルファイル名(/etc/passwd等)を書くと、ディレクトリトラバーサルのように、サーバー内部のファイルを閲覧できます。

ただし、PHPでこの種の攻撃が設立するには、libxml2のバージョンが古い必要があります。上記の実験はまったくパッチを当てていないCentOS 6.3では成功しましたが、CentOS 6.4ではlibxml2にパッチが当たっていて成功しません。
弊社の脆弱性診断サービスはスタンダード以上のプランでXXEの診断に対応します。スタンダード診断ではリモート診断の手法により、既知の攻撃パターンを用いて脆弱性の有無を検証します。プレミアム診断では、これに加えてソースコードの確認により、より深い診断が可能です。

A5 アクセス制御の不備

アクセス制御の不備は、IPA 安全なウェブサイトの作り方の「アクセス制御や認可制御の欠落 」に該当します。すなわち、認証を必要とするページに認証なしでアクセスできたり、強い権限が必要な機能を弱い権限で使用できる問題などを含みます。この項目は、2013年版の「A4 安全でないオブジェクト直接参照」と「A7 機能レベルアクセス制御の欠落」をマージしたものです。
弊社の脆弱性診断サービスはすべてのサービスで標準的に対応しています。IPA ウェブ健康診断仕様では下記の項目が該当します。
  • (L) 認可制御の不備、欠落 

A6 セキュリティ設定のミス

文字通りセキュリティ設定の不備による問題を指します。典型例としては、デフォルトパスワードのままでソフトウェアを使用していたり、詳細のエラー内容やスタックトレースがウェブページに表示される状態などです。2013年版ではA5でした。
弊社の脆弱性診断サービスでは、スタンダード以上のプランで標準的に対応しています。また、ウェブ健康診断とライトプランでも、下記項目はセキュリティ設定のミスとも考えられます。また、他の診断項目の結果として副次的に判明した場合は報告いたします。
  • (E) ディレクトリ・リスティング

A7 クロスサイトスクリプティング

おなじみのクロスサイトスクリプティングです。2013年版ではA3でした。弊社の脆弱性診断サービスはすべてのサービスで標準的に対応しています。IPA ウェブ健康診断仕様では下記の項目が該当します。
  • (B)クロスサイト・スクリプティング

A8 安全でないデシリアライゼーション

この項目は2017年版からの新規導入となります。「安全でないデシリアライゼーション」はPHP界隈ではオブジェクトインジェクションと呼ばれる場合もあります。詳しくは以前に書いた以下の記事を参照下さい。

安全でないデシリアライゼーション(Insecure Deserialization)入門

弊社の脆弱性診断では、安全でないデシリアライゼーションはウェブアプリケーション診断の標準としては診断していませんでしたが、OWASP Top 10入りを受けて、スタンダード診断以上にて以下のように診断項目に含めることにしました。

スタンダードプラン(リモート診断):
リモート診断にてベストエフォートの診断を実施します。脆弱なアプリケーションの例として、Welcartの1.9.3を題材とします。Welcartにて会員ログインすると、以下のようなクッキーが発行されます。
a%3A2%3A%7Bs%3A4%3A%22name%22%3Bs%3A0%3A%22%22%3Bs%3A3%3A%22rme%22%3Bs%3A0%3A%22%22%3B%7D
これをパーセントデコードすると以下の形になります。
a:2:{s:4:"name";s:0:"";s:3:"rme";s:0:"";}
これはPHPのシリアライズ形式であることがわかります。シリアライズ形式がクッキーとして発行されている限りは、これをデシリアライズしている可能性が高いと考えられます。このようなケースでは、「安全でないデシリアライゼーションの可能性」として報告します。
現実には、クッキーは発行しているが利用していないケースとか、自作のデシリアライザを用いて安全に処理している(可能性は低いと思いますが…)可能性もあるので、あくまで可能性であり、過検知の可能性はあります。しかし、シリアライズ形式を外部に出すこと自体が好ましくないため、指摘自体は有益なものと考えます。一方、特殊なシリアライズ形式で見かけ上は単なるXMLにしか見えないケースなど、見落としの可能性もありえます。

プレミアムプラン:
プレミアムプランではソースコードの確認を行うため、各言語のデシリアライズ機能を確認することにより、精度の高い診断が可能となります。

A9 既知の脆弱性を持つコンポーネントの使用

文字通り、ソフトウェアから使用しているコンポーネントに既知の脆弱性があるケースを指します。この項目は2013年版でもA9でした。
弊社の脆弱性診断では、この項目は基本的にプラットフォーム診断として実施していますが、アプリケーション診断でも判明する場合があり、その場合は報告しています。
既知の脆弱性の代表例としてSturts2の脆弱性がありますが、リモートからの診断ではStruts2のバージョン把握等には限界があります。ヒアリングの結果、必要に応じてリモートログインさせていただいての内部からの診断を提案させて頂く場合があります。

A10 不十分なロギングおよび監視

こちらも2017年版からの新設になります。ログ取得は攻撃の検知および事後調査に重要ですし、攻撃に対する監視もできれば実施するべきでしょう。
通常のリモートからの脆弱性診断では、A10の項目を外部診断業者が診断することは困難です。このため、この項目は弊社のスタンダード診断では未実施となります。
プレミアムプランでは、ソースコードを確認するため、ログ取得の状況を確認することが可能です。一方、監視についてはソースコードを確認しても判明しません。
監視をカバーする弊社サービスとしては、ウェブアプリケーションアセスメントがあります。このサービスは通常の脆弱性診断に加えて監査手法を併用し、アプリケーションの運用状況やログの活用、監視の状況などを確認し、サイト運営の改善点を指摘するものです。

診断対応のまとめ


ウェブ健康診断・ライトスタンダードプレミアムアセスメント
A1 インジェクション
A2 認証
A3 機密データの露出◎(*1)
A4 XXE
A5 アクセス制御の不備
A6 セキュリティ設定のミス
A7 XSS
A8 安全でないデシリアライゼーション
A9 既知の脆弱性を持つコンポーネント
A10 不十分なロギングおよび監視◎(ログ)◎(監視)

*1 サーバー内のデータ暗号化も確認

凡例
◎:標準的で網羅的な検査
○:抜き取り診断
△:簡易的な診断
-:非対応

まとめ

OWASP Top 10の改定に伴い、弊社診断サービスと新OWASP Top 10 (2017)とのマッピングについて紹介しました。2017年版は、XXEや安全でないデシリアライゼーション等、従来日本ではあまり話題にならない項目も含まれており、診断業者としても対応を迫られています。新規の脆弱性診断はもちろんのこと、既に診断済みサイトに関してもこれら新規項目について安全性を確認する機会ではないでしょうか。
弊社のサービスが貴社ウェブサイトの安全に寄与できれば幸いです。

2017年9月7日木曜日

診断文字列を打ち込まずにPHPのバージョンを推測する

脆弱性診断においてApacheのバージョンを外部から調べる方法を複数の専門家がブログ記事に書いておられます。
いずれも大変興味深いものですが、ApacheでできるのであればPHPはどうだろうかと気になる方も多いと思います。これは人間の自然な感情だと思うのです。
このあたり、各診断会社の「秘伝のタレ」みたいなところもあるのでしょうが、私からも少し知見を披露したいと思います。

タイトルにも書いたように、診断文字列を打ち込まずに、言い換えれば、通常のウェブ閲覧の範囲で分かること、さらに言えばHTTPレスポンスヘッダから分かることについて書きます。こういうと、「X-Powered-Byヘッダを見れば一目瞭然www」みたいな反応も考えられますが、そういう自明なものは対象外とします。

(1) キャッシュ制御のヘッダ

PHPは、session_start()関数の実行によりセッション管理を有効にすると、キャッシュ制御用のレスポンスヘッダを自動的に生成します。この挙動は、session_cache_limiter() 関数により変更可能ですが、大半のサイトはデフォルトの nocache のまま使っていると思います。これは通常安全な設定ですが、CDNによっては注意が必要です。
このうちのCache-Controlヘッダですが、PHPのバージョンにより、以下のように変わります。

PHP 4.0.0~4.0.2 Cache-Control: no-cache, post-check=0, pre-check=0
PHP 4.0.3~5.6.x Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
PHP 7.0.0~  Cache-Control: no-store, no-cache, must-revalidate

PHP 4.0.0等を使っているサイトは今時多くないとは思いますが、PHP 5なのか、PHP 7なのかの違いには使えそうです。

(2) setcookie関数に空文字列を指定した場合の挙動

以前、ログアウト機能の目的と実現方法にて書きましたが、徳丸自身はログアウト時にセッションクッキーを削除する必要はないと考えていますが、PHP本家のマニュアルには、ログアウト時にはセッションIDのクッキーを削除しなければならない(原文は"the session cookie must be deleted")とあります。このため、ログアウト時にセッションクッキーを削除するサイトはそれなりに見かけます。前述のマニュアルには、以下のようにセッションクッキーの削除スクリプトの例まで紹介されているので、これをコピペして用いる場合も多いかと思います。
$params = session_get_cookie_params();
setcookie(session_name(), '', time() - 42000,
    $params["path"], $params["domain"],
    $params["secure"], $params["httponly"]
);
これ、パッと見は、42000秒(11時間40分)前のExpireを指定したSet-Cookieを発行するように見えますが、実はそうではない…ということは以前の記事に書きました。これは、setcookie関数の第2引数に空文字列を指定した場合の特別な挙動です。そして、この挙動がPHPのバージョンによって異なります。

PHP 4.0.0~4.0.1  Set-Cookie: PHPSESSID=deleted; expires=Tuesday, 06-Sep-16 07:46:47 GMT; path=/
PHP 4.0.2~4.2.x  Set-Cookie: PHPSESSID=deleted; expires=Tue, 06-Sep-16 07:46:47 GMT; path=/
PHP 4.3.0~5.3.6  Set-Cookie: PHPSESSID=deleted; expires=Tue, 06-Sep-2016 07:46:48 GMT; path=/
PHP 5.3.7~5.4.x  Set-Cookie: PHPSESSID=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/
PHP 5.5.0~       Set-Cookie: PHPSESSID=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/

expires属性の値と、Max-Age属性の有無によって、PHPのバージョンが推測できます。特に、PHP 5.3.6まで expiresが約1年前の日時だったのに対して、PHP 5.3.7以降では1970年1月1日になるところが使えそうですね。PHP 5.5以降でMax-Age=0; が付与されるのも有用です。

(3) setcookieに空文字列を指定されたのかを判別する

しかし、上記の方法には欠点があり、本当にsetcookie関数の第2引数に空文字列が指定されたのか、実は第2引数に deleted を明示したのかは簡単には分かりません。しかし、Set-Cookieの挙動をよく見ると、これらを区別できる場合があります。
まず、PHP 5.3.6までは「約1年前」のexpiresと前述しましたが、厳密には1年+1秒前のExpiresになります。PHP 5.3.6でのレスポンスヘッダの例を下記に示します。
HTTP/1.1 200 OK
Date: Wed, 06 Sep 2017 08:38:34 GMT
Server: Apache/2.2.31 (Unix) PHP/5.3.6
X-Powered-By: PHP/5.3.6
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=deleted; expires=Tue, 06-Sep-2016 08:38:33 GMT; path=/
Content-Length: 5
Content-Type: text/html
Dateヘッダの時刻とSet-Cookieヘッダのexpires属性が1秒ずれていることがわかります。これがヒントになります。もちろん、明示的に1年+1秒前のexpiresを指定している可能性もありますが、通常はそういうことはしないでしょう。

また、setcookieヘッダの第2引数に空文字列以外を指定した場合は、過去日付のexpiresに対するMax-Ageの挙動が変わります。下記は、1年前のexpiresを指定した場合のSet-Cookieです。
PHP 5.5.0~7.0.18  Set-Cookie: PHPSESSID=deleted; expires=Tue, 06-Sep-2016 08:22:17 GMT; Max-Age=-31536000; path=/
PHP 7.0.19~       Set-Cookie: PHPSESSID=deleted; expires=Tue, 06-Sep-2016 08:22:17 GMT; Max-Age=0; path=/
上記のように、PHP 5.5.0~PHP 7.0.18までは、負のMax-Ageがセットされますが、PHP 7.0.19以降では、Max-Age=0がセットされます。setcookieの第2引数に空文字列を指定した場合と挙動が変わるのが興味深いですね。

どうやって調べたか

このような細かい調査をするには、実際にPoCを書いて動かしてみるのが確実ですが、PHPの全バージョンとなると200を超えるので、そう簡単ではありません。私は過去の記事で紹介した modphpall を用いて、実際に動かすことで調査しました。とある診断員さんのApacheの記事では以下のように書かれていますが、
以下のコマンド(以前検証した際、togakushiさんにご指導いただいたシェル芸を記載しています)を実行してApache HTTP Serverの2.2系を全部ソースインストールして、バージョンごとに別々のポートで起動させてみます。
僕が調べたApacheバージョン判定の小ネタ より引用
modphpallも、PHPのバージョン毎に別々のポートでApacheを起動するもので、似たようなことを考えるものだな思いました。

まとめ

診断文字列を打ち込まずにHTTPレスポンスヘッダだけからPHPのバージョンを推測する方法を紹介しました。本文中にも書いたように、アプリケーションの書き方によってはご判定の可能性もあり、機械的に上記の情報を適用してバージョンを推測することは危険ですが、複数の情報や顧客からのヒアリング内容等を組み合わせることにより、脆弱性診断に有用な情報が得られると考えます。

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ー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にコーポレートサイトをリニューアルしています。

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 プロジェクト」の運営を開始いたしました。

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

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

ところで、弊社徳丸は、ブログ執筆やイベントでの登壇などの様々な場面でWordPressに関わっています。
上記の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コンサルティングのサービス案内ページをご参照ください。

脆弱性診断研究会

私は、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」についてお気軽にお問い合わせいだだけると幸甚に存じます。



本サービスがウェブアプリケーションの脆弱性を少しでも減らすことに役立つことを願ってやみません。



いらすとや

フォロワー