Các chuyên gia bảo mật đã mô tả hai lỗ hổng rất được mong đợi mà nhóm Dự án OpenSSL đã vá hôm thứ Ba là những vấn đề cần được giải quyết nhanh chóng, nhưng không nhất thiết phải loại bỏ mọi thứ khác trong phản ứng khẩn cấp.
Việc phát hành phiên bản 3.0.7 của thư viện mật mã được sử dụng phổ biến nhất sẽ giải quyết hai lỗ hổng tràn bộ đệm tồn tại trong các phiên bản OpenSSL 3.0.0 đến 3.0.6.
Trước khi tiết lộ, các chuyên gia bảo mật đã cảnh báo rằng một trong những vấn đề, ban đầu được đặc trưng là "quan trọng" vấn đề thực thi mã từ xa, có thể gây ra vấn đề ở cấp độ Heartbleed, tất cả đều phải thực hiện. Rất may, điều đó dường như không xảy ra - và khi tiết lộ lỗ hổng này, nhóm dự án OpenSSL cho biết họ đã quyết định hạ mức đe dọa xuống mức “cao” dựa trên phản hồi từ các tổ chức đã kiểm tra và phân tích lỗi.
Một cặp lỗi tràn bộ đệm
Lỗi đầu tiên (CVE-2022-3602) thực sự có thể — trong một số trường hợp cụ thể — kích hoạt RCE, điều này ban đầu khiến một số chuyên gia bảo mật lo lắng rằng lỗ hổng này có thể gây ra hậu quả toàn ngành. Nhưng hóa ra lại có những tình tiết giảm nhẹ: Thứ nhất, rất khó để khai thác, như được giải thích bên dưới. Ngoài ra, không phải tất cả các hệ thống đều bị ảnh hưởng.
Cụ thể, theo Mark Ellzey, nhà nghiên cứu bảo mật cấp cao tại Censys, chỉ những trình duyệt hỗ trợ OpenSSL 3.0.0 đến 3.0.6, như Firefox và Internet Explorer, mới bị ảnh hưởng vào thời điểm này; Đặc biệt không bị ảnh hưởng là Google Chrome, trình duyệt Internet hàng đầu.
Ông nói: “Tác động dự kiến sẽ ở mức tối thiểu do tính phức tạp của cuộc tấn công và những hạn chế trong cách thực hiện nó”. “Các tổ chức nên tăng cường đào tạo về lừa đảo và theo dõi các nguồn thông tin về mối đe dọa để đảm bảo họ đã chuẩn bị sẵn sàng nếu trở thành mục tiêu của một cuộc tấn công như thế này”.
Để khởi động, Alex Ilgayev, trưởng nhóm nghiên cứu bảo mật tại Cycode, lưu ý rằng lỗ hổng này không thể bị khai thác trên một số bản phân phối Linux nhất định; và, nhiều nền tảng hệ điều hành hiện đại triển khai các biện pháp bảo vệ chống tràn ngăn xếp để giảm thiểu các mối đe dọa như thế này trong mọi trường hợp, Ilgayev cho biết.
Lỗ hổng thứ hai (CVE-2022-3786), được phát hiện trong khi bản sửa lỗi ban đầu đang được phát triển, có thể được sử dụng để kích hoạt các điều kiện từ chối dịch vụ (DoS). Nhóm OpenSSL đánh giá lỗ hổng này có mức độ nghiêm trọng cao nhưng loại trừ khả năng nó được sử dụng để khai thác RCE.
Cả hai lỗ hổng đều gắn liền với một chức năng được gọi là mã chữ để mã hóa tên miền quốc tế.
“Người dùng OpenSSL 3.0.0 – 3.0.6 là khuyến khích nâng cấp lên 3.0.7 càng sớm càng tốt,” nhóm OpenSSL cho biết trong một blog kèm theo việc tiết lộ lỗi và phát hành phiên bản mới của thư viện mật mã. “Nếu bạn nhận được bản sao OpenSSL từ nhà cung cấp Hệ điều hành hoặc bên thứ ba khác thì bạn nên tìm cách nhận phiên bản cập nhật từ họ càng sớm càng tốt.”
Không phải là một trái tim chảy máu khác
Việc tiết lộ lỗi chắc chắn sẽ được giảm thiểu - ít nhất là vào thời điểm hiện tại - mối quan tâm lan rộng đã làm dấy lên bởi thông báo của nhóm OpenSSL vào tuần trước về việc tiết lộ lỗi sắp xảy ra. Đặc biệt, mô tả lỗ hổng đầu tiên là “nghiêm trọng” đã khiến nhiều người so sánh với lỗi “Heartbleed” năm 2014 - lỗi duy nhất khác trong OpenSSL được xếp hạng nghiêm trọng. Lỗi đó (CVE-2014-0160) đã ảnh hưởng đến một phạm vi rộng trên Internet và thậm chí hiện tại vẫn chưa được xử lý đầy đủ tại nhiều tổ chức.
Jonathan Knudsen, người đứng đầu nghiên cứu toàn cầu tại Trung tâm nghiên cứu an ninh mạng Synopsys, cho biết: “Theo mặc định, Heartbleed bị lộ trên bất kỳ phần mềm nào sử dụng phiên bản OpenSSL dễ bị tấn công và kẻ tấn công rất dễ dàng khai thác để xem các khóa mật mã và mật khẩu được lưu trữ trong bộ nhớ máy chủ”. . “Hai lỗ hổng vừa được báo cáo trong OpenSSL đều nghiêm trọng nhưng không ở mức độ tương tự.”
Lỗi OpenSSL rất khó khai thác…
Knudsen cho biết, để khai thác một trong các lỗ hổng mới, các máy chủ dễ bị tấn công sẽ cần yêu cầu xác thực chứng chỉ ứng dụng khách, đây không phải là tiêu chuẩn. Và những khách hàng dễ bị tổn thương sẽ cần kết nối với một máy chủ độc hại, đây là một phương thức tấn công phổ biến và có thể phòng thủ được, ông nói.
Ông lưu ý: “Không ai phải lo lắng về hai lỗ hổng này, nhưng chúng rất nghiêm trọng và cần được xử lý với tốc độ và sự siêng năng thích hợp”.
Trong một bài đăng trên blog, Trung tâm Bão Internet SANS đã mô tả bản cập nhật OpenSSL là sửa lỗi tràn bộ đệm trong quá trình xác minh chứng chỉ. Để hoạt động khai thác, chứng chỉ cần chứa tên được mã hóa Punycode độc hại và lỗ hổng sẽ chỉ được kích hoạt sau khi chuỗi chứng chỉ được xác minh.
SANS ISC lưu ý: “Trước tiên, kẻ tấn công cần phải có chứng chỉ độc hại được ký bởi cơ quan cấp chứng chỉ mà khách hàng tin tưởng”. “Điều này dường như không thể khai thác được đối với các máy chủ. Đối với máy chủ, điều này có thể bị khai thác nếu máy chủ yêu cầu chứng chỉ từ máy khách.”
Điểm mấu chốt: Khả năng bị khai thác là thấp vì lỗ hổng này rất phức tạp để khai thác, cũng như quy trình và yêu cầu để kích hoạt nó, Ilgayev của Cycode cho biết. Thêm vào đó, nó ảnh hưởng đến một số lượng hệ thống tương đối nhỏ, so với những hệ thống sử dụng phiên bản OpenSSL trước 3.0.
…Nhưng hãy siêng năng
Đồng thời, điều quan trọng cần lưu ý là các lỗ hổng khó khai thác đã bị khai thác trong quá khứ, Ilgayev nói và chỉ ra một cách khai thác không cần nhấp chuột mà NSO Group đã phát triển cho lỗ hổng trong iOS năm ngoái.
“[Ngoài ra], giống như nhóm OpenSSL nói, 'không có cách nào để biết mọi tổ hợp nền tảng và trình biên dịch đã sắp xếp các bộ đệm trên ngăn xếp như thế nào' và do đó việc thực thi mã từ xa vẫn có thể thực hiện được trên một số nền tảng," ông cảnh báo.
Và thực tế, Ellzey đã phác thảo một kịch bản về cách kẻ tấn công có thể khai thác CVE-2022-3602, lỗ hổng mà nhóm OpenSSL ban đầu đánh giá là nghiêm trọng.
“Kẻ tấn công sẽ lưu trữ một máy chủ độc hại và cố gắng yêu cầu nạn nhân xác thực nó bằng một ứng dụng dễ bị OpenSSL v3.x, có khả năng thông qua các chiến thuật lừa đảo truyền thống,” ông nói, mặc dù phạm vi bị hạn chế do việc khai thác chủ yếu là máy khách- bên.
Những lỗ hổng như thế này nhấn mạnh tầm quan trọng của việc có một hóa đơn nguyên vật liệu phần mềm (SBOM) cho mỗi hệ nhị phân được sử dụng, Ilgayev lưu ý. Ông nói: “Chỉ nhìn vào các trình quản lý gói là chưa đủ vì thư viện này có thể được liên kết và biên dịch theo nhiều cấu hình khác nhau, điều này sẽ ảnh hưởng đến khả năng khai thác”.
