ペパボセキュリティ研修2024 公開版

Transcript

1. 1 ペパボセキュリティ研修2024 (公開版) 紫関 麗王 セキュリティ対策室 2024.07.04
2. ペパボセキュリティ研修2024 公開版 • 本資料はGMOペパボ株式会社において、2024年新卒エンジニアを対象に⾏ったセキュリティ研修の スライドを公開⽤に編集したものです • 社外秘である情報などは削除、およびマスクしている箇所があります 2 本資料について
3. 3 ⾃⼰紹介 セキュリティ対策室 2023年 新卒⼊社 紫関 麗王 Shiseki Reo セキュリティ対策室で2019年からアルバイトをして いました。セキュリティに関すること好き好きクラ ブ • セキュリティ‧キャンプ2023,2024全国⼤会講師 • SECCON、SECCON Beginners運営 • Twitter : @n01e0
4. • Kindleで漫画をたくさん買っています • 焼⾁が好きです • バイトのときにオフィス近くの焼⾁ランチほとんど⾏きました • 結論、韓の台所です • ⼀⼈で⾏くなら治郎丸も良いよ • 寿司も好きです • ⿂がし⽇本⼀によく⾏きます • パソコンが好きです • いっぱいあります ⾃⼰紹介 4 令和最新版
5. セキュリティ‧security‧Malware‧マルウェア‧脆弱性などのキーワードを光らせているのですぐに⾒つ けます。 ⼤量のチャンネルに⼊っています。 セキュリティに関する話が⼤好きです ⾃⼰紹介 5
6. 6 アジェンダ 1. この研修について 2. 脆弱性とは 2.1. 脆弱性の種類 2.2. 脆弱性の例 3. トリアージ 3.1. git CVE-2024-32002 3.2. runc Leaky Vessels 4. 被害 5. 意識してほしいこと 6. 攻撃者の⽬線をもつ
7. 1．この研修について 7
8. この研修について 8 • アプリケーション開発‧運⽤における セキュリティの観点 • 脆弱性を ⾒つける‧修正する‧作らない技術 これらを⾝につける ⽬標
9. この研修について 攻撃⼿法についても学びます 他⼈‧他社のサービスや⾃分の管理していないアプリケー ションなどに対しては絶対に攻撃を⾏わないでください。 倫理 9
10. この研修について 眠くならないようにがんばります。頑張りましょう。 ⼀旦座学です 10
11. 脆弱性とは 11
12. 12 脆弱性とは 脆弱性（ぜいじゃくせい）とは、コンピュータのOSやソフトウェアにおいて、プログラムの不具合や設計上のミスが原因となって発生し たサイバーセキュリティ上の欠陥のことを言います。脆弱性は、セキュリティホールとも呼ばれます。脆弱性が残された状態でコン ピュータを利用していると、不正アクセスに利用されたり、ウイルスに感染したりする危険性があります。
 
 (総務省 国民のためのサイバーセキュリティサイト)
 ぜいじゃくせい 長い
13. 実装上のバグだけでなく、設計のミスも脆弱性につながる →セキュリティ対策室では、設計や実装段階でのレビュー‧脅威モデリングなどを⾏っています よくあるコードのバグ だけじゃない 脆弱性とは 13
14. 攻撃者の視点で狙うポイントを探すため、脅威モデリングを⾏っています 具体例を⾒たほうが早いので⾒ましょう 設計段階でのセキュリティの考慮 脆弱性とは 14
15. • Spoofing • Tampering • Repudiation • Info Disclosure • Denial of Service • Elevation of Privelege これら6つの観点でみます STRIDE 脅威モデリング 15 https://developer.ibm.com/articles/threat-modeling-microservices-openshift-4/
16. • Spoofing • 他⼈のコントロールパネルへのログイン • Tampering • VMイメージの改ざん • Repudiation • SQLのクエリログ • Information Disclosure • 作成時の機微な情報がログに残っていないか 例 脅威モデリング 16
17. 脆弱性の種類 17
18. 18 脆弱性の種類 脆弱性のカテゴリや条件のリスト 種類ごとにIDを割り当てている。 例えばクロスサイトスクリプティング(XSS)はCWE-79 実装に⽤いる⾔語特有のCWEもあったりする(C,C++,Java,PHP) CWE (Common Weakness Enumeration)
19. ライブラリやアプリケーション、各種ソフトウェアの脆弱性に対し、⼀意のIDを割り当てて管理している 例えばlog4shellはCVE-2021-44228 CVE Common Vulnerability and Exposures 脆弱性とは 19
20. 脆弱性の影響度を図るための指標 log4shellはBase Score 10.0のCriticalでCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H - AV(Attack Vector) 攻撃と対象の物理的な距離。ネットワーク‧隣接ネットワーク‧ローカル‧物理 - AC(Attack Complexity) 脆弱性を悪⽤し、攻撃に使う場合の条件の複雑さ。低‧⾼ - PR(Privileges Required) 脆弱性を悪⽤し、攻撃に使うために必要な権限。なし‧低‧⾼ - UI(User Interaction) 攻撃を成功させるために、ユーザの操作が必要かどうか。不要‧必要 - Scope 脆弱性がシステム上の他のコンポーネントに影響を与えるか。変更あり‧変更なし - C(Confidentiality) 情報の気密性に与える影響。⾼‧低‧なし - I(Integrity) 情報の正確性‧信頼性への影響。⾼‧低‧なし - A(Availability) 情報やシステムの可⽤性に与える影響。⾼‧低‧なし CVSS 脆弱性とは 20
21. Base Scoreは最⼤10。10のヤツが出たらヤバい。 名前付きの脆弱性もヤバい。Log4shellもまさにそれ。HeartBleed、Spectre、Meltdown、etc… ⼀つ⼀つの脆弱性は⼤したこと無くても、組み合わせるとヤバいパターンもある。 緩和策のバイパス⼿法だけだとスコアは低いとか ある重⼤な脆弱性の修正‧緩和策に対して、それをバイパスする⼿法があれば攻撃に使える CVEの⾒⽅ 脆弱性とは 21
22. 脆弱性の例 22
23. 主にユーザの⼊⼒を直接レンダリングしたときに発⽣する 例えば "<h2>hello " + user_name + "</h2>" みたいなコードがあったときに、 </h2><script>alert(1)</script><!--という名前のユーザがいると…? XSS 脆弱性の例 23
24. 以下のコードには脆弱性があります XSS 24
25. 最近のフレームワークはサニタイズを⾏ってくれるので、普通に使う分には問題ありません <%= で変数を出⼒するときはサニタイズされるので、基本的にXSSは発⽣しません - <%== - <%= raw などのサニタイズを⾏わずに変数を出⼒する⽅法を採⽤する際は注意してください XSS 25 サニタイズ
26. SQL⽂を作成する際、ユーザの⼊⼒を組み込む際は注意が必要 “SELECT * FROM users WHERE id = ‘“ + id + “‘’ もしここでidが数値じゃなく⽂字列だったら? “0’ OR ‘1’=’1” SQL Injection 脆弱性の例 26
27. 脆弱性をみつけよう SQL Injection 27
28. トリアージ 28
29. 29 トリアージ セキュ対で判断を⾏っています - CVSS Score - DREAD Model - PoCの有無 - 社内影響の有無 - etc... 脆弱性が⾒つかった！さぁどうする？
30. トリアージ Leaky Vessels まず名前付き脆弱性の時点でヤバいことが多い git CVE-2024-32002 gitなのでみんな使ってる&cloneだけで発⽕する 具体例 30
31. トリアージ 1. 把握 2. 検証 3. 判断 流れ 31
32. トリアージ dockerなので影響範囲が広い 軽く調べてみると、ビルド時にエスケープできるもの 検証を始める Leaky Vessels 32
33. トリアージ あらゆるリソースを漁る - GitHub - Twitter - etc… PoCが公開されていると、検証もしやすいが攻撃もしやすい Leaky Vessels 33
34. トリアージ PoCがあった場合でも、まずは正しい情報を探る必要がある 悪意のあるコードの可能性もあるので、ちゃんと読む runcに脆弱性があり、ビルド時に使⽤しているfdの⼀つがホストのものだった そのfdを経由してホストへ影響を与えることができる PoCの検証 34
35. トリアージ cloneするとコードが実⾏される - hookとシンボリックリンクの組み合わせによる攻撃 - hookは便利だが、pre-commit以外にもある - gitにおける任意コード実⾏系の脆弱性はhookが多い気がする git CVE-2024-32002 35
36. 意識してほしいこと 36
37. あらためて 37 • アプリケーション開発におけるセキュリティの観点を⾝につける • 脆弱性を ⾒つける‧修正する‧作らない 技術を⾝につける ⽬標
38. 意識してほしいこと ⼀番重要で、簡単なこと 「ユーザの⼊⼒を信⽤しない」 「AIの出⼒も信⽤しない」 攻撃者もユーザの⼀⼈として攻撃を⾏ってくる フォームの⼊⼒値や、外部に公開しているAPIの使⽤など 脆弱性を ⾒つける‧修正する‧作らない ために 38
39. 攻撃者の目線をもつ 39
40. 40 攻撃者の⽬線をもつ ⼀番簡単なのは、実際に攻撃を⾏ってみること ただし、実際に動いているサービスなどに許可なく攻撃を⾏うのは犯罪 じゃあどうすれば? 脆弱性診断、CTF やってみましょう どうすれば?
41. やっぱり⼿を動かすのが⼀番 - セキュリティレビュー - 脆弱性診断 - 脆弱性の修正 これらを体験してみましょう ここからはハンズオンです 攻撃者の視点をもつ 41
42. セキュリティレビュー 42
43. 43 セキュリティレビュー 昨年、n01e0が作ったRails TutorialのアプリケーションをもとにPRを作成しています - (internalなリポジトリなので公開できません) ベースはRails Tutorialなので読めると思います。頑張ってください PRに脆弱性が無いか確認しましょう
44. 脆弱性診断 44
45. 脆弱性診断 45 診断⽤のやられアプリです trainingか個⼈の元にforkしてください make installして docker compose up -dすれば動きます Railsアプリケーションの脆弱性を探してみましょう
46. さぁ 脆弱性を⾒つけてください 脆弱性診断 46
47. 脆弱性診断 まずはアプリケーションの仕様と挙動を把握するために操作してみましょう 1. アカウント登録 2. ログイン 3. 投稿 4. ユーザ情報編集 など 流れ 47
48. ⾊々と操作をしていると「違和感」を感じることがあります これを⾒逃さず、バグを⾒つけましょう 直感を鍛えることが⼤事です 「違和感」を⾒逃さない 脆弱性診断 48
49. 脆弱性の修正 49
50. 50 脆弱性修正 今度は⾒つけた脆弱性を修正しましょう rspecで修正の確認ができます 修正もしましょう