本文の内容は、2022年8月12日にMiguel Hernándezが投稿したブログ(https://sysdig.com/blog/blackhat-2022-recap/)を元に日本語に翻訳・再構成した内容となっております。
SysdigはBlackhat 2022で、クリプトジャックに対抗するための機械学習によるクラウド検知・応答（CDR）を発表しました。もっと詳しく知りたい方は、以下のブログを参照してくてください。
25周年を迎えたBlackhat 2022が、今週ラスベガスで開催されました。このイベントは、情報セキュリティ・コミュニティにとって最も重要なイベントであり、セキュリティ・ベンダーにとっては、成長を続けるこのエコシステムにおけるすべてのイノベーションと製品を展示する最高の場所です。今年は111カ国から参加者が集まりました。
2020年、Black Hatは、Platform Securityに関する既存のトラックにCloudという言葉を追加しました。Kubernetesやコンテナなどのクラウド技術に関する研究は2020年以前からBlack Hatで発表されていましたが、トラックタイトルにCloudを加えることで、多くの企業や個人が日々依存しているクラウドのセキュリティの重要性を如実に打ち出しました。
まとめると、ほとんどの講演の核にクラウドがあり、eBPFは可視性が高まっており、サプライチェーンへの攻撃と防御を優先課題としています。脅威としては、クラウドのランサムウェアとグローバルな危機管理、最後にバーニングアウトの早期発見の重要性が言えると思います。
このBlackhat 2022の総括では、おそらくいくつか抜けていると思われるものの、最も興味深いと思われるいくつかの講演について、その見聞を紹介します。
Blackhat 2022 – KEYNOTES
今回のキーノートでは、情報のコントロールが主なトピックの1つで、フェイクニュースが私たちの生活にどのように影響しているかという問題や、信頼できる情報をチェックすることが本当に難しくなってきているという点について言及されています。その解決策として、情報共有の管理を強化するケースもありますが、これは検閲に利用される可能性があります。今は政府や企業だけでなく、個人という新しいプレーヤーも加わっており、スパム探知機のように、私たちを守ってくれる倫理的なものが必要です。ウクライナへの侵攻も、Blackhat 2022の最初の数分間で言及されたトピックです。いくつかの企業が参加し始め、ロシアのプロジェクトとの関係を禁止したり、ロシアでのドメイン更新に影響を与えたりしました。つまり、これらの紛争の終わりは確実ではなく、むしろ社会への影響を増大させながら、徐々に混沌としてきているようなのです。
CISAのディレクターであるChris Krebs氏は、Blackhat 2022の基調講演の1つで、なぜ今これほどひどいことになっているのか、主な4つの理由を説明し、「Life is too short to work for a^^holes」という重要な教訓を残していました。
- テクノロジー： ソフトウェアが増えるということは、より複雑になり、デフォルトでは、より安全でないコードの統合が維持・更新されることを意味します。さらに、クラウド内のビジョンの欠如が、いかに複雑なリスク管理を引き起こすかを強調しました。
- 悪質な行為者： 攻撃者はこれらすべてを知っており、利益がクラウドにあることを知っています。クラウド攻撃の解剖で述べたように、クラウドランサムウェアは将来の脅威であり、大きな影響を与えることになるため、攻撃者はサプライチェーンをターゲットにしてアクセスすることに賭けています。
- 政府： 規制、経済、イノベーションは拡大していますが、政府と効率的に連携することは非常に困難です。チェックリスト以上の成果を得るために、コンプライアンスも変わらなければなりません。将来の世界的な事件にも目を配り、備えなければなりません。
- 人：これらの情報をどのようにバランスさせるか。ほとんどの場合、彼らはこれらすべてのテクノロジーのエンドユーザーであり、セキュリティ侵害やインシデントの犠牲者でもあります。
調査ジャーナリストであるキム・ゼッターは、脅威の進化とそれが企業に与える影響について、適切な概要を説明しました。メディアは、新しい脆弱性や脅威を視聴者に説明する際に、適応しなければなりません。彼女は、すべてが変わったが、同じアクターが残っているStuxnet以前と以後の時代について言及しました。ランサムウェアから始まり、コードを改変する高度なマルウェアへと進化し、最終的にはSolarWindsのサプライチェーンに直接影響を与えるようになりました。
実際の事例をもとに、ランサムウェアに感染した場合に備えて完璧なバックアップシステムを構築し、復旧の準備をしていたある企業が、いざ感染したときに身代金を支払ってしまったことを説明しました。なぜか？それは、復旧プロセスのテストをしていなかったからです。ですから、消防訓練と同じように、万が一のことを想定し、シミュレーションを行う必要があります。
最後に、私たちは、ネットワークの分離、境界線の強化、MFA、IR計画、バックアップなど、セキュリティに関する優れた実践方法を知っており、それによってほとんどの攻撃を防いでいることを明確にします。しかし、重要なインフラストラクチャーはまだ完全に実装されておらず、インターネット上で認証されずに露出したままです。
Blackhat 2022 – トップブリーフィング
Blackhat 2022 USAの2日間のトレンドセッションで、私たちはサイバーセキュリティに関するハイレベルな講演をいくつか聴くことができました。その中でも、特に注目すべきものをご紹介します。IAM ノックする者
クラウドアカウントのセキュリティを確保する上で最も重要なことの1つは、IDアクセスをどのように管理するかということです。この講演では、IgalとNoamが、各パブリッククラウド（AWS、GCP、Azure）がアクセスと認証をどのように実装しているかについて、分かりやすく説明しています。各クラウドプロバイダーは異なる仕組みを持っていますが、他より明らかに優れているものはありません。大きな違いは許可のスコープで、AWSのスコープはポリシー自体の一部であり、彼らはAWS SSOを推奨しています。
ブラックハット2022 IAMクラウドもう一つの重要なトピックは、non-human アイデンティティで、各プロバイダーは異なる呼び方をしますが、攻撃者はこの種のことには関心がなく、クラウドIAMの弱点を突くことだけが好きで、スピーカーは様々な例を挙げてその方法を説明します。
以下、その内容を紹介します。
- デフォルトは攻撃者の最良の友である。優れたCSPMを維持することは、すべてのアカウントを制御する攻撃者の手法の大部分を阻止するために極めて重要です。一時的な修正が恒久的なものにならないようにしましょう。
- クレデンシャルを監視し、保護する。作成だけでなく、漏洩したアカウントの変更も大きな脅威となります。
- すべてを記録するが、限界を知る：セキュリティの黄金律はすべてを記録することですが、場合によっては限界を超えてしまうことがあります。攻撃者はこれを利用して、自分の行動を隠し、気づかれないようにするのです。この時点で、別の選択肢を強調したいと思います。大量のログを避けるために、実行時またはこれらのログが発生した時点で検知するようにするのです（最初の侵害攻撃を検知する場合は、1つのウィンドウだけで十分です）。これは、オープンソースのFalcoが行おうとしていることです。
最後に、講演者は、過剰なパーミッションの管理に役立つさまざまなオープンソースツールを共有しました。建設的（必要なものだけを追加する、最小特権の原則）と還元的（デフォルトの権限とそこから削除する）の2種類のツールです。
| 建設的 |
還元的 |
| policy-sentry | Cloudtracker |
| iamlive | Repokid |
| access-undenied-aws | IamSpy |
| PMapper | |
| Cloudsplaining |
すべてを引き受けようとする : 燃え尽き症候群について話そう
燃え尽き症候群は冗談ではなく、自分自身をケアし、手遅れになる前に燃え尽き症候群を発見しなければなりません。この講演では、セキュリティ業界における問題点として、セキュリティエンジニアは精神的な負担が大きく、人手不足が発生した時やサイバー攻撃を予測しなければならない時に迅速な対応を迫られるため、高いストレスが続くことにつながるということが明らかにされました。もちろん、セキュリティを数値化することは非常に難しいので、時間と労力（お金も！）をうまく投資できているかどうかはわかりません。このため、私たちは、どんなに頑張っても、自分の仕事がうまくいっていないと感じることがよくあります。
講演者は、健康、体力、リラクゼーション法を提案しています。燃え尽き症候群の解決法としては、短時間で仕事をする、私生活とのバランスをとる、できることなら仕事をやめて自由になる、などがよく言われます。冗談はさておき、燃え尽き症候群の危険性が少しでもあれば、助けを求めてください。
RCE-as-a-Service : 実世界でのCI/CDパイプラインの妥協の5年間から学んだ教訓
基本に立ち返ること、これは押さえておきたいポイントの一つです。講演者たちは、目新しいものではない問題をもとに、CI/CDパイプラインが危険にさらされたさまざまなユースケースや事例を説明しました。YAMLやその他の設定ファイルにエンコードされた認証情報の漏洩、ネットワークの分離の失敗、最小特権の原則に従わないことなどがその例です。デモの1つは、ますます一般的になっている脅威であるクラウド・ツー・プレミス・ホッピングに焦点を当てたものでした。この問題を解決するために、実行しているすべてのものを検証するための署名プロセスが、言及されたものの1つです。Kubernetesにおけるcosignとconnaisseurを使ったこれらの手順について詳しく説明します。
トレース・ミー・イフ・ユー・キャン Linuxのシスコールトレースを回避する(WIP)
システムコールトレースは、Linuxシステム内のさまざまな動作を検出するために使用されます。このデータを取得し、何かおかしなことが起こったときにアラートを生成するために処理しようとするツールがいくつかあります。Kubeconでの講演(Bypassing Falco)のように、この講演ではFalcoツールと現在のバージョンで解決されたTOCTOUの問題に焦点を当てます。TOCTOUとは、time-to-check to time-to-userの略で、レースコンディションによって引き起こされるソフトウェアのバグです。本講演では、攻撃者がどのようにシステムコールのトレースを変更できるかをいくつかのシナリオでシミュレートし、ここではそのうちの2つを要約しました。
- 1つ目は、クライアント（または侵害されたデバイス）とサーバー（このシナリオでは、C2C）間の通信に遅延をインジェクションする方法です。この技術は、通信が開始される際のハンドシェイクにおけるレスポンスを遅延させることに基づいています。エクスプロイトが元のIPを偽のIPに置き換えたときの通信は、フォレンジック後の分析から隠されています。Wiresharkでネットワークトレースを確認すると、最初のパケットでC2Cの本当のIPを発見することができます。
- 2つ目のシナリオは、同じアイデアですが、私たちが変更したいルートに関するものです。この攻撃は、GKEの内部に情報を保存するために行われ、書き込むファイルのパスを変更することで検出を回避します。
このデモは、DefCon 29 で発表された Phantom-attack を使用して実行されます。軽減策として、Falco の新しいバージョン (>0.32) を使用していました。seccomp などのシステム コールをブロックする他の方法を使用することもお勧めします。 これは、パフォーマンスに影響します。
Kubernetes Privilege Escalation（特権昇格）: コンテナエスケープ == クラスター管理者?
このトークは、KubeCon EUでTrampoline Podsというトークで発表されたのと同じコンセプトを解説しています。Kubernetesクラスター内ではコンテナが稼働していますが、そのうちの1つのコンテナが脆弱で、攻撃者がコンテナエスケープ技術を使用してコマンドを実行し、ノード全体を制御するためにアクセス権を取得するというシナリオが紹介されています。
次にクラスター全体を制御するためにはどうすればよいでしょうか。Kubeletの認証情報だけでは不十分で、ノードのパーミッションはadminと異なります。DaemonSetsのTrampoline Podを制御してノード間の横移動を行い、クラスター全体の制御を得ることが目標です。この種の攻撃を実行するために必要なパーミッションの明確なリストはありませんが、どのパーミッションが必要であるかによって、どちらか一方を実行することができます。
- AuthN/AuthZ: 権限をエスカレートさせるためになりすます。
- トークンを取得する: 特権昇格のために、サービスアカウントの有効なシークレットリストで新しいトークンを作成し、api-serverへの認証に使用します。
- RCE: コードを実行するために特権をエスカレートする必要はありません。これは構成によって異なります。 Kubelet を制御します。
- Podを盗む: 強力なサービスアカウントでPodをあるノードから別のノードに移動させる。ノードの更新や他のPodの削除のパーミッションが必要です。
注意：新たな悪用方法！ パイプを使わないが、ダーティパイプのような巧妙さ
Zhenpeng Linが発表した新しい悪用方法は、DirtyCredと呼ばれ、Linuxカーネルのクレデンシャルを交換することに基づいています。シンプルで効果的、かつ汎用的な手法です。このため、コンテナからエスケープすることができ、かつ、本当に脅威となります。CVE-2021-4154またはCVE-2022-2588に脆弱なシステムで実行され、講演者は2つのパス攻撃を説明しました。
タスククレデンシャル（struct cred）を攻撃する: カーネルヒープ内の非特権クレデンシャルを変更し、フリーで特権クレデンシャルを同じ場所に置いてなりすまします。
オープンファイルの認証情報（struct file）を攻撃する: チェックの後、メモリに書き込む前にファイルを解放します。解放されたメモリスロットに読み取り専用のファイルオブジェクトを割り当てます。
特権ユーザがタスク認証情報を割り当てるのを待たずに、これを決定論的に行うために、攻撃者はユーザ空間の特権プロセス（ルートSUIDを持つ実行可能ファイルまたはルートとして実行するデーモン）をトリガーすることができます。最後に、攻撃者は userfaultfd または FUSE (pause kernel execution) を拡張することで、ファイルエクスプロイトを安定化させる必要があります。
非常に興味深い悪用方法であるため、さらなる研究が必要です。
DNSSECダウングレード攻撃
DNSSEC は、暗号化署名と信頼の連鎖によるリゾルバの検証をベースとした DNS の解決方法です。DNSSECは、侵害されたアプリケーションがある場合、DNSポイズニングから私たちを保護します。DNSSECは、データの起源の真正性と完全性を提供しますが、機密性は提供しません。この攻撃は、リゾルバに最も弱いセキュリティ経路を使用させ、信頼の連鎖の最も弱いリンクを攻撃することに基づくものです。最終的なモデルは、攻撃者が暗号のシークレットを知らなくても、リゾルバを起動し、 傍受し、レコードと署名を変更できるようにすることです。本物のリゾルバへのなりすましに成功します。
これに対する対策は、より強力なDSを要求することと、SHA-1をやめることです。
DNSについてもっと知りたい、クラウドで安全な方法で構成したいという方は、「クラウドでDNSを保護する方法」の記事をお読みください。
OSSの脆弱性を一掃するセキュリティ・リサーチャーのスケールアップ
オープンソースのコードに脆弱性を発見したとき、それをどのように修正するのか？まあ、コードをフォークして、脆弱性を解決するような変更を内部でPRすればいいのです。しかし、この安全でないコードが何千ものリポジトリにある場合、どうすればいいのでしょうか？修正された最初の脆弱性は、HTTP経由で依存関係をダウンロードまたは更新することで、これはMiTMに対して脆弱であり、まったく推奨されません。しかし、それは本当に問題なのでしょうか？まあ、Sonatypeのmavenコアのダウンロードは今でもHTTPを使っていますが（25％）。
この問題を解決するために、講演者はCodeQLでpython botを作成し、簡単な正規表現で100kをスキャンしています。
これで、botは1,400以上のプルリクエストを作成し、採択率は40%でした。かなり印象的です。しかし、これはほんの始まりに過ぎません。大規模なリポジトリコード内のすべてのセキュリティ脆弱性で同じことをするにはどうしたらいいのでしょうか？
彼らはopenRewriteを導入しました。これは、APIの変更に追従し、脆弱性を修正し、コードの品質を向上させる自動ソフトウェアリファクタリングと、プロセス全体を管理するためのmoderneプラットフォームです。講演では、3つの脆弱性（temporary directory hijacking、Partial path traversal、Zip Slip）について、java言語にフォーカスして説明しました。
次は何でしょうか？
Blackhat 2022 USAで最も関連性が高いのはこの点でした。主なトピックはやはりKubernetesセキュリティ、クラウドセキュリティ、サプライチェーン攻撃ですが、世界的なインシデントの存在感がありますね。数ヶ月後にはヨーロッパで次のBlackHatが開催されますが、ここではもっと素晴らしい講演やデモを行いたいと考えています。
SysdigはBlackhat 2022で、クリプトジャックに対抗するための機械学習によるクラウド検知・応答（CDR）を発表しました。もっと詳しく知りたい方は、以下の資料で掘り下げてみてください。