Hôm qua là Bản vá thứ Ba đầu tiên của năm 2022, với hơn 100 lỗi bảo mật đã được sửa.

Chúng tôi đã viết tổng quan về các bản cập nhật, như chúng tôi làm hàng tháng, trên trang web chị em của chúng tôi news.sophos.com: Bản vá thứ ba đầu tiên của năm 2022 sửa chữa 102 lỗi.

Dù tốt hay xấu, một bản cập nhật đã thu hút sự chú ý của giới truyền thông hơn bất kỳ bản cập nhật nào khác, cụ thể là CVE-2022-21907, được gọi đầy đủ hơn là Ngăn xếp giao thức HTTP Lỗ hổng thực thi mã từ xa.

Lỗi này là một trong bảy lỗ hổng bảo mật của tháng này có thể dẫn đến thực thi mã từ xa (RCE), loại lỗi có nghĩa là ai đó bên ngoài mạng của bạn có thể lừa máy tính bên trong mạng của bạn chạy một số loại chương trình mà không cần xin phép trước .

Không cần đăng nhập trước; không có cảnh báo bật lên ở đầu bên kia; không Are you sure (Y/N)? câu hỏi.

Chỉ cần ra lệnh và phần mềm độc hại sẽ chạy.

Đó là lý thuyết, dù sao.

Lỗi RCE được coi là sâu

Một điều cần nhớ về hầu hết các lỗ hổng RCE là nếu bạn có thể tấn công máy tính của người khác từ bên ngoài và hướng dẫn máy tính đó chạy một chương trình độc hại mà bạn chọn…

…thì có thể, thậm chí có thể xảy ra, rằng bạn có thể yêu cầu nó chạy chính chương trình mà chính bạn vừa sử dụng để khởi động cuộc tấn công của chính mình.

Nói cách khác, bạn có thể sử dụng lỗ hổng để xác định vị trí và lây nhiễm Nạn nhân 1 bằng chương trình độc hại W hướng dẫn Nạn nhân 1 xác định vị trí và lây nhiễm Nạn nhân 2 bằng chương trình độc hại W hướng dẫn Nạn nhân 2 xác định vị trí và lây nhiễm Nạn nhân 3…, v.v. , thậm chí có thể là vô tận.

Trong một cuộc tấn công như thế này, chúng tôi đặt cho chương trình W một cái tên đặc biệt: chúng tôi gọi nó là sâu.

Sâu tạo thành một tập hợp con thích hợp của một loại phần mềm độc hại (hoặc phần mềm độc hại viết tắt) thường được gọi là virus máy tính, thuật ngữ bao trùm cho phần mềm độc hại tự sao chép thuộc bất kỳ loại nào.

Điều này có nghĩa là hầu hết các lỗi RCE, ít nhất là về mặt lý thuyết, sâu, nghĩa là chúng có khả năng bị khai thác để bắt đầu một chuỗi lây nhiễm phần mềm độc hại tự động, tự lây lan và tự duy trì.

Lý do ở đây rất rõ ràng: nếu một lỗi RCE cho phép bạn chạy một tùy ý chương trình do chính bạn lựa chọn trên máy tính của người khác, chẳng hạn như cửa sổ bật lên CALC.EXE hoặc tung ra NOTEPAD, thì nó gần như chắc chắn cho phép bạn chạy một riêng chương trình bạn chọn, chẳng hạn như một con sâu.

Một số lỗi dễ sâu hơn những lỗi khác

Như bạn có thể tưởng tượng, một số loại lỗi RCE được coi là dễ bị sâu hơn nhiều so với các loại lỗi khác, đặc biệt là các lỗi có thể được kích hoạt trực tiếp thông qua một tương tác mạng đơn giản.

Đó là nguy cơ đáng quan tâm trong thời gian gần đây. Câu chuyện về Log4Shell, trong đó một yêu cầu web bị mắc kẹt duy nhất với một số văn bản ASCII gây tò mò nhưng không thể loại trừ được trong đó có thể kích hoạt thực thi mã từ xa tùy ý.

Thật không may, CVE-2022-21907 là một lỗi trong cùng danh mục với Microsoft's bản tin bảo mật riêng nói rõ ràng như sau trong phần Câu hỏi thường gặp của nó:

*Kẻ tấn công có thể khai thác lỗ hổng này như thế nào?* Trong hầu hết các trường hợp, kẻ tấn công không được xác thực có thể gửi gói được chế tạo đặc biệt đến máy chủ được nhắm mục tiêu bằng cách sử dụng Ngăn xếp Giao thức HTTP (HTTP.sys) để xử lý gói. *Cái này có bị sâu không?* Đúng. Microsoft khuyên bạn nên ưu tiên vá các máy chủ bị ảnh hưởng.

Điều này có liên quan gì đến IIS không?

Ở đâu và như thế nào Ngăn xếp giao thức HTTP được kích hoạt?

Đây có phải là sự cố duy nhất đối với các máy chủ Windows, như bản tin của Microsoft ngụ ý khi nói về việc vá “các máy chủ bị ảnh hưởng” không?

Cuộc tấn công có phụ thuộc vào việc bạn có một máy chủ web đã biết như Microsoft IIS (Internet Information Services) đã được cài đặt và kích hoạt chưa?

Câu trả lời cho những câu hỏi này như sau:

• HTTP.sys là một phần của Windows và có sẵn cho bất kỳ chương trình nào sử dụng ASP.NET.
• HTTP.sys hoạt động trên máy khách Windows 7 và sau đó.
• HTTP.sys hoạt động trên máy chủ Windows 2008 R2 và sau đó.
• HTTP.sys không phải là một phần của IIS, và không yêu cầu cài đặt IIS.

Điểm cuối cùng ở trên cho thấy rõ rằng bạn có thể có bất kỳ số lượng ứng dụng nào đang được sử dụng – có thể bạn không nhận ra điều đó – cung cấp giao diện dựa trên HTTP thông qua HTTP.sys, cho dù bạn đã triển khai IIS hay chưa.

Trên thực tế, tài liệu riêng của Microsoft lưu ý rằng “HTTP.sys rất hữu ích […] khi cần đưa máy chủ trực tiếp ra Internet mà không cần sử dụng IIS.”

Thật vậy, IIS dựa trên HTTP.sys, không phải ngược lại, như Microsoft giải thích:

HTTP.sys là công nghệ trưởng thành giúp bảo vệ chống lại nhiều kiểu tấn công và mang đến sự mạnh mẽ, bảo mật và khả năng mở rộng của một máy chủ web đầy đủ tính năng. Bản thân IIS chạy dưới dạng trình nghe HTTP trên HTTP.sys.

Nói một cách đơn giản: về lý thuyết, bạn có thể cài đặt các ứng dụng, ngay cả trên máy tính để bàn hoặc máy tính xách tay, cung cấp một số loại giao diện dựa trên web được phục vụ bởi mã trình điều khiển HTTP.sys.

Lớp lót bạc, ít nhất đối với một số người dùng, là một phần của HTTP.sys chứa lỗi CVE-2022-21907:

• Chỉ ảnh hưởng đến Windows 10 trở lên các phiên bản máy tính để bàn.
• Chỉ ảnh hưởng đến Windows Server 2019 trở lên các phiên bản máy chủ.
• Không được bật theo mặc định trên Windows Server 2019.
• Có thể được miễn dịch chống lại lỗi này chỉ bằng cách cài đặt các bản cập nhật Bản vá Thứ Ba tháng 2022 năm XNUMX.

Theo những gì chúng tôi có thể biết, lý do lỗ hổng này không có trong các phiên bản trước của Windows và Windows Server là lỗi được tìm thấy trong mã liên quan đến Đoạn giới thiệu HTTP (chúng giống như Tiêu đề HTTP, ngoại trừ việc chúng được gửi sau dữ liệu HTTP thay vì trước nó); Hỗ trợ Đoạn giới thiệu HTTP chỉ được thêm vào sau khi hỗ trợ HTTP/2; và hỗ trợ HTTP/2 chỉ xuất hiện trong kỷ nguyên Windows 10.

Phải làm gì?

Nếu bạn thực sự không thể vá lỗi ngay lập tức và nếu bạn biết rằng bạn không chạy (hoặc ít nhất là không có ý định chạy) bất kỳ phần mềm dựa trên web nào sử dụng HTTP.sys, bạn có thể tạm thời chặn HTTP.sys trên máy tính của mình bằng cách đặt mục đăng ký sau:

HKLMSYSTEMCurrentControlSetServiceHTTPStart = DWORD(4)

Giá trị thông thường của mục đăng ký này là 3, biểu thị “bắt đầu theo yêu cầu”; thay đổi giá trị thành 4 đánh dấu trình điều khiển là “dịch vụ bị vô hiệu hóa”.

Sau khi khởi động lại, bạn có thể kiểm tra trạng thái của HTTP.sys từ dấu nhắc lệnh thông thường bằng lệnh SC Lệnh (Kiểm soát dịch vụ):

Truy vấn C:Usersduck> sc HTTP SERVICE_NAME: HTTP TYPE : 1 KERNEL_DRIVER TRẠNG THÁI : 1 STOPPED <--trước khi áp dụng hack registry ở trên, dòng này cho biết: "4 RUNNING" WIN32_EXIT_CODE : 1077 (0x435) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 C:Usersduck>

Lưu ý rằng chúng tôi chỉ thử nghiệm cách giải quyết này theo cách ngắn gọn nhất. Chúng tôi đã cài đặt Máy chủ 2022, bật IIS, tạo trang chủ và xác minh từ một máy tính khác rằng trang này hoạt động. Chúng tôi đã thay đổi giá trị bắt đầu dịch vụ cho HTTP thành 4, như được đề xuất ở trên và khởi động lại. Máy chủ IIS của chúng tôi không thể truy cập được nữa. Chúng tôi đã hoàn nguyên mục đăng ký thành 3, khởi động lại một lần nữa và xác minh rằng IIS đã tự động hoạt động trở lại. Từ đó, chúng tôi suy luận rằng việc vô hiệu hóa dịch vụ HTTP thực sự chặn quyền truy cập mạng dựa trên HTTP vào phần mềm cấp cao hơn mà có thể gặp phải lỗi này và chúng tôi cho rằng điều này khiến lỗ hổng tạm thời "không thể kích hoạt".

Khuyến nghị chính của chúng tôi là:

• Giả sử rằng tất cả các lỗ hổng RCE đều có thể bị sâu. Như đã đề cập, các lỗi có thể được kích hoạt trực tiếp thông qua các kết nối mạng thông thường cho đến nay có nguy cơ “bị nhiễm sâu” lớn nhất, nhưng về lý thuyết, bất kỳ lỗi nào cho phép thực thi mã từ xa tùy ý đều có thể cho phép thực thi mã sâu.
• Giả sử rằng tội phạm mạng đã tích cực đào sâu vào vấn đề này và tất cả các lỗ hổng RCE khác đã công bố Bản vá vào Thứ Ba này. Bạn có thể đã nghe câu chuyện cười về Thứ Ba Bản Vá được theo sau bởi Thứ Tư Khai Thác. Điều đó có phần đúng hơn, vì ngay cả các bản vá lỗi nguồn đóng cũng có thể bị xáo trộn ngược lại – thiết kế ngược, trong biệt ngữ – để tiết lộ các chi tiết bên trong của lỗi mà chúng ngăn chặn. (Và xem điểm 1.)
• Vá sớm, vá thường xuyên. Không sử dụng các giải pháp thay thế như một phần thông thường trong quy trình vá lỗi của bạn để câu thêm thời gian mỗi lần. Vá lỗi không được ưu tiên và giữ các giải pháp thay thế cho các tình huống mà bạn thực sự cần trì hoãn việc vá lỗi trong một thời gian. (Và xem điểm 1 và 2.)

Đừng trì hoãn… hãy làm ngay hôm nay!

TÌM HIỂU THÊM VỀ BẢNG MẪU THÁNG 2022 NĂM XNUMX