Вопросы Теги

мы можем знать пароль для других пользователей, если у нас есть корневой доступ?

Аппаратные средства, ядро и программы пространства пользователя могут иметь различные размеры слова ¹.

  • Вы видите, является ли ЦП 64-разрядным, 32-разрядным, или способным к обоим путем проверки flags строка в /proc/cpuinfo. Необходимо знать возможные флаги на семействе архитектуры. Например, на i386/amd64 платформах, lm флаг определяет amd64-способные центральные процессоры (центральные процессоры, которые не имеют того флага, i386-только).

    grep -q '^flags *:.*\blm\b' /proc/cpuinfo    # Assuming a PC

  • Вы видите, является ли ядро 32-разрядным или 64-разрядным путем запросов архитектуры с uname -m. Например, i[3456]86 являются 32-разрядными в то время как x86_64 является 64-разрядным. Обратите внимание, что на нескольких архитектуре, 64-разрядное ядро может запустить 32-разрядные программы пространства пользователя, поэтому даже если uname -m показывает 64-разрядное ядро, нет никакой гарантии, что 64-разрядные библиотеки будут доступны.

    [ "$(uname -m)" = "x86_64" ]    # Assuming a PC

  • Вы видите то, что доступно в пространстве пользователя путем запросов поддержки LSB с lsb_release команда. Более точно, lsb-release -s печать a :- разделенный список поддерживавших функций LSB. Каждая функция имеет форму module-version-architecture. Например, доступность библиотеки ix86 C обозначается core-2.0-ia32, в то время как core-2.0-amd64 аналог для amd64. Не каждое распределение объявляет все доступные модули LSB, хотя, таким образом, больше может быть доступным, чем обнаруживаемо таким образом.

  • Вы видите то, для чего создаются программы архитектуры в системе с командой как file /bin/ls. Обратите внимание, что возможно иметь смешанную систему; даже если ls 64-разрядная программа, Вашей системе можно было установить библиотеки для запущения 32-разрядных программ, и (реже) наоборот.

  • Можно узнать предпочтительный размер слова для разработки (предполагающий, что компилятор C доступен) путем компиляции программы C с 5 строками, которая печатает sizeof(void*) или sizeof(size_t). Можно получить ту же информацию немного менее надежным способом ² путем выполнения команды getconf LONG_BIT.

    #include 
int main() {
    printf("%d\n", (int)sizeof(void*));
    return 0;
}

Что касается виртуальных машин, можете ли Вы выполнить 64-разрядный VM в 32-разрядной системе или наоборот зависите от Вашей технологии виртуальной машины. Посмотрите в особенности, Как я могу установить виртуальную машину Linux на 64 бита на Linux на 32 бита?

¹ “размер Word” обычное название того, что Вы называете разрядностью.
² Это может быть ненадежно, если кто-то установил альтернативный компилятор C с другой целевой архитектурой, но сохранил системное значение по умолчанию getconf.

24
09.04.2012, 14:29
4 ответа

TL; DR: Нет, пароль хранятся как хеши, которые не могут (в целом) быть восстановлены.

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

Если Вам сохранили пароли где-нибудь кроме /etc/passwd база данных, они могут быть сохранены способом, который позволяет это. htpasswd файлы могут содержать wealy зашифрованные пароли, и другие приложения могут сохранить более слабые хеши или незашифрованные пароли по различным (обычно плохим) причинам.

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

Если бы пароли хешируются или шифруются с более старым, слабым алгоритмом (3DES, MD5), было бы возможно разработать обоснованно эффективно / дешево, чем пароль был - хотя посредством нападения на данные вместо того, чтобы просто инвертировать преобразование. (например: вещи как http://project-rainbowcrack.com/ или http://www.openwall.com/john/)

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

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

37
27.01.2020, 19:40
  • 1
    Больше информации в Википедии: /etc/shadow, криптографическая хеш-функция, соль и завершение –  Tim 09.04.2012, 14:47
  • 2
    Это - хороший ответ по большей части, однако 3DES, и MD5 не на самом деле значительно более слабы, чем другие алгоритмы. Грубая сила является все еще единственным методом для нахождения пароля от хеша (таблицы радуги являются способом ускорить методы грубой силы для любого алгоритма, не слабость MD5). Что улучшается, метод хеша для паролей - то, что это медленно и использует достаточно длинную соль. –  Gilles 'SO- stop being evil' 10.04.2012, 03:30

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

В основном корень может сделать что-либо на машине, которую может сделать сама система. Система может принять Ваш пароль, таким образом, корень может принять Ваш пароль или его собственное, на месте ваше, с достаточным усилием. Что еще более важно, он может просто изменить Ваш пароль или СТАТЬ Вами.

А именно, пароли обычно шифруются. Это обычно - своего рода так называемый "односторонний" алгоритм, который генерирует число (хеш), который может использоваться, чтобы проверить пароль, но обычно не инвертировать число и возвращать пароль снова. Так, это не вопрос просто чтения файла для получения чьего-то пароля.

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

Однако даже откладывая ту проблему, "одностороннее" шифрование не является действительно одним путем. Существует много инструментов вокруг этого, пройдет много комбинаций паролей, шифруя их с тем же односторонним процессом, до вашего того находки, который соответствует. Они затем знают пароль, который получит доступ (хотя как корень, у них УЖЕ есть доступ на ТОЙ машине).

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

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

13
27.01.2020, 19:40
  • 1
    Получение доступа к моей учетной записи отличается, чем получение моего пароля. Если Вы позволяете мне пользовательский вход в систему своей машины, и я (глупый, но распространенный) использую тот же пароль для всех машин, у Вас нет доступа ко всем машинам просто b/c, можно изменить мой пароль на машине. Я просто заблокирован из одной учетной записи. –  emory 22.04.2012, 04:25
  • 2
    Кроме того, если системы зашифрованного файла использования для уязвимых данных, корневой компромисс доступа не подразумевает время для запуска. –  emory 22.04.2012, 04:27
  • 3
    @emory при использовании систем зашифрованного файла и системы, является поставленным под угрозу корнем, затем можно ли доверять коду, который имеет дело с системой зашифрованного файла, читает пароль шифрования и т.д.? Я сказал бы, что Вы не можете, потому что по определению, компромисс полномочия пользователя root означает, что все в системе (право вниз на ядро) доступно для всех. –  a CVn 10.08.2013, 17:27
  • 4
    @MichaelKjörling я могу доверять коду, который имеет дело с системой зашифрованного файла? В большинстве случаев, нет. В моем случае, да. Это помещено в корпус на медиа только для чтения. Корень не может записать в него. Журналы переходят к накопителю WORM. Все равно я не раздаю ключи к корню и вероятно запустился бы. –  emory 15.08.2013, 02:00

Если Вы имеете root затем можно выполнить взломщика пароля против /etc/shadow (принимающий локальные пароли и не LDAP или Kerberos, и т.д.). Это не может быть эффективно, если они выбирают хорошие пароли, и система настроена для использования хеширования сильного пароля. Но системные пароли не хранятся в простом тексте; пароли не непосредственно доступны даже root.

8
27.01.2020, 19:40

Все пароли хранятся в /etc/shadow файл. Можно открыть этот файл с помощью корневого доступа и видеть hash value из этих паролей для каждого пользователя (даже пользователь root).

Если у Вас нет вида программного обеспечения дешифрования пароля, Вы не можете преобразовать их значение хэш-функции назад к обычному тексту.

Но все еще если у Вас есть доступ к пользователю root, можно изменить пароль любого обычного пользователя при помощи следующей команды и получить доступ к их учетной записи.

root@localhost$ passwd pradeep

Это попросит у Вас нового passwd, который Вы хотите установить для пользователя pradeep. Таким образом, можно изменить passwd для pradeep.

Теперь можно получить доступ из его учетной записи:

root@localhost$ su pradeep

Это приведет к переключению на pradeep пользователя, и Вы получите терминал как это:

pradeep@localhost$

5
27.01.2020, 19:40
  • 1
    , который можно сделать "su pradeep" даже без изменения pradeep пароль, потому что, когда Вы делаете "su pradeep" с пользователем root, Вы не должны вводить pradeep пароль для входа в систему... –  Wolfy 12.04.2012, 21:35

Теги

Похожие вопросы