Mod Security検証

目次

1.サイトの準備と攻撃方法の確認

2.WAF有効化

まとめ

 

1.サイトの作成と攻撃方法の確認

XSS用のページを準備します。

XSSの脆弱性を利用すると、任意のスクリプトを対象のWebブラウザ上で実行することができます。
改変したページを閲覧させたり、入力情報を第三者のもとへ送信させるように仕組むことが可能となります。
以下を実施します。
セッション管理IDを表示します
→クッキー情報が盗みだされると、なりすましの被害をされる可能性が非常に高くなります。
あらかじめ格納しておいたスクリプトをサイト内に仕込んでおき、任意のページに飛ばして、クッキー情報と成功したという画面を表示させます。
→盗んだクッキー情報を悪用して、攻撃者が指定したサーバへ転送し、知らぬ間に情報を入力させて、情報を入手したり、ウィルスをダウンロードさせるといった手法に応用ができます。
また、転送サーバへ送れば、クッキー情報も入手できます。

実験用として、3つの脆弱性があるログインページ（コード）を用意します。

・login.php

<!--?php session_start(); ?-->
<h1>LOGIN FORM</h1>
<h2>Please enter your name and password.</h2>
<form action="confirm.php" method="get">username:<input name="name" type="text" />
password:<input name="passwd" type="text" />
<input type="submit" value="OK" />
<input type="reset" value="CANCEL" /></form>

・confirm.php

<!--?php session_start(); $name = $_GET['name']; $passwd = $_GET['passwd']; ?-->
<h1>LOGIN FORM</h1>
<h2>Are you sure?</h2>
<form action="success.php" method="get">username:<!--?php echo $name; ?-->
password:<!--?php echo $passwd; ?-->
<input name="name" type="hidden" value="&lt;?php echo $name; ?&gt;" />
<input name="passwd" type="hidden" value="&lt;?php echo $passwd; ?&gt;" />
<input type="submit" value="OK" />
<input type="button" value="CANCEL" /></form>

・success.php

<!--?php session_start(); ?-->
<h1>Login successfully!</h1>

 

通常のパラメーターを入力すれば、問題なく画面遷移します。
（例）ここでは、userとしておきます。

しかし、username欄に以下を入力すると、セッションIDが表示されます。

<script>alert(document.cookie)</script>

Webサイトがクッキーによってセッション管理されている場合、上記のようにそのままの値を返してしまいます。
この例では、本人のセッションIDが表示されているので、被害が発生することはありませんが、脆弱性がある状態といえます。

次に、以下をusername欄に入力し、実行します。

<script>window.location='https://waf/xss.php?'+document.cookie;</script>

「Please click here」と表示されました。
このアドレスはサーバ内にあるxss.phpページへ表示させるスクリプトです。セッションIDも引き継いでいます。
アドレス確認すると、、セッション ID がアドレスに含まれてしまっていることが分かります。
PHPSESSID=lq7c73ie39ail27kle0c13ium7

OKクリックすると、ウィルスがダウンロードされる仕組みとなっている・・・ということはありませんが、実際の XSS 攻撃では、OKをクリックさせて、転送サーバにあるウィルスをダウンロードさせるといったことが可能となります。

また、XSSはあらかじめ攻撃者が仕込んでおく格納型といわれる手法もあります。
例えば、下記のスクリプトを仕込んでおき、ログインページの一部を変更した（confirm.php内にあるsuccess.phpではなく、trap.phpに移行するよう変更し、攻撃者が用意した外部サーバへ転送される）と仮定します。

・trap.php

<!--?php session_start(); ?-->
<h1>LOGIN FORM</h1>
<h2>Please enter your name and password.</h2>
<form action="xss.php" method="get">username:<input name="name" type="text" />
password:<input name="passwd" type="text" />
<input type="submit" value="OK" />
<input type="reset" value="CANCEL" /></form>・xss.php
<!--?php session_start(); ?-->
<script>alert(document.cookie)</script>
<script>alert("XXS attack successfully!");</script>

2度ログイン入力画面が表示されりと思います。
URLを見ると、trap.phpとなっていることがわかりますが、いつも通りのログインの場合、URLまで確認する方はほとんどいないと思います。

このような形で、ユーザが知らぬ間に実行してしまった時点で、XSS攻撃は成立します。

 

2.WAF有効化

それでは、WAFの機能を確認します。

Mod Securityを有効化します。SecRuleEngine OffをOnに変更し、Apacheを再起動します。
# vi /etc/httpd/conf.d/mod_security.conf
SecRuleEngine On
# systemctl restart httpd

まずは、通常通りの動作確認をしておきます。
問題なく動作しました。

では、先ほどと同じようにクッキー情報の表示と、xss.phpページへリンクさせてみますと、下記の通り遮断されました。

ログを確認します。

# tail -f /var/log/httpd/modsec_audit.log

Apache-Handler: proxy-server
Stopwatch: 1481277180308581 937 (- - -)
Stopwatch2: 1481277180308581 937; combined=444, p1=153, p2=276, p3=0, p4=0, p5=15, sr=36, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/); OWASP_CRS/2.2.6.
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips
Engine-Mode: "ENABLED"

--4b7a983a-Z--

--5d1f9b56-A--
[09/Dec/2016:18:54:18 +0900] WEp-SvwuO7p7HhYQ@c9bLwAAAAE <span style="color: #ff0000;">192.168.136.1</span> 58663 <span style="color: #ff0000;">192.168.136.135</span> 443
--5d1f9b56-B--
GET /confirm.php?name=%3Cscript%3Ewindow.location%3D%27http%3A%2F%2F192.168.136.135%2Fxss.php%3F%27%2Bdocument.cookie%3B%3C%2Fscript%3E&amp;passwd= HTTP/1.1
<span style="color: #ff0000;">Host: waf</span>
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://waf/login.php
Cookie: PHPSESSID=v0gpr485icssf93olco0hnf636
Connection: keep-alive
Upgrade-Insecure-Requests: 1

--5d1f9b56-F--
HTTP/1.1 403 Forbidden
Content-Length: 213
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

--5d1f9b56-E--

--5d1f9b56-H--
Message: <span style="color: #ff0000;">Access denied with code 403 (phase 2). Pattern match</span> "(?i:([\\s'\"`\xc2\xb4\xe2\x80\x99\xe2\x80\x98\\(\\)]*?)([\\d\\w]++)([\\s'\"`\xc2\xb4\xe2\x80\x99\xe2\x80\x98\\(\\)]*?)(?:(?:=|&lt;=&gt;|r?like|sounds\\s+like|regexp)([\\s'\"`\xc2\xb4\xe2\x80\x99\xe2\x80\x98\\(\\)]*?)\\2|(?:!=|&lt;=|&gt;=|&lt;&gt;|&lt;|&gt;|\\^|is\\s+not|not\\ ..." <span style="color: #ff0000;">at ARGS:name</span>. [file "/etc/httpd/modsecurity.d/activated_rules/<span style="color: #ff0000;">modsecurity_crs_41_sql_injection_attacks.conf</span>"] [<span style="color: #ff0000;">line "77"</span>] [<span style="color: #ff0000;">id "950901"</span>] [rev "2"] [msg "SQL Injection Attack: SQL Tautology Detected."] [data "Matched Data: script&gt;window found within ARGS:name: <script>window.location='http://192.168.136.135/xss.php?'+document.cookie;</script>"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.6"] [maturity "9"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]
Action: Intercepted (phase 2)
Apache-Handler: proxy-server
Stopwatch: 1481277258844113 726 (- - -)
Stopwatch2: 1481277258844113 726; combined=411, p1=105, p2=295, p3=0, p4=0, p5=11, sr=32, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/); OWASP_CRS/2.2.6.
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips
Engine-Mode: "ENABLED"

--5d1f9b56-Z--

==============================================
しかし、想定とは違う結果が出ました。
XSSのルールセットがありますが、SQLインジェクション攻撃とみなされて遮断されたようです。
意図しない方法で処理されてしまいましたが、こちらの処理を確認します。
設定ファイルは「modsecurity_crs_41_sql_injection_attacks.conf」で、その中に記載されている[line "77"] [id "950901"] というルールで処理されました。
このルールは以下のように定義されていました。（※ルールの基本書式　SecRule VARIABLES OPERATOR [ACTIONS]）
SecRule
VARIABLES＝チェックを実行する変数：
REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/*

VARIABLES
変数 説明
REQUEST_COOKIES リクエストクッキーの値
!REQUEST_COOKIES:/__utm/ リクエストクッキーの値の正規表現
REQUEST_COOKIES_NAMES リクエストクッキー名
ARGS_NAMES リクエストパラメータ名
ARGS POSTペイロードを含むパラメータ、静的パラメータ、または正規表現
XML:/* XML のすべてのエンティティ

 

OPERATOR＝フィルタリングルール：
"(?i:([\s'\"`´’‘\(\)]*?)([\d\w]++)([\s'\"`´’‘\(\)]*?)(?:(?:=|<=>|r?like|sounds\s+like|regexp)([\s'\"`´’‘\(\)]*?)\2|(?:!=|<=|>=|<>|<|>|\^|is\s+not|not\s+like|not\s+regexp)([\s'\"`´’‘\(\)]*?)(?!\2)([\d\w]+)))"

[ACTIONS]＝ルールにマッチした場合のアクションを指示：
"phase:2,rev:'2',ver:'OWASP_CRS/2.2.6',maturity:'9',accuracy:'8',capture,multiMatch,t:none,t:urlDecodeUni,t:replaceComments,ctl:auditLogParts=+E,block,msg:'SQL Injection Attack: SQL Tautology Detected.',id:'950901',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"

ACTIONS
変数 説明
phase:2 リクエスト・ボディを処理
maturity テスト量の相対的な成熟度
accuracy ルール判定の精度
severity ルールに当てはまる重要度

 

上記を踏まえて、この処理の流れを確認します。
①「script>window」の文字列をフィルタリング
②VARIABLESではARGS_NAMEとして検知
③ACTIONSとしてはphase 2で処理し、403で拒否

今回は、mod security（WAF）がどのように機能するか、XSS攻撃を通して動作検証しました。

次回以降は、他OSへのインストール方法、ルールセットの確認、偽陽性判定があった場合の除外方法、独自ルールの作成、などを順次検証していきます。

 

まとめ

・ModSecurity はオープンソースで無償で使用することができる。
・公式ホームページやgithubに、マニュアルがあるが、日本語版はなく、すべて英語で記載されており、ボリュームも比較的多い
・非常に有名な製品のため、他サイトでもブログ形式などで紹介しており、参考になる情報が多数ある

WAFは導入して完結する製品ではなく、導入していきなりしようするのではなく、仕様期間を設け、Detection Onlyでログを確認し、運用していく中で適正なルールを探すことが重要となります。
Webアプリケーションの需要は今後も高く、重要な対策であることは間違いありません。
すべての機能を使いこなせるようになるまでには、非常に時間がかかりますし、慣れや経験が必要です。
しかしながら、根本的な対策ではないため、あくまで弱点を補てんするものとして、導入することをお勧めします。

参考：
Mod Security Trustwave SpiderLabs
Mod Security Reference Manual
独立行政法人 情報処理推進機構　Web Application Firewall 読本
マスタリングTCP/IP情報セキュリティ編