本サイトは、快適にご利用いただくためにクッキー（Cookie）を使用しております。
Cookieの使用に同意いただける場合は「同意する」ボタンを押してください。
なお本サイトのCookie使用については、「個人情報保護方針」をご覧ください。
9月12～13日に米国ワシントンDCで開かれたOWASPカンファレンスに参加しました。OWASPのカンファレンスにはRegionalとGlobalの2種類がありますが、今回参加したのは年に数回開かれるGlobalの一つで、世界中からWebセキュリティの研究者が会して発表を行う場です。
以下、筆者が参加した初日のセッションについて簡単に報告します。
※ 各セッションの公式ページのURLを記していますが、そこにはスライドへのリンクはありません。スライドのURLが分かるものは、別途そのURLを記しています。
■ A Structured Code Audit Approach to Find Flaws in Highly Audited Webapps
Simon Scannell @ RIPS Techinologies
Highly auditedなWebアプリの脆弱性を発見するための、ソースコード診断の手法がテーマです。取り上げているソフトウェアはWordPress（以下WP）です。WPはご存じの通りとても有名なオープンソースのソフトウェアであり、多くの人がバグ探しに挑んできました。そのため、定番のシンプルなシンク・ソース分析で（プラグインは別として）コア部分の良いバグを発見するのは困難です。その中でRIPSは多くの脆弱性を発見しており、その例を挙げながら手法を解説していました。
個別の脆弱性についてはRIPS社のブログに分かりやすい解説があるので、ここでは割愛します。
筆者の理解したところの氏らの手法の要点は、
- 対象のソフトウェアをコンポーネントに分割する
- 各コンポーネントの機能をよく理解して単体では低いリスクのバグを見つける
- 見つけた低いリスクのバグを複数組み合わせて高いリスクのバグに仕上げる
というやり方です。
PHPのソースコード診断ツールで知られるRIPS社（独）の研究者であるScannell氏による発表です。RIPS社は自社の研究者が発見した様々なソフトウェアの脆弱性をブログで解説しており、筆者もよく記事を読んでいます。
セッションで説明された、複数のバグを組み合わせたものは「バグチェーン」とも言われます。通常のWeb診断では複数のバグを組み合わせることは余りないと思いますが、高リスクの脆弱性に大きな価値があるBug Bountyやペンテストのような状況では、バグをチェーンすることは一般的だと思います。
実際、筆者が昨年報告したスマホのバグチェーンも3つのバグを組み合わせてRCEに仕上げましたし、11個のバグをチェーンしたRCEの事例も聞いたことがあります。筆者のやり方だと、まず最初に核となるバグを探して、後はうまくチェーンとしてまとめるために手持ちのバグを使ったり、不足する部分を埋める別のバグを探すというイメージです。
ところで、このセッションに私が期待したのはタイトルにある「Structured approach」だったのですが、実際のところのは個別の脆弱性の面白さが発表の眼目になってしまっていた感があります（氏が発見したWPのバグはPwnie Award 2019にもノミネートされており、バグの内容だけで充分面白い訳ですが）。
結局のところ、バグをチェーンするところなどは特に、勘と知識と経験と粘り強さがものをいう世界であり、方法論だけで何とかなるものではないのでしょう。ただし（同社のものを含めて）何らかのツールによってフローを追う部分を自動化できれば、作業の効率化ができるケースは結構あるだろうと思いました。
■ Owning the Cloud through SSRF and PDF Generators
https://globalappsecdc2019.sched.com/event/Ur5M/owning-the-cloud-through-ssrf-and-pdf-generators
Ben Sadeghipour @ HackerOne
筆者はこのセッションには出ていないのですが、面白い内容なのでスライドだけを見ながらメモを書きます。そのためOWASPでの発表とは内容が異なる部分があるかもしれませんがご了承ください。ちなみに筆者が見ているのは、同じ研究者が似たタイトルで講演した今年のDefconのスライドです。
前半の「Owning the Cloud through SSRF」の箇所は、こういうブログを読んでいる方であればピンとくる内容だと思うので、ざくっと割愛します。
興味深いのは後半のPDF Generatorsの攻撃の方です。PDFの帳票を動的に生成してユーザに提供するサイトは昔からありますが、近年はPDFを生成する昔ながらのライブラリを使わないサイトが増えています。そういうサイトでは、HTMLで帳票を組み立てて、PDF出力機能を持つHTMLレンダラで処理してPDF化する方法がとられていることがあります（下図）。
スライドでは、その種の処理に使われるHTMLレンダラの例としてwkhtmltopdfやヘッドレスChromeなどを挙げています。
一般にSSRF攻撃の可能性が出てくるのは、レンダラに渡すHTMLを組み立てる際に、適切なエスケープなしで入力値をHTMLに埋め込んでいるケースです。XSSと似ていますが、通常のXSSであれば生成したHTMLをレンダリングするのはクライアント側のブラウザであるところ、このケースではサーバサイドのレンダラがHTMLをレンダリングします。いわば「サーバサイドのXSS」が発生している訳です。
このXSSで何ができるかは、レンダラ側でJSが有効か、ページのオリジン、リダイレクトやiframeなどが使用できるか、レンダリングした結果が得られるか、レンダラのソフトウェアの種類、等々によって異なりますが、ローカル（fileスキーム）のファイルの中身を窃取したり、クラウドであればメタデータ（http://169.254.169.254/...）を取得したりできることがあります。
単純な攻撃は下記のような方法で、指定したURLの中身を窃取します。
指定したURLの応答がPDF内に出力される
<iframe src=[取得したいURL]></iframe>XHRでURLの応答を取得
<script>xhr=new XMLHttpRequest() ... xhr.open("GET","[取得したいURL]");他にも、リダイレクト、DNSリバインディング、link（rel=attachment）などの攻撃に使える要素がスライドで説明されています。また診断で使用できそうなツールの説明も最後の方にあります。
興味深いのはやはり後半のPDFの攻撃です。特にlinkを使った攻撃は面白い攻撃方法だと思いました（詳細はDefconスライドを参照ください）。
なお、筆者自身は実例を見たことはありませんが、弊社の診断でもPDF生成時の脆弱性を検出したことがあり、ローカルのファイルの中身の窃取できた例もあります。PDFに限らず、サーバサイドでのレンダリングが普通になる（かもしれない）状況を踏まえて、昨年弊社のWebアプリ診断ツールに対応するシグネチャを実装したところです。応答にエコーバックする想定のシグネチャや、タイムベースのシグネチャがあり、PDF内へのエコーバックについてはPDFからテキストを抜き出して判定を行う仕組にしました。
■ OWASP Find Security Bugs: The community static code analyzer
Philippe Arteau @ GoSecure
OWASPのプロジェクトの1つであるFind Security Bugs（FSB）の紹介です。FSBはFindBugsの流れをくむSpotBugsのプラグインであり、その名の通りWebアプリなどのセキュリティバグを発見するものです。
対応しているバグのパターンは131種類とのことです。主要な脆弱性タイプは下記の写真のとおりです。
発表スライドJavaのバイトコードを解析する方式であるため、Java VMで動作する言語に対応しています。AndroidのAPKも（Dex2JarでJarに変換すれば）解析できるそうです。ただし、検出した脆弱性とソースコードとのマッピングが正しくできる言語は、純粋なJavaやJSPなどに限られています。
最後にFSBによって検出した、Struts2、Apache Derby、Spring Data Commonsの脆弱性の例を紹介していました。
発表者のArteau氏は脆弱性のある古いJSファイルを検出してくれるRetire.jsの開発者でもあります。
氏はGoSecureという会社に所属しており、FSBのGitHubページには同社がスポンサーとして挙げられています。米国滞在中に別の現地のセキュリティ企業の方と話をする機会があり、その時に聞いたのですが、社員が個人でプロジェクトを立ち上げて、会社がそれを支援するというのは、米国では割と一般的なようです。
筆者はFSBを使ったことはないのですが、FSBはデータフロー解析を行うため、明らかなFalse Positiveは取り除けますし、自分でルールを追加することもできます。本格的にJavaのソースコード診断をする際にはツールの候補になるだろうと思いました。
■ Quantifying the Security Benefits of Debloating Web Applications
Babak Amin Azad @ Stony Brook University
途中からの参加なので、ネット上のペーパー（USENIX）も参照しながらメモを書きます。
タイトル内の「Debloating」は「余分なものを取り除く」という意味の単語です。パッケージソフトタイプのWebアプリには、通常のユースケースでは使わないコードが大量に含まれており、これが脆弱性の原因になることがあります。そのような余分なコードを取り除くことで、既知あるいは今後発見されるかもしれない脆弱性の影響を受けないようにすることができる可能性があります。
OSやライブラリなどではセキュリティ対策としてのデブローティングが既に試みられているそうですが、それをWebアプリを対象に試行してその効果を測定した研究です。雰囲気的にお分かりかもしれませんが、大学のアカデミックな研究です。
デブローティングの対象は、古い既知の脆弱性がある4つのPHPアプリ（phpMyAdmin、MediaWiki、Magento、WordPress）です。大まかにいうと、研究では、
- ① 脆弱性の原因となるコードを特定する
- ② Webアプリのコードのうち不必要な部分を洗い出す
- ③ 不要な部分をファイル単位 or 関数単位で削除する
- ④ コード量や影響を受ける脆弱性数がどれくらい減るか調べる
肝となるのは、②の不要な部分の特定です。研究では、サーバでデバッガを有効にしておいた上で、クローラや脆弱性スキャナによる自動的な巡回・スキャンを行ったり、操作チュートリアルを利用した半自動的な巡回を行ったりして、使われているコードとそうでないコードを調べています。
最終的に、使われていないとみなされて削減されたコード量は、ファイル単位の削除で33.1%、関数単位の削除で46.8%だったそうです。それにより除去された脆弱性は60%との結果が得られたそうです。
発表では脆弱性の種類ごとの除去率なども提示されていました。詳細は氏のペーパーを参照ください。
汎用的なソフトウェアには、通常のユースケースでは明らかに不要なコードが多くあります。しかし、突き詰めていくと、正常なアクセスを定義することは困難であり、必要/不要なコードの境界線は曖昧です。そこがデブローティングを行う際に一番の悩みどころなのだろうと思いました。
そういう意味でいうと、少々研究の趣旨とはずれた話にはなりますが、WPなどのソフトウェアの開発者側が「Off by default」を徹底して、自らデブローティング的なことをすることが、（ソフトウェア利用者の手間は増えるものの）一番なのだろうと思いました。
後で思い付いたのは、言語によってはランタイムでデブローティング的なことをするアプローチもあるということです。まずは学習モードで必要/不要なコードを判別して、学習後は使っていないコードに処理が移った際に実行を止めたり、警告を出すような仕組みです。
発表を聞いていてなるほどなと思ったのは、仮に呼び出される可能性がないデッドコード的な部分があるとして、それを削除することがセキュリティ上のメリットになるのかという話です。呼び出されないコードであれば、その部分の脆弱性を悪用しようがないはずですが、「通常は到達可能性がないコードもPOI（PHP Object Injection。デシリアライズ攻撃）のガジェットとしては呼び出されうる」との説明がありました。確かにPOIやリフレクション系の攻撃については、ロード可能な状態になっているクラスは全て悪用される可能性があり、コードを削除する意味は出てきます。
■ まとめ
純粋に筆者の時間の都合ですが、初日に筆者が参加した主なセッションのみを取り上げました。
2日間のセッション全体を見ると、DevSecOpsを取り上げたものが多かったです。次に筆者の目についたのは、サーバレス、クラウドといった単語です。あとは全体としてディフェンシブなセッションがやや多い印象でした。
各セッションの出席者は30～60名くらいで、ややこじんまりしたカンファレンスでした。筆者が2012年に参加したOWASPカンファレンス（テキサス州オースティン）と比べて、若干スケールダウンしたような気もします。なお、日本から遠い東海岸のイベントということもあってか、日本人と思われる参加者は非常に少なかったです。
少々こじんまりしてはいますが、同時並行で6セッションが行われて、それらすべてが基本的にWeb関連なので、毎時間どれに出るかかなり迷います。Webセキュリティ好きな人であれば楽しめて、かつ何かしら得るものがあるカンファレンスだと思います。
おすすめ記事
