Các tác nhân đe dọa sẽ tấn công và sử dụng các container như thế nào? Đây là câu hỏi tôi không ngừng suy nghĩ. Tôi đã làm việc trong lĩnh vực này hơn hai thập kỷ nay và tôi cảm thấy mình nên có câu trả lời. Nhưng tôi thì không.
Thay vào đó, tôi có rất nhiều ý tưởng khác nhau, nhưng không có ý tưởng nào tôi thực sự có thể xác định là chính xác. Một phần của sự do dự này là do tôi đã dành toàn bộ thời gian để học về bảo mật trong thế giới “cũ”. Các thùng chứa không thực sự có chất tương tự. Chắc chắn, máy ảo (VM) thường được kết hợp với các thùng chứa, nhưng chúng không bao giờ có thể mở rộng quy mô như các thùng chứa. Chúng cũng được sử dụng cho những mục đích hoàn toàn khác so với container. Tôi phải mất một thời gian để điều chỉnh suy nghĩ và hiểu được vị trí thực sự phù hợp của các thùng chứa trên bề mặt tấn công.
Các ví dụ công khai về các cuộc tấn công chống lại môi trường được chứa trong container là rất hạn chế. Các vi phạm hầu như luôn liên quan đến khai thác tiền điện tử, đây là những cuộc tấn công nghiêm trọng, nhưng người ứng phó sự cố trong tôi thấy chúng không quá ấn tượng. Một điểm chung khác là chúng chủ yếu là kết quả của việc cấu hình sai, cho dù đó là trong Kubernetes hay tài khoản đám mây. Sự kết hợp giữa động cơ và chiến thuật cho đến nay vẫn chưa gây được nhiều cảm hứng.
Con đường cũ
Lỗ hổng thực thi mã từ xa (RCE) từ lâu đã là mối lo ngại chính về bảo mật máy tính. Vẫn như vậy, nhưng cách suy nghĩ này áp dụng như thế nào đối với các thùng chứa? Thật dễ dàng ngay lập tức coi RCE là mối đe dọa chính, nhưng dường như đó không phải là cách phù hợp để tiếp cận các container. Có một điều, các thùng chứa thường có tuổi thọ rất ngắn – 44% container tồn tại dưới XNUMX phút – vì vậy kẻ đột nhập sẽ phải nhanh chóng.
Cách tiếp cận này cũng giả định rằng container được tiếp xúc với Internet. Chắc chắn một số vùng chứa được thiết lập theo cách này, nhưng chúng thường rất đơn giản và sử dụng các công nghệ đã được thử nghiệm tốt, như NGINX. Có thể không có ngày nào dành cho những ứng dụng này, nhưng chúng sẽ cực kỳ có giá trị và khó có được. Kinh nghiệm của tôi cho tôi thấy rằng rất nhiều vùng chứa được sử dụng nội bộ và không kết nối trực tiếp với Internet. Kịch bản RCE trở nên khó khăn hơn rất nhiều trong trường hợp đó. Tôi nên đề cập đến log4j, mặc dù các loại lỗ hổng này có khả năng bị khai thác từ xa ngay cả khi hệ thống dễ bị tấn công không ở mức nguy hiểm.
Con đường mới
Nếu RCE không phải là mối đe dọa lớn nhất mà container phải đối mặt thì đó là gì? Các container có nằm trong tầm ngắm của các tác nhân đe dọa không? Đúng vậy, container và cơ sở hạ tầng hỗ trợ của chúng quá quan trọng để có thể bỏ qua. Phần mềm điều phối vùng chứa đã cho phép mở rộng quy mô khối lượng công việc trong vùng chứa đến mức không thể tưởng tượng được. Xu hướng sử dụng cũng ngày càng tăng nên bạn có thể chắc chắn rằng chúng sẽ là mục tiêu. Chúng không thể được coi giống như các máy chủ mà bạn truy cập thông qua các lỗ hổng RCE.
Thay vào đó, điều ngược lại mới thực sự đúng. Thay vì tấn công container từ ngoài vào trong, chúng cần được tấn công từ trong ra ngoài. Đây thực chất là những gì các cuộc tấn công chuỗi cung ứng thực hiện. Chuỗi cung ứng là một phương thức tấn công cực kỳ hiệu quả nhằm vào các container khi bạn bắt đầu hiểu cách chúng được xây dựng. Vùng chứa bắt đầu bằng tệp định nghĩa, chẳng hạn như Dockerfile, tệp này xác định mọi thứ sẽ có trong vùng chứa khi nó chạy. Nó được biến thành một hình ảnh sau khi được tạo và hình ảnh đó là thứ có thể được đưa vào khối lượng công việc vô số lần. Nếu bất kỳ nội dung nào trong tệp định nghĩa đó bị xâm phạm thì mọi khối lượng công việc đang chạy đều bị xâm phạm.
Các vùng chứa thường, nhưng không phải lúc nào cũng được xây dựng có mục đích với một ứng dụng thực hiện điều gì đó và thoát ra. Các ứng dụng này có thể là hầu hết mọi thứ - điều quan trọng cần hiểu là khối lượng được xây dựng bằng cách sử dụng các thư viện, nguồn đóng hoặc nguồn mở, do người khác viết. GitHub có hàng triệu dự án và đó không phải là kho lưu trữ mã duy nhất hiện có. Như chúng ta đã thấy với SolarWinds, nguồn đóng cũng dễ bị tấn công bởi chuỗi cung ứng.
Tấn công chuỗi cung ứng là một cách tuyệt vời để các tác nhân đe dọa xâm nhập vào môi trường container của mục tiêu. Họ thậm chí có thể để cơ sở hạ tầng của khách hàng mở rộng quy mô cuộc tấn công cho họ nếu sự xâm phạm không được chú ý. Loại kịch bản này đã tự diễn ra rồi, như chúng ta đã thấy với Vi phạm Codecov. Nhưng rất khó để phát hiện ra vì tất cả những điều này quá mới và suy nghĩ của chúng ta vẫn bắt nguồn từ những vấn đề trong quá khứ.
Một đường phía trước
Giống như việc khắc phục hầu hết các sự cố, khả năng hiển thị thường là nơi tuyệt vời để bắt đầu. Thật khó để sửa những gì bạn không thể nhìn thấy. Để bảo mật các vùng chứa của mình, bạn cần có khả năng hiển thị về bản thân các vùng chứa cũng như toàn bộ quy trình xây dựng chúng. Quản lý lỗ hổng bảo mật là một loại khả năng hiển thị phải được tích hợp vào quy trình xây dựng. Tôi cũng sẽ bao gồm các công cụ phân tích tĩnh khác, chẳng hạn như các công cụ tìm kiếm bí mật bị rò rỉ. Vì không thể dự đoán trước được một cuộc tấn công chuỗi cung ứng trông như thế nào nên việc giám sát thời gian chạy trở nên quan trọng để bạn biết chính xác vùng chứa của mình đang làm gì.
