Rackspace Cloud Office bị vi phạm an ninh

Dec 03 2022
Hàng nghìn doanh nghiệp vừa và nhỏ đang gặp khó khăn khi Rackspace gặp sự cố bảo mật trên dịch vụ Hosted Exchange của họ. Hôm qua, ngày 2 tháng 12 năm 2022, Rackspace đã thông báo ngừng hoạt động đối với Máy chủ Exchange được lưu trữ của họ: Đã cập nhật trong ngày, nhưng hơi mơ hồ: Cuối cùng, tôi đã tham gia, khi tôi nhận thấy điều gì đó và ghi lại nó trong chủ đề này: Chủ yếu là do Rackspace quản lý dịch vụ sử dụng tên máy chủ mex*.

Hàng nghìn doanh nghiệp vừa và nhỏ đang gặp khó khăn khi Rackspace gặp sự cố bảo mật trên dịch vụ Hosted Exchange của họ.

Hôm qua, ngày 2 tháng 12 năm 2022, Rackspace đã thông báo về việc Máy chủ Exchange được lưu trữ của họ ngừng hoạt động:

Cập nhật tiếp theo trong ngày, nhưng hơi mơ hồ:

Cuối cùng thì tôi cũng tham gia, khi tôi nhận thấy một điều gì đó và ghi lại nó trong chủ đề này:

Chủ yếu tại dịch vụ được quản lý của Rackspace sử dụng tên máy chủ mex*.emailsrvr.com cho Exchange và OWA:

Và sau đó khi xem xét dữ liệu Shodan gần đây nhất, rõ ràng là cụm Exchange đang hiển thị các số bản dựng dài của Exchange đã cũ:

Số bản dựng Exchange này là từ tháng 8 năm 2022, trước khi có các bản vá ProxyNotShell:

Trao đổi số bản dựng dài không phải lúc nào cũng đáng tin cậy… nhưng đó là một dấu hiệu đáng lưu ý.

Tôi đã viết về ProxyNotShell, một lỗ hổng mà tôi đã đặt tên — xin lỗi, ở đây: ProxyNotShell — câu chuyện về những ngày không được xác nhận trong Microsoft Exchange | của Kevin Beaumont | sao xung đôi

Sáng sớm hôm nay, Rackspace đã làm rõ đây là một sự cố bảo mật:

Bối cảnh mối đe dọa

Bây giờ, có thể vi phạm Rackspace đã xảy ra do các vấn đề khác — nhưng như một lời nhắc chung, tôi sẽ đề xuất một số điểm chính về mối đe dọa:

  • Có thể bỏ qua các biện pháp giảm thiểu do Microsoft cung cấp cho ProxyNotShell. IIS Rewrite, mà Microsoft đã sử dụng để giảm nhẹ, không giải mã chính xác tất cả các URL và do đó có thể bị bỏ qua để khai thác. Nếu bạn dựa vào ứng dụng giảm thiểu PowerShell hoặc EEMS, Exchange Server của bạn vẫn dễ bị tấn công — Microsoft chỉ chưa thông báo rõ ràng cho bạn điều này . Cách khắc phục là vá.
  • Mặc dù lỗ hổng cần xác thực, nhưng việc khai thác hoạt động mà không cần xác thực đa yếu tố vì Exchange Server hoàn toàn không hỗ trợ Xác thực hiện đại, vì Microsoft đã loại bỏ công việc triển khai (được đề cập trong blog khác).
  • Nếu bạn là một MSP đang chạy một cụm được chia sẻ, chẳng hạn như Hosted Exchange, điều đó có nghĩa là một tài khoản bị xâm phạm trên một khách hàng sẽ khiến toàn bộ cụm được lưu trữ bị xâm phạm. Đây là rủi ro cao.
  • Điều rất quan trọng là quản trị viên Exchange Server có được cả Bản cập nhật tích lũy Bản cập nhật bảo mật mới nhất cho Exchange Server 2013/2016/2019.
  • Trong trường hợp của Exchange Server 2013, đây là CU23 Nov22SU hay còn gọi là bản dựng 10.0.1497.44. Bạn có thể kiểm tra số bản dựng của mình từ Shodan hoặc quản trị viên Exchange có thể sử dụng Powershell này bên dưới. Kiểm tra lại .
  • $ExchangeServers = Get-ExchangeServer | Sort-Object Name
    ForEach ($Server in $ExchangeServers) {
        Invoke-Command -ComputerName $Server.Name -ScriptBlock { Get-Command Exsetup.exe | ForEach-Object { $_.FileversionInfo } }
    }
    

  • Nếu bạn sử dụng Quản lý lỗ hổng của Bộ bảo vệ Microsoft, hãy kiểm tra số bản dựng trong sản phẩm thay vì dựa vào các lỗ hổng đã xác định (bạn sẽ nhận thấy lý do).
  • Nếu bạn thuê ngoài quản lý Microsoft Exchange và bạn có tài nguyên, bạn nên yêu cầu bằng chứng rằng mỗi máy chủ được vá cho mỗi bản cập nhật. Tôi nhận ra rằng hầu hết các tổ chức thuê ngoài sẽ không có tài nguyên này.
  • Bạn nên quét các Máy chủ Exchange của mình, nếu cụ thể là bạn đã trình bày OWA trên internet, để tìm webshells (các cửa hậu dành cho lần sau) và các dấu hiệu của hoạt động thỏa hiệp sau đó. Cách dễ nhất để thực hiện việc này là chạy Microsoft Safety Scanner và Sophos Scan & Clean , là các công cụ quét một lần, để tự động quét và dọn dẹp hệ thống.

Bản vá Exchange Server cực kỳ phức tạp, trong một số trường hợp có rủi ro — bao nhiêu quản trị viên của chúng tôi đã gặp sự cố máy chủ? - và khó hiểu. Microsoft cần phải hiện đại hóa nó. Ngoài ra, Xác thực hiện đại cần triển khai trong Exchange Server của Microsoft — xác thực cơ bản không ổn trong năm không gian 2022.

Tôi cho rằng các tổ chức thông qua Microsoft Exchange sẽ tiếp tục bị tấn công cho đến năm 2023. Và đối với những người nói rằng 'hãy sử dụng Exchange Online, đồ ngốc!', vẫn còn một số thách thức xung quanh vấn đề đó: Cơ quan bảo vệ dữ liệu liên bang của Đức và 17 cơ quan quản lý nhà nước (DSK) đã công bố một báo cáo vào Microsoft 365 sau hai năm làm việc với Microsoft và tuyên bố rằng Microsoft 365 chưa đáp ứng GDPR do nhiều vấn đề .

Kết quả là các khách hàng của MS và các kỹ sư của MS bị bỏ lại trong tình huống này: