こんにちは。Vuls Slackチーム辺りをうろうろしている、井上と申します。 MORIO Dojoは白帯のままです(そろそろ青帯になりたい)。 某SNSでは、脆弱性情報やセキュリティインシデントを追いかけています。
近年、セキュリティ業界でも「シフトレフト」が叫ばれています。 「テストなどの工程を、プロジェクトライフサイクルのより速い段階で実施する」というアプローチです。 セキュリティに関しても同様で、リリース前にテストをすることで、リリース後のセキュリティ対応負荷を軽減することができます。
今回は、WEBアプリケーションの依存ライブラリの脆弱性を検査する OWASP Dependency Checkを利用して、WEBアプリケーションリリースのシフトレフト、を目指します。
OWASP Dependency Checkとは
OWASPとは、2015年の資料によると以下のように説明されています。
OWASPは、「The Open Web Application Security Project」の略称であり Webアプリケーションのセキュリティ向上や、セキュアなWebサービスの展開を目的として 2001年12月01日に設立されたグローバルなオープンなコミュニティです。 現在、世界198ヶ国ローカルチャプター(現地支部)があり、43,000人以上の メーリングリスト参加者が様々なプロジェクトに参加しています。
そのOWASPから、プロジェクトの依存関係から既知の脆弱性がないかをチェックするユーティリティとして Dependency Checkが公開されています。Javaと.NETがサポートされており、部分的に Ruby, Node.js, Python, C/C+(autoconf, cmake)サポートをしています。
ざっくりいうと、「対象のWEBアプリケーションで古いコンポーネント依存の脆弱性がないかを確認する」為のものです。
概要
リリース前のWebアプリケーションをスキャンする、というシチュエーションを想定してみます。
- Javaアプリケーションとして、Apache Struts2を用意します
- Java以外のRuby、Node.js、Pythonなども限定的ながらチェックができる可能性があるので、 一度試してみることをお勧めします
- VulsサーバーとOWASP Dependency Checkをするサーバーは、別サーバーとします。同一サーバーでも問題ありません
説明の為、以下のような構成とします。
- Vulsサーバーを、Vulsコミュニティテンプレートから作成する
- 開発用WEBサーバーとして、CentOS6のテンプレートから作成する
- 開発用WEBサーバーで構成したアプリケーションを、OWASP Depencency Checkで検査する
- 検査後のアプリケーションを、本番WEBサーバー等(今回は構成せず)に展開する
試してみる
WEBアプリケーションを用意する
今回は、Apache Struts2(現時点の最新版の 一つ前 である 2.3.2)を用意します。 アプリケーションの動作の脆弱性検査(ペネトレーションテスト等)はしないので、Struts2単体を検査します。
$ mkdir tmp $ cd tmp $ wget http://archive.apache.org/dist/struts/2.3.32/struts-2.3.32-all.zip $ unzip struts-2.3.32-all.zip $ ls struts-2.3.32 struts-2.3.32-all.zip $
OWASP Dependency Checkの環境を用意する
OWASP Dependency Checkは Javaが必須であるため、導入します。 実行ファイルは展開したディレクトリの bin/dependency-check.sh です。 個人的には、/opt/OWASP/Depencency-Check/ 辺りにインストールするべきと思っています。
$ sudo yum install java $ wget http://dl.bintray.com/jeremy-long/owasp/dependency-check-2.0.1-release.zip $ unzip dependency-check-2.0.1-release.zip $ ls dependency-check/bin/ dependency-check.bat dependency-check.sh $ ./dependency-check/bin/dependency-check.sh -v Dependency-Check Core version 2.0.1 $
OWASP Dependency Checkで検査する
先ほど導入した OWASP Depencency Checkで、Apache Struts2.3.32を検査します。
初回の検査ではNVDのCVEをダウンロードするため、多少時間がかかかります。
$ ./dependency-check/bin/dependency-check.sh --format HTML --project projectName --scan ./tmp/struts-2.3.32 --out ./result.html [INFO] Checking for updates [INFO] Skipping NVD check since last check was within 4 hours. [INFO] Check for updates complete (54 ms) [INFO] Analysis Started [INFO] Finished Archive Analyzer (15 seconds) [INFO] Finished File Name Analyzer (0 seconds) [INFO] Finished Jar Analyzer (9 seconds) [INFO] Finished Central Analyzer (124 seconds) [INFO] Finished Dependency Merging Analyzer (0 seconds) [INFO] Finished Version Filter Analyzer (0 seconds) [INFO] Finished Hint Analyzer (0 seconds) [INFO] Created CPE Index (7 seconds) [INFO] Finished CPE Analyzer (14 seconds) [INFO] Finished False Positive Analyzer (0 seconds) [INFO] Finished Cpe Suppression Analyzer (0 seconds) [INFO] Finished NVD CVE Analyzer (3 seconds) [INFO] Finished Vulnerability Suppression Analyzer (0 seconds) [INFO] Finished Dependency Bundling Analyzer (0 seconds) [INFO] Analysis Complete (171 seconds) $
出力形式をHTMLとしているため、HTMLが出力されています。人間は読みやすいですが、Vulsやその他のプログラムと連携するには少し難しい形式です。
検査結果をVulsと連携させる
まずはVuls等と連携しやすいように、XMLフォーマットで出力します。
$ ./dependency-check/bin/dependency-check.sh --format XML --project projectName --scan ./tmp/struts-2.3.32 --out ./result.xml $
ここで出力されたXMLファイルを、Vulsサーバーからアクセスできるようにします。
今回は、Vulsのコミュニティテンプレートに従い、/opt/vulsの下に配置します。NFS等でのアクセスでも問題ないです。
その後、Vulsのコンフィグを編集し、scan, reportを実行します。
[vuls@vulsserver ~]$ cd /opt/vuls/ [vuls@vulsserver vuls]$ vi config.toml ======================= ... [servers.vuls-server] host = "localhost" port = "local" dependencyCheckXMLPath = "/opt/vuls/result.xml" <--ここを追加 ... ======================= [vuls@vulsserver vuls]$ vuls scan [vuls@vulsserver vuls]$ vuls report -to-localfile -format-json [vuls@vulsserver vuls]$
結果を読む
VulsRepoで結果を確認します。
- Packagesに cpe:/ で始まるものとして、登録されています
- cpe:/a:apache:tomat:6.0.18 など
- cpe:/a:apache:tomat:6.0.18 など
利用している(依存している)Tomcatなどの脆弱性がこれでわかるので、リリース前にアップデート等を行って、リリース時に脆弱性が残らないようにしましょう。
- 脆弱性対応を、運用ではなく、開発側に「シフトレフト」しましょう。その方が、対策コストは少なくて済みます
Vulsの今後
Vulsですが、今後、OVALに対応予定です。現時点では08月末付近を予定しています。これにより、検知精度の向上等が見込まれます。
リリース後、既存コミュニティテンプレートを更新する方法を公開する予定です。
おわりに
脆弱性対応は運用で行うもの、という環境が多いかと思います。しかしながら、Webアプリケーションのリリース後の修正は運用では難しいです。そのため、開発段階でセキュリティを考慮したテストを行うことで、リリース時点で既知の脆弱性を作りこまないことが重要です。
また、今回は既知の脆弱性を検知しましたが、WEBアクセスを伴った脆弱性診断もこの段階で行うのが良いと思われます。OWASPでは OWASP Zed Attack Proxy (OWASP ZAP)も公開しています。利用には脆弱性に対する知識が必要ですが、機械的に自動スキャンする製品よりは自由度が高いです。
OWASP ZAPについては、例えば脆弱性診断研究会で実施している 「脆弱性診断ええんやで(^^)」という勉強会等で、利用方法を学ぶことができます。
OWASPには、Webアプリケーション開発時に有用な情報がありますので、一度確認されることをお勧めします。