Опубликован: 20.02.2007 | Уровень: специалист | Доступ: платный
Лекция 9:

Средства взлома/подбора паролей

Аннотация: Взлом паролей - старейший прием, который приносит наибольший успех, почему это до сих пор так объяснено в данной лекции

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

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

Очень важно узнать, как и где хранится большинство паролей, чтобы понять, как эти средства действуют, и какие методы работы за этим стоят. Пароли в Unix и Windows хранятся в одностороннем хеш-файле и не могут быть расшифрованы. И наоборот, имя пользователя можно легко подсмотреть. Например, пароль Нейла abc123 хранится в Unix в виде закодированной строки kUge2g0BqUb7k (помните, что мы не можем ее раскодировать). Сохраненная строка не расшифровывается. Сравнение хеш-строки известного слова с исследуемой строкой пароля - вот основа для атак на системы парольной защиты.

PassFilt.dll и политика паролей в Windows

Система Windows NT 4.0 заставляет своих пользователей подбирать псевдосложные пароли. Библиотека PassFilt.dll, которая поставляется с Service Pack 2, дает возможность администратору создавать элементарные правила для пользовательских паролей. Применение правил конструирования паролей обычно является достаточно удачным средством обеспечения безопасности. В конце концов, вы можете применить самые свежие заплатки к системам безопасности и задать самые строгие ограничения в конфигурации сервера, но недостаточно сложный пароль может свести на нет все ваши усилия.

Реализация

PassFilt.dll уже может быть в поставке системы NT, но для нее требуется произвести некоторые модификации в системном реестре.

  1. Убедитесь, что PassFilt.dll размещается в директории C:\WINNT\ System32 (или куда указывает переменная %SYSTEMROOT% ).
  2. Воспользуйтесь редактором реестра (в данном случае regedt32.exe работает лучше, чем regedit.exe ), чтобы открыть ключ HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Control\Lsa.
  3. В правой панели выберите ключ Notification Packages.
  4. Выберите Edit/Multi String.
  5. Если значение уже установлено в FPNWCLNT, удалите его, если нет необходимости обеспечивать совместимость с Novell.
  6. Введите значение passfilt.
Примечание. Помните, что если вы используете PassFilt.dll на первичном контроллере домена, вы должны использовать его и на резервном контроллере.

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

  • Пароль не должен содержать часть имени пользователя.
  • Пароль должен содержать минимум шесть символов.
  • Пароль должен содержать символы следующих четырех видов:
    • английские прописные (от A до Z);
    • английские строчные (от a до z);
    • цифры (0 through 9);
    • нечисловые символы (символы пунктуации, комбинации с клавишей shift и т.д.).

Эти правила не могут быть изменены. Технически библиотека DLL может быть заменена на другую, созданную с использованием интерфейса программирования приложений от Microsoft (password application programming interface, API), но схема шифрования NT порождает достаточно устойчивые пароли. Тем не менее, не следует считать PassFilt.dll панацеей. Пользователь по-прежнему может воспользоваться простым паролем, который легко подсмотреть или подобрать. Ниже приведены примеры слабых паролей, полностью удовлетворяющих ограничениям PassFilt.dll.

  • Passw0rd
  • Password!
  • p4ssw0rd!
  • Pa55werd

Что происходит на самом деле. Пользователи любят заменять числа гласными ( a это 4, e - 3, i - 1, o - 0 ) и добавлять восклицательный знак в свой пароль, чтобы удовлетворить ограничениям по созданию "хорошего" пароля. Словарь хороших паролей, которым владеет большинство взломщиков паролей, содержит различные перестановки обычных слов, которые содержат буквы и символы. И, наконец, пароли, которые основаны на именах спортивных команд, названиях городов, ругательствах и именах всегда относятся к множеству наиболее слабых паролей, поскольку пользователи предпочитают пароли, которые легко запомнить. Следовательно, вам захочется сфокусироваться на усилиях по защите списка паролей и защите служб (таких как электронная почта, система безопасности, Windows NetBIOS), которые опираются на пароли.

Локальная политика безопасности в Windows 2000 и Windows XP

Наследники NT перенесли настройки PassFilt.dll из системного реестра в графический интерфейс пользователя. Они не добавили дополнительных правил или методов модификации имеющихся правил. Чтобы включить принудительные процедуры создания сложных паролей, войдите в раздел Local Security Policy, в Administrative Tools на панели управления. Окно Local Security Settings показано на рисунке 9.1.

Усложнение пароля

увеличить изображение
Рис. 9.1. Усложнение пароля

PAM и политика создания паролей в Unix

Некоторые популярные Unix-системы, такие как FreeBSD, Linux и Solaris, содержат встраиваемую модель аутентификации ( PAM ). PAM управляет любыми действиями пользователя, которые требуют от него пароля. Это может быть доступ по telnet, вход в консоль или изменение пароля. Реализация PAM также доступна для схем строгой аутентификации, таких как Kerberos, S/Key и RADIUS. Конфигурация PAM остается одной и той же, независимо от метода или приложения, которое осуществляет аутентификацию. Сосредоточимся на том, как усилить политику доступа по паролям с использованием PAM.

Реализация для Linux

Рассмотрим, как можно настроить системную политику в нашей Linux-системе в сравнении с использованием PassFilt.dll под Windows NT. Во-первых, у вас должна быть установлена библиотека cracklib (или libcrack ). Эта библиотека проверки паролей, разработанная Алеком Маффетом, является частью установочного комплекта систем Debian, Mandrake, RedHat и SuSE. Для проверки пароля нам необходимо только изменить текст файла, содержащего конфигурацию PAM. Это может быть один из двух возможных файлов:

/etc/pam.conf

или

/etc/pam.d/passwd

Строки в файле /etc/pam.conf, которые относятся к изменению пароля, выглядят примерно так.

passwd password required    /lib/security/pam_cracklib.so retry=3
passwd password required    /lib/security/pam_unix.so nullok use_authtok

Они логически подразделяются на пять колонок. Первая колонка содержит имя службы - имя программы, на которую распространяются инструкции, прописанные в оставшихся колонках. Файл /etc/pam.d/passwd содержит только четыре колонки, поскольку имя определяет службу passwd. Принятый стиль конфигурации определяет порядок, когда каждое имя службы помещается в отдельный файл, вместо того чтобы использовать один файл для нескольких служб. Независимо от стиля конфигурирования, у службы может быть несколько строк описания. Это выглядит как stacking modules для службы. Ниже приведен пример файла /etc/pam.d/passwd со стеком модулей.

password required   /lib/security/pam_cracklib.so retry=3
password required   /lib/security/pam_unix.so nullok use_authtok

Первая колонка показывает тип модуля, которому соответствует строка. Строка может содержать один из четырех типов (нас интересует изменение модуля, который управляет изменением пароля).

  • account. Служба управляет действиями, основанными на атрибутах пользователя, такими как проверка полномочий пользователя на доступ и на чтение файла. Например, вы можете использовать описание account для обеспечения доступа к ресурсам, таким как общие файлы. Однако без строки auth пользователь не сможет войти в систему.
  • auth. Обеспечивает взаимодействие с пользователем, например, запрос пароля. Такое взаимодействие используется, когда система или ресурс собирается запросить у пользователя разрешение на вход.
  • password. Обновляет аутентификационную информацию, например, изменяет пароль. Не используется для проверки пользователя в системе. Служба разрешает доступ к системе безопасности, которая управляет пользовательскими полномочиями.
  • session. Поддерживает действия, которые происходят до или после работы службы, такие как проверка неудачных попыток входа в систему. Например, может использоваться для немедленного отображения времени дня после того, как пользователь вошел в систему. Первая строка может быть использована для модуля auth проверки пароля пользователя, затем может следовать модуль session, который вызывает модуль pAM для отображения текущего времени. Другой способ использования модуля session может обеспечивать специфические функции, выполняющиеся, когда пользователь войдет в систему, такие как запись строки в системный журнал или истечение срока действия временного идентификатора.

Следующая колонка определяет control для службы, или описывает, как должно поддерживаться ее выполнение. Успешное выполнение означает, что служба выполнила функцию, например такую, как изменение пароля пользователя. Ошибка выполнения означает, что служба не передает корректные данные, такие как пароль пользователя. Ниже приводятся функции управления.

  • requisite. Если работа службы завершилась неудачей, все последующие действия автоматически завершаются неудачно. Это означает, что ни один из модулей в стеке не может быть завершен успешно.
  • required. Если работа службы завершилась неудачно, выполняет последующие действия, но принудительно выдает сообщение о неудачном завершении. Если в стеке присутствуют другие действия, то они могут завершиться успешно, но это не приведет ни к каким изменениям.
  • optional. Если работа службы завершилась неудачно или прошла успешно, выполняются последующие действия. Никак не влияет на результат выполнения последующих действий.
  • sufficient. Если работа службы завершилась успешно и не установлен параметр requisite, или работа этого модуля завершилась неудачно, процесс выполнения завершается с положительным результатом.

Следующая колонка содержит параметр module path для библиотеки аутентификации, которую следует использовать. Этот параметр должен содержать полное имя файла для библиотеки аутентификации. Мы будем использовать cracklib, поэтому убедитесь, что в этой колонке стоит pam_cracklib.so.

Последняя строка содержит аргументы, которые передаются библиотеке аутентификации. Возвращаясь к первому примеру с файлом /etc/pam.conf, мы видим, что модуль pam_cracklib.so должен успешно завершить свою работу с аргументом retry=3, в то время как пользователь меняет пароль с использованием программы passwd.

passwd password required    /lib/security/pam_cracklib.so retry=3
Сергей Хлюкин
Сергей Хлюкин
Россия, Москва, Московский Государственный Открытый Университет, 2007
Игорь Касаткин
Игорь Касаткин
Россия, Москва