EN

NRIセキュア ブログ

「攻撃テクニック」を学ぶ方法|高度なセキュリティを実現する組織の在り方

目次

     blogtop

     

    NDIASでは20226月に、2つの「攻撃・防御手法研修」をサービス提供開始しました。1つはLinux上でのスタックBOFに関する研修で、もう1つはファジングに関する研修です。前者は製造業(主に自動車業界を想定)向けに、特に力を入れて開発した研修で、スタックBOFベースの各種攻撃手法、それらの対策となる各種防御手法、そしてそれらの防御手法を回避する各種攻撃テクニック、といった内容を扱うものとなります。

     

    この研修で受講者に学んでいただきたいことは各種の「攻撃テクニック」です。しかし、なぜわざわざ一般の企業向けに攻撃テクニックを学ぶ研修を作ったのか、疑問に思われる方がいらっしゃるかもしれません。

     

    そこで本記事では、Linuxベースの環境への攻撃テクニックを学ぶことの重要性、ひいては組織全体での風土づくりについて解説していきたいと思います。

     

    新規CTA

     

    オープンソースソフトウェアの台頭とセキュリティ

    近年Linuxに代表されるオープンソースソフトウェア環境が急速に普及し、サーバ用途だけでなく、自動車のECUやAndroidなどのスマートフォンなどにも利用されるようになりました。オープンソースソフトウェアは、ソースコードが確認できることの透明性、無償利用が可能であること、自分たちで手を加えやすい、など様々なメリットがあります。

     

    しかし視点を変えると、攻撃者にとってはソースコードを入手できることから攻撃テクニックを編み出しやすく、また情報共有しやすいといった特徴があります。防御する側も、理論的には同じように情報を得て対策することができるはずです。しかし攻撃テクニックの情報はアンダーグラウンドな側面も強く、内容が難しいことやコスト対効果が出にくい(製品の開発や製造に直接影響しない)ことも相まって、多くの企業ではあまり情報収集を実施されていないように見受けられます。

     

    セキュリティが声高に叫ばれるこのご時世では、企業は自社製品に対するセキュリティ面での対策を講じることが当たり前となりつつあります。しかし、いざ自社製品に脆弱性が指摘された場合、攻撃手法や防御手法だけでなく実際に利用される攻撃テクニックも組織としてある程度理解していないと、正しく対策を立てることは難しく、またスピード感を持った対策方針の決定もできません。セキュリティに関する問題は迅速な対応が必要になることが多く、有事に至ってからでは遅いのです。

    攻撃手法と攻撃テクニックを混同しない

    メモリ破壊系の脆弱性にスコープを絞った上での話となりますが、厳密な定義はないものの、一般に攻撃コード中で用いられるものは「攻撃手法」と「攻撃テクニック」に分類でき、それぞれ似て非なるものと筆者は考えています。

     

    その理由として、攻撃手法は例えばバッファオーバーフロー、解放後使用(Use-After-Free)、と言った脆弱性の本質であり、攻撃の起点であるのに対し、攻撃テクニックはそれらが引き起こす問題を上手く利用して既存の対策技術を回避したり、任意コード実行などに持ち込んだりするために使われる、環境依存で用いられる手法だからです。攻撃テクニックの例としては、以下の例が挙げられるでしょう。

     

    1. ユーザランドアプリにおいて、スタックBOFから任意のコード実行に持ち込む際、NXによるメモリプロテクションを回避するためのret2libcやROP
    2. ユーザランドアプリにおいて、Use-After-Freeから任意アドレスの上書きに持ち込むための、tcacheやfastbinのリンクリスト破壊
    3. Linuxカーネルにおいて、権限昇格を簡単にするための、modprobe_pathやcore_patternの書き換え

     

    攻撃手法はフレームワークである程度洗い出すことが可能ですが、これに対して攻撃テクニックは環境や状況や目的によって様々な手法が存在する上、ソフトウェアのバージョンが少し違っただけでも利用可否が変わるなどの事情もあり、綺麗にまとまったドキュメントやフレームワークは存在しません。一部をまとめた記事などは存在しても、網羅的に洗い出すことは事実上不可能です。

     

    それにもかかわらず、攻撃テクニックの中には全く異なる攻撃手法と組み合わせることができるような汎用性の高いものも一定数存在します。これが意味することは、攻撃手法を追いかけるだけでは強固な対策を立てることはできず、攻撃テクニックも並行して調査し対策を立てる必要があるということです。

    攻撃手法と攻撃テクニック図1: 攻撃手法と攻撃テクニック

    表面的な理解ではなく、深い理解を

    別の攻撃テクニックの例を挙げましょう。近年のOSでは当たり前のように利用されている対策技術の1つであるASLR(Address Space Layout Randomization)を導入すると、ライブラリなどのロードされるアドレスや、ヒープ、スタック等のアドレスがランダム化されます。ASLRによって確かに攻撃の成功率は低下し、リスクは緩和されますが、実は全ての状況で常に有効に機能する訳ではありません。筆者がざっと思いつくだけでも、LinuxのASLRに対しては以下の攻略手法(攻撃テクニック)が存在します。

     

    1. メモリのアドレスリークを使ったアドレス特定
    2. /proc/<PID>/mapsからのアドレス特定
    3. Partial Overwriteを用いた現実的な確率でのブルートフォース
    4. ヒープスプレーによる突破
    5. 32ビットマシンで発生する低エントロピー問題を用いたブルートフォース
    6. forkサーバ型プロセスにおける同一メモリマップを利用する仕様をついたブルートフォース
    7. offset2libによる別領域のアドレスリークからの間接的なアドレス特定

     

    このような攻撃テクニックと言えるような情報は、攻撃者は貪欲に吸収していきますから、当然知っていると考えるべきでしょう。

     

    つまり実世界の脅威として、お客様が開発する製品への攻撃にここで挙げたような攻撃テクニックが利用される可能性が十分考えられるのです。従ってセキュリティ対策を検討していくお客様も、ある対策技術を単に導入するだけではなく、攻撃テクニックまで織り込んだ深い理解を持った上で、多層防御として他の対策も立てられるようになることが望ましいといえます。

     

    これはセキュリティ部門の担当者が知っていれば良いだけのものではなく、設計、開発、運用のいずれのフェーズに携わる方にとっても関わりあるものとなりつつあります。以下にその理由を挙げておきます。

    設計フェーズで攻撃テクニックを考慮すべき理由

    設計フェーズでは、例えば攻撃手法や防御手法をリストアップして、導入すべき対策技術を比較検討することがあるでしょう。ただし攻撃手法や防御手法をいくらリストアップしても、そこに攻撃テクニックはあまり含まれません。つまり、ある対策技術の導入を検討する際にその対策技術が回避されるケースはあるのか、という点で正しい判断ができない可能性があります。

     

    また、全てをカバーすることは無理でも、よく使われる攻撃テクニックを知らないと、多層防御としての二次的対策を検討することはできません。こうした知識不足によって、対策技術の選定や仕様の策定に考慮漏れが発生し、後のフェーズで問題が発生する可能性が考えられます。

    開発フェーズで攻撃テクニックを考慮すべき理由

    開発フェーズでは、例えば仕様書に「○○への対策を講じること」という項目があった場合、開発中の製品に実際に防御技術を導入する場合があるでしょう。単にOSやビルド時の設定を変更するだけで良い場合もありますが、望む機能がない場合は新規開発する場合もあるはずです。ここで、よく使われる攻撃テクニックをどこまで想定して対策に含むことができるかが、考慮不足の削減や将来の他の脆弱性を緩和するために重要となります。

     

    開発フェーズの担当者は実際に開発を行う分、設計フェーズで見落とされていた技術的な問題点を見つけやすい立場にいるため、特に攻撃テクニックを幅広く知っていることが望ましいといえます。

    運用フェーズで攻撃テクニックを考慮すべき理由

    運用フェーズでは、市場出荷後に報告された事象をハンドリングする必要があるでしょう。数多く寄せられる報告の中には、セキュリティに関する報告も含まれるはずです。例えばこれまでは、新たに報告された脆弱性が自社製品に該当するのか、アップデートパッチを作成する必要があるのか、といった判断だけで良かったかもしれません。

     

    しかし、これでは脆弱性を含むパッケージをアップデートするだけという結果になりがちです。パッケージのアップデートだけでもやらないよりは断然良いのですが、将来類似の脆弱性が報告された場合同じことの繰り返しとなってしまい、根本的な改善にはなりません。

     

    よりハイレベルな運用としては、巷に出回っている攻撃コードを読み解き、どのような攻撃テクニックを用いているのかといった観点でも情報を集め、自社製品に該当する場合は単にパッケージをアップデートするかどうかの判断だけではなく、利用している攻撃テクニックそのものを包括的に無効化できるような仕組みを導入するよう、開発部門へフィードバックするなどが挙げられます(例えばカーネルのコンフィグを変更して堅牢化する、新たな保護機構を導入する等)。

     

    これによって、将来の未知脆弱性を防御・緩和できる可能性が出てくるのです。各フェーズで攻撃テクニックを考慮すべき理由

    図2:各フェーズで攻撃テクニックを考慮すべき理由

    攻撃テクニックの学び方

    攻撃テクニックは脆弱性情報と違い、それ単体ではあまり話題となりにくい(ニュースとして取り上げられにくい)上、攻撃テクニックがメインとなる記事自体もあまり書かれないという特徴があります。

     

    したがって、網羅的に学ぶどころか情報を見つけることすら一般的には困難です。このため攻撃テクニックを学ぶには、現実的には地道な情報収集の繰り返しとなります。情報収集先の例を以下に挙げてみましょう。

     

    1. 脆弱性の解説記事のうち、PoC(Proof of Concept)コードが付属しているもの。特にPoCコードは情報の宝庫で、記事で触れている攻撃テクニックだけでなく、触れられていない攻撃テクニックも使われている可能性があります。
    2. セキュリティ系の過去のカンファレンスで発表された論文やスライド。活用した攻撃テクニックがあるならば、論文やスライド中に書かれている可能性があります。
    3. 著名なセキュリティアナリストやホワイトハットハッカーの発信する情報。彼らはSNS等で興味のあるリンクや記事を話題にすることが多く、その中には攻撃テクニックを含むものも数多くあります。
    4. 過去のハッキングコンテスト(CTF: Capture The Flag)で出題された問題の解説記事。一部のハッキングコンテストはアカデミックな風潮もあって、作問者が想定している高度な攻撃テクニックが実現できるかを問う問題も多いです。解いたチームや作問者自身による解説(Write-up)がある場合は、利用する攻撃テクニックまで詳細に言及しているケースがあります。
    5. 新しくリリースされたパッケージのリリースノートやコミットログ。セキュリティ目的の変更が入っているならば、変更点の概要やパッチ内容・コメントなどを調査することで、修正前のバージョンで利用可能な攻撃テクニックのキーワードを知ることができる可能性があります。
    6. 有志がgithubなどに、個人のメモの形で、一部ジャンルの攻撃テクニックをリンク集の形でまとめていることがあります。更新が滞っていることもありますが、更新が続けられている場合は効率よく攻撃テクニックを収集することができます。

     

    なお、ある期間内の単発的な調査ではなく継続的に続けていくことも重要です。理由としては、有事の際にいきなり攻撃テクニックの情報を得ようとしても難しいからです。先ほど、私が普段から実践している情報収集先を幾つか挙げましたが、いきなりこれらの内容を正しく読み取ることは簡単ではありません。

     

    攻撃テクニックの背景や理論をゼロから説明しているケースは非常に少なく、ある程度のベース知識を読者に求めることが一般的です。そのため、継続的に情報を集めてベースとなる知識を溜めていくことが重要となります。

     

    進め方は色々考えられますが、攻撃テクニックの情報を集めたい場合は、まず攻撃手法や防御手法、攻撃テクニックに関するベース知識をつけることが最初のステップになるのではないかと思います。ベース知識の中には、一度理解してしまえば複数の攻撃テクニックに応用できるようなものも多々あります。

     

    従って多少なりともベース知識を持つことができれば、攻撃テクニックの理解がしやすくなるだけでなく、目利き力の向上(セキュリティベンダやホワイトハットハッカーからの指摘に対して正しい判断ができる)や、ひいては有事の際のフットワークを軽くすることにも繋がります。攻撃テクニック情報の収集と活用

    図3:攻撃テクニック情報の収集と活用

    攻撃テクニックに関する情報収集を是とする組織づくりや風土づくり

    先に挙げたような攻撃テクニックの情報収集については、組織内の各部署やグループが、自律的に知見を溜めていくことがより望ましいといえるでしょう。なぜなら各部署や各グループが普段から積極的に情報収集を行い、それらを納得いくレベルで理解していなければ、いざという時に受け取った情報を実際に扱う部署やグループが、影響やリスクを正しく判断できず、対策を間違ってしまう可能性があるからです。

     

    組織によっては、情報収集を主として行うセキュリティ担当部署を定める、もしくは外部組織に情報収集を委託するといった方針を取っている企業もあるでしょう。その方針自体は良いと思いますが、収集された情報は、それら情報収集を担当する部署やその周辺部署に閉じるのではなく、平時から組織全体でキャッチアップしていく必要があるということです。

     

    このように各部署・各グループがベース知識を普段から溜めた上で、組織全体がひとつ上のレベルで攻撃手法や防御手法、攻撃テクニックに関する会話ができるようになることが望ましいのです。セキュリティ面で総合的に強力な組織を作り上げるには、一個人や一部署が頑張るだけでは到達できず、組織全体で風土を醸成していく必要があります。経営者の方々には是非ともご一考頂きたいところです。

    セキュリティベンダがお手伝いできること

    本記事では、組織の各部署やグループが攻撃テクニックに関して自律的に情報収集を行えるようになることが望ましいという考えを述べました。攻撃テクニックの中には高度な知識を必要とするものもあり、知識不足を感じることもあるかと思いますが、それでも継続的に取り組むことが重要だと考えています。とはいえ、やはり最初のステップの敷居が高いということもあり、そこはセキュリティベンダをご活用頂くのが良いのではないかとも思います。

     

    NDIASでは、各部署やグループが攻撃テクニックの「ベース知識」をつけるためのお手伝いとして、攻撃テクニックに特化した研修サービスを2022年6月より提供開始しました。コンテンツのラインナップは今後拡充していく見込みです。

     

    また、NDIASに限らずとも、世の中には様々なセキュリティに関する研修があると思います。このような各種研修を取っ掛かりとしてご活用いただき、攻撃テクニックの知識を各部署各グループでのベース知識として持ち帰って頂くことで、自組織の総合的なレベルアップや組織づくり・風土づくりにお役立ていただければ幸いです。

     

     

     

    新規CTA