BLACK HAT USA - Las Vegas - Theo kịp bản vá lỗ hổng bảo mật là một thách thức tốt nhất, nhưng việc ưu tiên tập trung vào lỗi nào đã trở nên khó khăn hơn bao giờ hết, nhờ vào điểm CVSS thiếu ngữ cảnh, cố vấn của nhà cung cấp khó khăn và các bản sửa lỗi chưa hoàn chỉnh. để lại cho quản trị viên cảm giác an toàn sai lầm.

Đó là lập luận mà Brian Gorenc và Dustin Childs, cả hai đều thuộc Sáng kiến ​​Zero Day (ZDI) của Trend Micro, đưa ra từ sân khấu của Black Hat USA trong phiên họp của họ, “Tính toán rủi ro trong kỷ nguyên của sự che khuất: Đọc giữa các dòng tư vấn bảo mật".

ZDI đã tiết lộ hơn 10,000 lỗ hổng bảo mật cho các nhà cung cấp trong toàn ngành kể từ năm 2005. Trong suốt thời gian đó, giám đốc truyền thông Childs của ZDI nói rằng ông nhận thấy một xu hướng đáng lo ngại, đó là giảm chất lượng bản vá và giảm thông tin liên lạc xung quanh các bản cập nhật bảo mật.

“Vấn đề thực sự nảy sinh khi các nhà cung cấp tung ra các bản vá lỗi, hoặc thông tin không chính xác và không đầy đủ về các bản vá đó có thể khiến các doanh nghiệp tính toán sai rủi ro của họ,” ông lưu ý. "Các bản vá lỗi cũng có thể là một lợi ích để người viết khai thác, vì 'n-days' dễ sử dụng hơn nhiều so với zero-days."

Rắc rối với Điểm CVSS & Mức độ ưu tiên vá

Hầu hết các nhóm an ninh mạng đều thiếu nhân lực và chịu nhiều áp lực, và câu thần chú “luôn cập nhật tất cả các phiên bản phần mềm” không phải lúc nào cũng có ý nghĩa đối với các bộ phận đơn giản là không có đủ nguồn lực để chi trả cho vùng sông nước. Đó là lý do tại sao việc ưu tiên áp dụng các bản vá lỗi theo xếp hạng mức độ nghiêm trọng của chúng trong Thang điểm mức độ tổn thương chung (CVSS) đã trở thành một dự phòng cho nhiều quản trị viên.

Tuy nhiên, Childs lưu ý rằng cách tiếp cận này có sai sót sâu sắc và có thể dẫn đến việc sử dụng tài nguyên cho các lỗi khó có thể bị khai thác. Đó là bởi vì có một loạt thông tin quan trọng mà điểm CVSS không cung cấp.

Ông nói: “Thông thường, các doanh nghiệp không tìm đâu xa hơn cốt lõi cơ sở CVSS để xác định mức độ ưu tiên vá lỗi. “Nhưng CVSS không thực sự xem xét khả năng khai thác, hoặc liệu một lỗ hổng có khả năng được sử dụng trong tự nhiên hay không. CVSS không cho bạn biết liệu lỗi có tồn tại trong 15 hệ thống hay trong 15 triệu hệ thống hay không. Và nó không nói liệu nó có nằm trong các máy chủ có thể truy cập công cộng hay không. ”

Anh ấy nói thêm, "Và quan trọng nhất, nó không cho biết liệu lỗi có tồn tại trong một hệ thống quan trọng đối với doanh nghiệp cụ thể của bạn hay không."

Vì vậy, mặc dù một lỗi có thể mang xếp hạng quan trọng là 10/10 trên thang điểm CVSS, nhưng tác động thực sự của nó có thể ít liên quan hơn nhiều so với nhãn quan trọng đó sẽ chỉ ra.

Ông nói: “Một lỗi thực thi mã từ xa không được xác thực (RCE) trong một máy chủ email như Microsoft Exchange sẽ thu hút rất nhiều sự quan tâm từ các nhà khai thác”. “Một lỗi RCE chưa được xác thực trong một máy chủ email như Squirrel Mail có lẽ sẽ không gây được nhiều sự chú ý.”

Để lấp đầy khoảng trống theo ngữ cảnh, các nhóm bảo mật thường chuyển sang cố vấn của nhà cung cấp - Childs lưu ý, có vấn đề khó hiểu của riêng họ: Họ thường thực hiện bảo mật thông qua sự che giấu.

Thiếu thông tin tư vấn về bản vá thứ ba của Microsoft

Năm 2021, Microsoft đưa ra quyết định để xóa tóm tắt điều hành
từ hướng dẫn cập nhật bảo mật, thay vào đó thông báo cho người dùng rằng điểm CVSS sẽ đủ để ưu tiên - một thay đổi mà Childs đã thổi bùng.

Ông nói: “Sự thay đổi loại bỏ bối cảnh cần thiết để xác định rủi ro. “Ví dụ, một lỗi tiết lộ thông tin có làm đổ bộ nhớ ngẫu nhiên hoặc PII không? Hoặc đối với bỏ qua tính năng bảo mật, điều gì đang bị bỏ qua? Thông tin trong các bản ghi này không nhất quán và có chất lượng khác nhau, mặc dù gần như có nhiều lời chỉ trích về sự thay đổi này. "

Ngoài việc Microsoft “xóa hoặc che khuất thông tin trong các bản cập nhật được sử dụng để đưa ra hướng dẫn rõ ràng”, giờ đây việc xác định thông tin cơ bản về Bản vá thứ ba cũng khó khăn hơn, chẳng hạn như có bao nhiêu lỗi được vá mỗi tháng.

“Bây giờ bạn phải tự đếm, và đó thực sự là một trong những việc khó nhất mà tôi làm,” Childs lưu ý.

Ngoài ra, thông tin về bao nhiêu lỗ hổng đang bị tấn công tích cực hoặc được biết đến công khai vẫn có sẵn, nhưng giờ đây đã bị chôn vùi trong các bản tin.

“Ví dụ, với 121 CVE đang được vá trong tháng này, thật khó để tìm hiểu tất cả chúng để tìm kiếm cái nào đang bị tấn công tích cực, ”Childs nói. “Thay vào đó, mọi người hiện đang dựa vào các nguồn thông tin khác như blog và các bài báo, thay vì những gì nên là thông tin có thẩm quyền từ nhà cung cấp để giúp xác định rủi ro.”

Cần lưu ý rằng Microsoft đã tăng gấp đôi về sự thay đổi. Trong một cuộc trò chuyện với Dark Reading tại Black Hat USA, phó chủ tịch công ty của Trung tâm phản hồi bảo mật của Microsoft, Aanchal Gupta, cho biết công ty đã quyết định có ý thức hạn chế thông tin mà họ cung cấp ban đầu với các CVE của mình để bảo vệ người dùng. Trong khi các CVE của Microsoft cung cấp thông tin về mức độ nghiêm trọng của lỗi và khả năng nó bị khai thác (và liệu nó có đang bị khai thác tích cực hay không), công ty sẽ thận trọng về cách công ty tung ra thông tin khai thác lỗ hổng bảo mật.

Mục đích là cung cấp cho các cơ quan quản lý bảo mật đủ thời gian để áp dụng bản vá mà không gây nguy hiểm cho họ, Gupta nói. “Nếu, trong CVE của chúng tôi, chúng tôi cung cấp tất cả các chi tiết về cách các lỗ hổng bảo mật có thể bị khai thác, chúng tôi sẽ không còn là ngày của khách hàng nữa,” cô nói.

Các nhà cung cấp khác thực hành sự che khuất

Microsoft hầu như không đơn độc trong việc cung cấp thông tin chi tiết ít ỏi về việc tiết lộ lỗi. Childs nói rằng nhiều nhà cung cấp hoàn toàn không cung cấp CVE khi họ phát hành bản cập nhật.

“Họ chỉ nói rằng bản cập nhật khắc phục một số vấn đề bảo mật,” anh giải thích. "Bao nhiêu? Mức độ nghiêm trọng là gì? Khả năng khai thác là gì? Chúng tôi thậm chí đã có một nhà cung cấp gần đây nói cụ thể với chúng tôi rằng, chúng tôi không công bố tư vấn công khai về các vấn đề bảo mật. Đó là một bước đi táo bạo ”.

Ngoài ra, một số nhà cung cấp đặt các lời khuyên đằng sau các bức tường phí hoặc các hợp đồng hỗ trợ, càng che khuất rủi ro của họ. Hoặc, họ kết hợp nhiều báo cáo lỗi thành một CVE duy nhất, bất chấp nhận thức chung rằng CVE đại diện cho một lỗ hổng duy nhất.

Ông nói: “Điều này có thể làm sai lệch tính toán rủi ro của bạn. “Ví dụ, nếu bạn xem xét việc mua một sản phẩm và bạn thấy 10 CVE đã được vá trong một khoảng thời gian nhất định, bạn có thể đưa ra một kết luận về rủi ro từ sản phẩm mới này. Tuy nhiên, nếu bạn biết 10 CVE đó dựa trên hơn 100 báo cáo lỗi, bạn có thể đưa ra một kết luận khác ”.

Ưu tiên cho Bản vá giả dược Bệnh dịch hạch

Ngoài vấn đề tiết lộ, các nhóm bảo mật cũng phải đối mặt với những rắc rối với chính các bản vá lỗi. Theo Childs, “các bản vá giả dược” là “các bản sửa lỗi” thực sự không tạo ra các thay đổi mã hiệu quả, không phải là hiếm.

“Vì vậy, lỗi đó vẫn còn đó và có thể bị khai thác đối với các tác nhân đe dọa, ngoại trừ bây giờ họ đã được thông báo về nó,” ông nói. “Có nhiều lý do tại sao điều này có thể xảy ra, nhưng nó xảy ra - lỗi rất hay, chúng tôi vá chúng hai lần. "

Cũng thường có các bản vá lỗi không hoàn chỉnh; Trên thực tế, trong chương trình ZDI, đầy đủ 10% đến 20% lỗi mà các nhà nghiên cứu phân tích là kết quả trực tiếp của một bản vá bị lỗi hoặc không hoàn chỉnh.

Childs đã sử dụng ví dụ về sự cố tràn số nguyên trong Adobe Reader dẫn đến việc phân bổ heap dưới kích thước, dẫn đến tràn bộ đệm khi ghi quá nhiều dữ liệu vào đó.

Childs cho biết: “Chúng tôi mong muốn Adobe sẽ sửa chữa bằng cách đặt bất kỳ giá trị nào trên một điểm nhất định là không tốt. “Nhưng đó không phải là những gì chúng tôi đã thấy, và trong vòng 60 phút kể từ khi triển khai, đã có một bản vá bỏ qua và họ phải vá lại. Reruns không chỉ dành cho các chương trình truyền hình ”.

Làm thế nào để chống lại các tai ương về ưu tiên bản vá

Cuối cùng, khi nói đến ưu tiên bản vá, quản lý bản vá hiệu quả và tính toán rủi ro tập trung vào việc xác định các mục tiêu phần mềm có giá trị cao trong tổ chức cũng như sử dụng các nguồn của bên thứ ba để thu hẹp các bản vá lỗi nào là quan trọng nhất đối với bất kỳ môi trường nhất định nào, các nhà nghiên cứu lưu ý.

Tuy nhiên, vấn đề nhanh nhẹn sau công bố thông tin là một lĩnh vực chính khác mà các tổ chức cần tập trung.

Theo Gorenc, giám đốc cấp cao tại ZDI, tội phạm mạng không lãng phí thời gian để tích hợp những kẻ xấu có bề mặt tấn công lớn vào bộ công cụ ransomware hoặc bộ công cụ khai thác của chúng, tìm cách vũ khí hóa các lỗ hổng mới được tiết lộ trước khi các công ty có thời gian vá lỗi. Cái gọi là lỗi n-day này là điểm tiếp xúc cho những kẻ tấn công, những kẻ này trung bình có thể thiết kế ngược một lỗi trong vòng 48 giờ.

“Phần lớn, cộng đồng tấn công đang sử dụng các lỗ hổng n-day có sẵn các bản vá công khai,” Gorenc nói. “Điều quan trọng là chúng tôi phải hiểu khi tiết lộ liệu một lỗi có thực sự được vũ khí hóa hay không, nhưng hầu hết các nhà cung cấp không cung cấp thông tin liên quan đến khả năng khai thác”.

Do đó, các đánh giá rủi ro doanh nghiệp cần đủ năng động để thay đổi sau khi tiết lộ và các nhóm bảo mật nên theo dõi các nguồn thông tin tình báo về mối đe dọa để hiểu khi nào một lỗi được tích hợp vào bộ khai thác hoặc ransomware hoặc khi một khai thác được phát hành trực tuyến.

Bên cạnh đó, một mốc thời gian quan trọng mà các doanh nghiệp cần xem xét là mất bao lâu để thực sự triển khai một bản vá trong toàn tổ chức và liệu có các nguồn lực khẩn cấp có thể được cung cấp nếu cần thiết hay không.

“Khi các thay đổi xảy ra đối với bối cảnh mối đe dọa (sửa đổi bản vá, chứng minh khái niệm công khai và bản phát hành khai thác), các doanh nghiệp nên chuyển nguồn lực của họ để đáp ứng nhu cầu và chống lại những rủi ro mới nhất,” Gorenc giải thích. “Không chỉ là lỗ hổng được công khai và đặt tên mới nhất. Quan sát những gì đang diễn ra trong bối cảnh mối đe dọa, định hướng nguồn lực của bạn và quyết định khi nào nên hành động. "