Cách hack máy chủ Exchange chưa được vá bằng mã PowerShell lừa đảo

Dấu thời gian: 22:2022 chiều ngày 12 tháng 54 năm XNUMX
Nút nguồn: 1760191

by
Paul Ducklin

Chỉ chưa đầy hai tháng trước, một số tin tức về lỗi đáng lo ngại đã xuất hiện: một cặp lỗ hổng zero-day đã được công bố trong Microsoft Exchange.

Như chúng ta khuyên vào thời điểm đó, những lỗ hổng này, được chỉ định chính thức CVE-2022-41040 và CVE-2022-41082:

[là] hai zero-day [có thể] được xâu chuỗi lại với nhau, với lỗi đầu tiên được sử dụng từ xa để mở đủ lỗ hổng để kích hoạt lỗi thứ hai, lỗi này có khả năng cho phép thực thi mã từ xa (RCE) trên chính máy chủ Exchange.

Lỗ hổng đầu tiên gợi nhớ đến sự rắc rối và bị lạm dụng rộng rãi Lỗ hổng bảo mật ProxyShell từ hồi tháng 2021 năm XNUMX, vì nó dựa trên hành vi nguy hiểm trong tính năng Tự động phát hiện của Exchange, được mô tả bởi Microsoft như một giao thức đó là “được ứng dụng khách Outlook và EAS [Exchange ActiveSync] sử dụng để tìm và kết nối với hộp thư trong Exchange”.

May mắn thay, tính năng sai của Tự động phát hiện có thể bị khai thác trong cuộc tấn công ProxyShell bởi bất kỳ người dùng từ xa nào, dù đã đăng nhập hay chưa, là đã vá hơn một năm trước.

Thật không may, các bản vá ProxyShell đã không đủ để đóng khai thác đối với người dùng đã được xác thực, dẫn đến lỗi 2022 ngày CVE-40140-XNUMX mới. được mệnh danh là ProxyKhông Vỏ.

Không nguy hiểm bằng, nhưng vẫn nguy hiểm

Rõ ràng, ProxyNotShell không nguy hiểm bằng ProxyShell ban đầu, vì nó yêu cầu cái được gọi là quyền truy cập được xác thực, vì vậy nó không dễ bị lạm dụng bởi bất kỳ ai từ bất kỳ đâu.

Nhưng nó nhanh chóng xảy ra rằng trên nhiều máy chủ Exchange, việc biết tên đăng nhập và mật khẩu của bất kỳ người dùng nào cũng đủ để vượt qua trạng thái xác thực và thực hiện cuộc tấn công này, ngay cả khi bản thân người dùng đó cần sử dụng xác thực hai yếu tố (2FA) để đăng nhập đúng cách để truy cập email của họ.

Như chuyên gia Sophos Chester Wisniewski đặt nó vào thời điểm đó:

Đó là một “lỗ hổng xác thực giữa chừng”, nếu bạn muốn gọi nó như vậy. Đó là một phước lành hỗn hợp. Điều đó có nghĩa là một tập lệnh Python tự động không thể quét toàn bộ internet và có khả năng khai thác mọi máy chủ Exchange trên thế giới chỉ trong vài phút hoặc vài giờ, như chúng ta đã thấy với ProxyLogon và ProxyShell vào năm 2021. […]

Bạn cần một mật khẩu, nhưng thật không may, việc tìm một địa chỉ email và tổ hợp mật khẩu hợp lệ tại bất kỳ máy chủ Exchange cụ thể nào có lẽ không quá khó. Và bạn có thể chưa bị khai thác cho đến nay, vì để đăng nhập thành công vào Outlook Web Access [OWA] cần có mã thông báo FIDO hoặc trình xác thực của họ hoặc bất kỳ yếu tố thứ hai nào mà bạn có thể đang sử dụng.

Nhưng cuộc tấn công này không yêu cầu yếu tố thứ hai đó. […] Chỉ cần có được kết hợp tên người dùng và mật khẩu là một rào cản khá thấp.

Như bạn có thể nhớ, nhiều người trong chúng ta đã giả định (hoặc ít nhất là hy vọng) rằng Microsoft sẽ gấp rút sửa chữa các lỗ hổng ProxyNotShell, vì vẫn còn hai tuần nữa mới đến Bản vá thứ Ba của tháng XNUMX.

Nhưng chúng tôi đã thất vọng khi thấy rằng một bản sửa lỗi đáng tin cậy rõ ràng là phức tạp hơn mong đợivà tháng XNUMX đến rồi đi với ProxyNotShell chỉ được xử lý bằng các giải pháp thay thế chứ không phải bằng các bản vá thích hợp.

Ngay cả Bản vá thứ Ba của tháng XNUMX cũng không trực tiếp cung cấp các bản sửa lỗi cần thiết, mặc dù các bản vá tuy nhiên đã xuất hiện vào cùng ngày như một phần của bản cập nhật bảo mật dành riêng cho Exchange có thể được tìm nạp và cài đặt riêng:

Bằng chứng về khái niệm được tiết lộ

Bây giờ mọi chuyện đã lắng xuống và mọi người đã có thời gian để vá các máy chủ Exchange của họ (ít nhất là những máy chủ mà họ chưa quên), các nhà nghiên cứu tại Zero Day Initiative (ZDI), nơi những lỗ hổng này ban đầu được tiết lộ một cách có trách nhiệm để gửi tới Microsoft, đã giải thích làm thế nào các lỗi có thể được khai thác.

Tin xấu, tùy thuộc vào ý kiến ​​của bạn về các tiết lộ khai thác công khai, là nhóm ZDI hiện đã cung cấp một cách hiệu quả bằng chứng khái niệm (PoC) giải thích cách tấn công các máy chủ Exchange.

Tất nhiên, tin tốt là:

  • Bây giờ chúng ta có thể tự mình nghiên cứu và hiểu về các con bọ. Điều này không chỉ giúp tất cả chúng tôi đảm bảo rằng các biện pháp phòng ngừa tổng thể mà chúng tôi đã thực hiện (không chỉ giới hạn ở việc vá lỗi) có khả năng mang lại sự bảo vệ mà chúng tôi mong đợi, mà còn thông báo cho chúng tôi về các hoạt động lập trình mà chúng tôi sẽ muốn tránh trong tương lai, vì vậy chúng tôi không không bị mắc kẹt trong việc mở các lỗi thuộc loại này trong mã phía máy chủ của chúng tôi.
  • Bây giờ chúng tôi không còn lý do gì để không áp dụng các bản vá. Nếu chúng tôi chần chừ về việc cập nhật, lời giải thích của ZDI về lý do tại sao cuộc tấn công hoạt động cho thấy rõ rằng phương pháp chữa trị chắc chắn tốt hơn căn bệnh này.

Cách thức thực hiện

ZDI's giải thích về lỗ hổng này tạo nên một câu chuyện hấp dẫn về mức độ phức tạp của việc xâu chuỗi tất cả các phần bạn cần lại với nhau để biến một lỗ hổng thành một khai thác khả thi.

Nó cũng đáng đọc để giúp bạn hiểu tại sao việc đào sâu vào một khai thác hiện có có thể giúp tiết lộ những cách khác mà lỗ hổng bảo mật có thể bị lạm dụng, có khả năng thúc đẩy các bản vá bổ sung, thúc giục thay đổi cấu hình và thúc đẩy các phương pháp lập trình mới có thể không rõ ràng chỉ bằng cách sửa lỗi lỗ ban đầu.

Phần giải thích tất nhiên là phức tạp và khá kỹ thuật, đồng thời hướng dẫn bạn chuyển tiếp qua một loạt các bước dài để đạt được khả năng thực thi mã từ xa (RCE) ở phần cuối.

Với hy vọng giúp bạn theo dõi các chi tiết cấp cao dễ dàng hơn nếu bạn quyết định đọc báo cáo ZDI, đây là bản tóm tắt hy vọng không quá đơn giản hóa với các bước được liệt kê ngược lại…

…vì vậy bạn sẽ biết trước tại sao câu chuyện lại đi theo hướng như vậy:

  • BƯỚC 4. Đánh lừa Exchange từ xa để khởi tạo đối tượng .NET mà bạn chọn, với tham số khởi tạo do bạn chọn.

Trong mã hóa hiện đại, một đối tượng khởi tạo là từ biệt ngữ để chỉ một đoạn bộ nhớ được phân bổ, được khởi tạo tự động với dữ liệu và tài nguyên mà nó sẽ cần trong khi sử dụng và được gắn với một bộ chức năng cụ thể có thể hoạt động trên đó. (Khởi tạo chỉ là một từ ưa thích cho tạo.)

Các đối tượng có thể được quản lý và kiểm soát bởi chính hệ điều hành, để giúp tránh loại lỗi quản lý bộ nhớ sai phổ biến trong ngôn ngữ như C, nơi bạn thường cần tự cấp phát bộ nhớ, điền thủ công các trường dữ liệu có liên quan và nhớ giải phóng bộ nhớ và tài nguyên bạn đang sử dụng, chẳng hạn như ổ cắm mạng hoặc tệp đĩa, khi bạn hoàn tất.

Các đối tượng thường có một chức năng lập trình được liên kết với chúng được gọi là constructor, được thực thi tự động khi một đối tượng mới được tạo để phân bổ đúng dung lượng bộ nhớ và tập hợp đúng tài nguyên hệ thống.

Thông thường, bạn cần chuyển một hoặc nhiều tham số làm đối số cho hàm tạo, để biểu thị cách bạn muốn đối tượng được cấu hình khi nó bắt đầu.

Nói một cách đơn giản, nếu bạn khởi tạo, chẳng hạn, một TextString đối tượng (chúng tôi đang tạo ra những tên này, nhưng bạn hiểu ý) bằng cách sử dụng một tham số mà chính nó là một chuỗi văn bản, chẳng hạn như example.com:8888...

…bạn có thể sẽ kết thúc với một bộ nhớ đệm được phân bổ để giữ văn bản của bạn, được khởi tạo để nó giữ cùng một giá trị mà bạn đã nhập, cụ thể là văn bản thô example.com:8888.

Trong ngữ cảnh đó, chuỗi văn bản được truyền dưới dạng dữ liệu tới hàm tạo đối tượng không ngay lập tức gây ra bất kỳ mối đe dọa an ninh mạng rõ ràng nào khi bạn kích hoạt hàm tạo từ xa, ngoài khả năng từ chối dịch vụ (DoS) bằng cách liên tục yêu cầu các chuỗi ngày càng lớn hơn để cố gắng cạn kiệt bộ nhớ.

Nhưng nếu bạn khởi tạo, giả sử, một ConnectedTCPClient đối tượng sử dụng cùng một tham số chuỗi văn bản của example.com:8888, bạn có thể kết thúc với bộ nhớ đệm sẵn sàng chứa dữ liệu tạm thời, cùng với ổ cắm mạng được hệ điều hành cấp phát sẵn sàng trao đổi dữ liệu với máy chủ example.com qua cổng TCP 8888.

Bạn có thể thấy rủi ro thực thi mã từ xa ở đó, ngay cả khi bạn không bao giờ gửi bất kỳ dữ liệu nào đến ổ cắm mở, với điều kiện là bạn đã lừa máy chủ gọi về nhà đến một vị trí mà bạn kiểm soát.

Bạn thậm chí có thể tìm thấy một đối tượng được gọi là, chẳng hạn, RunCmdAndReadOutput, trong đó chuỗi văn bản bạn gửi dưới dạng tham số, theo đúng nghĩa đen, là lệnh bạn muốn chạy tự động ngay khi đối tượng được tạo, vì vậy bạn có thể thu thập đầu ra của nó sau.

Ngay cả khi bạn không bao giờ khôi phục được đầu ra của lệnh, tuy nhiên, việc khởi tạo một đối tượng như vậy sẽ cho phép bạn chọn một lệnh để chạy, do đó cung cấp cho bạn khả năng thực thi mã từ xa chung và đưa ra rủi ro chỉ bị giới hạn bởi quyền truy cập của chính quy trình máy chủ .

Tất nhiên, cuộc tấn công chỉ dễ dàng như vậy khi bạn đi đến giai đoạn cuối cùng, điều mà lẽ ra bạn không thể làm được, bởi vì Exchange có một danh sách cho phép nghiêm ngặt ngăn bạn chọn bất kỳ đối tượng cũ nào để khởi tạo.

Về lý thuyết, chỉ các đối tượng an toàn hoặc rủi ro thấp mới có thể được tạo từ xa thông qua PowerShell, do đó, việc khởi tạo các đối tượng tưởng tượng của chúng ta TextString ở trên, hoặc một SimpleIntegerValue, có thể được coi là chấp nhận được, trong khi một ConnectedTCPClient hoặc một RunCmdAndReadOutput chắc chắn sẽ không được.

Nhưng các nhà nghiên cứu của ZDI nhận thấy rằng trước khi kích hoạt bước cuối cùng, họ có thể làm điều này:

  • BƯỚC 3. Đánh lừa từ xa Exchange để họ nghĩ rằng một đối tượng có rủi ro thấp đã vượt qua bài kiểm tra an toàn trên thực tế là một số đối tượng khác mà bạn chọn.

Mặc dù vậy, bạn có thể mong đợi Exchange ngăn chặn việc tạo từ xa ngay cả đối tượng có rủi ro thấp, để giảm thiểu mối đe dọa hơn nữa.

Nhưng các nhà nghiên cứu nhận thấy rằng họ có thể:

  • BƯỚC 2. Đánh lừa Exchange từ xa bằng cách sử dụng Điều khiển từ xa PowerShell tính năng tạo đối tượng dựa trên các tham số khởi tạo được kiểm soát bên ngoài.

Và điều đó có thể xảy ra do lỗ hổng giống như ProxyShell chỉ được vá một phần:

  • BƯỚC 1. Đánh lừa Exchange từ xa chấp nhận và xử lý yêu cầu web có mã bằng cách đóng gói hợp lệ username:password trường vào yêu cầu là tốt.

Ngay cả khi người dùng có tên trong yêu cầu không thực sự đăng nhập và sẽ cần thực hiện một số loại quy trình 2FA để truy cập hộp thư của chính họ, thì kẻ tấn công biết họ username:password kết hợp sẽ có đủ thông tin xác thực để lừa Exchange chấp nhận kết nối web có thể được sử dụng để khởi động chuỗi tấn công được mô tả trong các bước từ 2 đến 4 ở trên.

Nói một cách lỏng lẻo, bất kỳ hợp lệ username:password kết hợp sẽ làm được, với điều kiện là "xác thực" chỉ cần thiết để ngăn Exchange từ chối yêu cầu HTTP trước.

Phải làm gì?

Lưu ý rằng cuộc tấn công này chỉ hoạt động:

  • Nếu bạn có máy chủ Exchange tại chỗ. Microsoft tuyên bố đã nhanh chóng khóa các dịch vụ đám mây của riêng mình, vì vậy Exchange Online không bị ảnh hưởng. Hãy chắc chắn rằng bạn biết máy chủ Exchange của bạn ở đâu. Ngay cả khi bạn hiện đang sử dụng Exchange Online, bạn vẫn có thể có các máy chủ tại chỗ đang chạy, có thể còn sót lại do nhầm lẫn trong quá trình di chuyển của bạn.
  • Nếu máy chủ của bạn chưa được vá. Hãy chắc chắn rằng bạn có đã áp dụng Bản cập nhật phần mềm Exchange 2022-11-08 đến đóng các lỗ hổng mà khai thác yêu cầu.
  • Nếu máy chủ của bạn vẫn chấp nhận Xác thực cơ bản, còn được gọi là xác thực kế thừa. Hãy chắc chắn rằng bạn có chặn tất cả các khía cạnh của xác thực kế thừa vì vậy máy chủ của bạn sẽ không chấp nhận username:password các tiêu đề được đề cập ở trên và sẽ không chấp nhận các yêu cầu giao thức Tự động phát hiện đầy rủi ro ngay từ đầu. Đây ngăn chặn những kẻ tấn công lừa một máy chủ chấp nhận các thủ thuật khởi tạo đối tượng bị mắc bẫy của họ, ngay cả khi máy chủ đó chưa được vá lỗi.

Bạn có thể theo dõi về lời khuyên phòng ngừa, khắc phục và phản hồi chính thức của chúng tôi và khách hàng của Sophos có thể theo dõi các tên phát hiện mối đe dọa được sử dụng bởi các sản phẩm của chúng tôi, thông qua nguồn cấp dữ liệu Twitter của Sophos X-Ops (@SophosXOps).

TÌM HIỂU THÊM VỀ XÁC THỰC EXCHANGE VÀ OAUTH2

Nhấp và kéo vào các sóng âm thanh bên dưới để chuyển đến bất kỳ điểm nào. Bạn cũng có thể nghe trực tiếp trên Soundcloud.

Với Paul Ducklin và Chester Wisniewski
Nhạc giới thiệu và kết thúc bởi Edith Mudge.

Dấu thời gian:

Thêm từ An ninh trần trụi