Тайна MiniDuke: 0-day PDF-эксплойт и ассемблерный микро-бэкдор 0x29A для слежки за госструктурами Исследовательский центр "Лаборатории Касперского" (GReAT) Эксперт «Лаборатории Касперского» опубликовано 4 мар 2013, 16:25 MSK Сюжеты: Adobe, Уязвимости и эксплойты http://www.securelist.com/ru/blog/207764493/Tayna_MiniDuke_0_day_PDF_eksployt_i_assemblernyy_mikro_bekdor_0x29A_dlya_slezhki_za_gosstrukturami 12 февраля 2013 года компания FireEye объявила об обнаружении эксплойта нулевого дня для Adobe Reader, применяемого для установки на компьютер ранее неизвестной сложной вредоносной программы. Мы дали новой вредоносной программе имя ItaDuke, потому что она показалась нам похожей на Duqu и потому что используемый ей шелл-код содержит цитаты из «Божественной комедии» Данте Алигьери на языке оригинала. После публикации первого сообщения мы обнаружили несколько новых атак с применением того же эксплойта (CVE-2013-0640), в ходе которых на компьютерах жертв устанавливаются другие вредоносные программы. Среди обнаруженных атак наше внимание привлекла пара инцидентов, которые оказались столь необычными в некоторых отношениях, что мы решили проанализировать их глубже. Вместе с нашим партнером CrySyS Lab мы выполнили подробный анализ этих необычных инцидентов. Результаты анализа указывают на появление новой, ранее неизвестной группы киберпреступников. Отчет CrySyS Lab о проведенном исследовании можно найти здесь. Наш анализ представлен ниже. Основные результаты исследования: • Организаторы атак с использованием MiniDuke по-прежнему активно действуют: известны образцы созданного ими вредоносного ПО, датируемые 20 февраля 2013 года. Для заражения компьютеров жертв злоумышленники использовали чрезвычайно эффективные методы социальной инженерии: целям атак отправлялись вредоносные PDF-файлы, содержание которых подбиралось очень тщательно и было чрезвычайно актуальным для потенциальных жертв. Это была сфабрикованная информация о семинарах по правам человека (ASEM), а также о внешней политике Украины и ее планах вступления в НАТО. Эти вредоносные PDF-файлы содержали эксплойты для уязвимостей, имеющихся в версиях 9, 10 и 11 Adobe Reader, которые обеспечивали обход встроенной в Adobe Reader «песочницы». • После успешного срабатывания эксплойта на компьютер устанавливался загрузчик очень маленького размера (около 20 КБ). Для каждой заражаемой системы создавался свой уникальный загрузчик, содержащий адаптированный для данной машины бэкдор, написанный на ассемблере. Запускаясь в процессе загрузки системы, загрузчик путем математических расчетов определял уникальный идентификатор (fingerprint) системы. В дальнейшем эти данные использовались для шифрования передаваемых данных с применением уникальных ключей. • Если целевая система отвечала заранее определенным требованиям, вредоносная программа использовала Twitter (без ведома пользователя): она искала определенные твиты, размещенные заранее созданными аккаунтами, которые были созданы операторами командных серверов. Твиты содержали определенные теги, которыми помечались зашифрованные URL-адреса, предназначенные для использования бэкдорами. По этим URL-адресам находились командные серверы, от которых бэкдоры могли получать команды и которые обеспечивали загрузку на компьютеры жертв дополнительных бэкдоров, зашифрованных в составе GIF-файлов. • Анализ показал, что создатели MiniDuke используют динамическую резервную систему связи, которая также защищена от обнаружения защитными программами: если Twitter не работает или соответствующие учетные записи отключены, вредоносная программа может использовать поиск Google для получения строк, содержащих зашифрованный адрес командного сервера, с которого можно получить новые команды. Это гибкая модель, позволяющая операторам при необходимости постоянно менять способ получения бэкдорами новых команд и вредоносного кода. • Установив соединение с командным сервером, зараженная система получала от него зашифрованные бэкдоры, обфусцированные как GIF-файлы, отображаемые на компьютере жертвы как изображения. Будучи загруженным на компьютер, такой бэкдор мог загрузить еще один бэкдор большего размера, который выполнял задачи кибершпионажа с помощью таких функций, как копирование файла, перемещение файла, удаление файла, создание папки, остановка процесса. Конечно, он также мог загружать и запускать на выполнение новые вредоносные программы и средства дальнейшего распространения по сети. • Последняя ступень бэкдора устанавливала соединение с двумя серверами, один из которых находился в Панаме, а другой – в Турции, и получала от злоумышленников дальнейшие инструкции. • Злоумышленники оставили в коде небольшую «зацепку» в виде числа 666 (0x29A hex) перед одной из подпрограмм расшифровки: • Анализ логов командных серверов позволяет говорить о наличии 59 уникальных жертв в 23 странах: Бельгии, Бразилии, Болгарии, Чешской Республике, Грузии, Германии, Венгрии, Ирландии, Израиле, Японии, Латвии, Ливане, Литве, Черногории, Португалии, Румынии, Российской Федерации, Словении, Испании, Турции, Украине, Соединенном Королевстве и США. Подробный анализ и информацию о способах защиты от данных атак можно найти в следующем материале: [The MiniDuke Mystery: PDF 0-day Government Spy Assembler 0x29A Micro Backdoor.PDF]
обязательно прочту полный отчет.вот это пиздец что тут сказать. однако не въехал во все моменты.во-первых какие и зачем нужны калькуляции для выявления подходящей машины для АССЕМБЛЕРНОГО коня? во-вторых загружаемые гифки,ну да помню была бага в осле такая которая позволяла через гифку запилить шелкод,ну ,а тут то что?бага в вьювере?у всех по дефолту разные вьюверы.или там извлекается эта гифка откуда то,короче не совсем понятно. в остальном-сок!поглазеть бы на сорцы хоть чуть)
Я думаю калкуляции нужны для присвоения уникального идентификатора компу, чтобы передать его на управляющий сервер где он будет записан, т.е должна быть некая база взломанных компов, в такой базе будут записаны эти идентификаторы, когда вирь обратится на командный сервер он пойдет искать свой уникальный идентификатор, чтобы исполнять то что нужно конкретно ему... На счет гифок, как я понял дело не в уязвимости гифа, а в том что они просто замаскировали код виря в файле гиф изображения, по моей версии изначальный загрузчик содержит код расшифровки шифрованных кодов из гиф файлов, т.е лоадер качает другую вирь и сам его достает из гиф файла, юзер не причем.. Хорошая штука, но нечем восхищаться, все логично и супер-просто, ничего нового, я такую фигню в 2010ом делал, когда даже не знал что означают такие слова как "бэкдор", "троян", "лоадер".. просто садишься программировать и думаешь как тебя будут искать, как можно провалиться, и что тебе конкретно нужно, код сам придет в башку, так всегда и во всем, главное намерение - остальное от бога!
нихера ты про гифку загнул.сам то понял?гифка это изображение,а не контейнер,там нельзя "хранить".мля если найду или вспомню суть работы этой методики-напишу.а так да,все просто,сел-нахерячил 10к строк на ассемблере,нашел 0-дэй тоже сам,додумался как его эксплуатировать в обход песочницы и все.проще некуда ага)
Может быть он делал свои картинки примерно 10 штук. Где вместо инфы по камере была часть кода и из каждой такой картинки получали эти данные и соединялись.
короче суть работы вот в чем: через т.н. heapspray выполнялся шелл-код,который заставлял скачиваться гифку,в которой был зашифрован пэйлоад,который расшифровывался и исполнялся шелл-кодом.