MOVEit Transfer CVE-2023-34362: SQL-инъекция, которую Cl0p превратила в конвейер

Начало июня 2023-го оказалось довольно показательным: группа Cl0p применила SQL-инъекцию в Progress Software MOVEit Transfer и за несколько дней добралась до файлов сотен организаций - от американских госструктур до европейских банков. Патч вышел 31 мая, но к тому моменту часть атак уже состоялась. Мы внутри команды немедленно задались вопросом: что из похожего стоит на периметре у наших клиентов?

Как работала уязвимость

CVE-2023-34362 - классическая SQL-инъекция в веб-приложении, которое доступно из интернета. MOVEit Transfer предоставляет HTTPS-интерфейс для управляемой передачи файлов (MFT), и именно там обнаружился уязвимый параметр. Злоумышленник без аутентификации мог передать в запросе специально сформированную строку, которая выполнялась как SQL в базе данных приложения (Microsoft SQL Server или MySQL в зависимости от конфигурации).

Через эту дыру атакующий:

• читал содержимое хранилища - файлы, загруженные пользователями и уже переданные получателям;
• создавал административные сессии - за счёт вставки данных в таблицы сессий;
• закладывал веб-шелл - Progress назвал его LEMURLOOT, он писался на ASPX и позволял выполнять команды на уровне ОС.

Всё это без единого пароля, просто HTTP-запросы. Именно поэтому Cl0p смогла автоматизировать атаку и пройтись по тысячам открытых инстансов.

Что мы нашли у клиентов

Когда в начале июня появились первые публичные отчёты (Mandiant, Rapid7, GreyNoise фиксировали массовый сканинг), мы начали инвентаризацию по своей клиентской базе. Задача была простой: найти всё, что торчит наружу и относится к категории MFT или похожих file-transfer шлюзов.

MOVEit Transfer ни у кого из наших клиентов не стоял - продукт специфический, популярен больше в западных enterprise-организациях. Но это не повод расслабляться: сам класс продуктов оказался шире, чем мы думали.

У нескольких клиентов нашлись:

• корпоративные FTP/SFTP-шлюзы с самописными веб-интерфейсами, доступными по HTTP из интернета - никакого WAF, иногда без актуальных патчей;
• Nextcloud и аналоги на виртуалках, поднятых «временно для обмена файлами с подрядчиком» и забытых;
• DMZ-серверы под Windows Server 2016 с IIS и самописным ASP.NET-приложением для партнёрского обмена данными.

Ни один из них не оказался уязвим к CVE-2023-34362 буквально, но все они относятся к одному классу риска: публично доступный веб-интерфейс, который работает с файлами, предположительно содержащими чувствительные данные, и при этом не получает того же внимания, что, например, корпоративный почтовый шлюз.

Чек-лист аудита управляемых файловых систем

По итогам проверки мы собрали список вопросов, который теперь задаём при аудите защищённости периметра.

Инвентаризация:

• Есть ли реестр всех систем передачи файлов - MFT, FTP-шлюзы, self-hosted файловые порталы?
• Кто ставил и кто сейчас отвечает за каждую из них?
• Какие из них доступны из интернета без VPN?

Аутентификация и доступ:

• Есть ли MFA на внешних интерфейсах?
• Используются ли сервисные учётки с фиксированными паролями, которые не менялись более года?
• Есть ли список авторизованных IP для административного интерфейса?

Патчинг:

• Когда последний раз обновлялось само MFT-приложение и его зависимости?
• Отслеживает ли кто-то CVE для этих продуктов - или «само работает, не трогаем»?

Мониторинг:

• Логируются ли запросы к веб-интерфейсу и попадают ли эти логи в SIEM?
• Есть ли алерт на аномальное количество скачиваний или обращений с новых IP?

Данные:

• Какие категории данных проходят через шлюз?
• Есть ли срок хранения - или файлы лежат бессрочно?

Последний пункт про данные оказался самым неудобным в разговорах с клиентами. В нескольких случаях выяснилось, что на FTP-шлюзе лежат архивы трёхлетней давности, которые «надо было удалить, но не дошли руки». При утечке именно эта история превращает инцидент из «кто-то скачал текущие файлы» в «кто-то скачал три года истории».

Про Cl0p и мотивацию атакующих

Cl0p не зашифровала данные - она их украла и стала шантажировать жертв публикацией. Это стало заметной тенденцией в ransomware последних полутора лет: зачем тратить время на развёртывание шифровальщика, если данных достаточно для вымогательства? MFT-системы идеальны для такого сценария: там по определению лежат файлы, которые кто-то считает достаточно важными, чтобы передавать защищёно.

Именно поэтому класс MFT-решений оказался привлекательной целью. В начале того же года та же Cl0p атаковала GoAnywhere MFT через CVE-2023-0669. Паттерн повторяется: найти массово установленный MFT-продукт, найти в нём критическую уязвимость, пройтись автоматически по всем открытым инстансам.

Где мы сейчас

По клиентам, где нашлись проблемные объекты, провели точечные работы: убрали прямой доступ из интернета там, где он был не нужен, настроили алерты по логам, в одном случае помогли с составлением регламента удаления файлов старше 90 дней.

MOVEit Transfer ни у кого не стоит, и это хорошо. Но инвентаризация показала то, что обычно и показывает: периметр живёт своей жизнью, и file-transfer шлюзы - ровно тот класс объектов, про который все знают что он есть, но никто не помнит зачем и в каком состоянии. OpenSSL-история в ноябре была про серверы-призраки в CMDB. Здесь - про шлюзы-призраки на периметре. Одна и та же проблема, другой вектор.

Progress Software выпустила несколько патчей волной - 31 мая, 9 июня, 15 июня - закрывая дополнительно найденные векторы. Если у кого-то стоит MOVEit Transfer и ещё не обновлён: это нужно было сделать вчера.