axiosの脆弱性解析事例（JVNDB-2020-013151）
はじめに
この記事では、axiosの脆弱性（JVNDB-2020-013151）を題材に、エンタープライズ系案件の脆弱性対応について紹介したいと思います。
この記事で題材にするエンタープライズ系案件の特徴としては、例えば大規模で自動テストも無く、簡単にはバージョンアップが出来ないような案件ということにしましょう。
そんな状況あるの？と思う方も居るかもしれませんが、これ、SIerの受託開発案件ではよくある状況といっても過言ではありません。
おおまかな流れとしては、脆弱性がシステムに与える影響を調査して、その後対応方針を検討し、対策を行います。
最初に、脆弱性がシステムに与える影響の調査から始めましょう。
影響調査
脆弱性の検知と脆弱性対策情報データベース
GitHubでソースコードを運用していれば、GitHub Advisory Databaseで脆弱性が通知されることでしょう。
この記事で題材にしている脆弱性はこちらです。共通脆弱性識別子（CVE）をキーワードに情報収集も出来ますが、JVN iPedia - 脆弱性対策情報データベースで情報公開されているようであれば、脆弱性対策情報データベースを参照するのが日本語で情報がまとまっていることもあり、とっつきやすいでしょう。
脆弱性対策情報データベースで公開されている情報はこちらです。早速、内容を確認してみましょう。
CVSS による深刻度
まずは CVSS による深刻度 を確認します。これは脆弱性の深刻度を示す指標です。深刻度を示す項目ごとにそのレベルや影響などが示されていますね。
この脆弱性では 攻撃元区分 が ネットワーク であり、機密性への影響 が 高 になっていますが、これは例えば、インターネット経由で攻撃されて機密情報が流出してしまう可能性がある、と読み取ることができる内容になっています。
影響を受けるシステム
次に 影響を受けるシステム には axios 0.21.0 と脆弱性が確認されたライブラリとそのバージョンが記載されていますね。
この段階で対象バージョンに該当しなければ脆弱性の影響を受けないと判断できますが、ここでは対象のバージョンを使っていると想定して、具体的な脆弱性の影響について、確認していきましょう。
この項目では脆弱性の影響を受ける具体的な条件までは記載されていないので、次の項目に読み進めていきます。
想定される影響
「情報を取得される可能性があります。」としか記載されていません。CVSS による深刻度 を読み解いた情報から追加の情報がないので諦めて読み進めましょう。
対策
「ベンダより正式な対策が公開されています。ベンダ情報を参照して適切な対策を実施してください。」とのことです。
端的に言えば、今回脆弱性対策情報データベースから得られる情報としては、ベンダーの提供情報を参照してね、ということだけです。
対策は ベンダ情報 に記載されているリンクを元に検討を行いましょう。
脆弱性対策情報データベースについてのまとめ
脆弱性対策情報データベースで脆弱性の深刻度から優先度を確認、さらに対象ライブラリとそのバージョンから該当判定を行う、という流れは理解いただけたのではと思います。
ここまでの流れでお気付きと思いますが、脆弱性を検知した多くの場合、影響調査も対応方針検討も、脆弱性対策情報データベースとは別に、別途情報を集めて作業を進めていく必要があります。なかなか大変な作業ですよね。バージョンアップが簡単ならさっさとバージョンアップして終わらせたいものです。
ここでは、情報を集めてさらに影響調査や対応方針検討を進めていく流れを見ていきましょう。
GitHub Issue から影響調査を再開
GitHub Issue を読む
ここからは GitHub Issue から脆弱性の情報を読み解いていきます。対象の Issue はこちらです。投稿された Issue の次の部分を読めば、リダイレクトを受けた後にプロキシサーバーを経由しないことが問題であることがわかります。
The following code spawns a proxy server that always responds with a 302 redirect, so requests should never reach the target url, however, axios is only reaching the proxy once, and bypassing the proxy after the redirect response.
脆弱性によって影響を受けるケース
読み解いた情報から、対象システムが以下のケースに該当する場合に脆弱性の影響がありそうです。
修正内容の確認による裏付け調査
ここで、修正内容から裏付け調査を行います。GitHub Issue に紐付けられたコミットログ*1から、修正内容を確認します。コミットログから修正内容を見ると、proxy オプションが有効な場合にしか作用しないことがわかります。
if (proxy) {
// If a proxy is used any redirects must also pass through the proxy
また、確かにリダイレクト時にプロキシサーバーを向くように設定されていますね。
if (proxy) {
// If a proxy is used any redirects must also pass through the proxy
options.beforeRedirect = function beforeRedirect(redirection) {
var location = redirection.href;
redirection.hostname = proxy.host;
redirection.host = proxy.host;
redirection.headers.host = parsed.hostname + (parsed.port ? ':' + parsed.port : '');
redirection.port = proxy.port;
redirection.path = location;
};
}
調査方針
裏付けがとれたので、これで調査方針が固まりました。
1. Web APIを呼び出す際にプロキシサーバーを使う（axiosのproxyオプションを使用する）
上記を確認するには、クライアントアプリケーションのソースコードを proxy で検索すれば良さそうです。ここで、該当しなければ影響なしで調査完了です。
今回のケースでは、proxy オプションを利用していたということにしておきましょう。
2. Web API を呼び出した結果、リダイレクトされるケースが存在する
もう一つの条件については、外部の API を呼び出している場合は、リダイレクトが発生する可能性は考慮しておく必要がありますし、
今後の改修でリダイレクトを扱うことも考慮しておいた方がよいでしょう。現時点でリダイレクトのケースが無いことを理由に対応を見送ったとして、リダイレクトのケースが出てきたときに、この脆弱性対応をセットで反映させられる保証が無いからです。
今回のケースでは、今後も見据えて該当する可能性があると判断したことにしておきます。
これで影響調査は完了とし、次に脆弱性の対応方針を検討していきましょう。
対応方針検討
対応方針の大まかなパターン
まずは、影響調査結果を元に、対応するかしないかを判断します。次に、大まかに以下のパターンです。
対応方針には次のようないくつかのパターンがあり、プロジェクトのコンディションに応じて対応を検討することになります。
- バージョンアップに対するシステムへの影響が大きいので、アプリケーションで回避する
- 脆弱性が対応されたバージョンにアップデートする
当然ながら、バージョン間の非互換に伴い、アプリケーションの改修が必要になるケースがあります。
対応方針を選択
今回は今後を見据えて脆弱性の対応を行うこととし、対応方針は axiosのバージョンアップを行う選択をした想定とします。
それでは、具体的な対策について見ていきましょう。
脆弱性の対策
コミットログから修正内容を確認した結果、アプリケーションの改修は不要であること、proxy オプションを使うケースのみ処理が追加されているのでテストバリエーションは少なく済む、ということがわかっています。
結果として、axios のバージョンを脆弱性対応が行われた v0.21.1 以降にバージョンにアップデートし、確認テストを実施するということで方針が定まりました。
まとめ
ここまで、脆弱性の検知から対策までの流れの一例を紹介しました。
自動テストが整備されていればさっさとバージョンあげた方が早いのは言うまでもないですが、そうもいかないケースでは、なかなか大変な作業になります。そうでなくても、社会的影響の高いシステムでは、攻撃の有無などインシデント調査に多くの時間をとられます。
所謂塩漬けと呼ばれるバージョンアップが行われないシステムが多い、エンタープライズ系案件の脆弱性対応について紹介しました。
