Уязвимость в OpenSSH: имена пользователей позволяют выполнить код

Уязвимость в OpenSSH: имена пользователей позволяют выполнить код

Уязвимость в OpenSSH: имена пользователей позволяют выполнить код

Исследователь безопасности Дэвид Лидбитер обнаружил уязвимость в OpenSSH — CVE-2025-61984 — которая демонстрирует: даже мелкие особенности парсинга команд и поведения shell могут привести к удалённому выполнению кода.

Суть проблемы проста и неприятна: в OpenSSH (до версии 10.1) контрол-символы в именах пользователей, полученных из ненадёжных источников, могли не отфильтровываться.

Когда такое «имя» подставлялось в ProxyCommand (через переменную %r), OpenSSH формировал строку для exec, которую запускал через shell. Если в этой строке оказывались символы вроде $[ и символы новой строки, некоторые оболочки (например, bash) могли интерпретировать это так, что первая команда аварийно завершается, а затем выполняется то, что идёт после — то есть возможна инъекция команды.

Эксплуатация требует специфической связки: конфигурация, использующая ProxyCommand с %r, уязвимая оболочка и «входной» источник имени пользователя, который злоумышленник контролирует. Практический пример — злоумышленный .gitmodules, где в URL подставляют строку вроде:

[submodule "foo"]
  path = foo
  url = "$[+]\nsource poc.sh\n@foo.example.com:foo"

Если SSH-конфиг содержит строку вроде

ProxyCommand some-command %r@%h:%p

и вы запускаете git clone --recursive, то в подходящих условиях может выполниться source poc.sh — до установления самого соединения.

Важно понимать: условия для успешной атаки нишевые, но реальны — инструментальная цепочка Git → SSH → shell и автоматизация (CI/CD) дают атакующему много точек входа. Проблема усугубляется тем, что OpenSSH фильтровал многие метасимволы, но пропустил $ и [ — и это создало неожиданный вектор.

Исправление уже включено в OpenSSH 10.1: разработчики начали проверять и запрещать управляющие символы в именах пользователей через iscntrl() в ssh.c. То есть долгосрочное решение — обновиться до 10.1 или новее.

Если обновиться сразу нельзя, Лидбитер предлагает два практических временных шага. Во-первых, брать имя пользователя в одинарные кавычки в ProxyCommand, чтобы предотвратить подстановку:

ProxyCommand some-command '%r@%h:%p'

(Обратите внимание: одинарные кавычки нужны именно потому, что двойные не защитят от $[ — оболочка всё ещё будет их обрабатывать.) Во-вторых, по умолчанию отключить SSH-подмодули в Git и не позволять автоматические URL-хендлеры, которые могут передавать непроверенные SSH-команды:

git config --global protocol.ssh.allow user

Главный вывод — не полагаться на то, что «маленький» символ или строка не принесут беды: при передаче входа от ненадёжных источников через несколько инструментов даже неочевидная каверза в парсинге может стать критической. Рекомендуется как можно скорее обновить OpenSSH или применить временные защитные меры в конфигурациях ProxyCommand и политиках Git.

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

Каждая вторая компания в Москве увольняла сотрудников после ИБ-инцидентов

Компания «СёрчИнформ» опубликовала исследование о том, как московские организации пережили 2025 год в части информационной безопасности. В опросе участвовали 125 специалистов ИБ из разных компаний — от госсектора до коммерческих структур. Главная цифра, которая сразу бросается в глаза: 59% московских компаний сталкивались с ИБ-инцидентами по вине сотрудников.

И, что важно, в 62% случаев нарушение произошло ненамеренно — обычные ошибки, невнимательность, неправильная работа с документами.

Эксперты считают, что это показатель недостаточной осведомлённости сотрудников и нехватки обучения.

Замгендиректора «СёрчИнформ» Алексей Парфентьев отмечает: случайные инциденты всегда преобладают, потому что даже люди, знающие базовые правила, могут допускать ошибки.

 

Поэтому ИБ-службам стоит не только внедрять защитные системы, но и помогать сотрудникам понимать, как правильно работать с конфиденциальными данными.

Какие инциденты случались чаще всего

В 2025 году компании фиксировали:

  • утечки данных — 47%
  • внешние атаки через сотрудников — 17%
  • откаты и взяточничество — 14%
  • стороннюю занятость/«боковики» — 12%
  • промышленный шпионаж — 11%
  • дискредитацию компании — 11%

Чаще всего злоумышленники пытались «слить»:

  • персональные данные — 56%
  • внутренние регламенты — 48%
  • данные о клиентах и сделках — 35%
  • финансовые документы — 24%
  • техническую информацию — 19%

Через какие каналы утекала информация

Лидеры здесь вполне ожидаемы:

  • почта — 63%,
  • мессенджеры — 59%,
  • облачные сервисы — 38%,
  • флешки и другие носители — 32%.

Интересно, что ИИ-сервисы пока не стали массовым каналом утечек — о таких случаях заявили лишь 6% компаний.

Кто становился виновником утечек

Чаще всего — обычные сотрудники: их упомянули 72% компаний. Далее идут:

  • линейные руководители — 30%,
  • руководители направлений — 22%,
  • топ-менеджеры — 15%,
  • внештатные специалисты — 12%,
  • контрагенты — 10%.

Как компании наказывают нарушителей

Большинство обходятся предупреждением или выговором — так делают 75% компаний. Но 52% организаций увольняли сотрудников, ставших причиной инцидента. До суда дело доходило в 10% случаев. А 9% работодателей нарушителей никак не наказывали.

 

Кто обнаруживает инциденты

  • ИБ- или ИТ-службы — 83%,
  • сотрудники других подразделений — 32%,
  • контрагенты — 9%.

Исследование проводится ежегодно в рамках Road Show SearchInform, и 2025 год в очередной раз показал: человеческий фактор остаётся главной причиной ИБ-инцидентов, а компании — даже при развитой технической защите — всё ещё нуждаются в системном обучении персонала.

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

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