В менеджере паролей LastPass снова нашли серьезную уязвимость

В менеджере паролей LastPass снова нашли серьезную уязвимость

В менеджере паролей LastPass снова нашли серьезную уязвимость

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

Теперь независимый исследователь Шон Кессиди (Sean Cassidy) обнаружил, что LastPass уязвим перед простейшими фишинговыми атаками, из-за которых мастер-пароль пользователя может быть скомпрометирован.

Кессиди заметил, что если сессия LastPass истекает, пока пользователь бродит в интернете, менеджер выводит соответственное предупреждение, встраивая его прямо в контент веб-страницы. Окно ввода логина и пароля, а так же кода двухфакторной аутентификации, если она включена, отображаются аналогичным образом. С точки зрения безопасности, это огромный просчет: подобное решение делает пользователей уязвимыми перед различными веб-инъекциями, — от таких хитрых фишинговых атак часто страдают пользователи онлайн-банков.

 

 

Исследователь создал инструмент, при помощи которого можно автоматизировать простейшую фишинговую атаку и собирать пароли пользователей LastPass (как от самой программы, так и содержащиеся внутри хранилища). Тулзу Кессиди иронично назвал LostPass.

Единственное, что нужно будет сделать атакующему – заманить жертву на легитимный сайт, содержащий XSS-уязвимость. LostPass использует уязвимость сайта, чтобы обнаружить на компьютере жертвы установку LastPass, разлогинит её, применив известный CSRF-баг, а затем отобразит фальшивое уведомление о том, что требуется заново ввести логин и пароль. Учетные данные жертвы попадут в руки злоумышленника, как только доверчивый пользователь повторно введет их в фальшивом окне, пишет xakep.ru.

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

Кессиди пишет, что пока атака работает только против пользователей браузера Chrome. Плюс злоумышленники могут зарегистрировать домен вида chrome-extensions.pw, который похож на настоящий центр управления расширениями в браузере Google. Firefox и прочие браузеры используют другой механизм для вывода всплывающих уведомлений LastPass. Впрочем, исследователь работает над «поддержкой» Firefox для своего инструмента.

Разработчики менеджера паролей уже знают о проблеме. Кессиди связался с ними в ноябре 2015 года. Ознакомившись с его изысканиями, компания сделала вывод, что «это не уязвимость, а фишинговая атака». Тем не менее, разработчики попытались переделать механизм вывода уведомлений об истекшей сессии. Согласно отчету Кессиди, безрезультатно – новая методика по-прежнему базируется на веб-инъекциях, а пользователи уязвимы для атак.

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

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

История с первой CVE для Rust-кода в ядре Linux, которая недавно привела к падениям системы, выглядела почти как повод для оптимизма. В тот же день для кода на C зарегистрировали ещё 159 CVE — контраст показательный. Но новое исследование напоминает: проблема не только в языках программирования.

Гораздо тревожнее первой Linux-дыры в коде на Rust тот факт, что многие ошибки в ядре Linux могут годами, а иногда и десятилетиями оставаться незамеченными.

Исследовательница Дженни Гуанни Ку из компании Pebblebed проанализировала 125 183 бага за почти 20 лет развития ядра Linux — и результаты оказались, мягко говоря, неожиданными.

 

По данным исследования, средний баг в ядре Linux обнаруживают через 2,1 года после его появления. Но это ещё не предел. Самый «долгоиграющий» дефект — переполнение буфера в сетевом коде — прожил в ядре 20,7 года, прежде чем на него обратили внимание.

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

Исследование опирается на тег Fixes:, который используется в разработке ядра Linux. Когда разработчик исправляет ошибку, он указывает коммит, в котором баг был добавлен. Дженни написала инструмент, который прошёлся по git-истории ядра с 2005 года, сопоставил такие пары коммитов и вычислил, сколько времени баг оставался незамеченным.

В датасет вошли данные до версии Linux 6.19-rc3, охватывающие период с апреля 2005 по январь 2026 года. Всего — почти 120 тысяч уникальных исправлений от более чем 9 тысяч разработчиков.

Оказалось, что скорость обнаружения ошибок сильно зависит от подсистемы ядра:

  • CAN-драйверы — в среднем 4,2 года до обнаружения бага;
  • SCTP-стек — около 4 лет;
  • GPU-код — 1,4 года;
  • BPF — всего 1,1 года.

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

Отдельная проблема — неполные фиксы. Исследование показывает, что нередко разработчики закрывают проблему лишь частично. Например, в 2024 году был выпущен патч для проверки полей в netfilter, но уже через год исследователь нашёл способ его обойти.

Такие ситуации особенно опасны: создаётся ощущение, что проблема решена, хотя на самом деле она просто сменила форму.

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