Một số note trong quá trình tìm hiểu về Kubernetes (K8s)

Với sự phát triển nhanh chóng về công nghệ thông tin, nhu cầu triển khai các hệ thống mới ngày càng nhiều với đa dạng các môi trường phát triển khác nhau (về công nghệ web, web server, DB,...). Việc sử dụng các mô trình triển khai truyền thống trên môi trường ảo hóa dần trở nên khó khăn mỗi khi cung cấp một dịch vụ mới do cần cài đặt các thành phần khác nhau để vận hành ứng dụng, mà công việc này chưa thể thực hiện tự động 100% được nên tốn rất nhiều thời gian và nguồn lực.   Do đó hiện nay nhiều cơ quan, tổ chức vận hành hệ thống công nghệ thông tin đang dần chuyển dịch sang các mô hình cloud. Hệ thống cloud mang lại nhiều lợi ích như khả năng triển khai nhanh chóng, khả năng mở rộng và co giãn linh hoạt, khả năng chia sẻ tài nguyên tránh lãng phí,...   Bài viết này không tập trung vào các mô hình cloud và các public cloud như AWS, GCP, Azure mà sẽ phân tích một hướng attack từ các hệ thống vệ tinh xung quanh cũng như một vài lỗ hổng trên Kubernetes.   Kubernetes (K8s) là một hệ thống mã nguồn mở giúp tự động hóa việc triển khai, nhân rộng và quản lý các ứng dụng container. Các khái niệm về các thành phần trong hệ thống có thể tham khảo đầy đủ tại đây và không giới thiệu lại trong phạm vi blog này. Một số loại kiến trúc đang được sử dụng phổ biến   Mỗi mô hình đều có các ưu điểm/nhược điểm riêng về quá trình triển khai, quản lý tài nguyên và bảo mật. Attack chain trong bài viết này được khai thác trên target triển khai với mô hình “Namespace per Tenant” được vận hành như sau: Các thành phần trong hệ thống bao gồm:

• Gitlab: chứa mã nguồn ứng dụng .
• Jenkin: hỗ trợ triển khai tự động.
• Harbor: lưu trữ các image để deploy.
• K8s: triển khai, vận hành các hệ thống.

  Dựa trên mô hình này có thể đưa ra một số hướng tấn công:

• Chèn mã độc thẳng vào mã nguồn: Kết quả chắc chắn đạt được là shell trên pod của ứng dụng nhưng chưa thể trực tiếp chiếm được các pod khác.
• Khai thác vào jenkin: Jenkin chứa nhiều thông tin khi triển khai các pod trên K8s. Ngoài các secret được lưu trên Jenkin (tuy nhiên không xem được trực tiếp từ giao diện web) thì các Jenkin agent chứa thông tin xác thực để giao tiếp với K8s api.
• Khai thác hệ thống Harbor: Upload image chứa mã độc và chờ được deploy
• Escape từ pod ra host.

  Escape từ pod ra host Một số kỹ thuật escape từ pod ra host trước đây đã có 1 bài viết trên container. Các phương pháp này cần lợi dụng các misconfig khi tạo pod. Tuy nhiên các image thường được đóng gói với khá ít các công cụ thường dùng (như curl, wget, ping, nc,...) nên việc kiểm tra này cũng gặp khá nhiều khó khăn. Để giải quyết vấn đề này mình có tìm được một công cụ giúp mình kiểm tra các thông tin này khá đầy đủ https://github.com/stealthcopter/deepce  VD: kết quả khi chạy deepce trên 1 pod Một vài cấu hình misconfig có thể lợi dụng để escape:

• Sử dụng các Capabilities như bài viết trước.
• Chroot kết hợp với host path mount: trường hợp này khá khó xảy ra trực tiếp do các ứng dụng khi cần mount ra host thường sử dụng các folder riêng biệt để lưu trữ. Tuy nhiên có thể lợi dụng nếu attacker có quyền trên namespace và tạo được pod.
• Sử dụng các lỗ hổng đã biết trên kernel hoặc các thành phần core của K8s khi tạo pod.

  Khai thác qua hệ thống Jenkins Tương tự với hướng attack từ pod escape ra host là push image lên harbor và chờ nạn nhân deploy lại image đó. Tuy nhiên phương pháp này khá thụ động nên mình đã chuyển hướng sang Jenkins.   Chain khai thác đã thực hiện: Tại thời điểm attack hệ thống Jenkins đã patch các bản vá security mới nhất. Tuy nhiên mình có kiếm được một số tài khoản trên hệ thống Jenkins này. Sau khi thử login hết các tài khoản này mình cũng có được 1 tài khoản có quyền tạo pipeline script

  Để phục vụ số lượng deploy lớn thì có nhiều Jenkin Agent khác nhau, nên ở script trên mình cũng không chỉ định riêng agent nào sẽ thực hiện. Pipeline này được chạy lại nhiều lần với mục tiêu kiếm hết các agent có thể, sau đó tìm toàn bộ các file kubeconfig (là file chứa thông tin xác thực giao tiếp với K8s api).

Kết quả cuối cùng mình thu được thông tin xác thực của 2 cụm K8s (như hình trên, mình tạm gọi là K8s v1 và K8s v2). Sau khi kiểm tra mình phát hiện 2 cụm này chạy cấu hình khác nhau. Một cụm deploy các hệ thống test nên lỏng lẻo hơn về bảo mật. Cụm K8s còn lại thì áp dụng đầy đủ Pod Security cũng như giới hạn lại về network. Như vậy là đã có init access trên cụm, tại thời điểm đó khi cầm kubeconfig trong tay là đã có toàn quyền trên namespace đó.  Nhưng mục tiêu đặt ra là phải từ đó chiếm được toàn bộ cụm nên mình tiếp tục đi sâu hơn. Mình đã thử nhiều cách bao gồm cả trường hợp mount host path như trên nhưng không thành công cho tới khi tìm được CVE-2021-25742

Ingress trong K8s có nhiệm vụ điều hướng các request từ bên ngoài vào các các dịch vụ trên các pod bên trong K8s cluster. Mình có check trên cả 2 cụm K8s nhưng chỉ khai thác được trên cụm K8s v1  Sử dụng token này mình đã xem được toàn bộ nodes Và lấy được cả thông tin xác thực của tài khoản admin Từ đây đã có đầy đủ quyền hạn trên toàn cụm K8s v1 này   Sau khi đã hoàn thành tấn công trên cụm K8s v1 mình chuyển sang tìm cách khai thác trên K8s v2. Bản này so với K8s v1 có apply nhiều policy khi khởi tạo các pod nên gặp khá nhiều hạn chế. Trong quá trình recon tiếp theo cũng check ra được ở K8s v2 này có sử dụng Multi Ingress nên cũng không dùng được CVE-2021-25742 để attack. Khá bế tắc nên mình đã chuyển hướng sang các thành phần khác và tìm được một lỗ hổng trên runc CVE-2024-21626 có thể escape từ pod ra host.

Tuy nhiên như đã đề cập trước đó, cụm K8s này đang áp dụng nhiều policy khác nữa nên mặc dù khai thác được lỗ hổng này nhưng chưa thể truy cập vào các thông tin khác trên host.   Kết luận Trên đây là một số note về những kiến thức mình đã tìm hiểu gần đây về K8s. Còn nhiều thành phần khác trên hệ thống cũng như các hướng attack khác mình chưa thành công (escape với kernel bug, bypass PSA, Kyverno,...).   Bài viết có thể còn nhiều thiếu sót và chắc chắn còn nhiều kỹ thuật khác nữa mình chưa tiếp cận đến, hy vọng thời gian tới sẽ được nghiên cứu tiếp và có thêm những bài viết phần 2,3 về chủ đề này.   Cuối cùng, cảm ơn anh đồng nghiệp khác trung tâm đã hỗ trợ mình nhiệt tình khi tìm hiểu về nền tảng K8s này