В промышленных VPN нашли критические RCE-уязвимости

В промышленных VPN нашли критические RCE-уязвимости

В промышленных VPN нашли критические RCE-уязвимости

Критические уязвимости в VPN-сервисах для промышленных предприятий позволяют потенциальному атакующему перезаписывать данные, выполнять вредоносный код или команды, а также вызывать DoS.

Поскольку с приходом COVID-19 VPN-сервисы стали одной из главных мишеней для киберпреступников, к подобным уязвимостям стоит относиться серьёзно.

«Успешная эксплуатация этих брешей позволит злоумышленнику получить прямой доступ к промышленным устройствам. Подобные атаки могут нанести физический урон», — описывают проблему безопасности исследователи из Claroty.

 

Специалисты сознательно искали уязвимости в промышленных VPN-шлюзах, используемых для доступа и мониторинга критически важных объектов вроде программируемого логического контроллера или IO-устройств (input/output).

Среди уязвимых VPN исследователи выделили Secomea GateManager M2M, промышленные VPN-серверы от Moxa и HMS Networks eCatcher VPN. Самым проблемным оказалась реализация Secomea GateManager, в ней нашли следующие бреши:

  • CVE-2020-14500 — некорректная обработка заголовков HTTP-запросов. Для эксплуатации не нужна аутентификация, атакующий может выполнить вредоносный код и получить доступ к внутренней сети жертвы.
  • CVE-2020-14508 — эта уязвимость может привести к состоянию DoS. Кроме этого, её тоже можно использовать для удалённого выполнения кода.
  • CVE-2020-14510 — жёстко запрограммированные в коде учётные данные Telnet.
  • CVE-2020-14512 — слабое хеширование, способное выдать пользовательские пароли.

К счастью, все вышеописанные уязвимости уже получили свои патчи, однако специалисты уверены, что таких дыр ещё много — их ещё предстоит выявить.

Подпишитесь на новости

Claude Code удалил 116 ГБ и сообщил, что файлы выглядят нормально

Пользователь Windows сообщил, что Claude Code при уборке временных файлов удалил около 116 ГБ данных из его домашней директории. Затем агент заверил, что остановил команду и все выглядит целым. По описанию инцидента, удаление продолжалось еще примерно 50 минут.

В отчете на GitHub пользователь рассказывает, что работал над анализом для соревнования Kaggle.

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

Целью стала домашняя директория, указанная коротким именем Windows формата 8.3. Автор предполагает, что защитная проверка могла не распознать такой вариант пути. Точный механизм отказа защиты и режим разрешений остаются неизвестными.

Через 120 секунд задача автоматически перешла в фон. Агент запросил остановку и получил сообщение об успехе, однако, судя по описанным изменениям файловой системы, удаление продолжалось. Вероятное объяснение — дочерний процесс пережил остановку задачи.

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

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

Особенно неприятна в этой истории уверенность агента. Наличие папки еще не означает наличие файлов.

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