Yahoo! случайно опубликовала свой сертификат цифровой подписи

Yahoo! случайно опубликовала свой сертификат цифровой подписи

Сегодня Yahoo! выпустив новый обозреватель Axis опубликовала сертификат, который является цифровой подписью для продукции компания; обозреватель предназначен для iPhone и iPad. Однако есть версии программы, которые могут быть использованы в качестве плагинов для обозревателей Chrome, Firefox, Internet Explorer и Safari.

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

Как оказалось, в Yahoo! перед выпуском приложения не проверили продукт на наличие уязвимостей. В данном случае такой ошибкой стала невнимательность, благодаря которой вместе с версией плагина для обозревателя Chrome  был опубликован конфиденциальный сертификат. Такой сертификат обычно является своеобразной "визитной карточкой" компании, и во время установки приложение проходит соответствующую верификацию. В случае, если приложение не имеет цифровой подписи изготовителя, оно будет определено как поддельное.

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

По его мнению, наиболее простым способом получения доступа является уязвимый DNS, через который легитимная версия  Axis будет загружать обновления. Таким патчем может оказаться подписанная легитимным сертификатом вредоносная программа.

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

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

Уязвимость в 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, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

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