Tích hợp liên tục và triển khai liên tục (CI/CD) pipelineCác công nghệ này đóng vai trò then chốt trong việc tạo điều kiện thuận lợi cho quá trình phát triển phần mềm hiệu quả. Tuy nhiên, vì vậy, các công nghệ này cần được xem xét cẩn thận. pipelineKhi công nghệ ngày càng trở nên quan trọng, nhu cầu bảo vệ chúng khỏi các lỗ hổng bảo mật càng trở nên cấp thiết hơn. Cuộc điều tra chuyên sâu này tập trung vào việc giải quyết một rủi ro nổi bật được xác định trong danh sách OWASP Top-10. CI/CD Rủi ro an ninh: Bị nhiễm độc Pipeline Thi hành (PPE).
Chất độc là gì? Pipeline Thi hành (PPE)
Theo OWASP Top-10 CI/CD Rủi ro an ninh, “Ngộ độc Pipeline Thực hiện (PPERủi ro (risk) đề cập đến khả năng của kẻ tấn công có quyền truy cập vào hệ thống kiểm soát mã nguồn – mà không cần quyền truy cập vào môi trường biên dịch – Thao túng quy trình xây dựng bằng cách chèn mã/lệnh độc hại vào quá trình xây dựng. pipeline cấu hình, bản chất 'đầu độc' pipeline và chạy mã độc hại như một phần của quy trình xây dựng.”
Nói tóm lại, bị đầu độc. Pipeline Việc thực thi (PPE) được thực hiện khi Kẻ tấn công có thể sửa đổi pipeline logic.
Có hai biến thể:
- Thiết bị bảo hộ cá nhân trực tiếp (D-PPE): Trong kịch bản D-PPE, Kẻ tấn công sửa đổi tệp cấu hình CI. trong kho lưu trữ mà họ có quyền truy cập, bằng cách đẩy trực tiếp thay đổi lên một nhánh từ xa không được bảo vệ trên kho lưu trữ, hoặc bằng cách gửi yêu cầu kéo (PR) với thay đổi từ một nhánh hoặc một bản sao (fork). Kể từ CI pipeline Quá trình thực thi được xác định bởi các lệnh trong tệp cấu hình CI đã được sửa đổi, các lệnh độc hại của kẻ tấn công cuối cùng sẽ được chạy trên nút xây dựng sau khi quá trình xây dựng hoàn tất. pipeline được kích hoạt.
- PPE gián tiếp (I-PPETrong một số trường hợp, khả năng sử dụng D-PPE không khả dụng đối với kẻ thù có quyền truy cập vào... SCM kho lưu trữ (ví dụ: nếu pipeline (được cấu hình để lấy tệp cấu hình CI từ một nhánh riêng biệt, được bảo vệ trong cùng kho lưu trữ). Trong trường hợp như vậy, thay vì đầu độc... pipeline Bản thân kẻ tấn công sẽ chèn mã độc vào các tệp được tham chiếu bởi... pipeline (ví dụ: các tập lệnh được tham chiếu từ bên trong...) pipeline tệp cấu hình)
Trong cả hai trường hợp, GitHub sẽ thực thi lệnh đã sửa đổi. pipeline không cần phải xem xét hoặc phê duyệt trước đó.
Phát hiện sớm PPE
Làm thế nào chúng ta có thể phát hiện loại lỗ hổng này?
Hãy xem ví dụ này. pipeline :
name: PR CI
on:
pull_request:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
jobs:
pr_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
# Simulation of a compilation
- name: Building ...
run: |
echo $MY_SECRET
mkdir ./bin
touch ./bin/mybin.exe
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh "${{ github.event.pull_request.user.login }}" "${{ github.workflow }}"
echo Tests executed.
Và nội dung của một tập lệnh shell giả lập (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0
pipeline Nó khá đơn giản: mục đích của nó là cung cấp cho người đánh giá một số gợi ý sơ bộ về... Pull Request (Quy trình chấp nhận PR):
- Nó sẽ được kích hoạt vào yêu cầu kéo (tức là mỗi khi một yêu cầu kéo (PR) được tạo)
- Nó kiểm tra mã PR (tức là mã được đóng góp).
- Nó sẽ tạo nên công trình xây dựng
- Nó sẽ chạy các bài kiểm tra trên mã nguồn do người dùng đóng góp (ví dụ: bằng cách thực thi một tập lệnh shell).
Bước #3 (tạo bản dựng) và #4 (chạy thử nghiệm) sẽ thất bại nếu mã không biên dịch được hoặc không vượt qua các bài kiểm tra. Vì vậy, các bước này là điều kiện cần thiết, nhưng chưa đủ, để chấp nhận yêu cầu kéo (PR). Nếu thành công, quản trị viên kho lưu trữ sẽ tiến hành xem xét mã được đóng góp và dựa trên đó, họ sẽ chấp nhận/từ chối/bình luận yêu cầu kéo.
Máy quét Xygeni
Xygeni cung cấp CLI (cái “Máy quét Xygeni”) có thể được nhúng vào một pipeline hoặc chạy trong dòng lệnh. Máy quét Xygeni sẽ xử lý pipelineCông cụ này sẽ kiểm tra các lỗ hổng bảo mật và, nếu có chứng chỉ PAT của GitHub, nó sẽ kết nối với GitHub để phát hiện các lỗ hổng ở cấp độ tổ chức/kho lưu trữ.
Kho hàng Xygeni
Khi chúng ta chạy Xygeni Scanner trên kho lưu trữ này, nó sẽ phát hiện ra một tập hợp các tài sản hữu ích (các tài sản này). Kho hàng XygeniKho hàng sẽ được bổ sung nhiều loại khác nhau. CI/CD tài sản, Chẳng hạn như:
- SCM WELFARE nơi kho lưu trữ được lưu trữ
- SCM bổ sung đã cài đặt/sử dụng
- Kho lưu trữ mã chính nó
- SCM Cơ quan nơi kho lưu trữ thuộc về
- CI/CD Pipelinevà Việc làm
- CI/CD WELFARE chạy pipelines
- IaC Trung Tâm Tài Liệu được định nghĩa trong kho lưu trữ
- Bên ngoài Sự phụ thuộc
- vv ..
Trong ví dụ của chúng tôi, chúng ta có thể lọc Kho hàng theo một số loại tài sản cụ thể (SCM- và các tài sản liên quan đến CICD), vì vậy chúng ta có thể thấy rằng:
- SCM Hệ thống là GitHub Cloud
- Kho lưu trữ được lưu trữ trên GitHub Cloud và thuộc về một Tổ chức GitHub cụ thể.
- Có hai pipelineđược cung cấp bởi GitHub (CI/CD hệ thống)
- Mỗi pipeline bao gồm một bước cụ thể
Bằng cách chọn mục trên pipeline Chúng ta có thể thấy một số điểm yếu:
- At pipeline ở cấp độ này, nó dễ bị tổn thương bởi cả hai trực tiếp và Thiết bị bảo hộ cá nhân gián tiếp.
Chúng ta có thể xem chi tiết về những người bị đầu độc. Pipeline Các lỗ hổng thực thi
Xygeni phát hiện ra rằng đó là dễ bị tổn thương bởi D-PPE vì nó được kích hoạt trên một Pull Request sự kiện và không có biện pháp kiểm soát bảo mật bổ sung nào, do đó bất kỳ người dùng kho lưu trữ nào cũng có thể sửa đổi. pipeline và những sửa đổi đó sẽ được thực hiện mà không cần xem xét hoặc phê duyệt.
Tương tự như vậy, Xygeni cũng phát hiện ra rằng nó... dễ bị tổn thương bởi I-PPE do việc gọi đến tập lệnh shell từ pipelineBất kỳ người dùng nào của kho lưu trữ đều có thể sửa đổi tập lệnh shell và những sửa đổi đó sẽ được thực thi mà không cần xem xét hoặc phê duyệt.
Bạn muốn biết thêm?
Lợi dụng thiết bị bảo hộ cá nhân (PPE).
Để khai thác tối đa lợi ích của PPE, hãy xem xét một kịch bản trong đó có... hai loại người dùng kho lưu trữ:
- An người dùng nội bộ (một nhà phát triển nội bộ đang làm việc trên kho lưu trữ đó), có quyền ghi vào kho lưu trữ.
- An người dùng bên ngoài (Một lập trình viên thuê ngoài đang làm việc trên kho lưu trữ đó nhưng chỉ có quyền đọc trên kho lưu trữ), tức là không được phép tạo nhánh từ kho lưu trữ và buộc phải làm việc trên một bản sao (fork).
Hãy tưởng tượng cả hai đều là những kẻ tấn công độc hại (hoặc bị một kẻ độc hại mạo danh). Kho lưu trữ chứa một số thông tin bí mật và cả hai đều muốn có được chúng. để đánh cắp bí mật kho lưu trữ và gửi nó đến một máy chủ do tin tặc kiểm soát. Để làm được điều đó, chúng sẽ lợi dụng lỗ hổng Poisoned. Pipeline Các lỗ hổng thực thi của pipeline.
Trong cả hai trường hợp (người dùng bên ngoài và người dùng nội bộ), họ đều mở một Pull Request với những sửa đổi tương tự:
- pipeline và tập lệnh shell được sửa đổi đến đọc bí mật từ môi trường và gửi nó đến máy chủ do tin tặc kiểm soát
Các điều chỉnh có thể như sau:
Cả hai người dùng sẽ tạo một Pull Request với những sửa đổiKhi tạo yêu cầu kéo (PR), GitHub sẽ thực hiện cả hai thay đổi. (không cần xem xét hoặc phê duyệt trước), dẫn đến kết quả sau:
Áp dụng tương tự cho người dùng ghi và người dùng đọc. Trong cả hai trường hợp, D-PPE và I-PPE đều được thực hiện.với sự khác biệt là Người dùng chỉ đọc không thể truy cập vào các thông tin bí mật. (!!!!)
Lý do là vì, Trong trường hợp yêu cầu kéo (PR) xuất phát từ một nhánh (fork), GitHub không cho phép truy cập vào các thông tin bí mật của kho lưu trữ. Mặc dù người dùng chỉ đọc không thể đọc được các thông tin bí mật, họ vẫn có thể chạy bất kỳ chương trình nào khác. Một ví dụ tấn công điển hình là tạo các yêu cầu kéo (PR) tải xuống phần mềm khai thác tiền điện tử, do đó trình chạy GitHub sẽ thực thi phần mềm khai thác tiền điện tử khi thực thi một yêu cầu kéo bị nhiễm độc. pipeline.
Đây rõ ràng không phải là một môi trường an toàn!! Người quản trị kho lưu trữ có thể làm gì để tránh điều đó?
Sau khi tìm kiếm trên Google, người quản trị kho lưu trữ quyết định sửa đổi... pipeline được kích hoạt trên mục tiêu yêu cầu kéo sự kiện. Tại sao? Bởi vì pipelines được kích hoạt trên pull_request_target không cho phép thực thi pipeline sửa đổi, tức là bất chấp mọi sự chỉnh sửa của người dùng, "bản gốc" vẫn giữ nguyên. pipeline sẽ được thực thi.
Theo như ví dụ của chúng tôi, cuộc tấn công sẽ diễn ra tương tự như trước. Vậy điều gì sẽ xảy ra sau đó? pipeline sửa đổi?
Như mong đợi, D-PPE không được thực hiện nhưng, vì I-PPE vẫn còn đó, Người dùng chỉ đọc hiện đã có thể truy cập vào thông tin bí mật của kho lưu trữ!!!
Lý do gì khiến người dùng chỉ đọc giờ đây lại có quyền truy cập vào các thông tin bí mật? Mặc dù... pipeline Mặc dù không thể sửa đổi trực tiếp, nhưng vẫn có thể sửa đổi tập lệnh shell. Khi một pipeline Khi sự kiện `pull_request_target` được kích hoạt, nó sẽ được thực thi ở chế độ đặc quyền. so Nó cũng sẽ là tập lệnh shell.Điều này dẫn đến việc tập lệnh shell có quyền truy cập vào các thông tin bí mật của kho lưu trữ!!
Biện pháp phòng ngừa
GitHub cung cấp một số biện pháp để bảo vệ chống lại các yêu cầu kéo (PR) độc hại.
Quy tắc bảo vệ chi nhánh
Với GitHub, bạn có thể định nghĩa các quy tắc bảo vệ nhánh cho các nhánh đã chọn.
Đối với các chi nhánh được bảo vệ, bạn có thể chỉ định một chính sách mà yêu cầu một pull request trước khi hợp nhất (cũng như các điều kiện bổ sung như số lượng phê duyệt cần thiết, đánh giá từ chủ sở hữu mã nguồn, v.v.)
Một vài điều kiện cần được đặc biệt lưu tâm là:
- "Cho phép các tác nhân được chỉ định bỏ qua yêu cầu bắt buộc pull requests".
- "Không cho phép bỏ qua các thiết lập trên."
Trong khi hầu hết các điều kiện đều làm tăng tính nghiêm ngặt của chính sách, thì những điều kiện này lại nới lỏng chính sách và điều đó có thể tạo ra kẽ hở cho các hoạt động độc hại, ví dụ như trường hợp thông tin đăng nhập bị đánh cắp bởi các đối tượng có "quyền hạn đặc biệt".
Hạn chế quyền truy cập GITHUB_TOKEN (quyền tối thiểu)
Chỉ giới hạn quyền truy cập của mã thông báo GitHub ở những quyền cần thiết; bằng cách này, ngay cả khi kẻ tấn công thành công trong việc xâm nhập vào hệ thống của bạn, bạn vẫn có thể kiểm soát được tài khoản của mình. pipelineHọ sẽ không thể làm được gì nhiều.
Tránh chèn chuỗi bằng cách sử dụng pipeline biến môi trường
Bất cứ khi nào bạn sử dụng một số biến đầu vào trong... pipelineHãy lưu ý rằng, theo mặc định, chúng nên được coi là dữ liệu "không đáng tin cậy" (nội dung của chúng do người dùng cuối kiểm soát). Xem thêm Các hành động và quy trình công việc không đáng tin cậy được bảo mật và Tìm hiểu về Github Actions.
Bạn nên luôn sử dụng biến môi trường để chèn các biến đầu vào vào trong tập lệnh thay vì sử dụng nội suy chuỗi.
Quy trình làm việc và các yêu cầu phê duyệt
Trong cáp công khai Các kho lưu trữ, GitHub cho phép chỉ định Cách làm việc với các yêu cầu kéo (PR) "bên ngoài".
Cài đặt Tổ chức GitHub (“Tổ chức >> Cài đặt >> Hành động >> Chung”) cho phép bạn chỉ định cách quản lý các yêu cầu kéo (PR) từ bên ngoài:
Theo mặc định, GitHub yêu cầu phê duyệt yêu cầu kéo (PR) đối với người đóng góp lần đầu, khiến các cuộc tấn công yêu cầu độc hại trở nên phức tạp hơn. Tuy nhiên, kẻ tấn công vẫn có thể giành được sự tin tưởng của người quản lý dự án, ví dụ bằng cách đóng góp một số mã nguồn vô hại. pull request trước cuộc tấn công thực sự.
Theo nghĩa này, Phương án thứ 3 (Yêu cầu phê duyệt đối với tất cả cộng tác viên bên ngoài) bổ sung thêm mức độ kiểm soát cao hơn.
Trong cáp riêng GitHub cũng cung cấp các công cụ kiểm soát hữu ích ở cả cấp độ Tổ chức và cấp độ Kho lưu trữ.
"Chạy quy trình công việc từ Pull Requests” (không được chọn mặc định) cho phép người dùng chạy các quy trình làm việc từ các yêu cầu kéo (sử dụng GITHUB_TOKEN với quyền chỉ đọc và không có quyền truy cập vào các bí mật). Bằng cách chọn tùy chọn này cùng với tùy chọn cuối cùng (“Yêu cầu phê duyệt quy trình PR phân nhánh”), bạn có thể đạt được chính sách tương tự như đối với kho lưu trữ riêng tư (như đã trình bày ở trên).
Như chúng ta đã thấy trong vụ khai thác lỗ hổng PPE từ người dùng chỉ đọc, cho phép chạy các quy trình công việc từ nhánh con. pull requests Không an toàn!!
Các lựa chọn còn lại (“Gửi mã thông báo ghi đến các quy trình công việc từ nhánh con. pull requests"Và"Gửi thông tin bí mật và biến đến các quy trình làm việc từ for pull requests") giảm mức độ bảo mật Áp dụng cho các yêu cầu kéo (PR) phân nhánh.
Bạn có thể định nghĩa chính sách phân nhánh này ở cấp độ Tổ chức hoặc cấp độ Kho lưu trữ. Nếu chính sách bị vô hiệu hóa ở cấp độ tổ chức, nó không thể được kích hoạt ở cấp độ kho lưu trữ. Nhưng nếu chính sách được kích hoạt ở cấp độ tổ chức, nó có thể bị vô hiệu hóa ở cấp độ kho lưu trữ.
Đậy nút lại
Chúng tôi hy vọng bạn đã thấy được những hệ quả của việc có một số... pipeline dễ bị nhiễm độc Pipeline Thi hành án. Quá dễ để commit một người dễ bị tổn thương pipelinevà thật khó để viết một cái an toàn.
Vì vậy, việc sử dụng Xygeni Scanner để nhận biết các lỗ hổng bảo mật như vậy là vô cùng hữu ích.
Bạn không thể khắc phục lỗ hổng bảo mật nếu bạn không biết đến sự tồn tại của nó!!
Nhưng… vẫn còn một câu hỏi chưa được giải đáp… Làm thế nào để tránh bị nhiễm I-PPE?
Đây sẽ là chủ đề của bài đăng tiếp theo của chúng tôi 🙂 … Ngộ độc gián tiếp Pipeline Thi hành (I-PPE) !!
