Pull to refresh

Comments 62

Спасибо, всегда интересно почитать про оригинальные идеи, воплощённые вирусописателями - ведь кому как не им постоянно приходится изобретать всё новые ухищрения. Особенно интересно читать от лица человека, проводящего реверс-инженеринг, препарируя вирус.

А вообще разве нельзя при перехвате обращений к файловой системе и реестру модифицировать результат работы функции таким образом, чтобы она просто не показывала что такие файлы/ключи есть? Если такое сделать на уровне ядра, то можно действительно стать невидимкой...
С диском и реестром это точно можно, но нужно перехватить не два вызова, а немного больше.
С процессами, это, кажется, тоже возможно.

А можно ли стать на все 100% невидимым, действительно интересный вопрос.
Хотелось бы услышать на него аргументированный ответ.
Причем можно ли стать невидимым как для процессов режима пользователя так и для драйверов (установленных после), полностью сохранив функциональность системы?
Дело в том, что можно перехватить (по крайней мере документированными способами) только часть вызовов ядра.

Автор же данного руткита ничего особенного не сделал.
Описанные возможности реализованы в относительно простых примерах к WDK (Windows Driver Kit) - пакета для разработки драйверов под Windows (бесплатного) от MS.
невидимых руткитов пруд пруди, вон hxdef погуглите.
Может скрывать всё, что попросите.

Обнаружить руткит можно только анализом хуков.
hxdef это очень старый публичный концепт, он видим всеми нормальными утилитами и при умении простым ядерным отладчиком :)

Руткит, работая в ОС, так или иначе с ней взаимодействует, а значит его активность может быть засечена. Написать руткит, который был бы не видим можно только сделав его совершенно независмым от ОС, либо, чтобы он работал на уровень ниже ОС. Под последним я понимаю использование возможностей аппаратной виртуализации современных процессоров(Vanderpool Technology от Intel и Pacifica от AMD), и такие концепты руткитов был представлены уже почти два года назад Джоанной Рутковской на конференции Black Hat (http://en.wikipedia.org/wiki/Blue_Pill_(malware)).
Есть руткиты, которые переразмечают винт, отводя себе несколько метров в конце hdd, записывая своё тело туда и загружаясь задолго до любой ОС, т.о. это практически невидимый концепт, но он очень сложен, хотя и возможен.

Поэтому написать невидимый руткит теоретически можно, а практически нафиг никому ненужно :)

И вот эта последняя тенденция реверса совершенно обыденных зверюшек так многих радует, хотя всё, что здесь описано существует уже несколько лет и ничего нового из себя не представляет, это средний уровень.
ага, первый в вашем описании - bluepill, это пока за гранью реальности. второй - буткит - выявляется и зачищается из юзерского режима на ура.
На bluepill я дал ссылку. Но вот про реальность я не понял, он ведь существует и даже работает :) После Рутковской нечто подобное писали и другие. Другое дело, что ITW такого ещё небыло, но раз есть proof-of-concept, значит реально. Уже есть не один антируткит на базе этих технологий(www.northsecuritylabs.com as example).

Насчёт второго я имел ввиду не тот буткит, который недавно задетектили и который повторял POC выложенный в паблик ещё годом ранее. Но смысл один ага. Примечательность этого руткита в том, что автор довёл его до рабочего состояния в массах.

PS Что за ограничение по постам :)
всмысле ограничение?
интересно, как буткит защищается от дефрагментации диска?
Если он находится не в секторах, которые принадлежат разделу, то легко. Загрузочный сектор дефрагментаторы точно не трогают, а все что не в разделе - тоже их не касается. Так что не вижу проблемм.
Дело в том, что буткиты хранят в загрузочном секторе только необходимый минимум для запуска основного кода. Этот основной код хранится в других секторах - их контент руткит прячет, перехватывая irp_mj для чтения сектора.

Вот про эти сектора было и интерсно - если их "дефрагментируют", то руткит (а то и комп целиком) просто перестанет загружаться.
вот черт, два комметария (
Дело в том, что буткиты хранят в загрузочном секторе только необходимый минимум для запуска основного кода. Этот основной код хранится в других секторах - их контент руткит прячет, перехватывая irp_mj для чтения сектора.

Вот про эти сектора и интерсно - если их "дефрагментируют", то руткит (а то и комп целиком) просто перестанет загружаться.
ну, вот давайте возьмем этот руткит. Он патчит IRP_MJ_CREATE в драйвере ntfs. Предположим, что он записал в границы модуля ntfs свою функцию, которая и будет обработчиком. SSDT он не патчит.

Какой анализ тут можно провести?
Взять код оригинального обработчика с диска и сравнить с тем, что в памяти. Это обходится, если руткит перехватывает IRP_MJ_READ(который направлен на чтение ntfs.sys) и подсовывает свой код, тогда такое сравнение ничего не даст. Либо работать в обход интерфейсов, которые предоставляет ОС, т.е. спуститься ниже ntfs.sys(т.е. фактически требуется разбор структр ФС целиком) и опять же попытаться прочесть необходимую инфу и сравнить её с той, что в памяти.
Ещё один самый простой способ - делать тайминги, хотя это неоднозначный метод детекта(функция, которая перехвачена затратит больше времени, ибо ей надо исполнить ещё и перехватчик). Но это больше эмпирический метод.
Это то, что сразу пришло в голову, методов детекта на самом деле предостаточно.
да, и это будет именно то, что наблюдается сейчас - постепенный спуск "на самое дно самого глубокого ущелья". для любого "копка" можно копнуть еще глубже
нет абсолютно невидимых руткитов, как нет и абсолютной защиты от них. Новые ухищрения с любой стороны противостояния заставляет противника эволюционировать)

ничего не сделал - ну, да. чем проще - тем лучше.
да, такое делается. данный руткит реагирует только на open/delete, на enumerate - заглушка есть, но пустая. наверное будет в следующих версиях )
Стать невидимкой, допустим. Мы можем просканировать свободное метсо на диске, и, найдя отличия, найти спрятанные файлы. В этом же случае - все файлы видны. Пусть их имена немного отличаются, но парадокс в том, что не прячась, программ вызывают меньше подозрений! Ведь вы не будете пытаться удать каждый файл, чтобы узнать не под руткитом ли он. :)
"снять такой хук на практике нереально"

Как насчет воткнуть винт в другую машину и тупо поудалять файлы?
можно просто грузануться с livecd)
Учитывая сложность драйвера, можно предположить что автор особо не задумывался о серьезном противостоянии.
С большой вероятностью Вам удасться загрузится перед ним, заявив, что вы инфраструктурный фильтр драйвер файловой системы или что-нибудь в этом духе. А после уже Вы будете перехватывать его запросы, а не он Ваши.
это круто, конечно )

снять хук - имеется ввиду в рантайме. Поудалять, конечно, можно, правда, надо знать, что удалять.
Вывод:
Не запускайте неизвестный софт с привилегиями на установку драйверов, и прочими из набора прав "Администратора".
Права "Администратора" действительно дают очень много возможностей по использованию Вашего компьютера, и вирусописатели все активнее начинают ими пользоваться.
В обратном случае остается надеятся, что программисты из антивирусных контор разбираются в предмете лучше, чем вирусописатели.
действительно. в одной статье читал: "в windows уже содержатся компоненты, достаточные для того, чтобы не заразиться вирусом и не дать установиться руткиту. Это ваши руки и голова".
Ну, возврат акцес денайд — это совсем безобидный руткит.
Гораздо забавнее, когда драйвер перехватывает функции листинга каталогов или ветвей реестра — «нежелательные» ключи скрываются от посторонних процессов.

Обнаружить такой руткит случайно практически невозможно: в процессах чисто, на диске чисто, в реестре чисто. Лишь анализ хуков позволяет выявить таких ребят.

Когда я впервые несколько лет назад прочитал статью об устройстве и возможностях руткитов, было немного жутковато. Когда я испытал на себе один из них — ужаснулся ещё более.
Пожалуйста, расскажите поподробнее про анализ хуков.
Разве после подмены адресов системных функций можно понять, что их поменяли?
Я давно не интересуюсь темой, так что очень боюсь наговорить ерунды.

Если смотреть данный пример…
Само понятие хука — это же не подмена адреса — это подписка на события. Колбек-функция регистрируется в системе, и эта регистрация прекрасно палится.
Насколько я знаю, это зависит от того, что перехватывать.
Системные вызовы подменяются в соответствующей таблице.
А подписки вроде IoRegisterFsRegistrationChange можно не использовать.
ах да, вспомнил один из методов ловли даже самых хитровывернутых руткитов:
программа использует собственные реализации часто подменяемых системных функций, сравнивая результаты с тем, что говорит система.

Тут даже патчинг ядра на ходу, как это было в недавней статье, можно спалить.
Это в случае, если Вы загрузитесь до руткира.
Иначе с самого начала у вас будет уже ненастоящий адрес (но что он не настоящий Вы не узнаете), и все что можно будет узнать таким методом - добавилось ли еще перехватчиков после Вас, но о предыдущих узнать так не получится.
Хм. Ну можно наверное тем же оружием - мегамега псевдодрайвер пусть будет кусочком антивируса. И этот мегадрайвер каким-то образом пусть грузится самым первым. Хотя это не решение проблемы (честно говоря, не знаю, возможно ли такое). Т.к. следующий руткит найдет способ еще раньше загрузиться, и так до бесконечности. Наверное, в ядре должно быть что-то встроено, счетчик чисто для чтения, чтобы все желающие могли эти перехваты попересчитать...
А как в винде определяется порядок загрузки подобных драйверов?
изменить его можно например утилитой loadord.exe из пакета sysinternals
Я имел в виду, как на уровне ядра системы определяется порядок загрузки? Есть какие-то идентификаторы, списки загрузки, правила и т. п.?

Судя по тому, что есть утилиты наподобие вышеупомянутой, какая-то система приоретизации существует, вот мне и интересно узнать про неё побольше.
Метод, описанный artyfarty вполне работает, если руткит был запущен раньше. Данный метод основан на том, что создатель руткита не предусмотрел все возможные функции чтения памяти, но предусмотрел самые популярные. Программа запрашивает сначала чтение памяти распостранённым методом, а потом этот же блок памяти редким. Если ответы различаются, то это сигнализирует о рутките. Такую программу написал Руссонович (неуверен, но вроде бы она называется rootkit hunter).
Для этого существуют свои методики. В данном случае рассмотренный руткит использует стандартные публичные методы перехвата. Ничего нового, ничего особенного, такое наблюдалось уже в 2006 году и с тех пор продвинутые техники ушли весьма и весьма :)

Среди достойного софта, который в состоянии такие хуки детектировать можно выделить:
RootkitUnhooker
RkTrap
GMER
ну, про русток мы молчим. Таким, как я, чтобы его разобрать, надо пару лет)
Вот где не ожидал услышать о нём, так это на хабре :)
Да его тут периодически поминают. Кто-то даже ссылку на сэмпл выкладывал :-)
можно. в простейшем случае поднимается файл ntosrknl.exe (или какой там работает) с диска, и сравнивается с его образом в памяти. Кстати, руткит Rustok при таком методе отдает подложные данные, и например GMER (антируткит) ничего не видит )

Также берется таблица системных вызовов и в них ищутся адреса, выходящие за пределы образа ntoskrnl в памяти. Найти модуль, на который они ссылаются, довольно просто.
Отличная статья!!! Тема реверсивного инженеренга интересна!
спасибо, на здоровье)
Они используют одинаковые механизмы для сокрытия данных или отслеживания работы обычных программ. И, кстати, шаги к этому совершаются больше темной стороной.
Писателями антивирусов?
%-)
Ну это как бы "светлые", пусть даже их программы порой далеки от совершенства.
А на основании чего вирусам дается название, вот например
Trojan-Dropper.Win32.Agent.rek
что означает Agent и rek?
я недавно поймал у себя Trojan.Win32.Agent.jox, а информации по нему в сети не нашел, поэтому интересно, что означает jox например.
В данном случае вы говорите о терминологии Касперского. У них последние буквы (.rek/.jox) - номер модификации. В DrWeb используются цифры. Agent - это ни о чем: троян есть, но либо функционал не ясен, либо не отнести ни к какому существующему семейству. Сколько раз под Agent скрывались бэкдоры, Downloader'ы и прочие очевидные вещи - не счесть. Это на основании эмпирических данных :-)

Вообще, названия даются исходя и функционала, либо по "почерку" вируса. Например, Trojan.Downloader - загружает файлы, имя дано по функционалу. А Trojan.PWS.LdPinch - и по функционалу (PWS - крадет пароли) и по "почерку" (LdPinch). Как-то так. Но часто бывает, что названия не отражают сути.
просто интересно было узнать, что же этот трой делал...
единственный видимый эффект его присутствия был svchosts.exe в папке system и регулярно слетающий фокус с окон.
Анализ надо проводить, так ничего не скажешь :-) Под одним именем может быть довольно большое число разных троянов - это тоже надо учитывать.
Отправил на virusinfo.info, посмотрим сообщат ли о результате
кстати, это раздражает. У симантека, например, другая крайность - крайне малое число разновидностей, Trojan.Downloader и все тут)

Если бы это было возможно, то я бы предложил развернутую классификацию:
- метод заражения - файловый, авторан и так далее
- действия - удаляет, троянит, рассылает спам
- распространение - рассылается сервером, заражает файлы
- упакован - тем-то и темто
- и что-то еще

и закодировать както. Типа F1.F2.D3.D4, по группе на пункт. Хотя есть опасность закопаться)
Мысль здравая, частично это уже есть: Win32.ИМЯ - вирус, как правило файловый. По функционалу большая часть именуется, но как быть, если троян и инжектит и спам шлет? :-) Распространение... Тоже частично у нас есть: HLLM - почтовый червь, HLLW.Autoruner - autorun.inf. Пакеры точно не нужно в название вносить. Во-первых, многие трояны пакованы несколько раз, во вторых для кучи пакеров просто нет названия, они вирусные. Вирусные пакеры, кстати, идут под именами Trojan.Paked (или Pakes), BitDefender тоже их ловит иногда.
А пока нет универсально классификации, непонятки будут...
ясно

тогда - "народное" название и мд5 хэш :) типа русток или нимда.
Хэш точно не поможет, поменяется адрес сервера, зашитый в файле - хэш и изменился. А рустоки, нимды, пинчи - это все есть :-)
Программа представляет собой nt-драйвер (так же известны, как legacy-драйвера, то есть не связанные ни с каким физическим устройством).
Описываются разные вещи.
NT-драйвер или legacy-драйвер это модель драйверов, разработанная для Windows NT 3.1. Работает на всей линейке NT, вплоть до последних (XP, Vista).
Legacy они называются в противоположность Windows Driver Model (WDM) — модели драйверов, совместимые с Windows 98/ME/2000/XP/Vista.
У Vista имеется собственный вариант модели драйверов Windows Driver Foundation
UFO just landed and posted this here
постоянно их путаю)
Так что же, только MINIX3 спасёт мир от руткитов? :)
Sign up to leave a comment.

Articles