Все знают что такое Conficker и как быстро он распространился. Почти никто не знал как именно он распространился, и какую технику заюзал этот фирус в частносте эксплуатируя уязвимость MS08-067 в Server Service of Windows.
Протокол RPC в Серверной Службе поддерживает удаленную процедуру, превращающую любой путь (например
\\C\Program Files\..\Windows) в (\\C\Windows). Но Windows не восспринимает чрезмерно длинный путь, приводя к буферному переполению. Для конкретизации, Windows процесс (svchost) использует функцию NetpwPathCanonicalize() библиотеки netapi32.dll чтобы выполнять выше упомянутое действие. Вот схема, псеудокод:
PHP код:
func _NetpwPathCanonicalize(wchar_t* Path)
{
// проверка длинны пути
if( !_function_check_length(Path) )
return;
…
_CanonicalizePathName(Path);
…
return;
}
func _CanonicalizePathName(wchar_t* Path)
{
// защита стеков с куками - /GS
_save_security_cookie();
…
wchar _wcsBuffer[420h];
…
// а эта функция вызывает оверран
wcscat(wcsBuffer,Path);
…
// функция конвертирования
_ConvertPathMacros(wcsBuffer);
…
return;
}
Как мы можем видетьиз этой схемы, NetpwPathCanonicalize() проверяет длину пути перед передачей параметров в функцию CanonicalizePathName(). Однако, CanonicalizePathName() использует wcscat() при этом копируя путь в локальную переменную (wcsBuffer). Последствие есть - функция не сможет создать буферный избыток в первом пробеге, но это должно случится в подэлементах последовательности. Например, содержимое wcsBuffer после каждого вызова к этой функции было бы:
- Call 1 : wcsBuffer = “\\a\aaaaa\aaaa\..\..\a”
- Call 2 : wcsBuffer = “\\a\aaaaa\aaaa\..\..\a\\a\aaaaa\aaaa\..\..\a”
- Call 3 : wcsBuffer = “\\a\aaaaa\aaaa\..\..\a\\a\aaaaa\aaaa\..\..\a\\a \aaaaa\aaaa\..\..\a”
- …
Значит мы можем определенным образом захлестнуть Серверную Службу с несколькими вызовами к NetpwPathCanonicalize() удаленно, обеспечив ей соответствующий длины путь))))). Вплоть до этого пункта, кажется как будто бы все не так уж сложно..
Но тут появляются два другие препятствия:
.Cookie: функция CanonicalizePathName() была построена с /GS, которая защищает кукисом только перед возвратом адреса. Каждый раз когда адрес возврата переписан, куки и система знает что столкнулась с буферным избытком
.DEP: процесс Серверной Службы (svchost.exe) связан с DEPом по умолчанию. В результате, если шеллкод поставлен на стек, DEP не даст возможность выполнить команду.
Но как Conficker смог это сделать??
Сейчас давайте рассмотрим функцию CanonicalizePathName(), которая называется ConvertPathMacros() - не выполняет никакой проверки кукисов и был взят Confickerом на использования) чтобы получить контроль над шеллом. Эта функция использовала локальную переменную, чтобы сохранится в буфере и эксплуатация чего делает оверфлов чтобы перезаписать адрес возврата в ConvertPathMacros(). Но сейчас ConvertPathMacros() нет никакой порции кода, который непосредственно копирует и захлестывает этот локальный буфер. Возможно переписать адрес возврата этой функции по причине слабости в его строке, обрабатывающей алгоритм. как последствие, функция wcscpy(), к которой в пределах обращается ConvertPathMacros(), его адрес возврата переписан для обхода DEPa, конфикер использовал ZwSetInformationProcess() для блокирования DEP в рантайме, а после этого слосный вирус передает контроль шелла на наш стек. Конфикер использует инструкции, доступные в библиотеке AcGenral.dll, которую загружает svchost, чтобы преодолеть оба предыдуще расказаных елементов механизма. Так с этим методом эксплуатации, Confickerу только нужно обратиться успешно к NetpwPathCanonicalize() только один раз для атаки.
Разворачивающийся модуль Confickerа, используя выше сказанные методы эксплуатации может эксплуатировать версии различных Windows (XP SP2/SP3). Со специфическим IP адресом, Conficker будет пробовать нападение, вот смысл:
func __Thread_Attack (IpAddress)
{
…
// Создает url, чтобы шеллкод загрузил вирус.
url = Make_Url_Download();
…
While(1)
{
if( ! IsConnect(IpAddress)) return;
…
// Создаем нападение буфера, каждый раз обращаемся к Make_Buffer(),
buffer = Make_Buffer(url, buffer);
…
Attack(IpAddress, buffer);
// подождем 1 сек,если все ок выходим из лупа.
// если нет, пробуем следующий буфер.
if( WaitForSingleObject(1000) != WAIT_TIMEOUT ) break;
}
}
Деятельность шеллкода Confickerа:
- Расшифровывает (Xor с 0xC4).
- Получают адреса необходимых функций программного интерфейса приложения: LoadLibrary(), ExitThread().
- Грузит urlmon.dll библиотека в процессе.
- Получают адрес URLDownloadToFileA() function в urlmon.dll.
- Заргужает вирус от нападающего компьютерного использующего http протокол.
- Адрес источника данных использовал для загрузки: http://xxxxxx
ort/xxxxx
- Загрузил вирус и сохранил под имям x.
- Убивает нить
Итог.
Очень интересно и занемально..
Материал взят из просторов интернета, текст написан мною.
ps:
keyboard feels soft on acid.
(c) sabe; bui quang minh; hoang xuann minh;
http://downloadportal.ru/12245-kak-conficker-poimel-internet.html
Как Conficker использовал MS08-067
Похожие темы
Линейный вид
