Sodin: угроза через MSP

В конце марта мы рассказывали об инциденте, в результате которого пострадали компании, пользующиеся услугами MSP-провайдера: в результате атаки на эту организацию в сетевую инфраструктуру его клиентов попал шифровальщик GandCrab. Тогда мы предположили, что этот случай вряд ли станет единичным — поставщики MSP-услуг слишком лакомый кусок для злоумышленников. И оказались правы.

В апреле мы обратили внимание на шифровальщик Sodin, который отличался от прочих тем, что для его распространения используются уязвимости в корпоративной Java-платформе Oracle WebLogic, а также бреши в защите инфраструктуры MSP-провайдеров. Оба варианта распространения крайне опасны: если обычно для запуска шифровальщика на машине жертвы требуется участие пользователя (например, чтобы открыть файл из письма), то в данном случае обходятся без него.

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

Методы распространения Sodin

В случае с WebLogic злоумышленники используют уязвимость десериализации (CVE-2019-2725) для выполнения PowerShell-команды на уязвимом сервере Oracle WebLogic. Это позволяет им загружать на сервер дроппер, устанавливающий затем полезную нагрузку в виде шифровальщика Sodin. Обновление для сервера было выпущено еще в апреле, однако в конце июня была обнаружена аналогичная уязвимость — CVE-2019-2729.

В случае с MSP-провайдерами Sodin попадает на машины пользователей разными путями. Пользователи как минимум трех MSP-провайдеров уже пострадали от этого шифровальщика. По информации портала DarkReading, в ряде случаев злоумышленники использовали для доставки трояна консоли удаленного доступа Webroot и Kaseya. В других случаях, о которых рассказывали на Reddit, злоумышленники проникали в инфраструктуру MSP, используя RDP-соединение, затем повышали привилегии, деактивировали защитные решения и бэкапы, после чего загружали на компьютеры клиентов шифровальщик.

Как быть MSP-провайдерам

Для начала — серьезно относиться к хранению паролей для удаленного доступа к чему бы то ни было, а по возможности использовать двухфакторную аутентификацию. Консоли и у Kaseya, и у Webroot поддерживают двухфакторную аутентификацию (после инцидента разработчики стали настаивать на ее обязательном использовании). Но, как показывает практика, распространяющие Sodin злоумышленники не просто используют подвернувшуюся возможность, а целенаправленно ищут различные методы эксплуатации MSP-провайдеров. Так что стоит внимательно относиться и к другим инструментам, применяемым в этой сфере. RDP-доступ, как мы не устаем повторять, должен использоваться только в крайнем случае.

Вообще MSP-провайдерам следует относиться к защите своей инфраструктуры не менее серьезно, чем к инфраструктуре клиентов. Особенно если вы предоставляете сервисы по обеспечению кибербезопасности. Вот что MSP-провайдерам может предложить «Лаборатория Касперского».

Как быть прочим компаниям

Разумеется, следует не забывать обновлять программное обеспечение — обидно, когда вредонос проникает в вашу инфраструктуру через уязвимости, обнаруженные и закрытые месяцы тому назад.

Компании, использующие Oracle WebLogic, должны в первую очередь ознакомиться с подробными описаниями обеих уязвимостей CVE-2019-2725 и CVE-2019-2729.

Ну и использовать надежные защитные решения, в которых работают подсистемы, способные выявлять шифровальщики и успешно защищать от них рабочие компьютеры.