敵を知り己を知れば百戦危うからず

サイバー攻撃者の動機や心理を把握する事は、サイバーセキュリティ対策やインシデント対応を考える上で重要になりつつありますが、結局は「孫氏」に戻るのではないか、そんな風にこの記事を読みました。

キタきつねの所感

Randoriの共同創設者兼CTOのDavid ”moose”Wolpoff氏の攻撃者視点での記事は、色々な気づきがありました。

攻撃者は、抵抗が最も少ない経路を探します。できるだけ少ない労力でアクセスを取得します。できるだけ騒音を出さないでください。可能な限り少ないエクスプロイトを使用します。

悪用する魅力的な資産を特定すると、攻撃者は脆弱性を見つけるための手法を採用します。攻撃者に早く勝利を与えることができるものもあれば、より時間がかかるものもあります。

(threat post記事より引用）※機械翻訳

侵入が検知されづらい(防御がされてない）経路から入ってくるという事や、資産あるいは資産がありそうな所を狙って更なる攻撃（エクスプロイト）をかけてくる所、考えてみると当たり前の事ではあります。

この攻撃者の心理を考えると、防衛側は可能な限り、初期侵入の段階で速やかに検知する、あるいは内部調査の段階で攻撃者にヒントを与えない様にする、といった事が重要なのがよく分かります。

David ”moose”Wolpoff氏は、攻撃者の視点として以下の４つの点を挙げており、この観点は企業（防衛）側にも重要だと思います。

最初の「ヒント」として挙げられているのが、CVE＝脆弱性情報の発表です。

クリティカルな脆弱性に対して対応をする事は誰もが必要と考えている事かとは思いますが、諸般の事情により（対外は金銭的、あるいは運用を止められないといった理由等で）パッチを当てない企業が狙われ、インシデントに発展する事は近年多く発生しています。しかしここで挙げられているのは、修正がされてない（けれども同じ脆弱性を抱える）バージョンや、それ自体では大きな侵害につながらない脆弱性に、更に新しい攻撃手法を重ねる事に対する危惧です。

CVEドッペルゲンガーを見つける
アラートの疲労に直面しているセキュリティチームと同じように、攻撃者は脆弱性情報のファイアホースに直面しています。そのうちのいくつかだけが彼らの目的にとって重要です。攻撃者は、開始点としてターゲットに対して脆弱性をクロスチェックする可能性がありますが、重大度の高いCVEが常に有益であるとは限りません（それらは公に知られており、セキュリティチームによって十分に監視される可能性があります）。ただし、既知のCVEは、コードに隠れている同様のバグを発見するための優れた出発点です。ソフトウェア開発サイクルについて考えてみてください。組織に導入されたコードは、再利用およびリサイクルされ、環境に侵入する可能性があります。現在開発中のコードの脆弱性にパッチを適用し、他のバージョンにはパッチを適用しない場合、そのバグの亜種にはパッチが適用されていません。

昨日、内閣府へのサイバー攻撃が話題となっていましたが、ファイル共有製品を提供していたSoliton社のサポートページを見ると、既知の脆弱性にゼロディ脆弱性を被せてくる攻撃だったとも考えられます。

www.soliton.co.jp

(2021/03/05更新：脆弱性修正済みアップデートファームウェアのリリースを記載)

FileZenに新たな脆弱性が存在することを確認しました。

FileZenをご利用のお客様は、必ず以下に記す設定をご確認いただき、必要な対策を実施いただきますようお願い申し上げます。

新たに確認した脆弱性は、システム管理者としてログオンしているセッション内に限り発現するものです。しかしながら、V4.2.2までの脆弱性を利用しFileZenに侵入された場合、パスワードを窃取する手法があることも確認しています。

アクセス制御が適切に行われていない場合、窃取されたパスワードと今回発見した脆弱性を利用することで、FileZenへの侵入される恐れがあります。

※この脆弱性内容が内閣府の被害を受けた脆弱性であるとはSoliton社のページには一切書かれていませんので、そうした可能性もあるという程度でお考え下さい。

2番目に挙げられているのが、「開発者のコメント(メモ）」や「バグのフラグ」です。Git等に残されている開発者の情報は、攻撃（ハッカー）側にも有益である事は言うまでもありません。正式版リリース前に大きな脆弱性は残ってない状態である事を、多くの開発者は確認してからリリースしているとは信じたい所ですが、人がする事にはミスはつきものですので、こうした視点から最終チェックを行う事も有効かと思います。

未解決の開発者向けメモ
ソースコードを読むことは、攻撃者のために宝の地図を発掘することに少し似ている可能性があります。私がよく見かける成果の1つは、開発者がお互いに残し、ソフトウェア開発サイクルのある時点で残したメモにあります。ソフトウェアを構築する際、開発者はコードを調べて、既知のバグのある領域にマークを付けます。しかし、開発者は迅速に行動し、これらのメモを未解決のままにしておくことができます。コード内に「FIXME」または「RBF」（フライト前に削除）というタグを見つけたとき、私は金を打ったことを知っています。このようなタグは、潜在的に悪用可能なパッチが適用されていない脆弱性に注目を集めます。「FIXME：ここでバッファオーバーフローが発生する可能性があります」というラベルの付いた関数にバグを見つけたことがあります。そのまま発送しないでください。」実際、それはそのまま出荷され、私たちはその欠陥を簡単に利用しました。

3番目は、関係者に限定されたGitの中だけではなく、ネット上のサポートサイトに自社情報やソースコードを含む”機微な情報”を知らない内に漏えいさせている可能性です。

性善説で"運用"している日本企業は、少しパターンが違いますが、以下の様な「出会いがしらの事故」が発生して初めて、そうした流出（関係者への教育不足）に気づく訳ですが、性善説だけでは企業を守り切れない時代になってきている事には十分な留意が必要です。

三井住友銀行などのソースコードが流出 “年収診断”したさにGitHubに公開か【追記あり】 - ITmedia NEWS

サポートフォーラムのSOSフラグ
かつて、ターゲットの境界で悪用する場所を探しているときに、私のチームは会社が新しいアプライアンスをテストしていることに気付きました。会社のITチームは、企業の電子メールアドレスを使用して一般的なサポートフォーラムにいくつかの質問を投稿しました。資産は壊れやすいように見えました。Googleですばやく検索した結果、このアプライアンスは有名な電話機器メーカーの高価な製品であることがわかりました。サポートフォーラムを調べたところ、オンラインで投稿されたファームウェアアップデートの一部が見つかりました。これには3つのバグが含まれていました。

（中略）

攻撃者は、ネットワークの壁の外でチームメンバーの足跡をたどって、エクスプロイトにつながる可能性のある情報の痕跡を見つけるのが大好きです。

最後はファジングです。ファジングについてはIPAが、まるで初心者ハッカー向けの教科書の様に解説資料を多数公開していますので、こちらをご参照頂ければと思います。

脆弱性対策：ファジング：IPA 独立行政法人情報処理推進機構

一般的なファジングの記事内容の引用は省略しますが、かなり広範囲に攻撃の痕跡が残りますので、ハッカー側は一般的なファジング手法を取る事はなく、標的を絞った「スピアファジング」手法を好むという部分が重要かと思います。

スピアファズ
（中略）

防御側は攻撃者にとって侵入をより困難にすることに常に焦点を合わせていますが、ハッカーは単に防御側のようには考えていません。ハッカーは、時間と労力の個人的なコストに拘束されますが、企業のポリシーやツールには拘束されません。企業にとって、ハッカーの論理に適応し、何が標的を誘惑するのかを理解することは、攻撃的な防御の最初のステップです。侵害された資産の潜在的な影響と、ハッキングが成功する可能性を理解することから始めます。これにより、防御するのに最も重要な攻撃対象領域の理解が狭まります。これにより、防御側は、適切なフェイルセーフと実際に問題となる可能性のあるCVEを検討できます。ハッカーの視点を理解することで、企業は従来のベストプラクティスを超えた回復力を構築し、階層化された防御戦略を構築し、永続的なハッカーを寄せ付けないようにすることができます。