Đánh giá lỗ hổng từ Hướng dẫn Kali Linux của OnWorks

Bỏ để qua phần nội dung

11.2.1. Đánh giá tính dễ bị tổn thương‌

A dễ bị tổn thương được coi là một điểm yếu có thể được sử dụng theo một cách nào đó để làm tổn hại đến tính bảo mật, tính toàn vẹn hoặc tính khả dụng của hệ thống thông tin. Trong đánh giá lỗ hổng bảo mật, mục tiêu của bạn là tạo ra một bản kiểm kê đơn giản về các lỗ hổng được phát hiện trong môi trường mục tiêu. Khái niệm về môi trường mục tiêu này là cực kỳ quan trọng. Bạn phải đảm bảo duy trì trong phạm vi mạng mục tiêu của khách hàng và các mục tiêu cần thiết. Việc vượt ra ngoài phạm vi đánh giá có thể gây ra gián đoạn dịch vụ, vi phạm lòng tin với khách hàng của bạn hoặc hành động pháp lý chống lại bạn và chủ lao động của bạn.

Do tính đơn giản tương đối của nó, kiểm tra tính dễ bị tổn thương thường được hoàn thành trong các môi trường trưởng thành hơn một cách thường xuyên như một phần của việc thể hiện sự cẩn trọng của họ. Trong hầu hết các trường hợp, một công cụ tự động, chẳng hạn như các công cụ trong Phân tích lỗ hổng bảo mật7 và Ứng dụng web8 các danh mục của trang web Kali Tools và menu Ứng dụng trên máy tính để bàn Kali, được sử dụng để khám phá các hệ thống trực tiếp trong môi trường đích, xác định các dịch vụ lắng nghe và liệt kê chúng để khám phá càng nhiều thông tin càng tốt, chẳng hạn như phần mềm máy chủ, phiên bản, nền tảng, v.v. .

Thông tin này sau đó được kiểm tra các chữ ký đã biết về các vấn đề hoặc lỗ hổng tiềm ẩn. Các chữ ký này được tạo thành từ các kết hợp điểm dữ liệu nhằm đại diện cho các vấn đề đã biết. Nhiều điểm dữ liệu được sử dụng, bởi vì bạn sử dụng càng nhiều điểm dữ liệu thì việc xác định càng chính xác. Một số lượng rất lớn các điểm dữ liệu tiềm năng tồn tại, bao gồm nhưng không giới hạn ở:

• Phiên bản hệ điều hành: Không hiếm trường hợp phần mềm dễ bị tấn công trên một phiên bản hệ thống điều hành nhưng không phải trên phiên bản khác. Do đó, máy quét sẽ cố gắng xác định, càng chính xác càng tốt, phiên bản hệ điều hành nào đang lưu trữ ứng dụng được nhắm mục tiêu.

• Mức bản vá: Nhiều lần, các bản vá cho hệ điều hành sẽ được phát hành không làm tăng thông tin phiên bản, nhưng vẫn thay đổi cách thức phản hồi của lỗ hổng, hoặc thậm chí loại bỏ hoàn toàn lỗ hổng.

• Kiến trúc bộ xử lý: Nhiều ứng dụng phần mềm có sẵn cho nhiều kiến trúc bộ xử lý như Intel x86, Intel x64, nhiều phiên bản ARM, UltraSPARC, v.v.

5https://en.wikipedia.org/wiki/Executable_space_protection#Windows 6https://en.wikipedia.org/wiki/Address_space_layout_randomization 7http://tools.kali.org/category/vulnerability-analysis 8http://tools.kali.org/category/web-applications‌‌‌

Trong một số trường hợp, một lỗ hổng sẽ chỉ tồn tại trên một kiến trúc cụ thể, vì vậy việc biết chút thông tin này có thể rất quan trọng đối với một chữ ký chính xác.

• Phiên bản phần mềm: Phiên bản của phần mềm được nhắm mục tiêu là một trong những mục cơ bản cần được nắm bắt để xác định lỗ hổng.

Những điểm này và nhiều điểm dữ liệu khác sẽ được sử dụng để tạo chữ ký như một phần của quá trình quét lỗ hổng bảo mật. Theo dự đoán, càng nhiều điểm dữ liệu trùng khớp thì chữ ký càng chính xác. Khi xử lý các trận đấu chữ ký, bạn có thể có một số kết quả tiềm năng khác nhau:

• True Positive: Chữ ký được khớp và nó nắm bắt được một lỗ hổng thực sự. Những kết quả này là những kết quả bạn sẽ cần theo dõi và sửa chữa, vì đây là những mục mà các cá nhân độc hại có thể lợi dụng để gây tổn hại cho tổ chức của bạn (hoặc khách hàng của bạn).

• Sai Dương tính: Chữ ký được trùng khớp; tuy nhiên, vấn đề được phát hiện không phải là một lỗ hổng thực sự. Trong đánh giá, chúng thường được coi là tiếng ồn và có thể khá khó chịu. Bạn không bao giờ muốn loại bỏ một kết quả tích cực thực sự là một dương tính giả mà không có sự xác nhận rộng rãi hơn.

• True Negative: Chữ ký không khớp và không có lỗ hổng. Đây là kịch bản lý tưởng, xác minh rằng lỗ hổng bảo mật không tồn tại trên mục tiêu.

• Sai Phủ định: Chữ ký không trùng khớp nhưng vẫn tồn tại lỗ hổng bảo mật. Âm tính giả cũng tệ như thế, âm tính giả còn tệ hơn nhiều. Trong trường hợp này, một vấn đề tồn tại nhưng máy quét không phát hiện ra nó, vì vậy bạn không có dấu hiệu về sự tồn tại của nó.

Như bạn có thể tưởng tượng, độ chính xác của các chữ ký là cực kỳ quan trọng để có kết quả chính xác. Càng cung cấp nhiều dữ liệu, càng có nhiều cơ hội có kết quả chính xác từ quá trình quét tự động dựa trên chữ ký, đó là lý do tại sao các bản quét xác thực thường rất phổ biến.

Với quá trình quét được xác thực, phần mềm quét sẽ sử dụng thông tin đăng nhập được cung cấp để xác thực với mục tiêu. Điều này cung cấp mức độ hiển thị sâu hơn vào mục tiêu so với mức có thể. Ví dụ, trong quá trình quét thông thường, bạn chỉ có thể phát hiện thông tin về hệ thống có thể được lấy từ các dịch vụ lắng nghe và chức năng mà chúng cung cấp. Điều này đôi khi có thể là một chút thông tin nhưng nó không thể cạnh tranh với mức độ và độ sâu của dữ liệu sẽ thu được nếu bạn xác thực hệ thống và xem xét toàn diện tất cả phần mềm đã cài đặt, các bản vá đã áp dụng, các quy trình đang chạy, v.v. . Phạm vi dữ liệu này rất hữu ích để phát hiện các lỗ hổng bảo mật mà chúng ta có thể chưa phát hiện ra.

Việc đánh giá tính dễ bị tổn thương được tiến hành tốt trình bày một cái nhìn tổng thể về các vấn đề tiềm ẩn trong một tổ chức và cung cấp các số liệu để đo lường sự thay đổi theo thời gian. Đây là một đánh giá khá nhẹ, nhưng thậm chí, nhiều tổ chức sẽ thường xuyên thực hiện quét lỗ hổng bảo mật tự động vào những giờ ngoài giờ để tránh các vấn đề tiềm ẩn trong ngày khi tính khả dụng của dịch vụ và băng thông là quan trọng nhất.

Như đã đề cập trước đây, quá trình quét lỗ hổng sẽ phải kiểm tra nhiều điểm dữ liệu khác nhau để có được kết quả chính xác. Tất cả các kiểm tra khác nhau này có thể tạo ra tải trên hệ thống đích cũng như tiêu tốn băng thông. Thật không may, rất khó để biết chính xác có bao nhiêu tài nguyên sẽ được sử dụng cho mục tiêu vì nó phụ thuộc vào số lượng dịch vụ đang mở và các loại

kiểm tra sẽ được liên kết với các dịch vụ đó. Đây là chi phí quét; nó sẽ chiếm tài nguyên hệ thống. Có một ý tưởng chung về các tài nguyên sẽ được tiêu thụ và mức tải mà hệ thống mục tiêu có thể chịu là rất quan trọng khi chạy các công cụ này.

Chủ đề quét Hầu hết các trình quét lỗ hổng bảo mật bao gồm một tùy chọn để thiết lập chủ đề mỗi lần quét, tương đương với số lần kiểm tra đồng thời xảy ra tại một thời điểm. Việc tăng con số này sẽ có tác động trực tiếp đến tải trên nền tảng đánh giá cũng như các mạng và mục tiêu mà bạn đang tương tác. Điều quan trọng cần ghi nhớ khi bạn sử dụng các máy quét này. Bạn muốn tăng các luồng để hoàn thành quá trình quét nhanh hơn nhưng hãy nhớ rằng việc tăng tải đáng kể liên quan đến việc này.

Khi quá trình quét lỗ hổng bảo mật kết thúc, các vấn đề được phát hiện thường được liên kết trở lại với các số nhận dạng tiêu chuẩn của ngành, chẳng hạn như số CVE9, EDB-ID10, và lời khuyên của nhà cung cấp. Thông tin này, cùng với điểm số CVSS của lỗ hổng bảo mật11, được sử dụng để xác định xếp hạng rủi ro. Cùng với âm tính giả (và dương tính giả), các xếp hạng rủi ro tùy tiện này là những vấn đề phổ biến cần được xem xét khi phân tích kết quả quét.

Vì các công cụ tự động sử dụng cơ sở dữ liệu chữ ký để phát hiện lỗ hổng, bất kỳ sai lệch nhỏ nào so với chữ ký đã biết có thể làm thay đổi kết quả và tương tự như tính hợp lệ của lỗ hổng nhận biết. Một kết quả dương tính giả không chính xác gắn cờ cho một lỗ hổng không tồn tại, trong khi một âm bản giả sẽ làm mù một lỗ hổng bảo mật và không báo cáo nó. Bởi vì điều này, một máy quét thường được cho là chỉ tốt như cơ sở quy tắc chữ ký của nó. Vì lý do này, nhiều nhà cung cấp cung cấp nhiều bộ ký hiệu: một bộ có thể miễn phí cho người dùng gia đình và một bộ khác khá đắt tiền nhưng toàn diện hơn, thường được bán cho khách hàng doanh nghiệp.

Một vấn đề khác thường gặp phải khi quét lỗ hổng bảo mật là tính hợp lệ của các xếp hạng rủi ro được đề xuất. Các xếp hạng rủi ro này được xác định trên cơ sở chung, xem xét nhiều yếu tố khác nhau như mức đặc quyền, loại phần mềm và xác thực trước hoặc sau. Tùy thuộc vào môi trường của bạn, những xếp hạng này có thể áp dụng hoặc không, vì vậy không nên chấp nhận chúng một cách mù quáng. Chỉ những người thành thạo về hệ thống và các lỗ hổng mới có thể xác nhận chính xác xếp hạng rủi ro.

Mặc dù không có thỏa thuận được xác định chung về xếp hạng rủi ro, ấn phẩm đặc biệt của NIST 800-3012 được khuyến nghị làm cơ sở để đánh giá xếp hạng rủi ro và độ chính xác của chúng trong môi trường của bạn. NIST SP 800-30 xác định nguy cơ thực sự của một lỗ hổng được phát hiện là sự kết hợp giữa khả năng xảy ra và tác động tiềm tàng.

9https://cve.mitre.org 10https://www.exploit-db.com/about/ 11https: //www.first.org/cvss‌‌‌

12http://csrc.nist.gov/publications/PubsSPs.html#800-30