Как установить линукс без пароля

Далее нам нужно монтировать линукс-раздел. Для этого создайте папку, в качестве точки для монтирования, используя команду: sudo mkdir /media/linx_part

Примонтируйте линукс-раздел командой sudo mount /dev/sda1 /media/linx_part

Источник

Как сбросить пароль Linux

Бывают случаи, что вы забыли или просто не знаете пароль пользователя для входа в систему. Можно установить новый пароль для любого пользователя. Для этого у вас должен быть физический доступ к компьютеру. В данной статье мы рассмотрим, как сбросить пароль пользователя в Linux — как установить новый пароль.

Первым делом нужно попасть в меню загрузчика GRUB. Для этого перезагрузите компьютер, и после того, как отобразится приветственный экран BIOS, нажмите и удерживайте клавишу Shift (или это может быть клавиша Esc ).

Появится меню загрузчика GRUB. Если вдруг с первого раза не получилось, например, вы не успели нажать Shift, и меню GRUB не показалось, попробуйте перезагрузить компьютер еще раз.

Меню GRUB выглядит следующим образом:

В меню представлен список операционных систем, которые установлены и доступны для загрузки. Найдите ваш Linux-дистрибутив (скорее всего это будет первый пункт меню). Под этим пунктом будет следующий пункт меню — это либо Advanced options for Ubuntu или Ubuntu, with Linux . generic (recovery mode) . Вместо Ubuntu будет стоять название вашего дистрибутива. В моем случае это, например, elementary.

Используя клавишу Вниз , выберете этот второй пункт в меню.

Так как в моем случае это пункт с надписью Advanced options for . , то после его выбора появятся несколько новых пунктов. Нужно выбрать пункт с пометкой (recovery mode) .

Появится новое меню — Recovery Menu. Используя клавишу Вниз , перейдите на пункт root (Drop to root shell promt) и выберите его, нажав клавишу Enter .

Вы попадете в командную строку. Если появилось сообщение «Press Enter for maintenance», тогда нажмите Enter .

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

Теперь можно установить новый пароль для вашего пользователя. Для этого вы должны знать имя пользователя в системе. Если вы его не помните, то можно вывести список всех пользователей, выполнив команду (мое имя пользователя было последним в списке):

Теперь установим новый пароль. Выполняем команду passwd в качестве аргумента для которой указываем имя пользователя, пароль которого мы хотим изменить (вместо yuriy укажите имя вашего пользователя):

Появится запрос на ввод пароля. Обратите внимание, что при вводе пароля на экран ничего не выводится. Поэтому вводите пароль с клавиатуры, а затем просто нажимайте Enter . Далее пароль нужно будет ввести повторно.

Теперь можно перезагрузить компьютер и попробовать войти в систему, используя новый пароль. Для перезагрузки введите команду:

Видео — изменяем пароль пользователя

В данном видео показаны все действия, описанные в статье — попадаем в меню GRUB, загружаем recovery mode, монтируем диск для записи и меняем пароль.

Источник

Локальная авторизация без пароля в 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%. Это очень круто для такого странного бага. Правда, стоит отметить, что доступны только активные окна, переключиться на свёрнутые окна нам не удалось. Также некоторые окна исчезали спустя время, а иногда наблюдался эффект разлогинивания, но один из четырех способов входа позволял вернуться обратно.

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

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

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

Для начала было решено проверить воспроизводится ли баг на обычных ПК (не ноутбуках) с 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. Также сообщество настаивает, что бага существует и её не стоит игнорировать.

Источник