DLL Hijacking в антивирусах

Это кросспост из нашего первого езина, статья от нашего старого друга pr0mix’a, очень достойная и несправедливо забытая. Узрите же!

Извиняюсь за мат, но таков стиль изложения автора.

Здарова!

Здесь попиздим о DLL Hijacking (с примерами данной атаки) в контексте антивирусов. Этот текст следует рассматривать только как заметку. Ну и по умолчанию, если эта инфа покажется вам простой, то пусть это будет докой для новичков =)

DLL Hijacking – она же подмена DLL. Многие проги при вызове функции LoadLibrary(char *) передают в качестве параметра не полный путь к файлу, а только его имя. Что даёт возможность подменить загружаемую библиотеку на любую другую. Это связано с тем, что поиск данной dll начинается в директории, содержащей вызывающий EXE-файл. При этом, подменённая длл’ка выполняется с теми же привилегиями, что и запущенный процесс.

К ав, как и к другому софту, также можно (и нужно) применять данную технику нападения. Ясное дело, что в результате успешной атаки наш код работает в доверенном приложении, имеет те же привилегии, а значит может делать всё, что хочет.

Значит, разобьём ав’ы в плане самозащиты на 2 группы:

  • нихуя себя не защищающие (директории/файлы/процессы/окна/реестр/атрибуты/etc – частичная защита (например, протекция файлов или только реестра итп) не считается);
  • те, кто старается это делать.

К первой группе, например, относится Comodo (AV/IS v5.10). (Увы) приложения, не входящие в список доверенных, так просто не смогут нанести урон различным данным в папке авера. Однако, имеется возможность копировать туда свои файлы. Далее, при беглом анализе некоторых компонентов комода, была обнаружена целая куча вызовов LoadLibrary для файлов, отсутствующих в заданной директории (и во всей оси в целом). Нам остаётся только закинуть свою библиотеку с конкретным именем в нужную папку и наслаждаться результатом (возможно, понадобится перезагрузка). Например, имеется такая дира:

(путь по умолчанию) – там comodo хранит цветовые схемы, которые представляют собой ресурсные PE-файлы:

p1

Алгоритм их подключения такой:

p2

  • поиск папки “themes”;
  • поиск всех файлов в данной папке по маске “*.theme” (FindFirstFile/FindNextFile);
  • загрузка очередного найденного файла с помощью функи LoadLibrary;

В течение работы антивируса цветовые схемы могут быть загружены/выгружены несколько раз:

  • при загрузке оси (темы загружает “C:\Program Files\COMODO\COMODO Internet Security\cfp.exe”);
  • при очередном скане папок (через “cavscan.exe”);
  • при открытии окна: COMODO -> Разное -> настройки -> внешний вид (темы грузит “cfp.exe”);
  • etc;

Таким образом, переименовываем свою dll, допустим, в “xuita.theme” и закидываем в папку с темами. Комод сосёт.

Ко второй же группе ав можно отнести KIS/NOD32/DrWeb/etc. Рассмотрим NOD32 (AV/SS v5.2). Его директории защищены от записи, перемещения файлов и т.д. Но и у него был обнаружен код динамической загрузки “ppeset.dll” (читай доки “plugin for cisco nac”) в сервисе “ekrn.exe”:

p3

При дефолтовых настройках установки (и вообше) авера данной библиотеки не было найдено во всей ОС.

Тогда поиметь нод32 мы можем так:

  • [1] задаём имя своей dll “ppeset.dll” и кидаем её в папку %TEMP%;
  • [2] в системной переменной окружения “Path” добавляем директорию %TEMP%;
  • [x] или же забросить либу в системную папку и не париться с реестром;

При следующей перезагрузке системы наша библиотека подхватится, вызовет функу DllRegisterServer() и выгрузится из адресного пространства (АП) процесcа “ekrn.exe”.

Есть ещё такая фишка: если какой-либо процесс АВ’a создал, например, диалоговое окно открытия файлов (“Open”/”Save”/etc), то мы можем через это окно перемещать свои файлы даже в защищаемые антивирусом директории (“Action Via Window” attack – пусть будет так, а хуле). Это связано с тем, что подобные окна создаются с помощью фунок GetOpenFileName / GetSaveFileName, которые принадлежат библиотеке “Comdlg32.dll”. А она выполняется как раз таки в АП процесса ав, который считается доверенным и может иметь права админа и выше.

Алгоритм для реализации данной атаки может быть такой:

  • [1] запуск нашего процесса;
  • [2] мониторинг окон на наличие диалогового окна открытия файлов;
  • [3] при появлении такого окна мы узнаём, какому процессу оно принадлежит, и получаем его текущую папку;
  • [4] если текущая директория – та, что нам нужна (защищённая папка авера) – тогда ещё проверим, имеется ли в ней (наш) файл (с определённым именем). Нашли? – Оке, прыгаем на пункт [6]. Иначе [5]. Если же текущая дира – другая, тогда [2];
  • [5] копируем/перемещаем файл в буфер обмена (БО), активизируем найденное окно, и отправляем ему комбинацию клавиш “Ctrl + V”;
  • [6] завершение работы нашей проги;

Это всё здорово, однако многие из представленных танцев наверняка не будут работать на Windows Vista/7 из-за ёбаного UAC’а.

Как известно, при включённом uac’e большинство приложений запускается с правами обычного пользователя (даже если он находится под учётной записью админа). И изменить различные системные параметры нихера не выйдет (копирование/вставка/etc файла в системную директорию, изменение системных переменных окружения, инжекты в процессы и/или передача оконных сообщений им (защита UIPI) с более высоким Integrity Level etc etc – всё это под запретом).

Очевидное решение – повышение прав, сводящееся к обходу данного контроля.

Итак, обход можно поделить условно на 2 вида: активный (диалоговое окно uac не появляется) и пассивный (появляется).

К активному отнесём:

  • эксплоиты;
  • (возможные) инжекты в процессы;
  • некоторые другие специфические фишки (например, известная манипуляция c интерфейсом“IFileOperation”);

Пассивный:

  • имя нашего приложения должно содержать любую из следующих строк: “install”, “setup”, “update”, “patch” (сработает эвристик загрузчика приложений, и наша прога при запуске попросит повышение привилегий);
  • клепаем в приложении специальный манифест (etc + доки по манифесту для повышения прав);
  • заёб юзера: проверка своих привилегий, и если они низкие – запускаем себя с повышенными правами (ShellExecute(Ex) с командой “runas”) до тех пор, пока юзер не охуеет от диалоговых окон (и, наконец-то, блядь, разрешит выполнение с нужными нам привилегиями);
  • после старта наша прога скачивает какой-нибудь подписанный инсталлятор/апдейт/etc (обычно такой апдейт заранее анализируется для атаки dll hijack), кладёт рядом с ним заранее подготовленную, нашенкованную всякими прелестями dll с определённым именем и запускает скачанный файл. (Обычно) если юзер подтверждает запуск такого апдейта, он будет выполняться с повышенными правами, а вместе с ним и наша dll;
  • после старта наша прога мониторит появление новых процессов. Если таковой найден, то выходим на его файл, анализируем и стараемся провести dll hijack (как вариант, перед новым процессом мониторинг “Consent.exe”). Другой путь – переименовываем свой файл в имя нового процесса и запускаем его с повышением привилегий;
  • использование буфера обмена в надежде на то, что файл попадёт в нужное место;
  • и т.д.;

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

В общем, возможно всё, действуй!

  • существуют готовые утилиты для поиска уязвимых приложений в системе (например,“DllHijackAuditKit”). Плюс к этому можно наваять ещё пару дополнительных тулз для более точного, качественного анализа конкретных файлов/процессов/etc (поиск по строкам, коду etc);
  • сорцы примеров находятся в папке dllhijack (перед запуском прог читай комменты в исходниках);
  • все тесты проводились на Win XP/Vista/7 x86 с дефолтовыми настройками всех ав;

Исходники: sources/pr0mix/dllhijack

______________________________
m1x
pr0mix@mail.ru / vxrulez@gmail.com
2012

Inception E-Zine

Добавить комментарий