1. Зміст статті Антивіруси 90-х дуже серйозно ставилися до проблеми буткіти. Їх автори радили не забувати...
2. Від концепту до «серійного» зразка
3. І знову концепти
4. захист Windows
5. Любитель культових фільмів
6. Нові горизонти
7. Продовжувачі справи TDL
8. Найскладніший, але не самий потайний
9. всюдисущі китайці
10. злив року
11. замість BIOS
12. Що день прийдешній нам готує?

Зміст статті

Антивіруси 90-х дуже серйозно ставилися до проблеми буткіти. Їх автори радили не забувати дискету в дисководі А :, вони завжди перевіряли цей диск перед вимиканням комп'ютера. Раптово «завантажувальні віруси» з минулого в нашому об'єктивному цьому знову опинилися на коні! Подивимося, якого рівня розвитку вони зараз досягли.

першовідкривачі жанру

Одним з перших вірусів для платформи IBM PC, що працюють в середовищі MS-DOS, був Brain, створений в 1986 році. Вірус Brain не була файловим, а завантажувальним - він інфікував 5-дюймові дискети, так як вінчестери тоді ще не були широко поширені. Після зараження шкідливий код поступово заповнював весь вільний простір дискети, так що використовувати її ставало неможливо. Автори Brain - брати Басить Фарух Алві і Амджад Фарух Алви з Пакистану, які вирішили написати програму для захисту своїх медичних програм від піратів. Вони навіть розмістили в коді програми свої адреси і телефони - щоб отримати кошти видалення Brain.

Однак потім, коли поширення вірусу прийняло масштаби епідемії, брати Алві під шквалом телефонних дзвінків були змушені змінити місце роботи і номери телефонів. На цьому їх досвід вирусописательстве і закінчився.

У 1987 році з-під пера одного студента з Нової Зеландії вийшов черговий вірус, що заражає MBR дискет і жорстких дисків. Назва йому дали Stoned, так як при завантаженні комп'ютера вірус в одному випадку з восьми виводив повідомлення: «Your PC is now Stoned!» - «Ваш комп'ютер зараз балдеет!». Крім того, всередині коду вірусу містився заклик до легалізації марихуани (Legalise Marijuana). Stoned на початку 90-х років довгий час турбував сисадмінів по всьому світу. Сам вірус за нинішніми мірками був зовсім маленьким - всього 512 байт (один сектор). Оригінальний сектор зберігався в іншому місці диска, його розташування було різним для дискети та вінчестера. В процесі роботи перехоплює переривання 13h (дискові операції BIOS), що дозволяло визначати моменти роботи ОС з дискетою і заражати її в цей час. Тоді ніхто не міг припускати, що через двадцять років ідеї, реалізовані в Brain і Stoned, знайдуть своє друге народження у вигляді буткіти - шкідливих програм, що приховують свою присутність в надрах операційної системи, отримуючи управління до її завантаження. Мало того, один з концептуальних проектів так і називається в честь свого попередника - Stoned bootkit.

Від концепту до «серійного» зразка

Появі in the Wild перших oбразцов malware, що використовують техніку отримання управління до моменту завантаження Windows, передували кілька концептуальних напрацювань. По-перше, це проект BootRoot (працював на системах Windows 2000 / XP), представлений на конференції Black Hat USA 2005 Дереком Седер (Derek Soeder) і Райаном Пермехом (Ryan Permeh) з компанії eEye Digital Security . По-друге - робота Vbootkit (демонстрація роботи на Vista RC1 / RC2) від Найтіна і Вайпіна Кумар (Nitin і Vipin Kumar), індійських дослідників систем безпеки з компанії NVlabs . Доповідь про Vbootkit був представлений на конференціях Black Hat і Hack in the Box в 2007 році і демонстрував можливість обходу захисних механізмів ОС Vista - перевірку цифрових підписів завантажуваних драйверів.

«Класичним» представником буткіти прийнято вважати Mebroot - шкідливий, перші штами якого були виявлені антивірусними компаніями в кінці 2007 року. Mebroot використовував численні запозичення з проекту BootRoot. Аналіз першого покоління Mebroot (version 0) показав, що ботнет на його основі працював в тестовому режимі, про що свідчить велика кількість налагоджувальних повідомлень, що відправляються на керуючий сервер. Як відзначають деякі реверсери, в цій версії чітко простежувалося використання при програмуванні методу copy-paste (присутність деякого кількість багів) без чіткого уявлення про роботу окремих ділянок коду. Незважаючи на помилки, Mebroot без коливань можна віднести до розряду hi-tech-шкідників.

В інтернеті Mebroot часто називають Sinowal, тоді як Sinowal (aka Torpig або Anserin) - відоме з 2005 року сімейство троянських програм, на базі яких формувався ботнет. Головна мета цього ботнету - крадіжка інформації для організації несанкціонованих банківських операцій. Так що Mebroot - це завантажувач Sinowal.

Встановлював Mebroot дроппер розміром від 250 до 350 Кб в ранніх версіях і до 430 Кб в більш пізніх. Рання версія Дроппер заражала жорсткий диск через 20 хвилин, а ще через 20 викликала перезавантаження ОС. Прямий доступ до диска в цій версії здійснювався стандартними функціями WinAPI, а саме викликом CreateFile з відкриттям пристрої \ Device \ Harddisk0 \ DR0 (в більш пізніх версіях - \ ?? \ RealHardDiskN і \ ?? \ PhysicalDriveN). Причому прямий доступ до диска здійснювався з ring 3 (НЕ ring 0!) При наявності прав адміністратора. Починаючи з вісти, прямий доступ до диска з призначеного для користувача режиму був заблокований, і Mebroot version 1, активно розповсюджується в лютому 2008-го вже в робочому режимі, для запису використовував завантаження власного драйвера, що виконував роль перехідника до системного драйверу disk.sys.

Компоненти буткіта розміщувалися в наступних місцях диска:

• сектор 0 - завантажувач;
• сектор 60 - патчер файлів ОС;
• сектор 61 - код, який відповідає за завантаження шкідливого драйвера;
• сектор 62 - оригінальна MBR з сектора 0;
• останні невикористовувані сектора (близько 650) - шкідливий драйвер.

Ініціалізація Mebroot при перезавантаженні ОС відбувалася в кілька етапів (див. Рис. 1):

Мал. 1. Етапи завантаження Mebroot

1. Завантажувач виділяв 2 кілобайт пам'яті і переміщував свій код з адреси 0x7C00 в 0x0000.
2. Вміст секторів 60 і 61 завантажувалося в виділену область пам'яті.
3. Оброблювач переривання 13h перехоплювати (встановлювався на адресу 0x004D).
4. За адресою 0x7C00 завантажувалася оригінальна MBR з сектора 62, і управління передавалося їй.
5. Перехоплювач переривання 13h відстежував момент завантаження модуля osloader (частина ntldr) за допомогою пошуку певного сигнатури і модифікував його.
6. Пропатченний osloader виконував шелл-код (сектор 60), який шукав і підміняв в ntoskrnl.exe функцію nt! IoInitSystem.
7. Пропатченний ntoskrnl.exe виконував шелл-код (сектор 61).
8. Шелл-код в ntoskrnl.exe виконував завантаження шкідливого драйвера, що зберігався в останніх секторах.

Mebroot досить успішно приховував свою присутність в системі від антивірусних програм, тому що не чинив ніяких змін в файлової системі і реєстрі, за винятком збереженої в зашифрованому вигляді корисного навантаження. Вона скачували шкідливим драйвером, які реалізують прихований канал передачі даних на основі перехоплення функцій NDIS драйвера мережевої підсистеми, що дозволяло успішно обходити файрвол. Крім того, драйвер відповідав за механізми приховування і самозахисту, перехоплюючи функції дві функції з disk.sys: IRP MJ READ і IRP MJ WRITE. Перша дозволяє приховувати справжній вміст використовуваних буткіта секторів жорсткого диска при їх читанні, а друга запобігала перезапис MBR.

Для взаємодії з керуючими серверами, крім жорстко заданого імені, використовувався механізм динамічного формування доменних імен (DGA - Domain Generation Algorithm). В якості вихідних даних бралася поточна дата, що отримується з системи, а в пізніх версіях - шляхом парсинга тимчасових міток у відповідях серверів Google. Канал передачі даних шифрувався. Корисне навантаження представляла собою зашифрований контейнер, що містить дві DLL і інструкції, в які процеси довантажувати другу з них (перша впроваджувалася в процес services.exe). Контейнер піддавався розшифровці, потім знову шифрувався іншим ключем і зберігався в каталозі% System% у вигляді файлу, ім'я якого вибирається з наявних в цьому каталозі файлів, а розширення випадкове. DLL, впроваджена в процеси браузерів, на льоту модифікувала HTML-сторінки банківських сайтів (шляхом впровадження iframe і jscript) і перехоплювала банківські реквізити доступу (логіни та паролі), які знову-таки в зашифрованому вигляді відправлялися на сервери зловмисників.

По ходу розвитку версій Mebroot видно, що його розробники пильно стежили за випуском засобів лікування від виробників антивірусів, аналізували використовувані методи виявлення і оперативно реагували випуском нових версій, знову невидимих ​​для антивірусів і з апгрейдом алгоритмів самозахисту. Так, у версії березня 2008 року перехоплювалися вже всі функції з disk.sys, а за їх зміною стежив окремий потік (watchdog). Якщо будь-яка антивірусна утиліта намагалася «повернути все як було», перехоплення відновлювалися і диск заражався повторно.

У квітні 2009 року Mebroot вже освоїв і новомодну на той момент Windows Vista.

І знову концепти

Детальний аналіз коду Mebroot можна знайти на сайті stoned-vienna.com авторства Пітера Клайснера (Peter Kleissner), який, мабуть, під враженням від виявленого, вирішив замутити свій буткіт з блекджек і повіями, в сенсі - взявся за розробку свого проекту Stoned Bootkit, представленого на Black Hat USA 2009. Сам Пітер Клайснер стверджує, що його проект носить чисто дослідницький характер і допомагає співробітникам антивірусних лабораторій розробляти нові методи протидії таким видам малварі. В кінцевому підсумку проект Stoned Bootkit став настільки популярним, що його повні останні версії, під тиском антивірусних компаній, не викладаються у відкритий доступ, а public lite версія досить сильно урізана в плані функціональності. Як показали подальші події, Stoned Bootkit став чудовою відправною точкою для багатьох зловмисників, які вирішили наділити свої вироби функціями буткіта. Ось, наприклад, Whistler Bootkit. Якісь заповзятливі товариші взяли Stoned v2 Alpha 3 від 20 жовтня 2009 року, підрихтували напилком і на початку 2010 року стали пропонувати до продажу. В якості реклами в одному з блогів була розміщена інформація про новий цікавий Бутко, який запускав шкідливі файли з каталогу C: \ System Volume Information з правами NT-AUTHORITY \ SYSTEM.

У тому ж 2009 році Найтін і Вайпін Кумар в рамках минулої в Дубаї конференції Hack In The Box продемонстрували Vbootkit версії 2.0, на цей раз заточений під Windows 7 x64. Застосовані в ньому методи дозволили успішно нейтралізувати дію механізмів PatchGuard і Driver Signing Policy, які не давали модифікувати ряд системних об'єктів для реалізації перехоплень функцій і завантажувати непідписані драйвери, щоб отримати можливість виконання коду в режимі ядра. Спочатку викладені під ліцензією GPL вихідні коди проекту Vbootkit спіткала доля початкових кодів Stoned Bootkit - вони точно так само були випив, щоб не плодити чергову натовп скріпткіддісов. Однак зацікавлені в темі особи необхідні для своєї чорної роботи матеріали все одно встигли отримати, і все заверте ...

Крім власне проекту Stoned Bootkit, на сайті stoned-vienna.com в розділі статей знаходяться кілька матеріалів, присвячених дослідженню та аналізу деяких зразків malware. Ось, наприклад, аналіз однієї з китайських виробів - товариші з КНР уважно вивчили Mebroot і прикрутили функції буткіта до свого трояни зі звучною назвою Ghost Shadow, скорочений аналітиками Microsoft до Ghodow. Одержаний гібрид, виявлений Symantec в березні 2010 року, відомий під назвою Trojan.Mebratix.B. Хоча окремі ділянки його коду начисто злизаний з Mebroot, деякі особливості були досить цікавими. Так, для зменшення ймовірності виявлення зі зміни MBR Mebratix НЕ переписував його цілком, а лише змінював аргументи інструкції mov, що знаходиться по зсуву 00D0h від початку завантажувального коду таким чином, щоб читання сектора і передача управління відбувалася не в перший сектор завантажувального розділу, а в другій сектор диска, який містить продовження Mebratix. Ця частина завантажувального коду виконувала читання 59 секторів жорсткого диска (починаючи з другого сектора) в пам'ять. У цих секторах зберігалися всі інші компоненти буткіта, причому сектора з другого по четвертий були зашифровані за допомогою операції Xor, ключ для якої обчислюється динамічно на кожній ітерації отримання чергового значення байта. Починаючи з п'ятого сектора зберігався драйвер розміром близько 17 Кб. Призначення драйвера буткіта - впровадження коду призначеного для користувача режиму в процес explorer.exe і установка перехоплень на обробники IRP-запитів типу IRP MJ READ / IRP MJ WRITE драйвера класу диска Disk.sys. Зазначені перехоплення забезпечували захист секторів диска, в яких зберігалися компоненти буткіта, від спроб читання або перезапису.

захист Windows

Активним просуванням технологій x64 на ринку десктопних операційних систем компанія Microsoft почала займатися з версії Windows Vista. Справедливості заради слід згадати про існування XP x64, яка в останній своїй редакції була зібрана з коду Windows Server 2003. Крім явної переваги у вигляді підтримки кількості оперативки, понад 4 Гб, в 64-бітних системах з'явилося кілька технологій, спрямованих на захист від впливу шкідливого ПО. Одна з них - PatchGuard, яка відстежує зміну критичних об'єктів ядра ОС, таких як:

• таблиця глобальних дескрипторів - GDT;
• таблиця дескрипторів переривань - IDT;
• таблиця дескрипторів системних сервісів - SSDT;
• деякі системні файли, наприклад NTOSKRNL.EXE, NDIS.SYS, HAL.DLL;
• службові MSR-регістри STAR / LSTAR / CSTAR / SFMASK.

При завантаженні, в рамках функціонування PatchGuard, ОС підраховує контрольні суми для зазначених вище об'єктів, зберігає їх і періодично перевіряє відповідність поточних значень зі збереженими. Виявивши модифікацію об'єктів (зі зміни контрольної суми), ОС аварійно завершує свою роботу з викликом BSOD. Крім PatchGuard, з'явився ще один захисний механізм - заборона завантаження драйверів, які не мають валидной цифрового підпису (Driver Signing Policy).

Механізми PatchGuard і Driver Signing Policy значно ускладнили життя розробникам шкідливих програм з функціями руткита, які працюють в режимі ядра. Це змусило зловмисників шукати обхідні шляхи для забезпечення функціонування своїх шкідливий в кінцевому підсумку призвело до виникнення особливого класу malware - bootkit (поєднання слів boot і rootkit).

Любитель культових фільмів

Прапор hi-tech-шкідників успішно підхопило сімейство TDL, трансформувалося в буткіт в версії TDL4 (aka Tidserv або Olmarik по ESET - і де вони такі назви беруть?). Цікавий факт про TDL: у авторів відмінне почуття гумору, в коді зустрічаються налагоджувальні рядки - цитати з культових кінотворів ( «Бійцівський клуб», «Сімпсони», «Страх і ненависть в Лас-Вегасі», «Форест Гамп», «Зоряні війни» та інші). За неперевіреною інформацією, за створенням TDL перших трьох версій стояла людина з ніком Tyler Durden, а TDL розшифровувався як Tyler Durden Loader (хоча з рівним успіхом він міг би розшифровуватись Trojan DownLoader - версії такі версії). Припускають, що Tyler Durden був одним із співробітників компанії Comodo. Бізнес на базі TDL3 було вирішено згорнути після злому співробітниками Esage Lab командних серверів TDL3 і партнерської програми Dogma Million , Що призвело до витоку бази клієнтів, яка спочатку ходила в публічному чаті, а потім потрапила в руки відділу До літа 2010 року. TDL4 розроблявся іншими кодерами з вихідних третьої версії, купленої за 65 тисяч доларів.

Так чи інакше, в липні 2010-го виходить TDL4 0.01, а вже в серпні 2010-го - TDL4 0.02 з підтримкою x64 операційних систем, ставши першим зразком malware такого виду, виявленим In The Wild. Проект Stoned Bootkit отримав підтримку платформ x64 тільки в 2011 році.

Підхопивши вдалу ідею Mebroot про зберігання своїх компонентів поза файлової системи, розробник TDL ще в третій версії розвинув її до концепції сховища з віртуальної файлової системою. Доступ до сховища забезпечувався драйвером-руткітом, який, крім того що мав функціями приховування і самозахисту, створював віртуальний пристрій, що дозволяло при роботі з файлами використовувати стандартні функції WinAPI, такі як CreateFile (), WriteFile (), ReadFile (). Компоненти TDL4 зберігалися в спеціальній області (розміром не більше 8 Мб) в кінці жорсткого диска. У зашифрованому алгоритмом RC4 сховище розміщувалися основні модулі з іменами ldr16, ldr32, ldr64, конфігураційний файл, а також інші модулі, що завантажуються по мережі. Код в MBR передавав управління компоненту ldr16. Після передачі управління ldr16 перехоплював функції роботи з жорстким диском. Для завантаження TDL4 використовувалася підміна файлу kdcom.dll (шляхом установки перехоплювача на Int 13h і пошуку певної сигнатури kdcom.dll), який необхідний для ініціалізації ядра на стадії завантаження. Замість kdcom.dll в результаті завантажувався шкідливий компонент ldr32 або ldr64 в залежності від розрядності цільової ОС. Бінарний код ldr32 і ldr64 практично ідентичний, так як він скомпільовано з одних початкових кодів.

Версія TDL4 0.03, яка вийшла у вересні 2010-го, для підвищення своїх привілеїв в системі використовувала експлуатацію уразливості в Task Scheduler, закриту патчем MS10-092. При цьому Windows XP не заражають, в ній дроппер просто завершував свою роботу.

Нові горизонти

Існуючі до 2011 року буткіті змінювалі компоненти ОС в процесі завантаження, перехопівші переривані BIOS 13h. А тим часом ця техніка вікорістовувалася ще за часів MS-DOS, и їй властіві певні недоліки: перехопленій обробнік віповнюється только до завантаження ядра, так як далі переривані BIOS Вже НЕ Використовують, кроме того, сигнатурної поиск потрібного модуля может НЕ спрацюваті, если шуканій патерн буде знаходітіся между двома секторами. Тому два студента Австрійського університету прикладних наук Вольфганг Етлінгер (Wolfgang Ettlinger) и Стефан Фібек (Stefan Viehbëck) пораскінул мізкамі и Прийшли до висновка, что можна задіяті таку фічу, як багатоядерність СУЧАСНИХ процесорів. Нехай завантаження відбувається на одному ядрі, а на другому в цей час буде крутитися шкідливий код, який і буде патчить компоненти ОС. Прототип буткіта, побудованого на цьому принципі, був представлений на NinjaCon 2011 року під кодовою назвою EvilCore. У загальних рисах алгоритм роботи його був наступним:

• після завантаження шкідливої ​​MBR EvilCore відключається режим Symmetric Multi Processing, який обмежує число процесорних ядер в ОС;
• зменшується розмір пам'яті, доступний ОС;
• код переноситься в кінець фізичної пам'яті, яка не використовується ОС, сам при цьому залишиться активним в кеші CPU;
• на ядрі CPU0 управління передається завантажувачу ОС, а на CPU1 залишиться активним код EvilCore в режимі ядра і з повним доступом до всієї фізичної пам'яті.

А ось як відбувається зміна коду ядра:

• в точку входу вставляється нескінченний цикл у вигляді інструкції jmp;
• поки CPU0 працює вхолосту, можна виробляти необхідні модифікації;
• після зміни нескінченний цикл вставляється в наступний блок коду;
• точка входу відновлюється.

Приклад патча наведено на рис. 2.

Мал. 2. Як EvilCore модифікує пам'ять

При демонстрації прототипу вказувалося на такі недоліки: мінус одне ядро ​​в task manager (палево!) І зниження продуктивності. Перша проблема легко вирішується, доступ до пам'яті є, тому число CPU можна просто підправити. Рішення другої теж тривіально: після патча компонентів ОС завершити виконання шкідливого коду і звільнити ядро ​​процесора. Поки ці напрацювання в «маси" не пішли, тому в даний час зразків malware, створених за зразком EvilCore, в «дикому вигляді» не виявлено.

Продовжувачі справи TDL

TDL згодом придбав багато приймачів. Чергова кіберзлочинністю угруповання (будемо називати її Pragma, такі ідентифікатори містилися в їхньому коді) прибрала до рук вихідні TDL3 і TDL4 і стала клепати свої альтернативні версії цих шкідників під назвою SST або MaxSS (Olmasco по ESET). Наступність кодів TDL привела до того, що в класифікації багатьох антивірусних вендорів панує повна плутанина і, по суті, різні сімейства продовжують іменуватися як їх предок (TDL, TDSS або Tidserv). Продаж електронних ваучерів TDL4 не привела до його зникнення, цей проект продовжив розвиватися паралельно проекту SST.

TDL3 based варіант SST (із зараженням драйвера) поширювався з початку 2011 року до початку літа, коли пішли завантаження тестової версії SST на базі TDL4 із зараженням MBR. На те, що це тестова версія, вказував великий обсяг трасувань логів, що відправляються на C & C під час установки, а також численні повідомлення про помилки, які буткіт відправляв під час своєї роботи. З фішок співробітники компанії Microsoft відзначили дуже цікавий спосіб «резервного» каналу відновлення зв'язку SST зі своїми командними серверами. Конфігураційний файл з їх адресами містився в файлах формату JPG, які розміщувалися на хостингу imageshack.us. Посилання на такі зображення містилися в постах, опублікованих на популярних блогерських майданчиках livejournal.com і wordpress.com.

Так чи інакше, тестова версія в серпні була замінена новою і містила в собі вже дещо інший спосіб отримання управління при завантаженні (див. Рис. 3). Виконуваний код MBR не змінився зовсім, а сховище файлів організовувалося не просто в останніх секторах диска, а у вигляді окремого розділу розміром до 15 Мб. Прапор активного розділу змінювався з завантажувального розділу ОС на розділ SST. Файлова система розділу зі сховищем в цілому повторювала ФС TDL4, проте містила деякі поліпшення, зокрема було прибрано обмеження на 15 файлів, а самі файли в заголовку містили контрольну суму CRC32. Це дозволяло реалізувати в ФС перевірку на цілісність, в разі виявлення пошкоджень файл віддалявся зі сховища.

Мал. 3. Зміни, що вносяться SST в MBR

В кінці року на сцену виходить форк TDL-4 під неблагозвучним назвою Pihar, який за своїми характеристиками майже не відрізнявся від оригінального TDL-4. У ньому був застосований ряд заходів, що змінюють сигнатурні характеристики компонентів. Наприклад, шифрувався не розподіл цілком, а тільки файл конфігурації. У заголовку цього файлу, до речі, була присутня рядок [PurpleHaze] - по всій видимості відсилання до пісні легендарного Джимі Хендрікса.

Дроппер Pihar використовував для своєї установки метод DLL hijacking із застосуванням легального установника Adobe Flash Player. Цю ж фішку використовував ZeroAccess, хіба що імена бібліотек розрізнялися (ncrypt.dll замість msimg32.dll).

У 2012 році компанія Damballa представила аналітичний звіт під назвою «A New Iteration of the TDSS / TDL4 Malware Using DGA-based Command-and-Control». У ньому йшлося про те, що виявлений трафік, аналогічний за своїми параметрами сімейства TDL. Він був виявлений за допомогою автоматизованої системи «Плеяди» (Pleiades), призначеної для виявлення малварі, що використовує механізм DGA для зв'язку зі своїми C & C. Подальший аналіз показав, що це дійсно нова модифікація TDL4, його алгоритм генерації доменних імен назвали DGAv14.

За інформацією ресурсу kernelmode.info, нащадки TDL4 з обфусцірованним конфіг (осмислені імена виду ldr16, ldr32, ldr64 замінені числовими рядками) зустрічаються в інтернеті до сих пір.

Найскладніший, але не самий потайний

Звання одного з самих наворочених буткіти слід віддати Gapz. Чого вартий один лише модуль режиму ядра, що містить власну реалізацію стека TCP / IP-протоколу, що дозволяє йому обійти перевірку локальних IPS / IDS при взаємодії з мережею! Цікава особливість шкідливого коду режиму ядра полягає в тому, що він не має структури виконуваного PE-файла. Замість цього він розбитий на кілька функціональних блоків, що мають власні заголовки. У процесі завантаження Gapz аналізує заголовок кожного блоку і викликає його функцію ініціалізації, яка, в свою чергу, виділяє пам'ять і заповнює їх покажчиками на функції блоку, а також різними структурами даних. Блоки модулів могли розміщуватися в секторах або до першого, або після останнього розділу. Сховище payload представляло собою файл (вміст зашифровано AES-256) в каталозі System Volume Information системного диска з ім'ям з випадкових hex-значень. Файлова система сховища - FAT32, реалізація якої була взята з опенсорсний проекту FullFAT.

Gapz має кілька версій, що розрізняються методами завантаження, влітку 2012-го заражалися MBR, а восени - VBR, причому досить цікавим способом. VBR томи NTFS містить в собі структуру даних, звану BIOS Parameter Block (BPB), де вказуються параметри томи. У BPB є поле HiddenSectors, яке вказує на початок Initial Program Loader (IPL) - коду, на який передається керування після VBR. IPL відповідає за пошук завантажувача в файлової системі томи NTFS і його запуск. Зміною 4-байтового поля HiddenSectors Gapz домагається того, що код VBR передає управління не на IPL, а на свій код (см. Рис. 4). Щось подібне використовував Mebratix (зміна декількох байт в MBR для отримання управління і труднощі свого виявлення).

Мал. 4. Gapz отримує управління, змінивши 4 байта BPB

Незважаючи на значну складність, показники скритності Gapz значно менше, ніж у інших представників класу буткіти, хоча б через розміщення сховища всередині файлової системи. До того ж кількість заражених Gapz комп'ютерів в 2012 році обчислювалося всього лише сотнями (більшість з них знаходилося в Росії).

всюдисущі китайці

Намагаються не відставати в технологічній гонці і товариші з Країни сонця, що сходить (в наше століття тотального інтересу до всякого аніме дуже приємно побачити людину, яка вважає Країною сонця, що сходить Китай :). - Прим. ред.).

Свіжий дроппер китайського трояна Guntior (відомий з 2010 року), виявлений влітку 2013 року співробітниками компанії Sophos, порадував черговим трюком обходу проактивного захисту при своїй інсталяції в систему. Сам дроппер спроектований і зібраний таким чином, що може запускатися і як виконуваний файл EXE, і як динамічна бібліотека DLL. Під ім'ям msimg32.dll він копіюється в каталог% Temp% і виставляє прапор в заголовку файлу, який вказує, що це DLL. Також в каталог% Temp% зберігається копія файлу HelpCtr.exe (він імпортує функції з msimg32.dll), який відповідає за відображення «Довідки та підтримки» в Windows. Але це ще не все - для запуску HelpCtr.exe змінна оточення PATH змінювалася так, щоб каталог% Temp% розташовувався раніше, ніж каталог% System%. Сам HelpCtr.ex викликався на виконання шляхом відправки повідомлення WM HOTKEY вікна Shell TryWnd (за замовчуванням довідка викликається комбінацією <Win + F1>). Таким чином, дроппер msimg32.dll довантажувати легітимним файлом HelpCtr.exe (метод dll hijacking), і не викликав спрацьовування проактивного захисту антивірусів. Після відпрацювання файли в% Temp% віддалялися, а змінна PATH відновлювалася до початкового стану. Ще з відмінних рис можна відзначити наявність великого списку процесів антивірусів і захисного ПЗ, які підлягають негайному завершення. Буткіт-компонент Guntior створений на базі вихідних кодів Stoned Bootkit (в Китаї взагалі люблять запозичувати вже працюють готові рішення). Механізм приховування і самозахисту повністю аналогічний Mebroot ранніх версій - перехоплення IRP MJ READ і IRPMJWRITE в disk.sys.

злив року

Carberp. Новини про це банківському трояни публікуються із завидною регулярністю. Навесні завдяки спільним зусиллям Служби безпеки України (СБУ) і Федеральної служби безпеки Росії (ФСБ) на території України були затримані розповсюджувачі і розробники Carberp. А влітку його вихідні тексти витекли в паблік. Близько 5 Гб вихідних текстів (2 Гб в архіві) виявилися доступними для завантаження будь-яким бажаючим. Серед початкових кодів окремий інтерес представляє код буткіта. Carberp з самого початку не мав своєї bootkit-складової до 2011 року, коли розробники купили фреймворк Rovnix. Крім того, в архіві є частина вихідних текстів буткіти Stoned і Sinowal.

Фреймворк Rovnix відомий з 2011 року, тоді він використовувався в якості завантажувача трояна Mayachok (Cidox). Головна особливість Rovnix - зараження не MBR, а завантажувального сектора системного розділу файлову систему NTFS, також званого Volume Boot Record (VBR). Дроппер Mayachok несе в собі як 32-бітний, так і 64-бітний драйвер Rovnix. На диску зберігався відповідний драйвер в залежності від розрядності користувальницької ОС. Він міг бути записаний як в початок диска (до першого активного розділу), якщо там достатньо місця, так і в його кінець. Аналізуючи завантажувальний запис, троянець знаходив місце для свого розміщення і перезаписував наявний там код. Оригінальний код упаковувався за допомогою бібліотеки aPlib і дописувався слідом. Номер початкового сектора розміщеного на диску драйвера і його розмір також «прошивали» в тіло зараженої VBR. На момент виявлення Mayachok співробітники антивірусних компаній не знали, що буткіт був стороннім компонентом і, цілком ймовірно, був куплений. Це встановили тільки після виявлення трояна Carberp з аналогічним модулем. На початку 2012 року ESET виявила модифікацію Rovnix, оснащену поліморфним генератором шкідливого коду, що розміщується в VBR, а також реалізацією зашифрованого за допомогою алгоритму RC6 сховища файлів. Цікаво, що в якості файлової системи використовувалася модифікація VFAT.

Rovnix став першим представником VBR-буткіти. І, проводячи аналогії з ситуацією після зливу початкових кодів Zeus (до речі, розробники Carberp їх активно використовували), слід очікувати сплеску розробок boot-компонентів на його основі.

замість BIOS

На зміну BIOS приходить система UEFI, комплекс специфікацій, що з'явився як «завантажувальний ініціатива Інтел» (Intel Boot Initiative) в далекому вже 1998 році. Ініціатива виникла тому, що обмеження BIOS, такі як 16-бітний виконуваний код, адресується пам'ять 1 Мб, відсутність підтримки завантажувальних дисків більше 2 Тб і інші, стали відчутно гальмувати розвиток обчислювальних систем. Фактично UEFI є якоюсь подібністю операційної системи. На відміну від BIOS, які пишуться на asm, UEFI написана на Сі. Є підтримка графічних режимів роботи відеоадаптера, драйверів пристроїв і мережевого стека. Передбачена підтримка загрузчиков ОС і розмітки диска GUID Partition Table (GPT), що дозволяє відмовитися від концепції завантажувальних секторів і завантажувати ядра ОС засобами UEFI (підтримується в сучасних Linux і 64-розрядних Windows, починаючи з Vista). Ключова фішка UEFI - механізм SecureBoot, який здійснює криптографічний перевірку завантажуваних компонентів ОС за допомогою ключів цифрового підпису, прошиваються в чіпи пам'яті материнських плат.

SecureBoot якраз і нейтралізує цілий клас шкідливий, які отримують управління до завантаження ОС. У той же час співтовариство Linux вважає, що Microsoft створює передумови до монополії завантаження тільки ОС Windows (хоча підкопатися до самої Microsoft не можна - що саме шити в материнську плату, визначають їх виробники). На поточний момент для сертифікації заліза на сумісність з Windows 8 потрібно наявність функції відключення SecureBoot на платформах, відмінних від ARM, а також установки своїх ключів. Але хто знає, як ситуація зміниться в подальшому? В умовах, коли SecureBoot буде включений постійно, а OEM-постачальники будуть прошивати тільки ключі Microsoft, може виникнути ситуація, коли встановити ОС, відмінну від Win, стане неможливо. Втім, співтовариство Linux може підписати свій завантажувач у компанії Microsoft. Як то кажуть, поживемо - побачимо.

Що день прийдешній нам готує?

На хвилі поширення MBR- і VBR-зарази все дружно згадали про UEFI. Поодинокі випадки малварі, що модифікує BIOS (Mebromi в 2011 році), пояснюються тим, що виробників BIOS велика кількість і писати код під значне різноманіття прошивок взагалі не варіант. Інша справа - UIFI, де все уніфіковано. З іншого боку, UEFI написаний на мові Сі, що має на увазі наявність численних помилок переповнення буфера. Італієць Андреа Алльеві (Andrea Allievi), провідний дослідник компанії ITSEC в області ІТ-безпеки, продемонстрував у вересні 2012 року вразливість механізму завантаження Windows 8, розробивши перший повноцінний UEFI-буткіт для цієї платформи. Дослідники ITSEC знайшли уразливість в UEFI і використовували її для заміни UEFI bootloader на свій власний. В результаті механізми захисту Kernel Patch Protection і Driver Signature Enforcement успішно обходяться. Навесні 2013 року на конференції HITB (Hack in the Box) Себастьян Качмарек (Sébastien Kaczmarek) з QuarksLab представив доповідь «Dreamboot: A UEFI Bootkit» і продемонстрував роботу чергового концепту буткіта для Windows 8. Вихідні тексти проекту Dreamboot доступні на github.com.

Слід зазначити, що всі ці напрацювання функціонують при відключеній функції SecureBoot, що дозволило компанії Microsoft з новими силами зайнятися її просуванням. Однак популярність Windows 8 на десктопах поки вкрай мала, програмувати під UEFI - одне задоволення (НЕ асемблер все-таки, а Сі), а це означає, що у творців буткіти ще є час не раз і не два покористуватися ресурсами комп'ютерів які нічого не підозрювали , а інший раз і залізти їм у кишеню. Оскільки пересічний користувач сам не в змозі відправити підозрілі файли на аналіз (хоча б тому, що до файлів буткіти, як правило, з ОС доступ отримати не можна), хочеться побажати, щоб сисадміни корпоративних мереж уважніше ставилися до моніторингу підозрілої мережевої активності (на шлюзі простіше всього відстежити, що якась гидота стукає в інтернет), а антивірусні компанії більш оперативно реагували на появу нових загроз такого типу.