Вход в личный кабинет Почему мы считаем, что это плохо
Уязвимость позволяет получить только локальный доступ к данным, и то не ко всем, а лишь к тем, что открыты в приложениях и развернуты. Однако, это все равно довольно критично, поскольку:
- Используемые данные могут быть не сохранены на диск (например, редактируемый документ).
- Данные могут находиться в шифрованной домашней директории (например, файлик с паролями).
- Данные могут быть на шифрованной флешке.
- Данные могут требовать дополнительной авторизации (как в нашем PoC с KeePass).
Что произошло?
Утром следующего дня
разобрал мой ноутбук и вставил туда свой жесткий диск. Он открыл крышку и увидел вместо начала загрузки своей ОС окно входа в мою систему. Оно было кликабельно, и
начал вводить случайные пароли, однако, всё безуспешно. Расстроившись, он нажал на кнопку выключения, и тут произошло
чудо
Вместо перезагрузки компьютера был выполнен успешный вход в мою систему, а также были показаны последние открытые мной программы и документы. Стоит отметить, что документы не просто были показаны, они вполне себе работали! Можно было скроллить по документам и ходить по вкладкам браузера. c4n тут же скинул мне скриншот.
На самом деле скриншот был другой. Я, уходя с работы, не оставляю открытый KeePass и сайт компании.
На лицо локальная авторизация без пароля!
Когда я вышел из отпуска, мне стало интересно, что является виной этого явления, всегда ли воспроизводится и всегда ли воспроизводится одинаково, на всех ли системах воспроизводится.
Описание
Программа
login
используется для запуска нового сеанса в системе. Как правило, эта программа вызывается автоматически и выводит приглашение
login:
на терминал пользователя. Программа
login
может восприниматься оболочкой командной строки не как простая программа и вызываться без создания нового процесса.
Обычно, оболочка запускает
login
посредством вызова
exec login, что приводит к завершению работы пользователя в текущей оболочке. Попытка запустить
login
из любой оболочки, отличной от регистрационной, приводит к сообщению об ошибке.
В какой-то момент пользователя попросят ввести свой пароль. Чтобы недопустить раскрытия, символы при вводе пароля не отображаются. Разрешено очень маленькое число попыток ввода неправильного пароля, перед тем как
login
закончит работу и прервёт подключение.
Если включён механизм устаревания пароля учётной записи, то перед входом в систему может потребоваться смена пароля. Для этого нужно ввести старый пароль и новый пароль. Подробней об этом написано в
passwd(1).
После успешного входа в систему, будут показаны сообщения от системы и о наличии почты. Можно отключить вывод файла системных сообщений из файла
/etc/motd, создав в домашнем каталоге файл нулевой длины с именем
.hushlogin.
Значения идентификатора учётной записи и группы будет взято из файла
/etc/passwd. Значения переменных
$HOME,
$SHELL,
$PATH,
$LOGNAME
и
$MAIL
устанавливаются согласно соответствующим полям учётной записи пользователя. Также могут быть установлены значения ulimit, umask и nice из поля GECOS.
В некоторых системах переменной среды
$TERM
будет присвоен тип терминала линии tty, согласно данным из файла
/etc/ttytype.
Также может быть выполнен сценарий инициализации пользовательского интерпретатора команд. Подробней об этой функции смотрите соответствующую страницу руководства.
Субсистемный вход в систему можно распознать по наличию символа “*” в начале регистрационной оболочки. Заданный домашний каталог будет использован как корень новой файловой системы, в которой регистрируется пользователь.
Программа
login
НЕ удаляет записи о пользователях из файла utmp. Эта задача программ
getty(8)
и
init(8)
удалять записи о владельце терминального сеанса. Если
login
запускается из командной строки без
exec, то пользователь продолжает находиться в системе даже после завершения работы в “порождённом сеансе”.
See also top
mail(1), passwd(1), passwd(5), utmp(5), environ(7), getty(8), init(8), lastlog(8), shutdown(8)
Всегда ли воспроизводится и всегда ли одинаково?
Наши эксперименты начались с Ubuntu 16.04. Действия были следующие:
- Отправляем компьютер в спящий режим.
- Вынимаем жесткий диск.
- Выводим компьютер из спящего режима.
Дальше, как оказалось, может быть несколько вариантов поведения системы:
- Компьютер показывает окно входа, вводим случайный пароль => видим окна пользователей перед слипом (все окна рабочие).
- Компьютер показывает окно входа, вводим случайный пароль => система говорит, что пароль неверный => однократно нажимаем кнопку питания => видим окна пользователей перед слипом (все окна рабочие).
- Компьютер показывает черный экран (по нему бегает курсор), нажимаем случайные клавиши и Enter => видим окна пользователей перед слипом (все окна рабочие).
- Компьютер показывает черный экран (по нему бегает курсор), нажимаем случайные клавиши и Enter => ничего не происходит => однократно нажимаем кнопку питания => видим окна пользователей перед слипом (все окна рабочие).
Скорее всего, пункты 3-4 аналогичны пунктам 1-2, просто по каким-то причинам графика не отрисовывает окно входа в систему.
Как мы пишем в ubuntu
Чтобы завести багу, нам пришлось зарегистрироваться на
, затем создать описание баги и добавить видео с PoC. Мы получили 406 очков рейтинга и значок костра (что бы это ни значило). Стали ждать. Баг мы завели 2022-06-18.
После длительной переписки товарищ Marc Deslauriers закончил нашу полемику сообщением, суть которого сводилась к: «Мы ничего исправлять не будем. Это то же самое, что иметь физический доступ».
Попытки переубедить не увенчались успехом. Нас отправили в тотальный игнор на неделю. После чего нам дали разрешение публиковать данное исследование:
UPD: 9 июля 2022 года, в 16 часов мы решили сделать багу публичной (спасибо amarao). В обсуждении на launchpad багу подтвердили для Mate 18.04, а не только для Unity. Также сообщество настаивает, что бага существует и её не стоит игнорировать.
На всех ли системах воспроизводится?
Условием тестирования было наличие всех последних обновлений на системе. Зачем нам бага, которую давно закрыли?
Для начала было решено проверить воспроизводится ли баг на обычных ПК (не ноутбуках) с Ubuntu 16.04 с Unity. Была теория, что показ окон может быть как-то связан с видеокартой. Поэтому проверка осуществлялась с ПК как с интегрированной, так и с дискретной видеокартой, во всех случаях результат был один и тот же – бага отлично отрабатывает.
Дальше была взята Ubuntu 16.04 с GNOME. И тут нас ждало разочарование: бага не отрабатывала. Иногда, при выходе из слипа, система на полсекунды показывала последние окна (вполне реально заснять на видео), про это исследователи сообщили ещё в 2022 году, и она не закрыта до сих пор.
Дальше мы взяли Arch с Wayland и Xorg — разочарование, не работает. Debian 9 c GNOME и опять разочарование. Также не отработало на новой Ubuntu 18.04 — не удивительно, ведь к этому времени мы уже стали подозревать, что проблема в Unity. Поэтому решили для последних тестов взять Ubuntu 14.
04, а еще посмотреть, что произойдёт с Ubuntu 18.04, если поменять оконный менеджер с GNOME на Unity. На Ubuntu 14.04 все хорошо отработало (хотя время жизни окон было значительно меньше, чем на 16.04). На Ubuntu 18.04 с Unity после выхода из слипа система сразу падает, и никакие эксперименты дальше провести нельзя.
Вывод: мы решили, что уязвимы версии Ubuntu с нативно установленной Unity, т.е. версии
Довольно внушительный список, не правда ли? Мы протестировали далеко не все. Если у кого-то есть возможность проверить на других версиях, которые мы не проверяли, с радостью добавим в пост.
Название
login – начинает сеанс в системе
Параметры
- Не выполнять аутентификацию, пользователь уже прошёл проверку.
- Имя удалённого хоста, на который нужно войти.
- Сохранить среду.
- Выполнить протокол autologin для rlogin.
Параметры
-r,
-h
и
-f
используются только если
login
запускается суперпользователем.
Предостережения
Данная версия
login
может быть собрана с разными параметрами и только некоторые из них смогут быть использованы на любой машине.
Расположение файлов может отличаться на разных системах.
Программа
login
НЕ удаляет записи о пользователях из файла utmp. Эта задача программ
getty(8)
и
init(8)
удалять записи о владельце терминального сеанса. Если
login
запускается из командной строки без
exec, то пользователь продолжает находиться в системе даже после завершения работы в “порождённом сеансе”.
Как и для любой программы, запуск
login
может быть подделан. Если неуполномоченные пользователи имеют физический доступ к машине, то атакующий может использовать это для получения пароля следующего человека, который будет работать за машиной.
Причины
Как оказалось, виной данного явления было то, что при закрытии крышки мой ноутбук уходил не в гибернацию, а в сон (т.е. оставлял питание на оперативной памяти), а после открытия крышки в оперативной памяти оставалась загруженная ОС и последние файлы, с которыми я работал.
Почему удаётся пройти авторизацию, для нас осталось загадкой. Мы грешим на работу модулей PAM (Pluggable Authentication Modules), которые, вероятнее всего, не находятся в оперативной памяти, а Ubuntu 16.04 неправильно обрабатывает их отсутствие, но потом поняли, что проблема в чём-то другом.
Синтаксис
- login [-p] [имя_пользователя] [ПЕРЕМЕННАЯ_СРЕДЫ=ЗНАЧЕНИЕ…]
- login [-p] [-h хост] [-f имя_пользователя]
- login [-p] -r хост
Файлы
/var/run/utmp
- содержит список работающих сеансов в системе
/var/log/wtmp
- содержит список завершённых сеансов работы с системой
/etc/passwd
- содержит информацию о пользователях
/etc/shadow
- содержит защищаемую информацию о пользователях
/etc/motd
- содержит системные сообщения за день
/etc/nologin
- при существовании файла блокируется доступ в систему обычным пользователям
/etc/ttytype
- содержит список типов терминалов
$HOME/.hushlogin
- при существовании файла системные сообщения при входе в систему не выводятся