Локальная авторизация без пароля в Ubuntu

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

Одним прекрасным летним вечером автор статьи закрыл крышку рабочего ноутбука с Ubuntu 16.04 Desktop на Unity и отправился домой. Вечер был настолько прекрасен, что я решил взять пару дней отпуска, бросил СМС начальнику, и он меня отпустил.

Как оказалось, не у всех моих коллег этот вечер был таким же прекрасным. У c4n сломался ноутбук, поэтому он попросил одолжить ему мой, но с его жестким диском. Я, конечно, разрешил.

С этого и началось наше увлекательное расследование.

Что произошло?

Утром следующего дня c4n разобрал мой ноутбук и вставил туда свой жесткий диск. Он открыл крышку и увидел вместо начала загрузки своей ОС окно входа в мою систему. Оно было кликабельно, и c4n начал вводить случайные пароли, однако, всё безуспешно. Расстроившись, он нажал на кнопку выключения, и тут произошло чудо.

Вместо перезагрузки компьютера был выполнен успешный вход в мою систему, а также были показаны последние открытые мной программы и документы. Стоит отметить, что документы не просто были показаны, они вполне себе работали! Можно было скроллить по документам и ходить по вкладкам браузера. c4n тут же скинул мне скриншот.


На самом деле скриншот был другой. Я, уходя с работы, не оставляю открытый KeePass и сайт компании.

На лицо локальная авторизация без пароля!

Когда я вышел из отпуска, мне стало интересно, что является виной этого явления, всегда ли воспроизводится и всегда ли воспроизводится одинаково, на всех ли системах воспроизводится.

Причины

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

Почему удаётся пройти авторизацию, для нас осталось загадкой. Мы грешим на работу модулей PAM (Pluggable Authentication Modules), которые, вероятнее всего, не находятся в оперативной памяти, а Ubuntu 16.04 неправильно обрабатывает их отсутствие, но потом поняли, что проблема в чём-то другом.

Всегда ли воспроизводится и всегда ли одинаково?

Наши эксперименты начались с Ubuntu 16.04. Действия были следующие:

1. Отправляем компьютер в спящий режим.
2. Вынимаем жесткий диск.
3. Выводим компьютер из спящего режима.

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

1. Компьютер показывает окно входа, вводим случайный пароль => видим окна пользователей перед слипом (все окна рабочие).
2. Компьютер показывает окно входа, вводим случайный пароль => система говорит, что пароль неверный => однократно нажимаем кнопку питания => видим окна пользователей перед слипом (все окна рабочие).
3. Компьютер показывает черный экран (по нему бегает курсор), нажимаем случайные клавиши и Enter => видим окна пользователей перед слипом (все окна рабочие).
4. Компьютер показывает черный экран (по нему бегает курсор), нажимаем случайные клавиши и Enter => ничего не происходит => однократно нажимаем кнопку питания => видим окна пользователей перед слипом (все окна рабочие).

Скорее всего, пункты 3-4 аналогичны пунктам 1-2, просто по каким-то причинам графика не отрисовывает окно входа в систему.

Эксперимент проводился много раз, и все разы удавалось получить доступ к окнам пользователя, т.е. воспроизводимость равна 100%. Это очень круто для такого странного бага. Правда, стоит отметить, что доступны только активные окна, переключиться на свёрнутые окна нам не удалось. Также некоторые окна исчезали спустя время, а иногда наблюдался эффект разлогинивания, но один из четырех способов входа позволял вернуться обратно.

PoC

Мы сняли небольшое видео, которое демонстрирует весь процесс атаки.

На всех ли системах воспроизводится?

Условием тестирования было наличие всех последних обновлений на системе. Зачем нам бага, которую давно закрыли?

Для начала было решено проверить воспроизводится ли баг на обычных ПК (не ноутбуках) с Ubuntu 16.04 с Unity. Была теория, что показ окон может быть как-то связан с видеокартой. Поэтому проверка осуществлялась с ПК как с интегрированной, так и с дискретной видеокартой, во всех случаях результат был один и тот же – бага отлично отрабатывает.

Дальше была взята Ubuntu 16.04 с GNOME. И тут нас ждало разочарование: бага не отрабатывала. Иногда, при выходе из слипа, система на полсекунды показывала последние окна (вполне реально заснять на видео), про это исследователи сообщили ещё в 2011 году, и она не закрыта до сих пор.

Дальше мы взяли 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, т.е. версии

• 10.10
• 11.04
• 11.10
• 12.04
• 12.10
• 13.04
• 13.10
• 14.04 (протестировано нами)
• 14.10
• 15.04
• 15.10
• 16.04 (протестировано нами)
• 16.10 (протестировано нами)
• 17.04 (протестировано нами)

Довольно внушительный список, не правда ли? Мы протестировали далеко не все. Если у кого-то есть возможность проверить на других версиях, которые мы не проверяли, с радостью добавим в пост.

Почему мы считаем, что это плохо

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

1. Используемые данные могут быть не сохранены на диск (например, редактируемый документ).
2. Данные могут находиться в шифрованной домашней директории (например, файлик с паролями).
3. Данные могут быть на шифрованной флешке.
4. Данные могут требовать дополнительной авторизации (как в нашем PoC с KeePass).

В дополнение к этому в Unity отправить компьютер в слип может любой человек, просто с экрана логина (без авторизации). Т.е. вполне себе реальная ситуация, что человек блокирует экран и уходит на обед, в этот момент злоумышленник отправляет компьютер в слип, вынимает жесткий диск и смотрит, что делал человек до того, как пошёл на обед. После остается перезагрузить компьютер уже с диском, и человек не догадается, что его данные могли быть скомпрометированы.

Скептики скажут, что подобного результата можно легко добиться, проведя cold boot атаку, а результаты буду даже лучше, но как часто кто-то из вас носит с собой термос с парой литров жидкого азота?

Мы решили, что проблема критичная и надо писать в Ubuntu.

Как мы пишем в Ubuntu

Чтобы завести багу, нам пришлось зарегистрироваться на launchpad.net, затем создать описание баги и добавить видео с PoC. Мы получили 406 очков рейтинга и значок костра (что бы это ни значило). Стали ждать. Баг мы завели 2018-06-18.

После длительной переписки товарищ Marc Deslauriers закончил нашу полемику сообщением, суть которого сводилась к: «Мы ничего исправлять не будем. Это то же самое, что иметь физический доступ».



Попытки переубедить не увенчались успехом. Нас отправили в тотальный игнор на неделю. После чего нам дали разрешение публиковать данное исследование:



UPD: 9 июля 2018 года, в 16 часов мы решили сделать багу публичной (спасибо amarao). В обсуждении на launchpad багу подтвердили для Mate 18.04, а не только для Unity. Также сообщество настаивает, что бага существует и её не стоит игнорировать.