5 sự cố bảo mật Kubernetes và chúng ta học được gì từ đó?
Bảo mật vẫn luôn là mối quan tâm hàng đầu của các tất cả doanh nghiệp hiện nay. Tuy nhiên, đối với các tổ chức sử dụng Kubernetes (nền tảng mã nguồn mở), người ta lại ít bận tâm tới mức độ bảo mật không cao vốn có của nó. Thay vào đó họ phần lớn chỉ chú ý đến mức độ phức tạp của Kubernetes, và thực tế cũng cho thấy ngay cả các chuyên gia lành nghề cũng gặp khó khăn nất định khi sử dụng công cụ.
Theo báo cáo gần đây của StackRox, các vấn đề như chưa được đào tạo, thiếu kinh nghiệm hay cấu hình sai là nguyên nhân lớn nhất gây ra sự cố bảo mật Kubernetes. Sau khi khảo sát hơn 540 tham gia vào năm ngoái,kết quả cho thấy có đến hơn 94% trong số đó đã gặp sự cố bảo mật với Kubernetes.
Tuy nhiên, không chỉ những người tham gia kẻ trên mà các trường hợp được liệt kê trong danh sách dưới đây cũng đã gặp sự cố tương tự. Vậy họ đã giải quyết lỗi bảo mật Kubernetes như thế nào, và chúng ta có thể học được gì từ đó? Tìm hiểu 5 sự cố bảo mật Kubernetes qua bài viết của Bizfly Cloud dưới đây nhé.
Capital One
Đây là sự cố bảo mật Kubernetes khá lớn và dường như là tiếng chuông cảnh tỉnh cả cộng đồng. Sự cố xảy ra đúng một năm trước, một vụ rò rỉ 30GB dữ liệu tín dụng ảnh hưởng đến khoảng 106 triệu người. Lỗ hổng thường thấy trong nền tảng Kubernetes thường bắt nguồn từ một cấu hình lỗi. Cụ thể, một tường lửa có cấu hình sai đã tạo điều kiện cho hacker tấn công truy vấn dữ liệu nội bộ và có được thông tin xác thực về IAM (quản lý truy cập và nhận dạng) của Amazon Web Services.
Một trong những bài học quan trọng mà chúng ta học được từ sự cố này là cần cẩn trọng hơn khi phân chia IAM role. Hầu hết mọi người vội vàng kích hoạt Kubernetes và bỏ qua các phần cần lưu tâm như quản lý dữ liệu quan trọng và phân chia IAM theo từng nhóm thay vì từng ứng dụng. Một nhiệm vụ quan trọng khác là thường xuyên cập nhật thông tin đăng nhập, tốt nhất là dùng một dịch vụ giới hạn thời gian đăng nhập. Điều này giúp đặt ra nhiều hạn chế về thời gian hoạt động của các hoạt động vi phạm trên hệ thống.
Wikimedia
Docker Hub
Với Kubernetes, trong các container và môi trường phân tán, phạm vi tấn công ngày càng lớn theo cấp số nhân và bạn không thể truy vết cuộc tấn công đó đến từ đâu. Ví dụ, khi hacker tấn công trình quản lý của Docker Hub để tạo ra những docker image gắn mã độc trong Docker Hub vào năm ngoái, khiến bất cứ ai sử dụng docker image đó đều bị mã hóa. Người dùng vô tình triển khai các công cụ khai thác tiền điện tử dưới dạng Docker containers, sau đó nó chuyển hướng tài nguyên sang khai thác cho kẻ tấn công. Đây chỉ là một trong số các cuộc tấn công bị phát hiện gần đây.
Tương tự như Capital One, cần thay đổi mật khẩu và thông tin đăng nhập thường xuyên để tránh loại tình huống này. Ngoài ra, đối với Kubernetes, cần thay phiên thông tin bí mật và kiểm tra docker image thường xuyên để đảm bảo chỉ những hình ảnh đã xác minh mới được sử dụng nhằm đảm bảo an ninh. Docker image gắn mã độc khá khó bị phát hiện, đặc biệt nó mất nhiều thời gian hơn. Đây là lý do vì sao các kiểm tra bổ sung sẽ sàng lọc bất kỳ sai lệch nào trong ứng dụng và phát hiện các quy trình ẩn được cài đặt trong hệ thống. Kiểu tấn công này khá hiệu quả.
>> Xem thêm: Mở rộng quy mô dịch vụ nhỏ với Message Queues, Spring Boot and Kubernetes
Microsoft Azure
Microsoft cũng nằm trong số những cái tên gặp rắc rối về tiền điện tử. Họ tiết lộ rằng, đã có một cuộc tấn công tiền điện tử quy mô lớn chống lại tổ hợp Kubernetes trong Azure vào tháng 4 năm nay, một chiến dịch tương tự được phát hiện vào tháng 6 nhằm vào các container Kubeflow được cấu hình sai để biến chúng thành tiền điện tử. Tương tự như trường hợp Docker Hub, Kubeflow sử dụng một số dịch vụ cho phép người dùng dùng ditto được tùy chỉnh như với Katib và Jupyter Notebook. Đối với Jupyter, hình ảnh được chọn không phải là hình ảnh hợp pháp và đó là kẽ hở cho các kẻ xấu tấn công.
Nếu xem xét nguyên nhân dẫn đến cấu hình sai thì đó là do tính thiếu kiên nhẫn, lười biếng và thiếu kiến thức. Bảng điều khiển UI của Kubeflow theo mặc định chỉ có thể truy cập nội bộ thông qua cổng Istio. Tuy nhiên, một số người dùng muốn rút ngắn công đoạn để truy cập trực tiếp vào bảng điều khiển mà không thông qua máy chủ API Kubernetes và không nhận ra rằng khi họ tiết kiệm được thời gian thì nó cũng đang mở ra một số backtime trong quy trình. Họ đã để lộ cổng xâm nhập Istio vào internet, cho phép mọi người đều truy cập được vào bảng điều khiển. Bài học ở đây là đảm bảo bảo mật cho mọi cài đặt hoặc thay đổi cấu hình đang dùng.
Pixabay
Tesla
Với trị giá tiền điện tử tăng vọt và tài nguyên khai thác vô hạn trong Cloud, việc chiếm đoạt tài nguyên sẽ sinh lợi cao hơn việc đánh cắp thông tin. Nhà sản xuất ô tô nổi tiếng Tesla là một trong những nạn nhân của tiền điện tử khi cụm Kubernetes bị xâm phạm do bảng điều khiển không được bảo vệ.
RedLock Cloud Security Intelligence phát hiện và công khai trong một báo cáo đã nêu rõ việc cấu hình sai đã tạo điều kiện những kẻ tấn công nắm giữ vùng chứa thông tin xác thực AWS S3 của Tesla. Những thông tin đăng nhập sau đó được sử dụng để chạy các tập lệnh được mã hóa trên một nhóm.
Điều thú vị trong cuộc tấn công là số lượng thủ thuật được thực hiện để tránh bị phát hiện. Ngoài việc không sử dụng nhóm khai thác đã bị phát hiện thay vào đó là một nhóm không công khai, chúng còn sử dụng dịch vụ CDN của Cloudflare để ẩn IP của chúng.
Những kẻ tấn công cũng thiết lập tập lệnh khai thác không sử dụng hết tài nguyên CPU để tránh gây ra báo động hoặc bị phát hiện và nghe trên một cổng không chính thức, khiến việc phát hiện dựa trên lưu lượng truy cập hầu như không thể. Cách duy nhất để phát hiện vi phạm này là chủ động giám sát các cấu hình để đảm bảo tất cả các chính sách bảo mật đang được tuân thủ.
Jenkins
Cùng với sự cố Tesla, tin tặc đã khai thác lỗ hổng trong Jenkins để mã hóa khoảng 3,5 triệu đô la, hay 10.800 Monero trong 18 tháng. Moreno là một loại tiền điện tử có liên quan đến sự cố hình ảnh độc hại Docker Hub được nhắc đến trước đó. Trong trường hợp của Docker Hub, người ta đã phát hiện có 6 hình ảnh gắn mã độc được kéo hơn 2 triệu lần, đó là 2 triệu người dùng bị kẻ tấn công tận dụng để khai thác Monero một cách khá kỳ công.
Sự cố bảo mật Kubernetes của Jenkins vẫn là một trong những vi phạm nghiêm trọng nhất được phát hiện cho đến nay. Nó sử dụng các máy Windows và máy tính cá nhân dễ bị tấn công và cũng nhắm vào các máy chủ của Jenkins CI. Nó liên tục tự cập nhật và thay đổi nhóm khai thác để tránh bị phát hiện. Việc nó có thể nhắm vào các máy chủ là một bước tiến mới của những kẻ tấn công đến từ Trung Quốc. Nếu họ có thể thu về hơn 3 triệu đô la từ máy tính bàn thì các máy chủ mạnh mẽ có thể mang lại nguồn lợi có giá trị thêm vài số 0 nữa.
Bảo mật Kubernetes gia tăng nhờ không gian tấn công ngày càng đa dạng
Sự cố bảo mật Kubernetes đang gia tăng vì môi trường tấn công cũng đang trở nên đa dạng vô cùng tận với các cụm Cloud, trung tâm dữ liệu tại chỗ, thiết bị IoT, máy tính cá nhân… Bảo mật khép kín không còn tồn tại nữa - khi bạn chỉ tập trung vào ứng dụng của mình và để phần công việc còn lại cho tường lửa phòng thủ.
Mối đe dọa có thể đến từ một dịch vụ đang được sử dụng ngay trong hệ thống hoặc từ bên cung cấp dịch vụ thứ ba bạn đang sử dụng. Giờ đây, bảo mật là trách nhiệm chung của tất cả mọi người, các nhà cung cấp dịch vụ Cloud hay quản lý Kubernetes chỉ có thể đảm nhiệm tốt phần công việc của họ mà thôi. Cryptojacking (khai thác tiền ảo) chỉ thực sự phát triển khi chúng nắm được lỗ hổng bảo mật đó và sẽ khá khó để phát hiện trừ khi bạn thực hiện các kiểm tra hóa đơn dịch vụ Cloud và phát hiện định mức cao bất thường.
Tham khảo Techgenx.com
>> Có thể bạn quan tâm: Bizfly Cloud chính thức ra mắt Kubernetes Engine đầu tiên tại Việt Nam
