Có ba điều bạn có thể chắc chắn trong cuộc sống: cái chết, thuế – và CVE mới. Đối với các tổ chức dựa trên CentOS 8, điều không thể tránh khỏi hiện đã xảy ra và không mất nhiều thời gian. Chỉ hai tuần sau khi chính thức kết thúc vòng đời, một sự cố đã xảy ra một cách ngoạn mục, khiến người dùng CentOS 8 có nguy cơ bị tấn công nghiêm trọng – và không có sự hỗ trợ từ CentOS.
Bạn sẽ nghĩ rằng vấn đề này không còn ảnh hưởng đến một số lượng lớn các tổ chức nữa bởi vì bây giờ, các công ty đã chuyển từ CentOS 8 sang một hệ điều hành được các nhà cung cấp hỗ trợ tích cực. Rốt cuộc, hỗ trợ của nhà cung cấp là rất quan trọng đối với bảo mật và tuân thủ.
Nhưng như mọi khi với những điều này, bạn có thể tin tưởng vào thực tế là một phần lớn người dùng CentOS 8 đang say mê với một hệ điều hành không được hỗ trợ, mặc dù nhận thức được những rủi ro. Với nguy cơ đó hiện đang kết tinh, chúng tôi đang sử dụng bài viết này để kiểm tra CVE-2021-4122, lỗ hổng mới được phát hiện trong mã hóa LUKS và để thảo luận về các tùy chọn của bạn để giảm thiểu nó.
Chờ đã, LUKS là gì?
Vậy LUKS là gì? LUKS là viết tắt của linux Unified Key Setup và là một cơ chế được sử dụng trong các hệ thống chạy bằng Linux để hỗ trợ mã hóa toàn bộ ổ đĩa, trong số những thứ khác. Nó được khuyến nghị trong nhiều hướng dẫn “thực tiễn tốt nhất” như một tùy chọn tăng cường hệ thống cần thiết cho các nhóm CNTT quan tâm đến bảo mật.
LUKS hoạt động như thế nào? Chà, trong quá trình triển khai hệ thống, bạn có thể tạo một phân vùng chỉ có thể đọc được – tức là dữ liệu bên trong nó chỉ có thể hiểu được – bằng mật khẩu do người dùng cung cấp. LUKS khá phức tạp và nhiều hệ thống bảo mật tương tác với LUKS, nhưng hướng dẫn về LUKS toàn diện không phải là mục tiêu của bài viết này.
Có một đĩa được mã hóa hoàn toàn (thiết bị khối trong Linux “nói”) đảm bảo rằng dữ liệu được an toàn khỏi những con mắt tò mò ngay cả khi ở chế độ nghỉ, có nghĩa là kẻ tấn công lấy cắp máy tính xách tay, chẳng hạn, vẫn không thể xem dữ liệu bí mật có trong nó.
Bạn có thể xây dựng thêm về bảo mật bằng cách gắn một thiết bị khối cụ thể với một máy tính cụ thể thông qua TPM (Mô-đun nền tảng đáng tin cậy). Điều đó tạo thêm một trở ngại khác cho kẻ tấn công, khiến việc lấy dữ liệu được mã hóa từ máy tính và cắm nó vào một hệ thống hiệu suất cao với mục tiêu cưỡng bức dữ liệu sẽ khó hơn. Mặc dù vậy, như mọi khi, khả năng thành công như thế nào phụ thuộc vào sức mạnh tính toán, thuật toán mã hóa đã chọn và chỉ là sự may mắn.
Nhìn chung, LUKS cung cấp khả năng bảo vệ tuyệt vời và vì lý do đó, nó thường được dựa vào để bảo mật các hệ thống trong nhiều tổ chức khác nhau.
Hiểu lỗ hổng LUKS
CVE-2021-4122 đã được chỉ định vào cuối năm ngoái, nhưng sự hiểu biết đầy đủ về các rủi ro bảo mật xung quanh LUKS chỉ mới xuất hiện gần đây. Hóa ra là có thể, ít nhất một phần, giải mã một đĩa được mã hóa LUKS và truy cập dữ liệu trên đó mà không cần sở hữu mật khẩu được sử dụng để định cấu hình mã hóa.
Một tính năng chính của LUKS là khả năng thay đổi nhanh chóng khóa được sử dụng để mã hóa một thiết bị nhất định. Bạn sẽ làm điều này, ví dụ, đối với các lần thay đổi khóa theo lịch trình trong môi trường bảo mật cao.
Tính năng mã hóa lại nhanh chóng này có nghĩa là thiết bị vẫn khả dụng trong quá trình thay đổi khóa. Nó được gọi là “mã hóa lại trực tuyến” – đề cập đến khả năng mã hóa lại đĩa bằng một khóa khác khi nó đang trực tuyến và đang được sử dụng.
Trong quá trình này, một lỗ hổng bảo mật đã được xác định. Nó chỉ ra rằng nếu bạn biết mình đang làm gì, bạn có thể thực hiện thao tác này mà không cần sở hữu mật khẩu gốc, hiện tại. Ngay cả khi không có mật khẩu, bạn có thể yêu cầu mã hóa lại.
Khai thác lỗ hổng, quá trình này sau đó sẽ có vẻ như bị hủy bỏ và một số dữ liệu sẽ được cung cấp mà không được mã hóa. Không lúc nào thiết bị gặp phải bất kỳ hành vi bất thường nào, vì vậy sẽ khó phát hiện kẻ tấn công đang thực hiện thao tác chỉ bằng cách nhìn vào trạng thái thiết bị chặn.
Các Sysadmins đang được khuyên nên nâng cấp cryptsetup, gói hỗ trợ LUKS, trên tất cả các hệ thống do họ kiểm soát, vì lỗ hổng bảo mật có thể dẫn đến tiết lộ thông tin.
Được rồi, vậy tôi sẽ chỉ sửa chữa và tiếp tục…?
Chính xác. Đó là điều mà mọi quản trị viên hệ thống nên làm trên hệ thống của họ – thay thế gói bị ảnh hưởng. Nhưng đối với một số sysadmins, điều này nói dễ hơn làm. Sysadmins nào sẽ gặp khó khăn? Bạn đoán đúng – những thứ vẫn dựa vào CentOS 8.
Hầu hết các nhà cung cấp đã có cảnh báo sớm về lỗi và đã cung cấp các gói cập nhật cho các bản phân phối của họ. Và cũng giống như Red Hat, ủng hộ CentOS. Tuy nhiên, với việc CentOS 8 hiện không còn được hỗ trợ chính thức nữa, bản vá lỗi của CentOS 8 cho lỗ hổng LUKS sẽ không xuất hiện.
Đối với người dùng CentOS 8, mọi thứ trở nên khá ảm đạm. Các hệ thống chưa được vá dễ bị đánh cắp dữ liệu do một lỗ hổng đã được công bố và được biết đến rộng rãi. Đó là một tình huống nghiêm trọng và bằng cách này hay cách khác, bạn nên triển khai các phiên bản vá cập nhật của gói bị ảnh hưởng.
Không làm gì không phải là một lựa chọn khi dữ liệu bí mật gặp rủi ro. Và, về cơ bản, tất cả dữ liệu của bạn là bí mật và không được tiết lộ công khai (nếu không thì dữ liệu đã được công khai) và bạn đang dựa vào giải pháp mã hóa toàn bộ ổ đĩa chính xác như LUKS để tránh bị tiết lộ.
Các tùy chọn vá lỗi của bạn nếu bạn vẫn đang sử dụng CentOS 8
Có hai con đường có sẵn cho các hệ thống dựa trên các hệ thống Linux bị ảnh hưởng đang hoạt động trong thời gian cuối của chúng. Một tùy chọn là tải xuống nguồn dự án ngược dòng và biên dịch cục bộ, tạo gói hệ thống thay thế. Tùy chọn khác là ký với một nhà cung cấp hỗ trợ mở rộng sẽ cung cấp các bản vá lỗi mà nhà cung cấp ban đầu không còn phát hành nữa.
Phương pháp build-it-local có nhược điểm. Đầu tiên, mã nguồn dự án ban đầu không thực hiện bất kỳ khoản phụ cấp đặc biệt nào cho một bản phân phối cụ thể. Mỗi bản phân phối hoặc họ bản phân phối đều có những điểm kỳ quặc riêng. Gia đình RHEL, bao gồm CentOS, cũng sẽ có những điều kỳ quặc này.
Điều đó bao gồm những thứ như vị trí nhị phân, cấu hình bắt đầu dịch vụ, cài đặt, v.v. Nhóm địa phương của bạn sẽ phải điều chỉnh những điều này theo cách thủ công. Liệu nhóm CNTT tại địa phương của bạn có đủ kiến thức chuyên môn cần thiết hay không là một câu hỏi khác. Tương tự, với các nhóm công nghệ thường chịu áp lực hoàn thành công việc, có nguy cơ nỗ lực vá lỗi tự làm của bạn bị trì hoãn. Ngoài ra, trên chính trang dự án LUKS, có điều đáng ngại là “Hãy luôn thích các công cụ xây dựng dành riêng cho phân phối để định cấu hình cryptsetup theo cách thủ công”.
Cách thay thế của bạn là nghĩ về các nhà cung cấp hỗ trợ mở rộng như một cách tiếp cận đáng tin cậy, hiệu quả về chi phí và dễ dàng hơn để giải quyết vấn đề này. Dịch vụ Hỗ trợ Vòng đời Mở rộng của TuxCare thực hiện điều đó. TuxCare cung cấp các bản vá chất lượng cao cho các bản phân phối cuối đời như CentOS 8 và làm như vậy đúng thời hạn.
Hơn nữa, bạn còn nhận được hỗ trợ đầy đủ cho các bản vá lỗi. Việc triển khai rất đơn giản, bạn triển khai các bản vá TuxCare dễ dàng như các bản vá do nhà cung cấp hỗ trợ.
Bạn phải hành động – ngay bây giờ
Nếu bạn quyết định không nhờ đến sự hỗ trợ từ bên ngoài, bạn vẫn phải làm gì đó ngay bây giờ để bảo vệ hệ thống của mình khỏi lỗ hổng bảo mật mới. Bạn có thể quyết định cắn viên đạn và biên dịch tập hợp mã hóa và các phụ thuộc của nó cục bộ, đồng thời thực hiện triển khai trên tất cả các hệ thống của mình.
Nhưng chắc chắn đây không phải là CVE cuối cùng ảnh hưởng đến CentOS 8. Để cung cấp cho bạn một số ý tưởng về phạm vi của những gì chúng ta đang nói đến: ngay cả ngày nay vẫn có những lỗ hổng ảnh hưởng đến hệ thống CentOS 6. Làm thế nào khả thi về lâu dài để tiếp tục đối phó với một dòng CVE liên tục ảnh hưởng đến CentOS 8?
Bạn có thể đang chạy CentOS 8 tại thời điểm này vì bạn đã bị ngăn chuyển sang một giải pháp thay thế vì lý do này hay lý do khác. Nó có thể là khả năng tương thích, hỗ trợ hoặc bất kỳ một trong nhiều lý do.
Các lỗ hổng bảo mật sẽ không dừng lại ở ngày EOL, vì vậy, hãy làm cho nhóm CNTT của bạn dễ dàng hơn, an toàn hơn cho các chuyên gia bảo mật của bạn và đáp ứng các yêu cầu tuân thủ xung quanh việc vá lỗi cho doanh nghiệp của bạn – hãy xem nhóm dịch vụ của TuxCare và đặc biệt là Hỗ trợ Vòng đời Mở rộng. Đó là một cách vững chắc để có được sự bảo vệ liên tục chống lại các CVE mới ảnh hưởng đến CentOS 8 – giúp bạn có thời gian để di chuyển sang một hệ điều hành khác.
.
