Kubernetes cho đến nay đã trở thành hệ thống chứa đám mây phổ biến nhất. Vì vậy, thực sự chỉ là vấn đề thời gian cho đến khi lỗ hổng bảo mật lớn đầu tiên của anh ta bị phát hiện.
Và nó là như vậy, bởi vì gần đây Lỗ hổng bảo mật lớn đầu tiên trong Kubernetes được phát hành theo CVE-2018-1002105, còn được gọi là lỗi leo thang đặc quyền.
Lỗ hổng lớn này trong Kubernetes là một vấn đề vì nó là lỗ hổng bảo mật quan trọng của CVSS 9.8. Trong trường hợp có lỗi bảo mật Kubernetes lớn đầu tiên.
Chi tiết lỗi
Với mạng yêu cầu được thiết kế đặc biệt, bất kỳ người dùng nào cũng có thể thiết lập kết nối thông qua từ máy chủ giao diện lập trình ứng dụng (API) Kubernetes tới một máy chủ phụ trợ.
Sau khi thành lập, kẻ tấn công có thể gửi các yêu cầu tùy ý qua kết nối mạng trực tiếp đến phần phụ trợ đó trong đó mục tiêu luôn luôn là máy chủ đó.
Các yêu cầu này được xác thực bằng thông tin đăng nhập TLS (Bảo mật lớp truyền tải) từ máy chủ Kubernetes API.
Tệ hơn nữa, trong cấu hình mặc định, tất cả người dùng (được xác thực hoặc không) có thể chạy các lệnh gọi khám phá API cho phép kẻ tấn công báo cáo đặc quyền này.
Sau đó, bất kỳ ai biết được lỗ hổng đó đều có thể nắm quyền chỉ huy cụm Kubernetes của họ.
Hiện tại, không có cách nào dễ dàng để phát hiện xem lỗ hổng này đã được sử dụng trước đó hay chưa.
Khi các yêu cầu trái phép được thực hiện qua kết nối đã thiết lập, chúng sẽ không xuất hiện trong nhật ký kiểm tra máy chủ Kubernetes API hoặc nhật ký máy chủ.
Yêu cầu xuất hiện trong máy chủ API tổng hợp hoặc nhật ký kubelet, nhưng chúng được phân biệt với các yêu cầu ủy quyền và ủy quyền thích hợp thông qua máy chủ Kubernetes API.
Lạm dụng lỗ hổng mới này trong Kubernetes nó sẽ không để lại dấu vết rõ ràng trong nhật ký, vì vậy bây giờ lỗi Kubernetes bị lộ ra, chỉ là vấn đề thời gian cho đến khi nó được sử dụng.
Nói cách khác, Red Hat nói:
Lỗ hổng báo cáo đặc quyền cho phép bất kỳ người dùng trái phép nào có được đặc quyền quản trị viên đầy đủ trên bất kỳ nút máy tính nào đang chạy trong nhóm Kubernetes.
Đây không chỉ là hành vi trộm cắp hoặc sơ hở để tiêm mã độc, nó còn có thể làm giảm các dịch vụ sản xuất và ứng dụng trong tường lửa của tổ chức.
Bất kỳ chương trình nào, kể cả Kubernetes, đều dễ bị tấn công. Các nhà phân phối Kubernetes đã phát hành các bản sửa lỗi.
Red Hat báo cáo rằng tất cả các sản phẩm và dịch vụ dựa trên Kubernetes của họ bao gồm Red Hat OpenShift Container Platform, Red Hat OpenShift Online và Red Hat OpenShift Dedicated đều bị ảnh hưởng.
Red Hat bắt đầu cung cấp các bản vá và cập nhật dịch vụ cho những người dùng bị ảnh hưởng.
Theo như được biết, vẫn chưa có ai sử dụng lỗ hổng bảo mật để tấn công. Darren Shepard, kiến trúc sư trưởng và đồng sáng lập của phòng thí nghiệm Rancher, đã phát hiện ra lỗi và báo cáo nó bằng quy trình báo cáo lỗ hổng Kubernetes.
Làm thế nào để sửa lỗi này?
May mắn thay, một bản sửa lỗi cho lỗi này đã được phát hành.. Trong đó chỉ họ được yêu cầu thực hiện cập nhật Kubernetes vì vậy họ có thể chọn một số phiên bản vá lỗi của Kubernetes v1.10.11, v1.11.5, v1.12.3 và v1.13.0-RC.1.
Vì vậy, nếu bạn vẫn đang sử dụng bất kỳ phiên bản Kubernetes v1.0.x-1.9.x nào, bạn nên nâng cấp lên phiên bản cố định.
Nếu vì lý do nào đó họ không thể cập nhật Kubernetes và họ muốn chấm dứt sự thất bại này thì cần phải thực hiện quy trình sau.
Bạn nên ngừng sử dụng API tổng hợp máy chủ hoặc xóa quyền thực thi / đính kèm / chuyển tiếp của nhóm đối với những người dùng không có quyền truy cập đầy đủ vào API kubelet.
Jordan Liggitt, kỹ sư phần mềm của Google, người đã sửa lỗi, cho biết những biện pháp đó có thể sẽ gây bất lợi.
Vì vậy, giải pháp thực sự duy nhất chống lại lỗi bảo mật này là thực hiện cập nhật Kubernetes tương ứng.