Шифровальщик Cring проникает в сети через уязвимость в Fortigate VPN

Шифровальщик Cring проникает в сети через уязвимость в Fortigate VPN

Шифровальщик Cring проникает в сети через уязвимость в Fortigate VPN

Команда Kaspersky ICS CERT опубликовала результаты расследования инцидента с участием вымогательской программы Cring. Как оказалось, для проникновения в сеть авторы атаки использовали известную уязвимость в VPN-серверах FortiGate.

Шифровальщик Cring появился на интернет-арене в конце 2020 года. В новом году злоумышленники провели серию атак с его использованием, от которых в числе прочих пострадали европейские промышленные предприятия.

Уязвимость CVE-2018-13379 в продуктах линейки FortiGate производства Fortinet открывает возможность для выхода за пределы каталога ресурса. Эксплойт позволяет удаленно и без авторизации получить аутентификационные данные для доступа по VPN — они содержатся в открытом виде в файле сеанса sslvpn_websession.

Патч для CVE-2018-13379 вышел в мае 2019 года, и с тех пор Fortinet неоднократно призывала пользователей его установить, предупреждая о возможности атак, в том числе со стороны APT-групп.

Разбор нападения Cring, проведенный специалистами «Лаборатории Касперского», показал, что злоумышленники вначале проверили VPN-шлюз на уязвимость, а затем уже проникли в сеть посредством эксплойта. С этой целью они могли провести сканирование блока IP-адресов либо просто купить готовый список уязвимых устройств FortiGate в даркнете.

Оказавшись в целевой сети, авторы атаки пустили в ход утилиту Mimikatz и с ее помощью заполучили логин и пароль администратора домена. Доступ к привилегированному аккаунту позволил им запустить на избранных машинах вредоносный PowerShell-скрипт для установки бэкдора Cobalt Strike Beacon. Его командный сервер был поднят в сетях американского хостинг-провайдера ColoCrossing.

Получив контроль над зараженной системой, злоумышленники загружали в нее cmd-скрипт, который запускал PowerShell с именем «kaspersky» и инициировал, таким образом, загрузку Cring. Активация зловреда производилась вручную.

Прежде чем приступить к шифрованию, Cring останавливает службы программ Veritas NetBackup и Microsoft SQL Server, а также службу SstpSvc, используемую для создания VPN подключений. Он также завершает процессы приложений Microsoft Office (mspub.exe) и Oracle Database (mydesktopqos.exe и mydesktopservice.exe), чтобы беспрепятственно шифровать соответствующие файлы данных.

Для удаления резервных копий, из которых можно было бы восстановить зашифрованную информацию, на диске создается cmd-скрипт kill.bat, который после исполнения удаляет сам себя.

Шифрование выполняется с использованием алгоритма AES; ключ при этом шифруется вшитым в код открытым ключом RSA длиной 8192-бит. Список файлов, подлежащих преобразованию, включает документы Microsoft Office, архивные файлы, файлы баз данных dBASE, резервные копии, созданные утилитой Microsoft Windows Backup, веб-страницы ASP.NET, PHP и Java, а также виртуальные диски. После выполнения основной задачи Cring создает RTF-файл с требованием выкупа — за возврат данных злоумышленники просят 2 биткоина, указывая два email-адреса для связи.

 

Аналитики не преминули отметить высокий уровень подготовки целевой атаки. В ходе разведки злоумышленники хорошо изучили целевую инфраструктуру, что обеспечило правильный выбор инструментов и тактики. Об этом говорит, например, способ маскировки вымогательской программы — ее выдали за защитное решение, используемое на предприятии (Kaspersky). В пользу такого вывода свидетельствует также выбор серверов для шифрования: потеря доступа к ним может вызвать сбой технологического процесса предприятия.

Успеху атаки в данном случае, по мнению экспертов, способствовали следующие обстоятельства:

  • использование устаревшей и уязвимой версии прошивки VPN сервера Fortigate (6.0.2);
  • отсутствие своевременного обновления антивирусных баз используемого защитного решения, в котором к тому же на момент атаки были отключены некоторые компоненты;
  • слабые настройки прав доступа в доменных политиках и доступа по RDP.

Представители Fortinet уже отреагировали на новость официальным заявлением:

«Безопасность клиентов – наш главный приоритет. Например, CVE-2018-13379 – это старая уязвимость, устранённая еще в мае 2019 года. Компания Fortinet немедленно выпустила рекомендации PSIRT и неоднократно коммуницировала с клиентами через статьи в корпоративном блоге, настоятельно рекомендуя устанавливать обновления, – в августе 2019 года, июле 2020 года, а также в апреле 2021 года».

«После решения проблемы мы постоянно общались с клиентами, в том числе и совсем недавно – в апреле 2021 года. Чтобы получить дополнительную информацию, посетите наш блог и незамедлительно обратитесь к рекомендациям от мая 2019 года. Мы настоятельно рекомендуем клиентам немедленно установить обновления и внедрить меры по снижению рисков, если это еще не было сделано».

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Роботы-официанты и курьеры оказались под угрозой удалённого взлома

Исследователь под ником BobDaHacker обнаружил серьёзную брешь в API управления роботами Pudu Robotics. Ошибка была настолько простой, что даже человек с минимальными техническими знаниями мог «угнать» любого робота — от официанта BellaBot в ресторане до робота-доставщика лекарств в больнице.

Проблема заключалась в том, что API требовал токены, но при этом не проверял права пользователя и «владение» устройством.

В итоге можно было смотреть историю вызовов, менять настройки, перенаправлять задания или даже заставить роботов крутиться по кругу.

 

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

Но в больнице или офисе последствия могли быть куда серьёзнее — от срыва доставки лекарств до кражи документов с охраняемых этажей.

BobDaHacker сообщил о проблеме ещё 12 августа, но Pudu Robotics игнорировала обращения почти три недели. Лишь после того как исследователь напрямую предупредил крупных клиентов вроде японских ресторанных сетей Skylark и Zensho, компания наконец «обнаружила» уязвимость и выпустила заплатку.

Реакция производителя вызвала не меньше вопросов, чем сама дыра. У Pudu не оказалось ни выделенного контакта для безопасности, ни прозрачного процесса обработки сообщений о проблемах. Ответ пришёл в виде шаблонного письма, где даже не удалили плейсхолдер «[Your Email Address]».

История показывает: красивые слова о «приверженности безопасности» на сайте мало что значат без реальных мер. Когда роботы обслуживают рестораны, отели, школы и особенно больницы, сбои в их работе могут обернуться не только испорченным ужином, но и угрозой для здоровья и безопасности.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

RSS: Новости на портале Anti-Malware.ru