Использование уязвимостей архитектуры Win32 для повышения уровня привилегий пользователя
В этой статье описывается новый класс атак на ОС Microsoft Windows, и, возможно, на ряд других систем, управление в которых осуществляется путем посылки сообщений. Предотвращение этих атак требует функциональности, предоставить которую ни одна из существующих Windows систем не может. Microsoft был уведомлен об этой уязвимости, ответом было то, что они не считают эту особенность ОС уязвимостью. Это письмо в Microsoft можно прочитать здесь — http://security.tombom.co.uk/response.txt.
Этот документ описывает шаги проведения демонстрационной атаки этого класса. Существует много способов и вариаций проведения атак, используя нижеописанную уязвимость. Это – всего лишь один пример.
то что лежит в основе – Win32 Messaging System
Все приложения Windows управляются сообщениями. Например, когда нажата клавиша, активному окну посылается сообщение WM_KEYDOWN, когда в пределах активного окна двигается курсор мыши, окну посылается сообщение WM_MOUSEMOVE и т.д. Во всех случаях, когда происходит что-то, имеющее отношение к данному приложению, ОС посылает ему сообщение. Сообщения помещаются в очередь сообщений и обрабатываются по порядку.
Это достаточно гибкий и надежный способ контроля приложений. Но, этот механизм контроля в Windows – уязвим. Любая выполняющаяся программа может посылать любые сообщения любому окну, в независимости от того владеет ли она этим окном, и необходимы ли тому окну эти сообщения. Не существует механизма определения источника сообщения; сообщение посланное вредоносным приложением неотличимо от того, что было послано ядром Windows. Мы будем использовать именно это отсутствие аутентификации для манипулирования окнами и владеющими ими процессами.
краткий обзор атаки
В этом примере, я проведу атаку на Network Associates Virus Scan v4.5.1 выполняющийся в Windows 2000 Professional. Virus Scan Console выполняется с правами LocalSystem, я вошел в систему как guest. Цель – заставить Virus Scan исполнить некий код, повышающий мои привилегии. Это может быть выполнено за несколько несложных шагов:
1. Обнаружить подходящее окно в Virus Scan (edit box – отличный вариант) и получить его хэндл.
2. Убрать запреты на длину вводимых в edit box данных, чтобы я мог ввести необходимое их количество.
3. Вставить некий двоичный код.
4. Заставить Virus Scan его выполнить (с правами LocalSystem).
Я написал небольшое приложение – Shatter, с помощью которого можно осуществить эти шаги. Также понадобятся: hex-редактор, способный копировать двоичные данные в буфер обмена (например, UltraEdit) и debugger (например, WinDbg).
Шаг 1: Нахождение Окна.Нам нужно любое окно – любой элемент управления, допускающий ввод данных. Запустите Virus Scan Console и выберите “New Task”. Сверху диалогового окна находится edit box – то, что нам нужно. Теперь нам нужно узнать его хэндл, с чем нет никаких проблем. Запустите Shatter и поместите его так, чтобы было видно Virus Scan Console. При активном окне Shatter, поместите курсор над нужным нам edit box и в окне Shatter нажмите “Get cursor window”. Таким образом мы получим хэндл нужного edit box – он отобразится в окне Shatter, что-нибудь вроде 30172. Теперь, зная хэндл, мы можем взаимодействовать с окном, права доступа которого выше наших.
Шаг 2: Сброс Запретов.Имея хэндл, мы можем посылать окну любые сообщения, т.е., практически, делать с ним все, что угодно. Сначала, удостоверимся, что edit box позволит ввести все нам необходимое – уберем запреты на длину вводимых в edit box данных. Активируйте Shatter, наберите хэндл edit box в текстовое поле “Handle”, чтобы установить некоторую максимальную длину вводимых данных, нужно послать сообщение EM_SETLIMITTEXT edit box’у. Наберите FFFFFFFF в текстовом поле “WPARAM” – это ограничит максимальную длину ввода 4 Гб (теоретически). Этого должно хватить для любых целей.
Шаг 3: Вставка Кода.Запустите hex-редактор и загрузите в него sploit.bin (это — шеллкод, взятый из Jill от Dark Spyrit), включенный в shatter.zip (скачать архив можно с сайта автора — http://security.tombom.co.uk/shatter.zip). Он запускает remote command shell на вашем компьютере. Запустите Netcat с параметром –lp 123 и, на время, забудьте об этом. Возвратимся к hex-редактору: скопируйте шеллкод в буфер обмена, включая строку FOON в начале – она нам понадобится. Активируйте Shatter, нажмите на “WM_PASTE” – шеллкод вставлен в edit box.
Шаг 4: Исполнение Кода.Запустите debugger и привяжите его к процессу avconsol.exe (в WinDbg – F6 и выбор процесса). Затем, найдите в памяти строку FOON. Команда для WinDbg – s –a 00000001 10000000 "FOON". Запомните адрес памяти, где находится “FOON”, у меня это был 0x00148c28. Последнее сообщение, которое мы будем использовать – WM_TIMER. Это – странноватое и довольно опасное сообщение, т.к. оно может содержать адрес функции обратного вызова (callback function), в качестве второго параметра. Если второй аргумент не равен нулю (первый аргумент – это ID таймера), то выполняется код находящийся по заданному адресу. Сообщение WM_TIMER НЕ поступает в очередь сообщений, поэтому у приложения нет никакой возможности его проигнорировать. Глупо…
Итак, в Shatter поле “Handle” должно содержать хэндл edit box. Первый параметр (“WPARAM”) может быть чем угодно, второй – на 512 байт выше полученного ранее адреса (мы имеем 1 Кб NOP’ов в начале шеллкода); на моей машине это - 0x148c28 + 0x200 = 0x148e28. Нажмите “WM_TIMER”, сообщение будет послано, Netcat оживет командной строкой. Все, вы не guest, вы – LocalSystem.
решение проблемы
Я вижу два быстрых и неудобных способа, которые могут нарушить функциональность системы, и одно комплексное и сложное решение которое всего полностью не решит:
— запрет получения списка окон в системе;
— запрет обмена сообщениями между приложениями с разными привилегиями;
— добавление информации об отправителе к отсылаемому сообщению, т.о. позволяя приложению решать обрабатывать сообщение или нет.
Не существует простого решения этой проблемы, поэтому Microsoft не хочет признавать это уязвимостью. Проблема в том, что если я обнаружил этот баг, то, можно уверенно утверждать, что о нем знают и другие люди. Они могут проникнуть в вашу систему как непривилегированные пользователи и заполучить полномочия выше чем у вас (LocalSystem > Administrator). В чем дело? Вы ведь устанавливаете все последние заплаты, не правда ли?
Когда в Microsoft увидели копию этого документа, мне прислали ответ ясно излагающий, что они осознают возможность проведения подобных атак, но не считают все вышеизложенное прорехой системы безопасности т.к. а) взломщику нужен физический доступ к компьютеру б) взломщику необходимо исполнить некий зловредный код. Я полностью согласен с обоими утверждениями, но они не поняли сути – того, что эта уязвимость используется для поднятия уровня привилегий пользователя. Вспомните hk.exe, ERunAsX (a.k.a. DebPloit), isshack.dll, это – признанные Microsoft, эксплоиты для поднятия уровня прав пользователя. Почему же они не признают этот? Простой факт – в Microsoft знают, что залатать эти дыры они не могут! Используемый механизм – Win32 API, в принципе, оставался неизменным со времени выхода WinNT 3.5 в июле 1993. Его невозможно изменить.
Этот документ описывает шаги проведения демонстрационной атаки этого класса. Существует много способов и вариаций проведения атак, используя нижеописанную уязвимость. Это – всего лишь один пример.
то что лежит в основе – Win32 Messaging System
Все приложения Windows управляются сообщениями. Например, когда нажата клавиша, активному окну посылается сообщение WM_KEYDOWN, когда в пределах активного окна двигается курсор мыши, окну посылается сообщение WM_MOUSEMOVE и т.д. Во всех случаях, когда происходит что-то, имеющее отношение к данному приложению, ОС посылает ему сообщение. Сообщения помещаются в очередь сообщений и обрабатываются по порядку.
Это достаточно гибкий и надежный способ контроля приложений. Но, этот механизм контроля в Windows – уязвим. Любая выполняющаяся программа может посылать любые сообщения любому окну, в независимости от того владеет ли она этим окном, и необходимы ли тому окну эти сообщения. Не существует механизма определения источника сообщения; сообщение посланное вредоносным приложением неотличимо от того, что было послано ядром Windows. Мы будем использовать именно это отсутствие аутентификации для манипулирования окнами и владеющими ими процессами.
краткий обзор атаки
В этом примере, я проведу атаку на Network Associates Virus Scan v4.5.1 выполняющийся в Windows 2000 Professional. Virus Scan Console выполняется с правами LocalSystem, я вошел в систему как guest. Цель – заставить Virus Scan исполнить некий код, повышающий мои привилегии. Это может быть выполнено за несколько несложных шагов:
1. Обнаружить подходящее окно в Virus Scan (edit box – отличный вариант) и получить его хэндл.
2. Убрать запреты на длину вводимых в edit box данных, чтобы я мог ввести необходимое их количество.
3. Вставить некий двоичный код.
4. Заставить Virus Scan его выполнить (с правами LocalSystem).
Я написал небольшое приложение – Shatter, с помощью которого можно осуществить эти шаги. Также понадобятся: hex-редактор, способный копировать двоичные данные в буфер обмена (например, UltraEdit) и debugger (например, WinDbg).
Шаг 1: Нахождение Окна.Нам нужно любое окно – любой элемент управления, допускающий ввод данных. Запустите Virus Scan Console и выберите “New Task”. Сверху диалогового окна находится edit box – то, что нам нужно. Теперь нам нужно узнать его хэндл, с чем нет никаких проблем. Запустите Shatter и поместите его так, чтобы было видно Virus Scan Console. При активном окне Shatter, поместите курсор над нужным нам edit box и в окне Shatter нажмите “Get cursor window”. Таким образом мы получим хэндл нужного edit box – он отобразится в окне Shatter, что-нибудь вроде 30172. Теперь, зная хэндл, мы можем взаимодействовать с окном, права доступа которого выше наших.
Шаг 2: Сброс Запретов.Имея хэндл, мы можем посылать окну любые сообщения, т.е., практически, делать с ним все, что угодно. Сначала, удостоверимся, что edit box позволит ввести все нам необходимое – уберем запреты на длину вводимых в edit box данных. Активируйте Shatter, наберите хэндл edit box в текстовое поле “Handle”, чтобы установить некоторую максимальную длину вводимых данных, нужно послать сообщение EM_SETLIMITTEXT edit box’у. Наберите FFFFFFFF в текстовом поле “WPARAM” – это ограничит максимальную длину ввода 4 Гб (теоретически). Этого должно хватить для любых целей.
Шаг 3: Вставка Кода.Запустите hex-редактор и загрузите в него sploit.bin (это — шеллкод, взятый из Jill от Dark Spyrit), включенный в shatter.zip (скачать архив можно с сайта автора — http://security.tombom.co.uk/shatter.zip). Он запускает remote command shell на вашем компьютере. Запустите Netcat с параметром –lp 123 и, на время, забудьте об этом. Возвратимся к hex-редактору: скопируйте шеллкод в буфер обмена, включая строку FOON в начале – она нам понадобится. Активируйте Shatter, нажмите на “WM_PASTE” – шеллкод вставлен в edit box.
Шаг 4: Исполнение Кода.Запустите debugger и привяжите его к процессу avconsol.exe (в WinDbg – F6 и выбор процесса). Затем, найдите в памяти строку FOON. Команда для WinDbg – s –a 00000001 10000000 "FOON". Запомните адрес памяти, где находится “FOON”, у меня это был 0x00148c28. Последнее сообщение, которое мы будем использовать – WM_TIMER. Это – странноватое и довольно опасное сообщение, т.к. оно может содержать адрес функции обратного вызова (callback function), в качестве второго параметра. Если второй аргумент не равен нулю (первый аргумент – это ID таймера), то выполняется код находящийся по заданному адресу. Сообщение WM_TIMER НЕ поступает в очередь сообщений, поэтому у приложения нет никакой возможности его проигнорировать. Глупо…
Итак, в Shatter поле “Handle” должно содержать хэндл edit box. Первый параметр (“WPARAM”) может быть чем угодно, второй – на 512 байт выше полученного ранее адреса (мы имеем 1 Кб NOP’ов в начале шеллкода); на моей машине это - 0x148c28 + 0x200 = 0x148e28. Нажмите “WM_TIMER”, сообщение будет послано, Netcat оживет командной строкой. Все, вы не guest, вы – LocalSystem.
решение проблемы
Я вижу два быстрых и неудобных способа, которые могут нарушить функциональность системы, и одно комплексное и сложное решение которое всего полностью не решит:
— запрет получения списка окон в системе;
— запрет обмена сообщениями между приложениями с разными привилегиями;
— добавление информации об отправителе к отсылаемому сообщению, т.о. позволяя приложению решать обрабатывать сообщение или нет.
Не существует простого решения этой проблемы, поэтому Microsoft не хочет признавать это уязвимостью. Проблема в том, что если я обнаружил этот баг, то, можно уверенно утверждать, что о нем знают и другие люди. Они могут проникнуть в вашу систему как непривилегированные пользователи и заполучить полномочия выше чем у вас (LocalSystem > Administrator). В чем дело? Вы ведь устанавливаете все последние заплаты, не правда ли?
Когда в Microsoft увидели копию этого документа, мне прислали ответ ясно излагающий, что они осознают возможность проведения подобных атак, но не считают все вышеизложенное прорехой системы безопасности т.к. а) взломщику нужен физический доступ к компьютеру б) взломщику необходимо исполнить некий зловредный код. Я полностью согласен с обоими утверждениями, но они не поняли сути – того, что эта уязвимость используется для поднятия уровня привилегий пользователя. Вспомните hk.exe, ERunAsX (a.k.a. DebPloit), isshack.dll, это – признанные Microsoft, эксплоиты для поднятия уровня прав пользователя. Почему же они не признают этот? Простой факт – в Microsoft знают, что залатать эти дыры они не могут! Используемый механизм – Win32 API, в принципе, оставался неизменным со времени выхода WinNT 3.5 в июле 1993. Его невозможно изменить.
Chris Paget аka FOON.
Сетевые решения. Статья была опубликована в номере 06 за 2003 год в рубрике save ass…
