В Rackspace Cloud Office обнаружена брешь в системе безопасности
Тысячи малых и средних предприятий страдают из-за инцидента, связанного с безопасностью службы Rackspace Hosted Exchange.
Вчера, 2 декабря 2022 года, Rackspace объявила об отключении своего размещенного сервера Exchange:

Обновления последовали через день, но были немного расплывчаты:

Я вмешался в конце концов, так как я кое-что заметил и задокументировал это в этой теме:
В основном управляемая служба Rackspace использует имена хостов mex*.emailsrvr.com для Exchange и OWA:

А затем при просмотре самых последних данных Shodan стало ясно, что кластер Exchange показывает старые номера длинных сборок Exchange:

Этот номер сборки Exchange датирован августом 2022 года, до того, как стали доступны исправления ProxyNotShell:

Номера длинных сборок Exchange не всегда надежны… но об этом стоит помнить.
Я писал об уязвимости ProxyNotShell, которую назвал — извините, здесь: ProxyNotShell — история заявленных нулевых дней в Microsoft Exchange | Кевин Бомонт | ДаблПульсар
Рано утром Rackspace пояснила, что это инцидент с безопасностью:

Контекст угрозы
Теперь, возможно, взлом Rackspace произошел из-за других проблем, но в качестве общего напоминания я хотел бы предложить несколько ключевых моментов об угрозе:
- Предоставленные корпорацией Майкрософт средства защиты от ProxyNotShell можно обойти. IIS Rewrite, который Microsoft использовала для смягчения последствий, не правильно декодирует все URL-адреса, и поэтому его можно обойти для эксплуатации. Если вы полагались на средство защиты PowerShell или приложение EEMS, ваш Exchange Server по-прежнему уязвим — Microsoft просто не сообщила вам об этом внятно . Исправление заключается в патче.
- Хотя для этой уязвимости требуется проверка подлинности, эксплойты работают без многофакторной проверки подлинности, поскольку Exchange Server еще вообще не поддерживает современную проверку подлинности, поскольку Microsoft снизила приоритетность работы по реализации (описанной в другом блоге).
- Если вы являетесь MSP, работающим с общим кластером, таким как Hosted Exchange, это означает, что одна скомпрометированная учетная запись одного клиента скомпрометирует весь размещенный кластер. Это высокий риск.
- Очень важно, чтобы администраторы Exchange Server получили как последнее накопительное обновление , так и обновление безопасности для Exchange Server 2013/2016/2019.
- В случае с Exchange Server 2013 это CU23 Nov22SU, также известная как сборка 10.0.1497.44. Вы можете проверить номера своих сборок в Shodan, или администраторы Exchange могут использовать этот Powershell ниже. Двойная проверка .
$ExchangeServers = Get-ExchangeServer | Sort-Object Name
ForEach ($Server in $ExchangeServers) {
Invoke-Command -ComputerName $Server.Name -ScriptBlock { Get-Command Exsetup.exe | ForEach-Object { $_.FileversionInfo } }
}
Исправление Exchange Server чрезвычайно запутано, а в некоторых случаях рискованно — у скольких из нас, администраторов, случались сбои серверов? — и сбивает с толку. Microsoft нужно модернизировать его. Кроме того, Microsoft должна внедрить современную аутентификацию в Exchange Server — базовая аутентификация не годится в космическом 2022 году.
Я ожидаю, что атаки на организации через Microsoft Exchange продолжатся до 2023 года. И для тех, кто говорит: «Используйте Exchange Online, дураки!», по-прежнему есть некоторые проблемы: Федеральный орган по защите данных Германии и 17 государственных регуляторов (DSK) опубликовали отчет. в Microsoft 365 после двух лет работы с Microsoft и заявляют, что Microsoft 365 еще не соответствует GDPR, ссылаясь на широкий круг проблем .
В результате клиенты MS и инженеры MS остаются в такой ситуации: