あわせてこちらも改めて…
はじめに
FileZenというツールをご存じでしょうか？FileZenはソリトンシステムズ(株)が開発する、ファイル共有アプライアンスです。FileZenを使っている層は官公庁、地方自治体や企業等の法人です。FileZenでGoogle検索をすると、このように広告が載る事からも、主なターゲットは自治体と言えます。
そんなFileZenですが、2020年12月2日に脆弱性が公表されました。脆弱性についてはJPCERT/CCからも注意喚起が発出されたことからも、それなりに注目度が高い、と言えます。残念ながら現時点ではCVEは確認できず、脆弱性の種類も何なのか、不明といった状況です。（情報更新：１２月１０日にソリトンシステムズ（株）から脆弱性に係る情報が詳細の公開されました。https://www.soliton.co.jp/support/2020/004278.html）
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=内閣府さんに限らずですが、公開サーバのパッチマネジメント、大丈夫ですか？と心配になってしまいます（余計なお世話）。と同時に開発側も、バージョンを推測できるような不用意な実装な避けるべきでしょう。もちろん、今回のケースではバージョンが確実にこれだ、と特定できたわけではありません。しかし、攻撃の戦略を組み立てる中で最小限の工数で最大限の成果を得ることは基本です。バージョンが推測できるなら、まずはそこを狙うのは攻撃者の心理として想像に難くないと考えます。もしこれが、デコイなのであれば、心配は稀有であり、流石です、の一言になります。