[OSINT]Shodanを使ってFileZenを探せ その３(番外編: 運用状況の分析）
これまで「Shodanを使ってFileZenを探せ」として2回、FileZenを題材に、Shodanを使った実際の調査手法について、ご紹介していきました。残念ながら「[OSINT]Shodanを使ってFileZenを探せ その1」でBy Name挙げた内閣府は、その後2021年4月22日に内閣府が攻撃を受けて個人情報を含めた情報漏洩が発生していたことを明らかにしました。その原因はソリトンシステムズのFileZenのファームウェアに存在していたゼロデイの脆弱性だった事を明らかにしています。詳細についてはPiyokangoさんのPiyolog「内閣府のFileZenへの不正アクセスについてまとめてみた」を見ていただければと思います。
私はこれまで、昨年12月にBlogに書く以前から、FileZenの作りに攻撃者を利する問題＝ある程度のバージョン特定が可能、ある事が気が付いており、その事から継続的に調査を進めていました。これまでの調査から、内閣府の件は、単にゼロデイの脆弱性があるから、といった問題だけではない、と感じています。特に、内閣府以外の中央省庁について、攻撃を受けて情報漏洩に至った、と言う話が出てこない（単に情報を公開していないだけかもしれませんが）と言う点が気になって居ます。攻撃は他では成立していないのでは？その差は、内閣府の運用にはセキュリティ的な何らかの”Bad Habbit”があったのでは？と考えています。今回はShodanに残った痕跡から、内閣府のFileZen運用が、運用業者である富士通によってどのようになされていたのか、「OSINTデータだけで」調査をしてみました。
1. 調査手法
調査手法についてですが、shodanを使って調査をしています。実はその１は随時追記をしていました。調査手法についてはそこから一部抜粋します。
調査手法は
・Shodan Betaに備わったHistory機能を用いた履歴調査
を使っています。
まずは2.では、2020年12月に公開されたパッチをいつ適用したのか、Historyから追って明らかにしていきます。2.の内容は抜粋、一部編集となります。
2. 脆弱性が公開されてからパッチを適用するまでのリードタイムを明らかにする(その1から抜粋)
shodanでどこまで適用状況を追えるのか、改めてやってみました。まずはSolitonが公開している（今回の脆弱性に係り公開した情報である（ファームウェアのバージョンの時系列情報です。
脆弱性と対応については以下のように並べられています。
2020年12月2日に注意喚起が発出、至急バージョンアップを行うよう呼びかけがなされています。その後さらに12月7日に新しいファームウェアがリリースされています。今回、事例として取り上げた内閣府についてですが、その１Blogの公開日、12月8日の段階では①last-modifiedの情報が2012年、②WebUIのCopyrightsが-2018となっていることから、導入されていたファームウェアは上記時系列から考えてv4.2.2である可能性が高い事が判ります。その場合、バージョンアップ対象であることがわかります。それではいつファームウェアをバージョンアップしたのか？それはこのHTTPヘッダを追う事でわかります。
実はshodanには、shodanとベータ版のshodanの二つのバージョンが存在します。ベータ版はhttps://beta.shodan.io/からアクセス可能です。ベータ版と通常版では機能が若干異なっているのですが、ベータ版で特筆すべきは、shodanによるスキャン履歴を見る事が可能な点です。例えば、今回のケースではこちらのように見る事が可能です。
このデータからおおよそのバージョンアップ作業日を分析していきます。スキャンについての基本的な知識ですが、shodanは1週間に一度、巡回して情報を収集します。そのためshodanでは1w単位で絞込が可能です。ちなみに、同じような機能は他のスキャンサービスでも実装されており、これらを組み合わせて評価することで、もう少し細かく日時を特定が可能です、が今回はshodanだけで話を進めていきます。
早速、結論から言ってしまいます。
スキャン結果から類推するに、12月21日から28日の間にバージョンアップを実施した事がわかります。脆弱性情報が公開されてからリードタイムとしては19日+7日程度です（新しいファームは起動時がLast Modifiedとなる仕様にみえること（後述）から、作業実施は12月24日20時ころと考えられます）。これが速いのか遅いのか、ここでは考察しません（注：運用保守の観点では、特に年末は業務集中による作業抑止期間である事が多くあり、作業のリードタイムは運用上の事情に依存している可能性がある為です）。ただ、いちセキュリティをやっている人間からすると、（後述しますが）脆弱性に該当するバージョン、しかも深刻な脆弱性に該当する、しかも公開システムなのに、このリードタイムで使い続けたことは疑問に感じます（ありえない）。もちろん、運用の大原則は「止めない」こと、そのために種々実施する事がBest Practiceです（ちなみに、私は運用をしていた人です）。その為の運用のBest Practiceが結果的にセキュリティとしてBad Practiceとなり、それがBad Habbitであったと考えられます。その辺の運用の姿勢はマクロな視点でみてもわかります。
次の章では内閣府の運用をマクロの視点から分析していきます。これはなんども強調させていただきますが、あくまでOSINTデータから分析をしていることをご理解ください。現実は違うかもしれません（がデータが物語っているとしか思えません）。
3.内閣府と他省庁(A省庁)のFileZenの運用の比較
2章ではパッチの適用について、リリースから適用までに19日(+7)のリードタイムがあった可能性があることを書かせていただきました。また、そのパッチ適用まで、古いバージョン（2018年9月27日リリースのv4.2.2）を使い続けていたと思われることを書きました。
他方、内閣府と同等格の中央省庁（独法や庁ではなく）では、同じようにFileZenを使っていながら、プレスリリースがだされていないことと言う薄い根拠ながら、攻撃を受けていない、または攻撃が成立していないと考えられる組織も存在しています（公共機関は攻撃を受けていて被害が出ているのであれば、情報は当然、公表するものとの一国民としての認識を前提としています）。
3章では、そのＡ省庁と内閣府の運用を比較して、セキュリティ的なBestPracticeについて考察をしていきます。
3.1. 内閣府とＡ省庁の運用比較
早速ですが、内閣府とＡ省庁（以下Ａ）の運用比較として、HTTPのResponseヘッダ、Last-Modified:の値を対象として、ShodanのHistoryデータを集計して下表にまとめてみました。
ＡはShodanのデータから複数台のFileZenを運用していることが見受けられます。グラフ作成にあたっては、この3台の平均値を値として採用しています。なお、3台の平均値はほぼ中央値に集束していたことは指摘しておきたいと思います。
一目見てわかるのは、
・内閣府もAも、当初のバージョンがV4.2.2である可能性が高い事(特定手法はその１を参照）
・Aのバージョンアップが内閣府と比較して早く行われていた事
・FileZenのファームウェアがどこかの段階で改善され、再起動時がLast-Modifiedの値となるよう仕様変更（改善）がなされた事
です。それではなぜ内閣府がV4.2.2を2年以上使い続けていたのか、その判断を考えます。
3.2. なぜV4.2.2を使い続けたのか、そしてその結果は
内閣府がV4.2.2を使い続けたことには二つの理由があると考えられます。一つは利用開始時に提供されていた最新のバージョンがV4.2.2であった事、そして2020年12月10日まで、V4.2.2には脆弱性が公開されていなかった事が理由として考えられます。
しかし、ソリトンシステムズが公開した情報からは”結果的に”2019年1月30日にリリースされたV4.2.3では脆弱性が修正されていた事、つまり、V4.2.2には脆弱性が存在していた事が判ります。そしてこれが攻撃に悪用されていた可能性も、ソリトンシステムズのプレスから読み取れます。
新聞報道では、攻撃は2020年3月から2021年1月まで継続的に行われていた事が言及されています。ここで先にあげた線表グラフに戻ります。ここからはあくまで想像になりますが、Aが内閣府と同様に攻撃を受けていた、という前提にたって考えると、V4.2.2を脆弱性が無いから使い続けるという決定が分水嶺になっていた可能性が考えらます。これは双方に攻撃があったとの前提の上の、さらに想像と可能性の話になってしまいますが。。。（ないとは言えないのは、このAが重要省庁だからです）
そして、これは、運用をやっている側＝止めたくない、可用性を重視したい、という気持ちを理解している側からすると、非常に辛いです。が、インターネットに公開されているシステムについてはすでにその考え方は最適解ではない事が今回のケースでも見えてきています。表でも見えてきていますが、内閣府は結果的に3か月近く、システムを止める事となってしまってしまった、他方Aは脆弱性情報が公開になった2月の短期間のみ、Shodanを非公開としていた形跡からも読み取れるのではないでしょうか？
4. （まとめと考察）運用における最適解は？
FileZenに限らずですが、昨年からVPN装置の脆弱性を突かれたことでVPN装置の情報を窃取される、また、侵入されたケースが多数報道されています。あの件は既知の脆弱性を放置していたという根本的なミスがあるので、同じに語るのは相応しくないと考えます。
ただ、これは当たり前の話ではあるのですが、①インターネットに公開されているシステムについては、脆弱性に対する修正パッチがリリースされたのであれば、他よりも優先をして即時適用をする、といった運用のポリシーは決めておくべきでしょう（とはいえゼロデイ() )
そして、特にFileZenについては、②アップデートパッケージがリリースされた場合、追随していく事がマストであるという事です。理由は大きく二つあります。一つは「なんか知らんけど、治っていた」V4.3.3 のケースがあるからです。そしてもう一つ、これは朝日新聞のインタビューに答えていたソリトンシステムズの方が指摘していましたが、攻撃者側にハードウェアが渡っている可能性です。SkySeaの件でもそうでしたが、アクター側が物品を入手して研究をしている事がほぼ確実といえるからです。私もFileZenを研究するためにアプライアンスの入手にトライ（＝ヤフオクで探す）しようとしていましたが、この攻撃者もおそらく同じことを考えていると思います。アプライアンス、かつドメスティックな製品をターゲットとしてきた場合、その背景にはこの可能性は考えるべきです。この二つについては心がけておくべきかと思います。
最後に
まさか3回にもわたってこのネタを書くことになるとは…当然最後の1回のこの回は半分くらい私怨が入っております（笑）。が、今回の一連については色々思う事があります。
特に情報共有について、攻撃の事実が速やかに明らかにされなかったこと、詳細な情報が開示されないことで対応の遅れや正確な対応ができないといった弊害が出てしまっている事です。これは非常に問題だと感じています。原因がわからなくても、まず情報の公開、その後段階的に情報を公開すること、それがいまのベストプラクティスです。
私たちがセキュリティ運用を行う上で、攻撃発生の事実は非常に重要な要素です。その有無で、対応の優先度は変わるからです。今回（あえて言いますが）攻撃発生の事実を「隠ぺい」したことで、正常な判断が出来ず、対応が遅れ被害者が増えている可能性も否定できません。内閣府、そしてNISCは、被害者ではなく加害者になっている、公益に反する事をした事は理解すべきです。
実はいまだに対応ができていない自治体（小樽、所沢、石狩）もあります。
最早ここまでくると別な話な気がしますが…初動でもう少し騒げれば話は別になっていたかも。。。と。かすかな希望を持っています。そして内閣府は…
ファームウェアは最新にしたようですが、結局UIはデフォルトのまあ使い続けています。先にBlogでも書きましたが、製品をデフォルトで使い続けること自体が、攻撃者を利する。この先が心配です。
最後に、自分の中で最近、もっとも良い対応をしているケースを挙げたいと思います。これが政府系、CERTのやるべき理想形だと思います。今回のケースだって、これに近いことをできたのではないでしょうか？
日本もここまで辿り着いてほしいと切に願いつつ、この話は終わりにいたいと思います。。
この記事が気に入ったらサポートをしてみませんか？