สรุป OWASP Top 10 CI/CD Security Risks

สำหรับ Blog นี้เป็นเดินทางมาไกลเลย จากวงเวียนใหญ่ มาตรง MFEC กว่าจะออกมาได้ CI Test พังด้วย 555 แต่พอเดาสาเหตุได้และ เลยรีบมาฟัง OWASP Top 10 CI/CD Security Risks ที่จัดโดยทาง OWASP Bangkok Chapter และ 2600Thailand ครับ แชร์โดยคุณณัฐวรพงษ์ ลอยไสว จาก Shipty ครับ สำหรับหัวข้อที่จดๆมาประมาณนี้ครับ

CI / CD คือ อะไร ?

  • CI = Continuous Integration เอาไว้ช่วย Verify ว่าตัว App สร้าง Build ออกมาได้อย่างสมบูรณ์
  • CD = Continuous Delivery เอาไว้ช่วยได้ติดตั้งได้สะดวก และไวขึ้นด้วย
  • CD = Continuous Deployment จริงๆมันจะครอบ CI+CD เลย

CI / CD มาช่วยลดความผิดพลาดจาก

  • เดิม ที่เป็น Manual + ช้า + Scale ยาก
  • ใหม่ ให้งานมัน Automate ขึ้น สะดวกมากขึ้น / ได้ Fast Feedback / ใช้ Resource ให้คุ้มค่า (ทำ Shared Resource ระหว่าง Environment)

แต่อีกด้านนึงตัว CI/CD เปิด Attack Surface เพิ่มขึ้นด้วยเช่นกัน อาทิ Shared Resource จุดนึง / ตัว CI/CD อีกจุด

NOTE: สำหรับ OWASP Top 10 CI/CD มองในส่วนของ CI/CD ใน DevOps นะครับ ไม่ใช่ DevSecOps

  • อีก Keyword ควรรู้เพิ่ม SCM = Source Code Management เห็นใน Slide Speaker เขียนเยอะ

Tools: CI/CD Goat

OWASP Top 10 CI/CD Security Risks

- CICD-SEC-1: Insufficient Flow Control Mechanisms

สำหรับอันนี้ Attacker ใช้จุดเด่นของ CI/CD คือ Fast Feedback มาให้โจมตี เช่น แก้ไข Code เพื่อใส่ malicious code และปล่อยให่กระจายไปตาม pipeline โดยอิงจากสิทธิ / policy ของ SCM / CI / CD หรือ Server อื่นๆให้เกิดผลกระทบสูงสุด หากไม่ได้กำหนด Policy ในการจัดการได้ดีพอ

Recommendations

  • กำหนด branch protection rules / คนที่สามารถ Merge ได้
  • ใช้ Feature Auto Merge อย่างระวัง ต้องกำหนด Policy เพิ่ม เช่น ถ้ามีเพิ่ม Third Party Library จะให้ระบบคน Approve แทน
  • scan code เพื่อหา drifts เช่น มีการเอา CheckCode ตรวจ S3 จากเดิม private > public หรือ มีใช้ Code ที่ทำงานได้นอก Scope ขแง CI/CD เพิ่ม
  • review approval ในส่วนงานที่สำคัญ เช่น ส่วน Production
    อ๋อ Merge ห้าม Approval ตัวเองด้วย

CI/CD Goat Lab: Dodo

- CICD-SEC-2: Inadequate Identity and Access Management

การจัดการ identities ในตัว CI/CD ที่ไม่ดีพอ ทำให้เกิดปัญหา

  • Overly permissive identities - User ได้สิทธิสูงเกินวามจำเป็น
  • Stale identities - พวก User ตกค้าง เช่น ลาออกไป แต่เอาจริงๆ มีเคสอยู่นะที่เคยแจกออกไป 2 เดือนแล้ว แต่ดันโผล่มา Commit เจอตอน Merge ตกใจเหมือนกัน
  • Local identities - Local User มันเอา Policy กลางพวก password policy, lockout policy, MFA คุมยาก
  • External identities - คนภายนอก Outsource ที่จ้างเข้ามา มีสิทธิระดับไหน ใช้เวลาเท่าไหร่ หรือไปสร้าง User ตัวเอง แทนที่ใช้ของส่วนกลาง
  • Self-registered identities - เปิดให้สมัครได้เอง
  • Shared identities - Share User Account กันระหว่างคน หรือระบบ

จากปัญหาพวกนี้ Attacker สามารถเข้าถึงระบบได้ง่าย ถ้าจัดการได้ไม่ดี และทำให้ยากแก้การ Trackเคสด้วย เพราะมันมี identities หลายจุดที่ทำให้ระบบถูก compromise ได้

Recommendations

  • ใช้ identity provider (IdP) เข้ามาจัดการพวก user และคุมสิทธิจากส่วนกลาง ใช้กับทุกระบบ เวลาออกจะได้จัดการที่เดียว
  • กำหนดสิทธิเท่าที่ใช้ (Lease Privilege + ตามเวลาที่ใช้) และต้องมีการ Review เป็นประจำ
  • ลดการใช้ Local User มันจัดการยาก
  • จำกัด Self-registered คุมจากส่วนกลาง
  • ไม่ใข้ shared accounts / identities ในแง่ Dev/Sec เหมือนกันจับโจรยาก 555

CI/CD Goat Lab: Hearts

- CICD-SEC-3: Dependency Chain Abuse

Attacker ไม่ได้เข้ามาโจมตีตัวระบบเราตรงๆ แต่จะไปแผงตัวมาปรับ Library ต่างๆที่ Code ของเราใช้งานแทน ทำให้เกิด Executing malicious code (RCE) โดยมีรูปแบบการปลอมแปลงดังนี้

  • Dependency confusion - ตัว Library private repository ที่ใช้งานองค์กร ถูก Attacker สร้าง library ชื่อเหมือนกันใน public repository หลอกดักไว้
  • Dependency hijacking - เข้าไป Hack Repo Library นั้นใส่ Code ประสงค์ร้ายเพื่อเข้าไป
  • Typosquatting - ตั้งชื่อผิด เผื่อคนจะเรียกผิด เอา Code ประสงค์ร้ายไปใช้
  • Brandjacking - ตั้งชื่อ Library ตาม Naming Convention ของบริษัทดังๆ เพื่อให้เหยื่อเข้าใจผิด และเรียกใช้งาน

Recommendations

  • ป้องกันเครื่องที่ใช้ทำงานกับ Source Code เช่น Dev / CI / CD ไม่ใช้เข้าถึง Library ได้ตรงได้จาก Internet อาจจะต้องทำ Private Repo เพื่อ Filter ก่อน ที่ บ ผม ตอนนี้ใช้ Nexus นะ หรือเวลาดึงต้องให้ผ่านจาก Proxy Server
  • Library มี checksum verification + signature verification 
  • กำหนด Scope ให้ชัดเจนว่า Library อันไหน ต้องดึงจาก private / public repository พวก Node จะกำหนดจาก Prefix ได้ ที่ไล่ให้ Dev ไปทำมา แต่อันนี้ อาจจะต้องไปทำเครื่อง Dev
npm config set '@<<YOUR_PREFIX>>:registry' https://<<YOUR_LOCAL_REPO/repository/npm-group/
  • ตรวจสอบ Library ทุกครั้งก่อนขยับเสมอ ว่าเป็นการแก้ Feature อันนี้อาจจะต้องสักพัก แต่ถ้าเป็น Security Patch ต้องรีบ Update
    Note ใน Code มันจะกำหนด Rule ได้จะตาม Semantic Version ว่าจะขยับได้สุดๆเท่าไหน อันนี้จะเป็นตัว NuGet Package Version Reference | Microsoft Learn
  • ตอน Run Code ที่มีการขยับ Library ต้องลองทำใน Sandbox ก่อนขยับจริงๆ

CI/CD Goat Lab: Twiddledum

- CICD-SEC-4: Poisoned Pipeline Execution (PPE)

attacker เข้าถึง Code ใน SCM ได้ เลยพยายามขยาย Scope โดยการส่งคำสั่งเข้ามาใน CI/CD pipeline ให้ทำงาน และขยายผล เช่น Worker Node ที่ Run มี Credential/Secret อะไรหลงไว้น้า / เอา Code ออกไปแก้ หรือใส่ malicious code โดย attacker ทำ PPE 3 รูปแบบ

  • Direct PPE (D-PPE) - เข้าถึง SCM ได้ตรง แก้ Pipeline เลย
  • Indirect PPE (I-PPE) - เข้าถึง SCM ที่ต้องการไม่ได้ แต่มีสิทธิใน Code อีก Repository ที่ CI/CD pipeline ใช้งานได้
  • Public-PPE (3PE) - คล้ายกับ CICD-SEC-3

Recommendations

  • ตอนที่ให้ CI/CD ทำงาน Worker Nodes เป็นควร isolated nodes เกิดมาทำงาน และลบทิ้ง ไม่ต้องแชร์กับใคร ไม่เก็บ Credential/Secret
  • ตัว CI/CD pipeline เป็น Lease Privilege + ตามเวลาที่ใช้
  • ที่เหลือจะเหมือน CICD-SEC-1

CI/CD Goat Lab: Caterpillar

- CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)

Attacker ใช้สิทธิของ CI/CD pipeline ระหว่างทำงาน มาขยายผลการโจมตีทำ Lateral movement เช่น ลองหา Secret แล้วขโมยออกมา หรือ เพื่อเข้าถึง VM อื่นๆ เป็นต้น

Recommendations

  • แต่ละ Stages ใน Pipeline เป็น Lease Privilege + ตามเวลาที่ใช้ เช่น ตอน Get Code / Build / Test / Deploy เป็นต้น
  • OS user ที่ Run Pipeline (shared node) เป็น Lease Privilege / ใช้งานเสร็จให้ลบ Credential ออกไป //แย่ละตอนนี้ root 55
  • pipeline jobs ให้ส่งไป Run ที่ Node อื่นๆ ไม่ควรให้จัดการที่ Master / Controller Node มันมักจะถึอ Credential/Secret/Privilege สูงไว้

CI/CD Goat Lab: Cheshire Cat

- CICD-SEC-6: Insufficient Credential Hygiene

Code ใน SCM มี Credential/Secret เอาไว้ในนั้นเลย โดยหลุดจากไหนบ้าง

  • Code containing credentials being pushed to one of the branches of an SCM repository - ลีมไว้ใน Code commit + push แล้ว credentials มันติดมาด้วย
  • Credentials used insecurely inside the build and deployment processes - ลืม Credentials ไว้ใน CI/CD pipeline เช่น
    - credential เอาไว้ login เพื่อ get code จาก Git
    - credential ติดต่อกับ private docker repositories
    - token service อื่นๆ อย่าง SonarQube เป็นต้น
  • Credentials in container image layers คล้ายๆกับข้อก่อนหน้าเลย แต่ไปฝังไว้ใน dockerfile แทน
  • Credentials printed to console output - พอฝัง Credential ไว้ใน Code หรือที่ใดๆ ตอน CI/CD pipeline แล้วเรียกใช้ตัว Log มัน Print ออกมาด้วย
  • Unrotated credentials - ใช้ Credentials เดิมไม่มีการ Rotate เพรากลัวพัง แต่เราไม่รู้ว่ามันหลุดไปตอนไหน

จากที่หลุดออกมาทาง Attacker เอามาวางแผนโจมตีต่อได้ เช่น ใส่ malicious code หรือ Lateral movement เพื่อขยายผลต่อไป

Recommendations

  • อย่า Hard Code Credential ไว้ใน code //ตัว Sonar / SonarLint มันเตือนอยู่นะ
  • ใช้พวก Key Vault Tools + Rotate Key มาข่วย เช่น Azure Key Vault / HashiCorp Vault
  • ไม่ใช้งาน credentials เดียวกันกับทุก Code Repositories / pipeline
  • ถ้าจำเป็นต้องเก็บ credentials พวก Tools ต่างๆ มันมีมาให้นะ อย่าง Jenkins จะมีตัว Credential Store มาช่วย จะได้ไม่ต้องไป Hard Code ใน pipeline / dockerfile ตอน CI/CD ทำงาน แล้วหลุดออกมาใน Logs การทำงาน

CI/CD Goat Lab: Duchess

- CICD-SEC-7: Insecure System Configuration

ตัว Infra ของ CI/CD เองรวมไปถึงพวก Layer OS / Network ไม่ได้ทำตามคำแนะนำ เช่น

  • ใช้ Default Config พวก user+pass หรือ เปิดให้ register ได้
  • Overly permissive network access controls เช่น เปิดให้ Access CI/CD จาก Network ภายนอก เป็นต้น
  • ขาดการ Update Security Patch OS / Network / Software รวมถึงตัว CI/CD เอง ส่วนใหญ่คนมักจะ Patch OS / Network แต่ลืม Jenkins ว่าควร Update Patch ตามด้วย //เออจริง ที่ บ ยัง Version ไม่เท่ากัน บางอัน 5-6 ปี 555
  • หลุดตามข้อ CICD-SEC-6: Insufficient Credential Hygiene

Recommendations

  • ตรวจสอบ inventory systems มีระบบอะไรบ้างสิทธิยังไง ใครเข้าถึงได้ และ versions ที่ใช้งาน
  • network access - Least Access
  • review system configurations เป็นประจำ สม่ำเสมอ เพื่อตรวจความผิดปกติ
  • permissions ของ pipeline execution least privilege

CI/CD Goat Lab: - อันนี้จะเป็น Case Study ของ Mercedes-Benz onboard logic unit (OLU) source code leaks online | ZDNET

- CICD-SEC-8: Ungoverned Usage of 3rd Party Services

คล้ายๆข้อ CICD-SEC-3: Dependency Chain Abuse แต่จะเป็น 3rd Party Services ที่ต้องให้สิทธิ ไม่ว่าจะเป็น OAuth / Access Token ใช้ SSH key โดยตัวอย่าง 3rd Party Services เช่น พวก Build เสร็จแล้วให้ Notify แจ้งที่ MS Team หรือ ให้ GitLab Webhook กับ Jenkins

ถ้าจัดการได้ไม่ดีพอ Attacker อาจจะทำ command injection แล้วหา key secret ออกมา ขยายผลต่อไป

Recommendations

  • Approval -ตรวจสอบการให้สิทธิ และ least privilege
  • Integration - เวลาเราให้สิทธิ 3rd Party ให้ดูว่า
    - มาจากแหล่งที่น่าเชื่อถือไหม
    - มี Protocol เขื่อมต่อที่เป็นมาตรฐาน ปลอดภัย เช่น OAuth
    - ขอสิทธิเท่าที่จำเป็น
  • Visibility over ongoing usage -มี Log ให้เห็นชัดว่าสิทธิที่เราให้ 3rd Party ทำอะไรได้บ้าง
  • Deprovisioning - ไม่ได้ใช้งานนานๆ เอาออกไป

CI/CD Goat Lab: Dormouse

- CICD-SEC-9: Improper Artifact Integrity Validation

Artifact ที่เรานำไปใช้งาน อาจจะไม่ใช่ของที่เราใช้ประจำ มันแอบคล้ายกับ CICD-SEC-3: Dependency Chain Abuse

Recommendations

  • Code signing - คนที่ Commit Push นอกจากมีสิทธิแล้ว ต้องทำ sign commits dev แต่ละ account มี Key ยืนยันของตัวเอง GitHub > commit signature verification
  • Artifact + 3rd party resources verification - checksum verification + signature verification ของที่เอามาใช้
  • Configuration drift detection >> เหมือนเจอ Pre-Sale ในงาน Infrastructure drift and drift detection explained | Snyk

CI/CD Goat Lab: Dormouse

- CICD-SEC-10: Insufficient Logging and Visibility

อันนี้พอระบบมันใหญ่ขึ้น แต่เราไม่สามารถตามดูแลได้ทั่วถึง พวก Telemetry + observability ไม่ชัด ทำให้ Attacker เข้ามาเดินเล่นใน Enviromint ของเราได้

Recommendations

  • ทำ Inventory และจัดลำดับความสำคัญ จะได้วางแผนเรื่อง Log ได้
  • เปิดใช้งาน Log ของแต่ละจุก และ ทำ centralized log - ทำพวก SIEM
  • ตรวจสอบพฤติกรรมที่แปลก anomalies + potential เด๊่ยวนี้มี AI ทำเยอะเลย

CI/CD Goat Lab: -

Sample Case Study

ระหว่าง Meetup มียกตัวอย่างเคสที่เกิดขึ้นจริงๆ เรื่องพวกนี้ไม่ได้ไกลตัวเลย อาจจะเป็นเรื่องใหม่ที่ต้องมาสนใจตามเทรน DevOps เช่น

สรุป หลักๆ พยายามคุม Lease Privilege / Least Access / จัดการพวก Security Patch สม่ำเสมอ / ตัว Code + Pipeline ที่เปลี่ยนแปลง ต้องมีการตรวจสอบความผิดปกติด้วย ถ้า Attacker ทำตามขั้นตอน Cyber kill Chain สำหรับจนได้ Credential > Privilege Escalation และเอาตัว Data ออกไปได้ อาจส่งผลร้ายแรงตามมาได้

Resource: Slide

Reference

Discover more from naiwaen@DebuggingSoft

Subscribe to get the latest posts sent to your email.

Tags

Related Posts