[OSINT]Shodanを使ってFileZenを探せ その1
【更新履歴】
2020年12月10日 情報更新：１２月１０日にソリトンシステムズ（株）から脆弱性に係る情報が詳細の公開されため追記。
2021年3月2日 情報更新：「【重要】FileZen脆弱性に関するお知らせ」として2月18日に開発元のソリトンシステムズから新たな脆弱性に係る情報の発出がなされました。本件については脆弱性に係るパッチが存在しない「ゼロデイ」の情報であることが公開されています。
https://www.soliton.co.jp/support/2021/004334.html
2021年4月27日 情報更新：
内閣府職員等が利用する「ファイル共有ストレージ」に対する不正アクセスについて
https://www.cao.go.jp/others/csi/security/20210422notice.html
また、情報がでてきたため、追加調査（パッチはいつ適用したのかを調査）を行い本文中「(追記：History機能を用いた調査手法について)」に加筆しました。ShodanのHistory機能についてはまだメジャーではないと思います。ぜひ使ってみてください。
【本Blogに対する削除依頼について】
なお、本Blogについて、私の所属企業を通して、本Blog自体の削除依頼を受けました。問題の箇所は本文内、内閣府の状況を指摘して書いた箇所です。依頼内容は内閣府の箇所の削除ではなく、Blog全体を停止する旨の依頼でした。依頼を出してきたのは内閣府ではなく、第3者である大手SI企業であった事から、検討の必要すらないと判断しました。その後、会社を通して個人に対して削除依頼を寄こすよう依頼したものの、一切の反応がない状況です。なお、本Blogは個人の意見を表明した個人Blogです（その旨は記載しています）。また、主目的はOSINTツールを使って調査をする手法を紹介する事です。今回、具体的な組織を挙げましたが、特定組織を挙げた理由はケーススタディとして解りやすさ、再現性の重視、また、官公庁を事例として挙げたのはその公益性にあります（公益性の観点で私企業はケースとして選択していません）。最近の報道で結果的に当該組織が攻撃を受けていた事については残念でなりません。（殊更、内閣府を取り上げた理由は、中央省庁（省庁格）のTLDを調査した際にパッチ適用が最新版に追い付いていないと判断可能な機関の一つであった為です。他中央省庁でもFileZenを使っている機関はありましたが、パッチが適用済と判断が可能であったため、取り上げませんでした。）
話を戻しますが、削除依頼について、所属企業を特定し、所属を通して圧力をかけるやり方には疑問を感じざるを得ません。正直、戸惑いとある意味恐怖を感じました。
私のBlogではOSINT(Open Source Intelligence)を一つのテーマとしています。したがって今回の情報もすべてOpenデータであることを改めて御理解、御認識いただければ幸いです。
はじめに
FileZenというツールをご存じでしょうか？FileZenはソリトンシステムズ(株)が開発する、ファイル共有アプライアンスです。FileZenを使っている層は官公庁、地方自治体や企業等の法人です。FileZenでGoogle検索をすると、このように広告が載る事からも、主なターゲットは自治体と言えます。
そんなFileZenですが、2020年12月2日に脆弱性が公表されました。脆弱性についてはJPCERT/CCからも注意喚起が発出されたことからも、それなりに注目度が高い、と言えます。残念ながら現時点ではCVEは確認できず、脆弱性の種類も何なのか、不明といった状況です。（情報更新：１２月１０日にソリトンシステムズ（株）から脆弱性に係る情報が詳細の公開されました。https://www.soliton.co.jp/support/2020/004278.html）
今回はそんなFileZenを、前回の記事同様、主にShodanを使って調査をしてみたいと思います。なお、記事の長さの関係上、その1とその2にわけて記します。その２については後日、公開をします。
1章: Filezen特定の足掛かりを見つける。
Shodanを使って調査をする場合、まずは調査の起点となる足掛かりを見つけることから始めます。FileZenのフィンガープリントを探すためにFileZenの公開サーバを探します。この手のツールはだいたい、Youtubeで使い方を公開していたりします。今回はCTCさんが動画を公開していました。
これをみているとわかるのですが、
ログイン画面が存在しており、画面内から"FileZen, Copyrights(C)"の文字列がありそうな事が伺えます。この辺は調査に使えそうです。しかもCopyrightsにYearも入っています。これはもしかして…
それではGoogleを使ってFileZenを使っているホストを特定します。Googleで"Filezen"を検索します。検索結果のほとんどはSolitonさんのページなのですが、その中に一つ気になる結果が含まれています。
どうもPDFでつくられた利用マニュアルのようです。実際に見てみましょう
早速URLが特定できました。その他、参考になる情報がいろいろ含まれていました。実際にアクセスをしてみます。
FileZenですね。その他、以下のように調査すると「それらしい」結果が返ってくることわかっています。
まずは滋賀案件を手掛かりに調査を進めます。
IPが特定できました。
2章 足掛かりをもとに実調査のフェーズ
第1章ではIPの特定までできました。それでは調査を進めていきます。このIPをShodanをつかって検索します。
見つかりました。ここからもう少し掘り下げていきます。"View Raw Data"からスキャン結果を見ていきます（ここからは要ログイン、課金が必要な場合があります）。
Raw Dataですが、Finger printとして使えそうなデータが多数含まれています。今回は大きく二つ、Finger printの候補がみつかりました。一つはfavicon、もう一つはtitleです。
これは攻撃者にもよくみられる「パッケージで買ってきたものを変更しないままデフォルトで使ってしまう」という”Bad habbit”が見られる箇所です。特にFaviconについては存在に気が付かない事があり、デフォルトのまま残ってしまう事も多く、攻撃者インフラの特定にも使える技術となります。今回のこのケースですがどうもデフォルトでFileZenのFaviconが使われているようです。下がそのFaviconになります。
もう一つはTitleですが、これは変更済ケースがあることを先のGoogle検索の結果から得られています。とはいえ、デフォルト運用している、”より意識の低い”組織の特定には使える要素です。
それではハッシュ値を使った検索手法で調査をします。検索式は
”http.favicon.hash -1338145819” です（要ログイン）。
このFaviconを使っていたホストは224IPあることがわかりました。
ちなみに、タイトル検索についてはhttp.title:FileZenの検索結果はこちらです。
それぞれの結果をORで集計して重複を排除すればホストの特定はできそうです。個人的にはホストを特定するところは技術的な観点では興味がないのでやりません。その2で結果のバルクダウンロードのテクニックも書こうと思いますので、もしご興味あるかたはやってみてはいかがでしょうか？
さて、この検索結果を得て、内容を見ていて、「モヤっ」とした、あることに気が付きました。それが次の章です
3章: モヤっ1？他に調査手法・観点があるのでは？
得られた結果について、ぜひじっくり見ていただければと思います。そして違和感に気が付くのではないでしょうか。それはResponse headerです。
2012年です。あまりに古すぎて違和感を感じます。別のホストを見てみましょう。
これもLast-Modifiedが同じだ。まさかこの2012年のLast ModifiedはFilezen特有のものではないか？と感じたら検索です。
"Last-Modified: Sat, 29 Dec 2012 06:08:22 GMT"
上図の結果をみていただければおわかりいただけると思いますが、Faviconを変更したとしてもFileZenで動いているホストが見つかってしまっています（もっとも、タイトルがFileZenですので、タイトル検索の結果からもこのホストに係る情報は得られています）。この検索手法の場合、関係のないホストが結果に出てしまう欠点はあるのですが、調査の手掛かりのヒントにはなります。さて、このLast Modifiedですが、これがさらなるモヤッにつながります。
4章: モヤっ2？Last Modiedのヘッダは、何に依存？
'Last-Modified: Sat, 29 Dec 2012 06:08:22 GMT'の謎は何なのか。実際にこのResponceヘッダを返してくるホストにアクセスしてみます。
ここのホストにアクセスしてみます。注目は表示されたWebページのフッタです。
2008-2018年のCopyrightです。実は他のホストも同じような傾向を示しています。別のヘッダをみてみます。
このケースは2019年です。このWebを見ると以下となります。
2019年のヘッダの場合、Copyrightは2019年までとなっています。2020年のヘッダの場合は
となっています。すべてを調べているわけではありませんが、どうもヘッダのLast Modifiedを以てFileZenのファームウェアのバージョンの特定まではいかないものの、バージョンの推測ができるかもしれません。そこであらためて今回発出された注意喚起を見てみます。
今回の脆弱性については2019年1月30日にリリースされたバージョン以降に該当するとの記載が確認できます。
ヘッダが示す2012年のホストに存在するCopyrightが2018年まで、となると、2012年のLast Modifiedを持つホストは脆弱性パッチが当たっていないのでは？＝脆弱性が存在している、と疑いの目を持っている次第です。
その１のまとめ
今回の脆弱性について、幸い、POC（Proof Of Concept: 脆弱性を実証するコード）は確認できていないため、攻撃を成立させる事はキディレベルであれば難しいと考えられます。また、そもそも脆弱性が不明という事もあり狙うためのモチベーションも高くならないのではと想像します。
とはいえ、過去に公開されたFilezenの脆弱性を確認すると
RCEとDirectory traversalです。少し気になっているのが、今回リリースされたパッチは、過去のバージョンに遡って対応をしている事です。脆弱性の種類については現時点では不明ですが、この時の修正漏れが原因であれば、同様の脆弱性である可能性は想像に難くありません。
いろいろと書き連ねてきましたが、エンタープライズ、個人においてもパッチ管理はセキュリティにおける基本中の基本。特にインターネットに公開されているシステムについては脆弱性が公開された場合、即時対応が基本だと考えます。
そういった観点ですと、
CAO=内閣府さんに限らずですが、公開サーバのパッチマネジメント、大丈夫ですか？と心配になってしまいます（余計なお世話）。と同時に開発側も、バージョンを推測できるような不用意な実装な避けるべきでしょう。もちろん、今回のケースではバージョンが確実にこれだ、と特定できたわけではありません。しかし、攻撃の戦略を組み立てる中で最小限の工数で最大限の成果を得ることは基本です。バージョンが推測できるなら、まずはそこを狙うのは攻撃者の心理として想像に難くないと考えます。もしこれが、デコイなのであれば、心配は杞憂であり、流石です、の一言になります。
(追記：History機能を用いた調査手法について)
ここまで、パッチマネジメントについて書きましたが、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日程度です。これが速いのか遅いのか、ここでは考察しません（注：運用保守の観点では、特に年末は業務集中による作業抑止期間である事が多くあり、作業のリードタイムは運用上の事情に依存している可能性がある為です）。
今回はこのような使い方をしましたが、この機能は攻撃者インフラを追う上でも非常に有効な機能です。今回はフィンガープリントとしてHTTPヘッダのLast-modified: を参照しましたが、例えばSSL/SSHのKey Fingerprintであるとか様々な攻撃者の痕跡をもとに、その攻撃インフラがいつからいつまで維持されてきたのか、攻撃キャンペーンを時系列をもって追うような使い方もできます。いままで、これがshodanではできなかったため、不便だった事もあった為、この追加機能はThreat Intlの分析として、非常に有難い!と感じている次第です。このテクニック、ぜひご活用ください。
不正侵入報道後の改めての思い
先にも書きましたが、残念ながら（そして寄りによってここで取り上げた組織にて）不正侵入事案が発生してしまいました。ここで偶然にも調査手法のケーススタディとして取り上げてしまった事について、複雑な思いがあるのは事実です。攻撃について、誰が悪いというのはもうただ一つ、攻撃者が悪いです。被害を受けた組織はただシンプルに、被害者です。他方、このように外部から容易にバージョンを類推できるような実装にしたのは、脆弱性とまでは言わないものの（監査であれば私は脆弱性として指摘事項とします）、問題はないのか？と感じざるを得ません。幸い、最新バージョンではWebUIのCopyrightが消えたりと改善はなされています。開発側としては引き続き、攻撃者視点で実装を考えていただきたいです。同時に、SI(System Integrator)としては問題はないのか？という点もあります。公開されているWebUIについて、Faviconをデフォルトで使う、titleを初期値のまま使うということは即、プロダクト特定のフィンガープリントとなる、そしてそのリスク＝ターゲットとなり得る事、は理解すべきだと考えます。セキュリティとなると即Blue Teamer視点で認証だログだ、と言う話になりがちですが、Red Teamer観点に立てば、また違った景色が見えてきます。今回であればMITREのATT＆CKでいうところのReconnaissanceです。ぜひそのような視点で設計をしていただければと思います。
その２：予告
その2では今回の結果をバルクでダウンロードする手法についてご紹介をします。この手法はご質問をいただくことが多いです。
この記事が気に入ったらサポートをしてみませんか？