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

Discussion in 'Песочница' started by sabe, 30 Apr 2009.

  1. sabe

    sabe Elder - Старейшина

    Joined:
    16 Mar 2007
    Messages:
    313
    Likes Received:
    178
    Reputations:
    14
    Все знают что такое Conficker и как быстро он распространился. Почти никто не знал как именно он распространился, и какую технику заюзал этот фирус в частносте эксплуатируя уязвимость MS08-067 в Server Service of Windows.

    Протокол RPC в Серверной Службе поддерживает удаленную процедуру, превращающую любой путь (например
    \\C\Program Files\..\Windows) в (\\C\Windows). Но Windows не восспринимает чрезмерно длинный путь, приводя к буферному переполению. Для конкретизации, Windows процесс (svchost) использует функцию NetpwPathCanonicalize() библиотеки netapi32.dll чтобы выполнять выше упомянутое действие. Вот схема, псеудокод:
    PHP:
    func _NetpwPathCanonicalize(wchar_tPath

    // проверка длинны пути
    if( !_function_check_length(Path) ) 
    return; 
    … 
    _CanonicalizePathName
    (Path); 
    … 
    return; 

    func _CanonicalizePathName(wchar_tPath

    // защита стеков с куками - /GS 
    _save_security_cookie(); 
    … 
    wchar _wcsBuffer
    [420h]; 
    … 
    // а эта функция вызывает оверран
    wcscat(wcsBuffer,Path); 
    … 
    // функция конвертирования 
    _ConvertPathMacros(wcsBuffer); 
    … 
    return; 
    Как мы можем видетьиз этой схемы, NetpwPathCanonicalize() проверяет длину пути перед передачей параметров в функцию CanonicalizePathName(). Однако, CanonicalizePathName() использует wcscat() при этом копируя путь в локальную переменную (wcsBuffer). Последствие есть - функция не сможет создать буферный избыток в первом пробеге, но это должно случится в подэлементах последовательности. Например, содержимое wcsBuffer после каждого вызова к этой функции было бы:
    Значит мы можем определенным образом захлестнуть Серверную Службу с несколькими вызовами к 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 будет пробовать нападение, вот смысл:
    Деятельность шеллкода Confickerа:
    - Расшифровывает (Xor с 0xC4).
    - Получают адреса необходимых функций программного интерфейса приложения: LoadLibrary(), ExitThread().
    - Грузит urlmon.dll библиотека в процессе.
    - Получают адрес URLDownloadToFileA() function в urlmon.dll.
    - Заргужает вирус от нападающего компьютерного использующего http протокол.
    - Адрес источника данных использовал для загрузки: http://xxxxxx:port/xxxxx
    - Загрузил вирус и сохранил под имям x.
    - Убивает нить

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

    ps: keyboard feels soft on acid.

    (c) sabe; bui quang minh; hoang xuann minh;

    http://hek.me
     
    #1 sabe, 30 Apr 2009
    Last edited: 13 Nov 2010
    6 people like this.