脆弱性の探し方　～発見と対応のノウハウ in NTTDATA～

© 2017 NTT DATA Corporation
脆弱性の探し方
～発見と対応のノウハウ in NTTDATA～
2017/11/24
株式会社NTTデータ生産技術部ソフトウェア工学推進センタ
浅原舜平

© 2017 NTT DATA Corporation 2
はじめに

自己紹介
浅原舜平
株式会社NTTデータ
技術革新統括本部
システム技術本部生産技術部
ソフトウェア工学推進センタ
TERASOLUNA FW開発チーム所属
- セキュリティ

TERASOLUNAフレームワークのコンセプト
エンタープライズ利用における当社知見をベースに、
Springを最大限活用したフレームワークへ
Spring IO Platform
Spring
Security
Spring
MVC JPA
MyBatis
1. OSSを組み合わせ、独自部分を極小化
2. OSSの機能を最大限に活かして開発するた
めのベストプラクティスを提供することに注力
開発ガイドライン
http://terasolunaorg.github.io/

本題

6© 2017 NTT DATA Corporation
1. 背景
2. なぜ、取り組んでいるのか？
3. 脆弱性の探し方
4. 報告・対応のノウハウ
5. まとめ
目次

「Spring」、「脆弱性」というキーワードで心配になる人もいるかもしれまんが、
Spring FWはキケンなのでしょうか？
Spring FWはキケンなのか？

「Spring」、「脆弱性」というキーワードで心配になる人もいるかもしれまんが、
Spring FWはキケンなのでしょうか？
NO!
小さいものが年に2-3個見つかる程度
Spring FWはキケンなのか？
Spring FWでは今のところ、
ニュースで騒がれるような重大な脆弱性は報告されていません
現時点では

背景

背景
近年、セキュリティに対する世の中の関心は高まっており
ニュースで取り上げられることも多くなっています
https://www.ipa.go.jp/security/ciadr/vul/20170914_blueborne.html
https://www.ipa.go.jp/security/ciadr/vul/20171017_WPA2.html
https://www.ipa.go.jp/security/ciadr/vul/20170514-ransomware.html
いずれも情報処理推進機構情報セキュリティに関するニュースリリース

共通脆弱性識別子（Common Vulnerabilities and Exposures: CVE）
→1つの脆弱性につき、ユニークなCVEが発行される
→MITRE社が払い出し、管理している
→2016年はCVE-2016-10699まで発行された
→2017年はCVE-2017-16867まで発行されている（11月現在）
2016/17年の脆弱性
ここ最近、脆弱性は年間1万件以上発生しています
CVE-2017-xxxx
4桁では足りなくなっている

WebAP/Java分野でのニュース
WebAP/Javaの分野も例外ではなく
重大インシデントに繋がる脆弱性が報告されています
情報処理推進機構 https://www.ipa.go.jp/security/ciadr/vul/20170308-struts.html

• Webアプリにおける脆弱性で代表的なもの
- XSS（クロスサイトスクリプティング）
- SQLインジェクション
- RCE（リモートコード実行攻撃）
- パストラバーサル etc…
• 特に、被害が拡大するケース
- リモートコード実行可能なもの、データ改ざん・読み取り
→個人情報・クレジットカード情報の流出に繋がるケースも
基礎知識
脆弱性とは、プログラムの不具合や設計上のミスが
原因となって発生した情報セキュリティ上の欠陥

問題提起
脆弱性に対して、
開発者は何をする必要がある？

問題提起
何をやるべき？
そもそも意識
しないとダメ？
どこまで
やるべきなの？
危機感は
あるんだけど、、、

今日のテーマ

TERASOLUNA FWとして
どんな取り組みを行っているか紹介します！
今日のテーマ

TERASOLUNA FWとして
どんな取り組みを行っているか紹介します！
今日のテーマ
「探す」活動まで行っています！

なぜ、取り組んでいるのか？

そもそも、なぜ取り組んでいるのか
TERASOLUNA FWは古くはStruts1をメインFWに据えて
2007年から展開していました
業務アプリケーション
Struts1 iBATIS
独自フレームワーク層
Spring IO Platform
Spring
Security
Spring
MVC JPA
MyBatis
開発ガイドライン開発ガイドライン
2007年 2016年

そもそも、なぜ取り組んでいるのか
TERA FWは古くはStruts1をメインFWに据えて
2007年から展開していました
Struts1 iBATIS
Spring IO Platform
Spring
Security
Spring
MVC JPA
MyBatis
2007年 2016年
当時から、脆弱性対応も
FW開発者としての責務・
サポートの一環として実施

取り組みのサイクル
収集
分析対処
脆弱性情報の収集
影響確認と
対策立案
情報展開や
修正版リリース
当時から、FW開発者としての責務・サポートの一環として
脆弱性に対する取り組みを実施しています。

2014年4月
Struts1
ClassLoader脆弱性が発生

Struts1の話
取り組みの必要性を再確認すると同時に、
改善が必要と再認識！
http://www.nttdata.com/jp/ja/news/information/2014/2014042801.html

Struts1脆弱性からの学び
取り組みの必要性を再確認すると同時に、
改善が必要と再認識！
収集
分析対処
がんばって対処すること
も大切だが、、、
脆弱性を探して
被害を未然に防ぎたい！

Struts1脆弱性からの学び
収集
分析対処
脆弱性を「探す」
公知の脆弱性を対応するだけではなく、
未知の脆弱性を「探す」活動も必要！

Spring FWに対しても
TERASOLUNA FWのメインOSSがSpring FWに移行してからも
脆弱性を「探す」取り組みまで実施しています！
Struts1 iBATIS
Spring IO Platform
Spring
Security
Spring
MVC JPA
MyBatis
2007年 2016年

脆弱性の探し方

取り組み概要
収集
分析対処
脆弱性を「探す」
脆弱性を「探す」活動を含め、情報収集から解析・対応まで
一貫した取り組みを実施しています
再掲
情報展開や
修正版リリース
影響確認と
対策立案

「探す」とは
脆弱性を「探す」活動とは
攻撃コード（PoC）を「探す」ということ！
PoC（Proof of Concept）とは：
脆弱性対応の文脈では
脆弱性をつく攻撃コード＝ exploit
という意味で用いられる。
PoCの重要性：
PoCがあるかどうかで解析の難易度・速度が大きく変わる。
また、脆弱性の影響範囲を正確に把握するには、PoCの存在が必
要不可欠である。

「探す」活動の概要
「探す」という活動に対して、
外的・内的な活動でアプローチしています
外的：
情報収集
内的：
コードレビュー
design-vector http://design-vector.hatenablog.com/entry/2015/09/16/090000
みふねたかし「いらすとや」 http://www.irasutoya.com/2013/07/blog-post_8147.html

外的：
情報収集
内的：

脆弱性に対応するためには
できるだけ「新鮮」で「正確」な情報が必要になります
そしてその情報を「もれなく」「いちはやく」キャッチすることが重要です
OSSコミュニティの監視
・Springをはじめ、TERASOLUNA FWで利用している全てのOSSが対象
- 新しい脆弱性情報が公開されていないか
- 攻撃コードが世の中に出回っていないか
・OSINT活動
情報収集
外的なアプローチ：
日々の情報収集は取り組みの基礎！

OSINT活動とは
githubやJIRAの情報に対してOSINT活動することで
脆弱性やPoCの情報を探しています！
オープンソースインテリジェンス(open source intelligence：OSINT)活動
もともとは諜報活動の分野のひとつ。
「合法的に入手できる資料」を「合法的に調べ突き合わせる」手法。
github/JIRAのissueで議論中の話題から脆弱性を先んじて検知したり、
脆弱性の修正コミットに含まれるテストコードからPoCを割り出したり、
機械的には収集できないような脆弱性情報をいち早くキャッチし、速やかな対
応に繋げている。

外的：
情報収集
内的：

公知の脆弱性を対応するだけではなく、
未知の脆弱性を「探す」ための活動も必要
この活動によって、脆弱性のリスクを未然に防ぎ、
脆弱性に対するノウハウを蓄積しています。
ソースコードレビュー
・Springをはじめ、TERA FWで利用している全てのOSSが対象
・一般的なコードレビューとは異なる観点が必要になる
・いくつかの戦略を立てて実施している
ソースコードレビュー
内的なアプローチ：
ソースコードレビューを実施しています！

• その１：What
- 仕様どおりに実装されているか確認する
• その２：When
- 新機能やアップデートした部分を確認する
• その３：Where
- モジュール間の整合性を確認する
• その４：How
- 他のOSSで話題になっている脆弱性を確認する
コードレビューの戦略

脆弱性とは何か？
脆弱性はバグの延長線上！
なので、バグを見つける工程を意識する
仕様・JavaDocの記載どおりに実装されているか確認する。
特に、FWから外部のOSSを利用している場合、注意が必要。
そのOSSの仕様や注意書きが変わっており脆弱性となることがある。
デシリアライズを実現するOSSなどで注意が必要
その１：What
仕様どおりに実装されているか確認する！

こんなケースだと、どちらの脆弱性か？（ケース１）
FWMarshaller 利用
脆弱性
脆弱性の影響を受ける
使い方をしている場合

こんなケースだと、どちらの脆弱性か？（ケース１）
FWMarshaller 利用
脆弱性

こんなケースだと、どちらの脆弱性か？（ケース２（CVE-2017-9805:S2-052 ））
FWMarshaller 利用
脆弱性
脆弱性が存在します。
回避策は～です。
公式アナウンス

こんなケースだと、どちらの脆弱性か？（ケース２（CVE-2017-9805:S2-052 ））
FWMarshaller 利用
脆弱性
脆弱性が存在します。
回避策は～です。
公式アナウンス
利用しているOSS全ての脆弱性情報を収集し、
正しい使い方ができているかレビューする

• その４：How

いつ脆弱性は作りこまれるのか？
新機能の追加や修正した時
（特に脆弱性の修正）
その２：When
新機能やアップデートした部分を確認する！
新機能
11%
修正漏れ
22%
その他
67%
Spring Framework/Security
脆弱性全体（18個）の
33%を占めている

• その４：How

どこで脆弱性は作りこまれるのか？
モジュール間で
動作が異なる部分
Spring MVCとSpring Securityでのパスマッチング
APサーバとの連携
アクセス制御すり抜けやパストラバーサル脆弱性に繋がる可能性がある
その３：Where
モジュール間の整合性を確認する！

具体例：Spring Securityでのアクセス制御のメカニズム
Spring Security
Spring MVC
リクエストのパス
をURLデコード
<sec:intercept-url ~>
とパス比較
パスパラメータ
を削除する
を削除する
request =
/foo;[path parameter]~
@RequestMapping(~)
とパス比較
パスパラメータを
削除してから
URLデコード

具体例：CVE-2016-9879のメカニズム
Spring Security
Spring MVC
をURLデコード
とパス比較
を削除する
を削除する
request =
@RequestMapping(~)
とパス比較
をURLデコード
APサーバに依存して
処理の中身が変わっている

具体例：CVE-2016-9879のメカニズム
Spring Security
Spring MVC
をURLデコード
とパス比較
を削除する
を削除する
request =
@RequestMapping(~)
とパス比較
をURLデコード
要注意な文字列（OWASPより）： < > ” ‘ % ( ) & + ¥ ¥’ ¥” など
Spring Securityのアクセス制御はすり抜るが、、、
Spring MVCとパスマッチングしてしまう

• その４：How

どのように脆弱性を「探す」か？
その他のOSSで見つかっている脆弱性についても
Spring FWへ横展開して調査
我々はSpring以外のOSSに対しても脆弱性調査も実施している
例えば、Struts2で話題になっているOGNL式
からよく似た機能を実現している
SpEL式へ横展開など
その４：How
他のOSSで話題になっている脆弱性を確認する！

以下のような実装をしてしまえば、OSコマンドが実行される
FWの中でSqelExpressionParserが実装されているときに、引数が検証された
値ではなく、ユーザが入力した任意の値を受け付けるような実装をしていれば
RCE（リモートコード実行攻撃）が成立する。
そういった実装があるかどうかを確認する
SpELへの横展開の具体例
検証された値をFW内で
受け渡しているだけなら問題ないが、、、

• その４：How

取り組みの成果
こうした取り組みの結果、
昨年は2件脆弱性を報告しました！
CVE-2016-9878 Directory Traversal in the Spring Framework ResourceServlet
CVE-2016-9879 Encoded “/” in path variables
CVE-2014-3625 Directory Traversal in Spring Framework
CVE-2015-3192 DoS Attack with XML Input
CVE-2015-5211 RFD Attack in Spring Framework
直近、3年間では15件の脆弱性のうち、
5件の脆弱性報告にNTTデータが寄与しています！

報告・対応のノウハウ

・脆弱性は再現性があるか
- どういう条件下で発生するのか
- 最新のバージョンで影響があるか？
・似た攻撃方法・発生条件があるか
・何を実現できる脆弱性か
・どうやったら対策できるか
- 対策方法・軽減策・修正案など
・影響範囲（プロダクトやバージョンなど）はどこまでか
見つけたら何をすべきか？
報告する！の前に
やらなくてはいけないことがあります
発見！
報告！
以下のような情報を整理し、社内のCERT組織と連携しておく

・信頼できる窓口に報告する
- github/JIRAなどのpublicな場所に投稿しない
- 修正前にpublicにするとゼロデイ攻撃になりえる
・修正案も提示する
- 攻撃コードやメカニズムだけ報告しても調整が長引く
- 修正案があるとスムーズに話が進む（ケースが多い）
・パッチのレビューする
- 先方でパッチが作成されるとレビューをお願いされる
- 修正漏れがないか、デグレがないか確認する
・公開までのスケジュールを確認しておく
- パッチリリースの予定など
- 修正対象のプロダクトやバージョンも確認しておく
報告～公開までに気をつけるべきことは？
いざ、報告！となっても、公開されるまで
気を抜いてはいけません！
発見！
報告！

一般的な報告ルート（IPA「早期警戒パートナーシップ」資料より）
早期警戒パートナーシップとは？
脆弱性関連情報の適切な流通を実現するために、
関係者に推奨する行為をとりまとめたもの
IPA「早期警戒パートナーシップ」資料より
https://www.ipa.go.jp/files/000059694.pdf

Spring FWの場合の報告ルート
発見者から直接の届出を受け入れる旨を受諾している
製品開発者の場合、直接届け出ることも可能
～「2. 発見者の対応 3) 脆弱性関連情報の届出」より～
IPA「早期警戒パートナーシップ」資料より
https://www.ipa.go.jp/files/000059694.pdf

見つかったものを対応するケースが
多いかもしれません
しかし、実際には、、、

・PoCが世の中に出回っていないか
出回っていれば、再現できるかどうか
・脆弱性の概要
何を実現する脆弱性か、どのような条件で発生するか
・修正バージョンは脆弱性を防げているか
PoCがあればそれを起点に攻撃確認やレビュー
ない場合は修正箇所のレビューなど
その他のデグレについても確認する
・影響プロダクト・バージョンはどこまでか
最新情報をキャッチアップすること
公開された脆弱性を対応する際に気をつけること
影響範囲・内容を正しく理解し、
正しい対処を実施すること！
公開！
以下の情報を確認し、対処方法を立案する

・PoCが世の中に出回っていないか
出回っていれば、再現できるかどうか
・脆弱性の概要
何を実現する脆弱性か、どのような条件で発生するか
・修正バージョンは脆弱性を防げているか
PoCがあればそれを起点に攻撃確認やレビュー
ない場合は修正箇所のレビューなど
その他のデグレについても確認する
・影響プロダクト・バージョンはどこまでか
公式アナウンスを鵜呑みにしない！
公開された脆弱性を対応する際に気をつけること
影響範囲・内容を正しく理解し、
正しい対処を実施すること！
公開！
以下の情報を確認し、対処方法を立案する
対応は迅速に！しかし過剰に反応しすぎないこと！
リスクを正しく見積もることが大切！

まとめ

問題提起

まとめ
NTTDATAでは、TERASOLUNA FWに関係する脆弱性に対して・・・
①．日々、OSINT活動などを駆使して情報収集しています！
②．戦略をもってコードレビューを実施しています！
③．報告・対応のノウハウをもっています！
脆弱性を「探す」活動まで
実施しています！

世の中に公表されていないからといって、誰も見つけていないとは限りません！
悪意のある攻撃者だけが知っていて攻撃しているケースもあるかもしれません！
そういった可能性を排除し、OSSをセキュアにするためには、
脆弱性がどんどん見つかったほうがよいですよね！
提言
OSSにとって、脆弱性が見つかるというのは
不幸なことでしょうか？
脆弱性を探しましょう！
Springをセキュアにしていきましょう！
セキュアなSpringを使いましょう！

まとめ
NTTDATAでは、TERASOLUNA FWに関係する脆弱性に対して・・・
①．日々、OSINT活動などを駆使して情報収集しています！
②．戦略をもってコードレビューを実施しています！
③．報告・対応のノウハウをもっています！
脆弱性を探しましょう！
Springをセキュアにしていきましょう！
セキュアなSpringを使いましょう！

© 2017 NTT DATA Corporation
「TERASOLUNA」及びそのロゴは、日本及び中国における株式会社NTTデータの商標または登録商標です。
その他、記載されている会社名、商品名、サービス名は各社の登録商標または商標です。

最後に
今後もSpringを中心に各種OSSの
ベストプラクティスを提供し続けます
今回の話やTERASOLUNAに興味がある方は下記までご連絡ください
TERASOLUNA窓口
E-mail: terasoluna@am.nttdata.co.jp
電話: 050-5546-2482（平日10時〜18時）
Springをエンタープライズシステム開発で積極的に活用し、
情報交換やコミュニティ活動を活発化して
さらなるSpringの発展、繁栄に向けて共に歩んでいきましょう。
http://terasolunaorg.github.io/

脆弱性の探し方 ～発見と対応のノウハウ in NTTDATA～

More Related Content

What's hot

Similar to 脆弱性の探し方 ～発見と対応のノウハウ in NTTDATA～

More from apkiban