Форум АНТИЧАТ - Как Conficker использовал MS08-067

Как Conficker использовал MS08-067

30.04.2009, 17:38

sabe

Постоянный

Регистрация: 16.03.2007

Сообщений: 380

Провел на форуме:
1404552

Репутация: 568

Отправить сообщение для sabe с помощью ICQ

Отправить сообщение для sabe с помощью AIM

Отправить сообщение для sabe с помощью Yahoo

Как Conficker использовал MS08-067

Все знают что такое 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

Последний раз редактировалось sabe; 01.05.2009 в 19:30..