Контакты
Подписка
МЕНЮ
Контакты
Подписка

Уязвимости Windows. Взгляд изнутри

Уязвимости Windows. Взгляд изнутри

В рубрику "Оборудование и технологии" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Уязвимости Windows. Взгляд изнутри

Часть 2

О.М. Бойцев
эксперт

Предлагаем Вашему вниманию вторую часть статьи О.М. Бойцева об уязвимостях ОС Windows, которые наиболее часто используются злоумышленниками.Первую часть статьи читайте в № 1-2 журнала "Информационная безопасность" за 2006 г.

Нулевой сеанс: добро пожаловать!

Наверное, многие из читателей не раз встречались с выражение типа "удаленный взлом через NetBIOS". Ну что ж, попытаемся внести ясность и наполнить данное выражение смыслом. Нулевой сеанс, который реализуется посредством протокола NetBIOS, используется в Windows-сетях для диагностических целей, что, впрочем, не исключает его использования в совершенно другом "амплуа". Дело в том, что создание нулевого сеанса не требует аутентификации соединения, что может быть с легкостью использовано в злонамеренных целях. Чтобы установить null session (нулевой сеанс, или анонимное подключение), необходимо ввести пустое имя пользователя и пустой пароль, при этом для анонимного подключения всегда открыт специальный ресурс IРС$ (inter-process communication). Для того чтобы соединиться с ресурсом IPC$, выполняется следующая команда: c:\>net use \\[IP-адрес]\ipc$ "" /user:""

Анонимный доступ имеет ряд ограничений, но с помощью этого инструмента возможно многое, а именно: просматривать и модифицировать отдельные ветви реестра; запускать User Manager и просматривать список существующих пользователей и групп; запускать Event Viewer и другие средства удаленного администрирования. В системах NT4 и Win2k и по сей день можно встретить данный непропатченный баг. Кстати, ликвидировать возможность подключения через IPC$ можно занесением значения "1" в ключ реестра "HKEY_LOCAL_MACHINE \System\CurrentControlSet\Control\ LSA Name: RestrictAnonymous", также желательно прикрыть в настройках вашего брандмауэра 139-й порт, который, собственно, и является дверью для IPC$.

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

Для хранения и обработки таких атрибутов пользователя, как пароли в ОС Windows NT и ей подобных, используется SAM (Security Accounts Manager - администратор учетных записей в системе защиты). SAM размещает всю информацию в одноименной базе данных, которая находится по адресу %SystemRoot%\system32\config. Забегая вперед, необходимо сказать, что именно SAM-файл является наиболее ценным трофеем, пропустив который через соответствующий софт, можно получить пароли от текущих учетных записей. Но в данном случае, учитывая тему статьи, нас в большей степени интересует не взлом как таковой, а баг, посредством которого брут (от англ. brute - грубый, в контексте brute force - взлом грубой силой) имеет место быть.

В ОС Windows NT для защиты паролей используются две однонаправленные хэш-функции (хеш-функция - алгоритм, используемый для генерации хеш-кодов цифровых объектов, в нашем случае паролей). В системе Windows присутствуют LM-хэш (Lan Manager хэш) и NT-хэш (Windows NT). Наличие двух аналогичных функций необходимо для совместимости со старыми ОС. Алгоритм LM-хэш изначально был разработан Microsoft для операционной системы OS/2, он интегрирован в Windows 95/98, Windows for Workgroups и частично в Windows 3.1. Хэш Windows NT был разработан специально для ОС Microsoft Windows NT. На страже LM-хэша стоит известный алгоритм шифрования DES; NT-хэш держится на алгоритме шифрования MD4. Как при локальном, так и при удаленном способах входа в систему, SRM (Security Reference Monitor - "смотрящий" за безопасностью - служба, работающая в режиме ядра, контролирующая безопасность системы посредством таких компонентов, как LSA - Local Security Authority; уже упомянутого SAM -Security Accounts Manager; AD -Active Directory и ряда других) сначала пытается идентифицировать NT-хэш. Если его нет,тогда SRM пытается проверить подлинность LM-хэша. А теперь внимание! Вот, собственно, и момент истины. Создание LM-хэша происходит по алгоритму, который вряд ли кто-либо осмелится назвать криптостойким. Посмотрим, как "элегантные брюки превращаются в шорты":

1.Пароль преобразуется в 14-символьную строку.

2.Комбинация символов переводится в верхний регистр.Полученное 14-байтовое значение разбивается на две 7-байтовых части.

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

Эпикриз: независимо от длины выбранного пароля "окно" обрежет его до 14 символов, после чего переведет полученное значение в верхний регистр. Все, что надо сделать "злоадмину", - это взломать два семисимвольных пароля;-)...

Прокомментировать такой расклад можно по-разному, и было бы удивительно, если бы никто не возразил: "Постойте, все не так уж и плохо, как Вы тут нам написали! Ведь для исправления сложившейся ситуации Microsoft выпустила гораздо более защищенный протокол NTLMv2, присутствующий уже в 3-м Service Pack-е для Windows NT 4.0. и, наконец, в Windows 2000 и XP для сетевой аутентификации был введен протокол Kerberos, криптостойкость которого на порядок выше!" Оно-то так. Но дело в том, что для совместимости со старыми системами в Windows опять-таки используются все предыдущие протоколы. И если компьютеры Windows 2000/XP не в состоянии идентифицировать друг друга через Kerberos, они автоматически переходят на использование все тех же NTLM или LMЕ.

Повышение прав пользователя

Архетиктура ОС Windows такова, что содержит процессы (в качестве процессов выступают различные сервисы, например, LSASS - один из сервисов, обеспечивающих безопасность cистемы), которые работают в системе чаще всего от имени SYSTEM. Нетрудно догадаться, что если "злоадмин" сможет запустить нужную ему программу от имени SYSTEM, то получит доступ к системе с правами полноценного администратора. Один из вариантов запуска может быть осуществлен посредством методов типа переполнения буфера, но существуют и другие способы, реализация которых достаточно полно освещена в современной литературе. Первой и самой известной из программ, реализующих данную возможность, была утилита GetAdmin. Для выполнения произвольного кода разработчик применил интересный механизм, называемый "внедрением в процесс".Для внедрения в процесс используются функции OpenProcess,Write-ProcessMemory, CreateRemo-teThread, для чего необходимы привилегии SeDebugPrivilege -отладка объектов низкого уровня, в том числе потоков (threads), которые по умолчанию даются только группе администраторов. Следующий пример - яркое подтверждение того, что подмена процессов отнюдь не фантастична, можно даже назвать этот процесс несложным. Независимый эксперт и аналитик Radim "EliCZ" Picha (Bugs@EliCZ.cjb.net) уже давно обнаружил в безопасности Windows NT и Windows 2000 критическую уязвимость, под которую был написан эксплоит, демонстрирующий очевидную слабость локальной подсистемы безопасности NT/2000 и полностью компрометирующий всю систему безопасности этих ОС. Программа, названая Deb-Ploit (англ. Debug и Exploit), эксплуатирует брешь в подсистеме отладки (debugging subsystem) и позволяет совершенно любому пользователю с любыми полномочиями выполнять программный код с правами администратора или локальной системы. Принцип работы Deb-Ploit приблизительно таков:программа "просит" отладочную подсистему (в Windows это smss.exe,которую, кстати, вы можете найти в процессах диспетчера задач) вернуть дескриптор (то же, что и handle -используется в Windows для уникальной идентификации объекта или ресурса) процесса,запущенного с правами администратора или локальной системы, результатом чего и является получение прав администратора. Данной уязвимости подвержены Windows NT/2000.В Windows XP такого бага нет.Но это вовсе не означает, что через некоторое время и здесь не найдут ничего подобного...

Довольно оригинальным примером получения административных прав, реализованным на основе подмены,является манипуляция с хранителем экрана. Причем баг этот и по сей день не пропатчен. Для запуска "приложения-крота", работающего с правами администратора, достаточно скопировать его в директорию c:\windows\system32\, предварительно переименовав в logon.scr и удалив все скринсейверы. Результатом вышеописанных манипуляций станет запуск того, что мы скопировали в system32, причем работать этот крот будет, "притворяясь" скринсейвером.

P.S. Приведенные материалы носят исключительно ознакомительный характер. Автор статьи не несет никакой ответственности за использование материалов в злонамеренных целях.

Опубликовано: Журнал "Information Security/ Информационная безопасность" #3+4, 2006

Приобрести этот номер или подписаться

Статьи про теме