В последнее время появилось и постепенно набирают обороты жалобы пользователей на наличие вредоносных файлов, которые не удаётся удалить никаким образом. Эти файлы видно в списке актиынх процессов, и что характерно — все они размещаются в папке C:\System Volume Information\ (или подпапках) и выполняются с правами NT-AUTHORITY\SYSTEM.
Если у Вас обнаруживается такое поведение — поздравляю, Вы подхватили Whistrler Bootkit. О нём и пойдёт речь сегодня.
На данный момент я, как и некоторые мои друзья в антивирусных компаниях, не располагаем инфектором этого буткита. Однако совершенно очевидно, что зловред не является новым изобретением, а представляет собой продолжение идеи Питера Клейсснера, выраженной в PoC-проекте Stoned. В этом случае вирмейкер, вероятно, откровенно скопировал код, даже не потрудившись его дополнить или изменить. Итак, история…
До некоторого времени, проект Stoned Питера Клейсснера был способом показать возможность загрузки кода в память системы до фактической загрузки системы. Это позволяло получить полный контроль над ОС: начиная от выполнения произвольных процессов с произвольными полномочиями до обхода системы безопасности Windows и контроля лицензионного ключа на Vista / Seven. Проект довольно стабильно развивался в рамках open source, пока «Лаборатория Касперского» и некоторые другие организации не подали в суд на автора за якобы распространение зловредного программного обеспечения. Не буду комментировать этот поступок и насколько он разумен, однако с конца прошлого года автор прекратил распространение новых версий и значительно урезал доступную публичную версию. Также были приостановлены разработки поддержки Linux-платформ на момент протекания судебного процесса. И появился Whistler…
По информации от Питера, утечка произошла скорее всего до января этого года, поскольку первый «промоутерский» шаг о Whistler появился вот в этом блоге именно в январе. Спустя месяц блоггера вынудили выкинуть явно рекламную информацию, а также информацию о стоимости буткита и стоимости его поддержки, придав статье более «информационный», а не рекламный характер. Сейчас «оффсайт» буткита расположен здесь, где информации поменьше, но денег хочется пооткровеннее :)
На основании этой даты можно предполагать, что Whistler базируется на Stoned v2 Alpha 3 от 20 октября 2009 года. Именно эта версия шла в комплекте с компилированными файлами инфектора и дезинфектора. Приняв это за рабочую гипотезу, за неимением дроппера, следующая информация сделана именно на основании работы и возможностей этой версии Stoned.
Исходно, хорошо документировались самые различные методы инфицирования: автозапуск с флешки, pdf-эксплоиты (инфицирование из заражённого pdf-файла), инфекторы, заражение при загрузке специальных образов LiveCD/LiveUFD. Поэтому инфектор может быть в чём угодно, что затрудняет понимание, как же передаётся и где берётся Whistler.
Список инфицируемых ОС внушителен: 2000, XP, Vista, Seven, Server 2003, Server 2008, порддерживается х64. При этом корректно работает с аппаратным и программным шифрованием всего содержимого винчестера. Отключение возможности модифицирования MBR в BIOS не помогает (это работало только в DOS и win95/98, так что уже в принципе неактуально).
На заражённой системе загрузчик в MBR патчится на первичное выполнение кода буткита с последующей передачей управления оригинальному загрузчику. Оригинальный загрузчик, код буткита и его плагины хранятся в неразмеченной области в конце физического диска в специальной файловой системе (RawFS — так было в оригинальном Stoned). При этом код буткита является первым файлом этой системы и расположение его точно известно. Это важный момент, позволяющий проводить инфицирование даже полностью криптованных дисков, поскольку в них не криптуется загрузчик и точно известно начало неразмеченной области — а этого вполне достаточно.
После выполнения загрузки код буткита размещается в памяти и позволяет реализовать различный функционал, подгружая плагины в существующие процессы. Трудно сказать, попала ли автору Whistler public-версия, или закрытая (которая включала готовый плагин запуска приложений с правами NT-AUTHORITY\SYSTEM), но в общем схема выполнения плагинов со стороны буткита следующая.
1. По функции PsGetVersion / RtlGetVersion определятся версия операционной системы.
2. На основании этой информации определяются структуры EPROCESS и KTHREAD.
3. Буткит через асинхронный вызов процедуры внедряет код плагина в любой исполняемый user-mode процесс.
Как видно из пп. 1-2, код буткита позволяет работать на любой ОС. Однако нужно отличать от буткита его плагины: последние являются зависимыми от ОС (особенно разрядности — х32 или х64), а потому в системе RawFS могут находится различные версии под различные системы. Если автор Whistler написал плагин, позволяющий запускать с повышенными правами процессы — и этот плагин написан под х32, значит, в общем Whistler будет заражать и х32 и х64, в памяти будет находится буткит — но свой потенциал он будет раскрывать только на х32, поскольку плагин на другой разрядности не заработает.
Если автору Whistler попалась закрытая версия Stoned — там не было возможности запуска и эскалации прав у процессов на х64 (NB!!!)
Оригинальный Stoned никак не скрывал своё присутствие и изменение MBR (как это делал, например, Sinowal). В принципе, это возможно сделать с помощью дополнительного плагина (см. выше), но его необходимо кодить. Хватит ли на это ума и возможностей автора Whistler — неизвестно.
Что же делать, если у Вас появился Whistler? Исходя из доступности MBR достаточно стандартной fixmbr. Однако, принимая во внимание то, что пока этот вирус — «тёмная лошадка», настоятельно рекомендуется предварительно снять дампы MBR. Это можно сделать, к примеру, с помощью MBRWizard, выполнив в командной строке:
Можно попробовать в действии и antiboot. Я немного изменил эту утилиту, а точнее — автоматизировал сбор карантина. Суть: утиль проводит исследование antiboot по такой команде:
Потом упаковывает папку MBR в zip-архив quarantine.zip с паролем virus и удаляет папку MBR.
Непосредственно в утилите имеются баги: тормоза в ходе работы и подвисание на некоторых машинах. Выглядит это так: в консоли пишет:
после чего — тишина и надолго. В этом случае нужно попросить пользователя закрыть окно и вручную прислать созданную папку MBR (дампы в ней уже будут).
(По словам представителя ЛК, об этом баге знают, но устранить не представляется возможным по различным причинам).
Безусловно, возможно использование и широко известного «универсального» лечителья буткитов eSage Bootkit Remover. Тем не менее, имеются сведения, что при наличии активного заражения TDL2 эта тулза выдаёт «no disk found». Это следует иметь в виду при её использовании, но в целом — вполне хорошая вещь, тоже рекомендуемая к использованию. Но не напрямую, а хотя бы с таким скриптом:
Полученные дампы MBR можно разослать любимому производителю антивируса :) Это позволит оценить, насколько Whistler отличается от Stoned. Сильно подозреваю, что никак :)
P.S. Огромное спасибо Питеру Клейсснеру за содействие, оказанное в подготовке этого материала и вообще за работу, проделанную в рамках проекта Stoned.
Если у Вас обнаруживается такое поведение — поздравляю, Вы подхватили Whistrler Bootkit. О нём и пойдёт речь сегодня.
На данный момент я, как и некоторые мои друзья в антивирусных компаниях, не располагаем инфектором этого буткита. Однако совершенно очевидно, что зловред не является новым изобретением, а представляет собой продолжение идеи Питера Клейсснера, выраженной в PoC-проекте Stoned. В этом случае вирмейкер, вероятно, откровенно скопировал код, даже не потрудившись его дополнить или изменить. Итак, история…
До некоторого времени, проект Stoned Питера Клейсснера был способом показать возможность загрузки кода в память системы до фактической загрузки системы. Это позволяло получить полный контроль над ОС: начиная от выполнения произвольных процессов с произвольными полномочиями до обхода системы безопасности Windows и контроля лицензионного ключа на Vista / Seven. Проект довольно стабильно развивался в рамках open source, пока «Лаборатория Касперского» и некоторые другие организации не подали в суд на автора за якобы распространение зловредного программного обеспечения. Не буду комментировать этот поступок и насколько он разумен, однако с конца прошлого года автор прекратил распространение новых версий и значительно урезал доступную публичную версию. Также были приостановлены разработки поддержки Linux-платформ на момент протекания судебного процесса. И появился Whistler…
По информации от Питера, утечка произошла скорее всего до января этого года, поскольку первый «промоутерский» шаг о Whistler появился вот в этом блоге именно в январе. Спустя месяц блоггера вынудили выкинуть явно рекламную информацию, а также информацию о стоимости буткита и стоимости его поддержки, придав статье более «информационный», а не рекламный характер. Сейчас «оффсайт» буткита расположен здесь, где информации поменьше, но денег хочется пооткровеннее :)
На основании этой даты можно предполагать, что Whistler базируется на Stoned v2 Alpha 3 от 20 октября 2009 года. Именно эта версия шла в комплекте с компилированными файлами инфектора и дезинфектора. Приняв это за рабочую гипотезу, за неимением дроппера, следующая информация сделана именно на основании работы и возможностей этой версии Stoned.
Исходно, хорошо документировались самые различные методы инфицирования: автозапуск с флешки, pdf-эксплоиты (инфицирование из заражённого pdf-файла), инфекторы, заражение при загрузке специальных образов LiveCD/LiveUFD. Поэтому инфектор может быть в чём угодно, что затрудняет понимание, как же передаётся и где берётся Whistler.
Список инфицируемых ОС внушителен: 2000, XP, Vista, Seven, Server 2003, Server 2008, порддерживается х64. При этом корректно работает с аппаратным и программным шифрованием всего содержимого винчестера. Отключение возможности модифицирования MBR в BIOS не помогает (это работало только в DOS и win95/98, так что уже в принципе неактуально).
На заражённой системе загрузчик в MBR патчится на первичное выполнение кода буткита с последующей передачей управления оригинальному загрузчику. Оригинальный загрузчик, код буткита и его плагины хранятся в неразмеченной области в конце физического диска в специальной файловой системе (RawFS — так было в оригинальном Stoned). При этом код буткита является первым файлом этой системы и расположение его точно известно. Это важный момент, позволяющий проводить инфицирование даже полностью криптованных дисков, поскольку в них не криптуется загрузчик и точно известно начало неразмеченной области — а этого вполне достаточно.
После выполнения загрузки код буткита размещается в памяти и позволяет реализовать различный функционал, подгружая плагины в существующие процессы. Трудно сказать, попала ли автору Whistler public-версия, или закрытая (которая включала готовый плагин запуска приложений с правами NT-AUTHORITY\SYSTEM), но в общем схема выполнения плагинов со стороны буткита следующая.
1. По функции PsGetVersion / RtlGetVersion определятся версия операционной системы.
2. На основании этой информации определяются структуры EPROCESS и KTHREAD.
3. Буткит через асинхронный вызов процедуры внедряет код плагина в любой исполняемый user-mode процесс.
Как видно из пп. 1-2, код буткита позволяет работать на любой ОС. Однако нужно отличать от буткита его плагины: последние являются зависимыми от ОС (особенно разрядности — х32 или х64), а потому в системе RawFS могут находится различные версии под различные системы. Если автор Whistler написал плагин, позволяющий запускать с повышенными правами процессы — и этот плагин написан под х32, значит, в общем Whistler будет заражать и х32 и х64, в памяти будет находится буткит — но свой потенциал он будет раскрывать только на х32, поскольку плагин на другой разрядности не заработает.
Если автору Whistler попалась закрытая версия Stoned — там не было возможности запуска и эскалации прав у процессов на х64 (NB!!!)
Оригинальный Stoned никак не скрывал своё присутствие и изменение MBR (как это делал, например, Sinowal). В принципе, это возможно сделать с помощью дополнительного плагина (см. выше), но его необходимо кодить. Хватит ли на это ума и возможностей автора Whistler — неизвестно.
Что же делать, если у Вас появился Whistler? Исходя из доступности MBR достаточно стандартной fixmbr. Однако, принимая во внимание то, что пока этот вирус — «тёмная лошадка», настоятельно рекомендуется предварительно снять дампы MBR. Это можно сделать, к примеру, с помощью MBRWizard, выполнив в командной строке:
mbrwiz.exe /save=mbr /filename=mbr.binМожно попробовать в действии и antiboot. Я немного изменил эту утилиту, а точнее — автоматизировал сбор карантина. Суть: утиль проводит исследование antiboot по такой команде:
antiboot.exe -l "%cd%\log.txt" -p "%cd%\MBR"Потом упаковывает папку MBR в zip-архив quarantine.zip с паролем virus и удаляет папку MBR.
Непосредственно в утилите имеются баги: тормоза в ходе работы и подвисание на некоторых машинах. Выглядит это так: в консоли пишет:
Antibootkt, (c) Kaspersky Lab 2010, version 1.2.1
Log started
Unpacking driver
Starting up driverпосле чего — тишина и надолго. В этом случае нужно попросить пользователя закрыть окно и вручную прислать созданную папку MBR (дампы в ней уже будут).
(По словам представителя ЛК, об этом баге знают, но устранить не представляется возможным по различным причинам).
Безусловно, возможно использование и широко известного «универсального» лечителья буткитов eSage Bootkit Remover. Тем не менее, имеются сведения, что при наличии активного заражения TDL2 эта тулза выдаёт «no disk found». Это следует иметь в виду при её использовании, но в целом — вполне хорошая вещь, тоже рекомендуемая к использованию. Но не напрямую, а хотя бы с таким скриптом:
start /wait remover.exe dump \\.\PhysicalDrive0 mbr.bin
remover.exe fix \\.\PhysicalDrive0Полученные дампы MBR можно разослать любимому производителю антивируса :) Это позволит оценить, насколько Whistler отличается от Stoned. Сильно подозреваю, что никак :)
P.S. Огромное спасибо Питеру Клейсснеру за содействие, оказанное в подготовке этого материала и вообще за работу, проделанную в рамках проекта Stoned.
