Điều gì có thể xảy ra sai sót với CI/CD pipelines?

Tích hợp liên tục và phân phối liên tục (CI/CD) pipelineTự động hóa là nền tảng của bất kỳ tổ chức phần mềm nào xây dựng phần mềm theo cách "hiện đại". Tự động hóa mang lại sức mạnh to lớn, nhưng hầu hết các nhà phát triển lại bỏ qua trách nhiệm đi kèm.

Nhà phát triển: Vâng, chúng tôi lấy CI/CD an ninh nghiêm túc và kiểm soát chặt chẽ những người bảo trì mã nguồn, xem xét lại. committrước khi sáp nhập; công việc và pipelineCác hệ thống này được duy trì bởi các nhân viên cấp cao, họ đảm bảo không để lộ bí mật. pipelineVà công cụ này được lắp đặt bởi những người am hiểu về nó. Vậy thì còn gì có thể xảy ra sai sót chứ?

Kính gửi nhà phát triển, CI/CD Hệ thống rất phức tạp. Bề mặt tấn công rộng lớn của nó đã thu hút các tác nhân xấu. Tốt hơn hết là nên cảnh giác và đừng bao giờ quá tự tin.

Cấu hình mặc định đôi khi được giữ nguyên và trở thành "người bạn tốt" của tin tặc. Những lỗ hổng nghiêm trọng có thể tồn tại trong đó. CI/CD pipeline các nguồn, trong cấu hình của hệ thống, hoặc xung quanh quy trình và bối cảnh của pipeline và cách thức nó được kích hoạt.

Trong bài viết này, chúng ta sẽ đặt mình vào vị trí của những kẻ xấu. Hãy tưởng tượng rằng chúng ta đang đọc những suy nghĩ của... M3M3N70 (Nhớ về cái chết?) và Cơn thịnh nộ đầm lầy Đâu đó trên mạng đen, có lẽ bằng một ngôn ngữ không phải phương Tây, nhưng đừng bao giờ quên rằng cái ác đang lan rộng khắp thế giới.

 

Ngày xưa mọi chuyện thật dễ dàng…

M3M3N70: Quay trở lại thời hoàng kim, công việc kinh doanh của chúng ta dễ dàng hơn rất nhiều… Các lỗ hổng bảo mật chưa được khai thác (zero-day) là những mục tiêu dễ đạt được, các ứng dụng còn nhiều lỗ hổng dễ bị khai thác, và chúng ta có thể di chuyển ngang nhanh chóng.

Cơn thịnh nộ đầm lầy: Chết tiệt! Vẫn còn vài người đầu óc ngu ngốc ngoài kia, nhưng mọi thứ đã thay đổi. Những ông lớn đã đặt nhiều nghi ngờ vào cái trò bảo mật ứng dụng đó rồi.

M3M3N70Đúng vậy. Nhưng những kẻ ngốc mới lại là các nhà phát triển. Đối với chúng tôi, việc sử dụng các công cụ mà những người này dùng thì dễ dàng hơn. Đặc biệt, CI (Computer Interruption) là một kho báu! Mã thông báo truy cập đám mây, SCM Thông tin đăng nhập, mật khẩu cơ sở dữ liệu sản xuất, khóa riêng SSH, thông tin đăng nhập của người dùng CI khác… Việc chuyển từ những công việc phát triển nhàm chán sang phần quan trọng thực sự khá dễ dàng.

Tự động hóa quá trình xây dựng, kiểm thử và triển khai phần mềm với... CI/CD Công cụ này thường cần truyền các thông tin bí mật cho các lệnh theo từng bước. Và thường thì những thông tin đó bị rò rỉ, dẫn đến những hậu quả tai hại.

Pipelinehọ cần những bí mật mà đôi khi bị rò rỉ.

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

Có lẽ thời hoàng kim xưa kia là tìm thấy trong lịch sử Git một điều gì đó .env tệp (nhà phát triển quên thêm nó vào) .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

được sử dụng trong quy trình làm việc của GitHub. .github/deploy.yaml trong đó có nội dung tương tự như sau:

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: Tuyệt vời! Các khóa AWS đó hoạt động rồi! Chúng tôi đã thử nghiệm trước một thay đổi nhỏ trong ứng dụng, sau đó thêm thủ thuật vì những người đó dường như không biết. Thành công! Một chiến dịch tuyệt vời…

Kẻ xấu chỉ đơn giản sử dụng khóa AWS để tải lên một ứng dụng đã được sửa đổi chứa phần mềm độc hại, sau đó chạy lệnh triển khai bằng các thông tin đăng nhập đó. Các bí mật bị rò rỉ, cùng với thông tin có trong... pipeline“Thật là một chiến dịch!” có lẽ có nghĩa là Memento đã gây ra thiệt hại nặng nề cho nạn nhân tội nghiệp.

Điều Memento cho chúng ta biết ở đây là một khi bí mật bị rò rỉ, như ví dụ về khóa truy cập AWS, bạn phải thu hồi bí mật đó (xoay vòng các khóa nói trên). ngayLuôn luôn có một cửa sổ phơi sáng giữa chỗ rò rỉ commit và việc hủy bỏ bí mật; Việc viết lại lịch sử Git rất khó. (Ngay cả những quốc gia độc tài hà khắc nhất cũng đã từng cố gắng viết lại lịch sử như vậy, nhưng không thành công) và có lẽ cũng không hiệu quả (có thể bạn bè của chúng ta đã sao chép trước khi kho lưu trữ bị rò rỉ thông tin bí mật). commitHãy xoay chìa khóa ngay lập tức và cầu nguyện trong khi đọc nhật ký hoạt động của tài khoản mục tiêu trong khoảng thời gian bị lộ!

Có lẽ các tổ chức nên cấm sử dụng bí mật dài hạn trong CI/CD pipelinesvà thay thế chúng bằng thông tin xác thực tạm thời. Trong ví dụ trước với khóa AWS trong GitHub Actions, việc sử dụng một phương thức an toàn hơn. Nhà cung cấp OpenID Connect (OIDC) Để có được chứng chỉ tạm thời cần thiết cho các hoạt động.

Cơn thịnh nộ đầm lầyBạn thật may mắn! Việc rò rỉ các tập lệnh có khóa được mã hóa cứng là chuyện thường thấy ngày xưa, ngay cả trên các bucket S3 có thể truy cập công khai. Tất cả những gì bạn cần làm là duyệt qua các đối tượng trong bucket và sử dụng lệnh grep để tìm những thứ thú vị.

Đôi khi khu vực được sử dụng để triển khai (trong ví dụ này là một bucket AWS S3) bị mở cho người ngoài đọc được do lỗi cấu hình (mà không được phát hiện). Vậy điều gì sẽ xảy ra? Cơn thịnh nộ đầm lầy Trước đây nó có dạng như thế này:

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

Thùng chứa đó có thể được tạo bằng mẫu cấp phát, mẫu này có thể được quét tự động để tìm các lỗ hổng bảo mật.

Cấu hình mặc định của công cụ chỉ là một món đồ chơi đối với chúng tôi.

Để đưa ra những ví dụ cụ thể, chúng ta hãy nói về... Jenkins, một trong những công cụ CI phổ biến nhất.

Cơn thịnh nộ đầm lầyBạn còn nhớ ô chọn "Kích hoạt bảo mật" trong Jenkins không, và có bao nhiêu tổ chức đã chọn không kích hoạt nó vì lý do tiện lợi? Và những "Ai cũng có thể làm bất cứ điều gì.“Các tổ hợp quyền mặc định? Và những plugin Jenkins phiền phức đó, như…” Plugin GitHub OAuthNgười cấu hình đã chọn cả hai tùy chọn “Cấp quyền ĐỌC cho tất cả Người dùng đã xác thực” và “Sử dụng quyền truy cập kho lưu trữ GitHub”, cho phép chúng tôi truy cập vào tất cả các dự án của họ.

(Xin lỗi Jenkins, vì đã lấy bạn làm ví dụ 😉)

Hãy luôn thành thạo (thậm chí là nghiện) các nguyên tắc an ninh. Một trong số đó là... Bảo mật theo mặc định Nguyên tắc: Các biện pháp kiểm soát nên mặc định ở chế độ bảo mật cao nhất có thể. Bảo mật cần được tích hợp ngay từ đầu. CI/CD công cụ và pipelineNó cần được xây dựng từ đầu, chứ không phải là một ý tưởng thêm vào sau. Nhưng tính thân thiện với người dùng và sự tiện lợi thường mâu thuẫn với tính bảo mật.

Đối với trường hợp của Jenkins, cơ chế xác thực tích hợp quá dễ bị lỗi: Không bao giờ sử dụng các cơ chế xác thực tích hợp sẵn trong Jenkins.Tốt hơn hết là nên chọn cơ chế của bên thứ ba (SAML, LDAP, Google…) với plugin Chiến lược ủy quyền dựa trên vai trò (“RBAC”). Và cần hết sức thận trọng với… admin tài khoản.

Hãy chăm sóc công việc của bạn và pipeline Các tệp trong Jenkins được xử lý. Tương tự với Plugin cấu hình dưới dạng mã và các tệp cấu hình của nó, áp dụng cho cấu hình Jenkins.

Chuyển từ máy chủ tự lưu trữ CI/CD Việc chuyển đổi từ hệ thống nội bộ sang hệ thống SaaS dựa trên đám mây giúp loại bỏ một số rủi ro tiềm ẩn, cho phép di chuyển ngang trong mạng lưới tổ chức, nhưng lại tạo ra những rủi ro khác, chẳng hạn như phải mở các kết nối bên ngoài giữa các hệ thống nội bộ hiện có và hệ thống bên ngoài. CI/CD công cụ.

Các tổ chức nên thực hiệncise sự cẩn trọng cần thiết trong việc làm cứng CI/CD hệ thống, bắt đầu với các thiết lập hạn chế nhất và dần dần mở rộng với các quyền tối thiểu cần thiết cho... pipeline các bước.

Cấu hình bảo mật trong CI/CD Việc phát triển các công cụ có thể khá phức tạp. Nhiều công cụ có các plugin hoặc tiện ích mở rộng, chứa hầu hết các lỗ hổng bảo mật và cần được cập nhật.

Các công cụ quét lỗi cấu hình bảo mật cho những công cụ phức tạp như vậy, hoặc các công cụ đánh giá hiệu năng có thể hữu ích.

Chèn mã vào pipeline các lệnh để giải trí và kiếm lợi nhuận

M3M3N70Bạn đã từng sử dụng các công cụ kiểm tra mã không đáng tin cậy, những công cụ chứa các hành động và tập lệnh dễ bị tấn công bằng phương pháp chèn lệnh chưa?

Phần này cho thấy rằng pipeline Bản thân nó có thể chứa các lỗi lập trình cho phép kẻ xấu chèn mã thực thi tùy ý vào bên trong. pipeline mà không thay đổi pipeline nguồn gốcVí dụ, sử dụng yêu cầu kéo (PR).

Một ví dụ đầu tiên về quy trình làm việc GitHub không may mắn:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

Kết hợp pull_request_target Việc kích hoạt quy trình làm việc bằng cách kiểm tra rõ ràng một yêu cầu kéo (PR) không đáng tin cậy là một hành vi nguy hiểm có thể dẫn đến việc kho lưu trữ bị xâm phạm. Trong ví dụ này, sự kết hợp không may mắn của:

• pull_request_target sự kiện này, theo mặc định có quyền ghi vào kho lưu trữ mục tiêu và các bí mật của kho lưu trữ mục tiêu, ngay cả từ các nhánh bên ngoài, và chạy trong ngữ cảnh của kho lưu trữ mục tiêu của PR.
• Kiểm tra mã PR từ nguồn, kho lưu trữ không đáng tin cậy.
• kích hoạt bất kỳ tập lệnh nào có thể hoạt động trên nội dung do PR kiểm soát, như trong trường hợp của npm installvà
• không sử dụng điều kiện để kích hoạt pull_request_target Sự kiện chỉ được chạy nếu yêu cầu kéo (PR) đó được gán nhãn "đã được kiểm duyệt" (người dùng bên ngoài không thể gán nhãn cho PR).

Ví dụ thứ hai sử dụng dữ liệu đầu vào không đáng tin cậy (từ một vấn đề, bình luận hoặc...) pull request) làm nguồn cho các đối số được truyền cho một pipeline lệnh thông qua biểu thức. Đây là pipeline phiên bản của lỗ hổng tấn công chèn lệnh hệ điều hành.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

Thao tác chạy sẽ tạo ra một tập lệnh shell tạm thời dựa trên mẫu, với $ đã được thay thế, khiến nó dễ bị tấn công bằng cách chèn lệnh shell. Kẻ tấn công sử dụng tài khoản GitHub giả mạo có thể tạo ra một vấn đề với tiêu đề tương tự. a"; bad_code_goes_here;#Và bùm! 

Cơn thịnh nộ đầm lầyỒ, những người đó đã tạo điều kiện cho việc chèn lệnh bằng cách đơn giản là mở một vấn đề…

Có những lỗ hổng thực thi mã trong GitHub Actions, ví dụ như... gajira-commentĐã được sửa lỗi. Vui lòng đọc. “Đầu vào không đáng tin cậy trong quy trình làm việc của GitHub” để biết chi tiết đầy đủ.

Noi dung chinh cua cau chuyen: Tuyệt đối không bao giờ tải xuống và xây dựng các yêu cầu kéo (PR) từ các nguồn không đáng tin cậy mà không xem xét kỹ yêu cầu kéo đó trước. Ở đây, "không đáng tin cậy", trừ khi được xác thực nguồn gốc một cách nghiêm ngặt, có thể ám chỉ bất kỳ tài khoản nhà phát triển nào có khả năng bị chiếm đoạt.

 

Việc triển khai phần mềm độc hại ngoài ý muốn đã xảy ra!

Triển khai liên tục Đây là đỉnh điểm của quá trình tự động hóa, nhưng đỉnh điểm đó có thể bị cản trở bởi việc thiếu các biện pháp kiểm soát phê duyệt phù hợp. pipeline lưu lượng.

Rủi ro của việc triển khai hoàn toàn tự động từ mã nguồn commit Các rủi ro đối với hệ thống sản xuất bao gồm khả năng mã độc có thể được triển khai vào môi trường sản xuất mà không bị phát hiện, cũng như khả năng xảy ra lỗi trong quá trình triển khai gây ra gián đoạn hoặc sự cố.

Để giảm thiểu những rủi ro này, người ta thường khuyến nghị các tổ chức nên thực hiện một “điểm dừng cứng” trong quy trình triển khai của họ, điều này đòi hỏi sự chấp thuận của con người trước khi các bản phát hành được triển khai đến môi trường cuối cùng.

Họ đang đóng cửa.

Cơn thịnh nộ đầm lầy: Những mật khẩu mặc định vui vẻ đó trong CI/CD Các công cụ đang bị xóa. Truy cập vào... /var/lib/jenkins/secrets/initialAdminPassword Đó giờ là một lối mòn cũ. Nhiều công cụ hiện nay đã cung cấp xác thực hai yếu tố (2FA), thứ mà Covid đã làm cho phổ biến, và ngay cả những lập trình viên lười biếng nhất cũng đang sử dụng nó!

M3M3N70Chúng tôi đang chống lại xác thực hai yếu tố (2FA), nhưng điều đó không dễ dàng. Rất khó để tấn công lừa đảo có chủ đích vào những kẻ đó, vì... “Scatter Swine” đã hợp tác với Twilio.Với khóa WebAuthn thì khó hơn nhiều. Ít nhất, chúng ta có thể thử. đánh cắp cookie để vượt qua xác thực đa yếu tố (MFA).nhưng cần phải đột nhập vào "hộp" của nhà phát triển.

Xác thực đa yếu tố (MFA) là một bước tiến đúng hướng để hạn chế rủi ro rò rỉ thông tin xác thực. Hầu hết các công cụ DevOps hiện đại đều hỗ trợ MFA. Và các khóa xác thực theo WebAuthn / U2F (xem Dự án FIDO2(Có lẽ đây là lựa chọn tốt nhất cho xác thực đa yếu tố trong DevOps, nếu được quản lý đúng cách.)

Cơn thịnh nộ đầm lầyMấy anh chàng DevOps đang dần tỉnh giấc. Cái nguyên tắc “quyền hạn tối thiểu” chết tiệt đó đã ăn sâu vào máu họ rồi. Và họ không còn là những con khỉ biết viết code nữa. Giờ đây chúng ta bị các nhà phê bình bắt quả tang.

Trong thực tế, pipelineHiện tại, hệ thống đã mạnh mẽ hơn so với vài năm trước, với các hành động và tập lệnh yếu đã bị loại bỏ, cùng với các bước kiểm tra bảo mật bổ sung, thậm chí còn phát hiện ra các phần mềm phát tán mã độc ẩn mình. commitnhững chiếc xe và gói hàng mà chúng tôi đã cướp.

Câu hỏi dành cho người đọc: Liệu quy trình xây dựng phần mềm từ mã nguồn và triển khai vào môi trường sản xuất có phải là một công việc rủi ro? Bạn có thể thấy nhóm DevOps của mình đang ở giai đoạn nào trong quá trình này? những kỷ niệm đẹp đẽ Dành cho những kẻ xấu?

Khuyến nghị cuối cùng

Bắt đầu từ đâu CI/CD pipelineS?

Lời khuyên đầu tiên ở đây rất đơn giản: Hãy cẩn thận. xem xét pipelines (họ là) quan trọng (nguồn lực) cho các vấn đề bảo mật. Việc xem xét rất tốn kém nhưng cần thiết và phải được thực hiện đúng cách. Người xem xét cần biết cần kiểm tra những gì. Mỗi bước phải được kiểm tra kỹ lưỡng để phát hiện lỗi.

Có lẽ sự kết hợp giữa các chuyên gia đánh giá được trang bị các phần mềm quét mã độc tự động sẽ hữu ích.

Khuyến nghị thứ hai là đào tạo các nhà phát triển viết mã pipelinevà duy trì chúng trong môi trường an ninh.Những điều cần cân nhắc:

• Làm thế nào để xử lý xác thực đúng cách với các dịch vụ nội bộ và đám mây, tránh những rắc rối khi phải quản lý thông tin đăng nhập dài hạn.
• Cách giới hạn pipelineNó chỉ định chính xác tập hợp các nguồn lực cần thiết. Nguyên tắc đặc quyền tối thiểu lại một lần nữa được thể hiện rõ.
• Cách viết các bước để thực hiện pipelineCó thể tái tạo lại như ghim phiên bản và tránh các lỗ hổng tấn công chèn lệnh.
• Làm thế nào để phê duyệt triển khai từ góc độ bảo mật (còn có những góc độ khác nữa!): bảo mật nào standardCác tham số cần được khớp và cách thêm các bước kiểm tra/cổng tương ứng vào hệ thống. pipelines.

Khuyến nghị thứ ba là cấu hình CI/CD hệ thống với sự cẩn trọng thích đáng. Xác thực mạnh mẽ, không sử dụng mật khẩu mặc định hoặc cài đặt không an toàn, quyền hạn tối thiểu… Hãy chú ý đến các lỗ hổng bảo mật trong các plugin và tiện ích mở rộng đã cài đặt. Đây có thể là trọng tâm của các bài viết tiếp theo, hãy đón chờ nhé.

Khuyến nghị thứ tư là tận dụng CI/CD pipelines cho tự động hóa bảo mậtPhân tích mã nguồn (SAST), phân tích thành phần nguồn (SCACác công cụ như quét rò rỉ thông tin bí mật, công cụ chống phần mềm độc hại, trình quét bảo mật container hoặc trình phát hiện thời gian chạy tự động (DAST và phần mềm độc hại) có thể được chạy thường xuyên trên hệ thống. pipelineVà tổ chức của bạn có thể thực thi điều đó. standards về phạm vi phủ sóng của việc quét bảo mật trong CI/CD.

Cần lưu ý rằng, những công cụ này vẫn không loại bỏ được vai trò của chuyên gia, nếu không bạn có thể có cảm giác an toàn sai lầm.

Nếu bạn quen thuộc với danh sách OWASP top-ten, một dự án gần đây khá hay là... Top 10 của OWASP CI/CD Rủi ro bảo mật.

Lưu ý tuyên bố từ chối trách nhiệm

(1) Các ví dụ trong bài đăng này đang sử dụng GitHub làm SCMAWS là nhà cung cấp dịch vụ đám mây, và GitHub Actions hoặc Jenkins là... CI/CD Công cụ này không hề yếu hơn/an toàn hơn so với các công cụ thay thế. Không có ý định bôi nhọ danh tiếng! Những công cụ này rất mạnh mẽ và cần được sử dụng đúng cách.

(2) M3M3N70 và Cơn thịnh nộ đầm lầy Đây là những nhân vật hư cấu. Bất kỳ sự tương đồng nào với người hoặc nhóm người, dù còn sống hay đã chết, chỉ là sự trùng hợp ngẫu nhiên… hay không?

Để đọc thêm

• Haymore, A. và cộng sự “10 câu chuyện thực tế về cách chúng ta đã thỏa hiệp CI/CD pipelineS"Tập đoàn NCC, tháng 1 năm 2022.
• configure-aws-credentials Hành động GitHub và Cấu hình OpenID Connect trong Amazon Web Services Để biết thêm chi tiết về cách chạy các lệnh AWS để triển khai trong quy trình làm việc GitHub.
• Lobacevski J. “Bảo mật GitHub Actions và workflows của bạn Phần 1: Ngăn chặn các yêu cầu tấn công chiếm quyền kiểm soát”Phòng thí nghiệm bảo mật GitLab, tháng 12 năm 2020.
• Lobacevski J. “Bảo mật GitHub Actions và quy trình làm việc của bạn Phần 2: Dữ liệu đầu vào không đáng tin cậy”Phòng thí nghiệm bảo mật GitLab, tháng 1 năm 2021.
• OWASP. “OWASP Top 10 CI/CD Rủi ro an ninh”Tháng 7 năm 2022.
• Saltzer J. & Schroeder M. “Bảo vệ thông tin trong hệ thống máy tính”Tháng 4 năm 1975. Các nguyên tắc an ninh đã phát triển cùng với công nghệ, nhưng 47 năm sau, hầu hết các ý tưởng về an ninh và an toàn vẫn còn hiệu lực.
• NCSC Vương quốc Anh. “Đảm bảo quá trình xây dựng và triển khai” pipeline"Trung tâm An ninh mạng Quốc gia Anh, tháng 2 năm 2019.