Історія бойового трояна Stuxnet не закінчилася атакою на військовий завод в Ірані, де таємно вироблялося ядерну зброю. Восени минулого року фахівці з безпеки виявили троян Duqu, в коді якого впізнається почерк загадкових авторів Stuxnet. Duqu виявився не менш цікавим об'єктом для вивчення: досить сказати, що один з його компонентів написаний на мові програмування, який не вдалося впізнати аналітикам "Лабораторії Касперського".

Зараз майже ніхто не ставить під сумнів те, що метою Stuxnet було руйнування промислової лінії, імовірно використовується для незаконного виробництва ядерної зброї. Незважаючи на відсутність безпосередніх доказів, антивірусні компанії зібрали достатньо доказів на користь цієї версії. Ось що було відомо в листопаді 2010 року:

За відомостями Symantec, черв'як Stuxnet розшукував специфічні промислові перетворювачі частоти, вироблені тільки двома компаніями: одна в Фінляндії, інша - в Ірані. Програма стежила за роботою перетворювачів, і якщо частота виявлялася в діапазоні від 807 до 1210 герц, брала управління на себе. Частотні перетворювачі можуть використовуватися для чого завгодно, але така висока частота вказує на одне конкретне застосування - центрифуги для збагачення урану.

Захопивши контроль над центрифугами, троян давав їм такі команди, які приводили до пошкодження обладнання.

Що з цього випливає? По-перше, автори Stuxnet мали докладною інформацією про те, як влаштований секретний іранський завод, яке програмне забезпечення там використовується і як налаштоване обладнання. По-друге, у них були ресурси для налагодження своєї програми, для чого бажано мати в розпорядженні ті самі рідкісні центрифуги.

У світі не так вже й багато організацій, здатних спорудити промислову лінію для збагачення урану заради того, щоб налагодити троян, і при цьому знайомих з іранськими секретами. Очевидно, що Stuxnet не міг бути справою рук одинака. Швидше за все, він був створений за участю спецслужб однієї з ворожих Ірану країн.

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

Цікава деталь: як видно, Duqu не здатний поширюватися самостійно. В кінці листопада 2011 року компанія Symantec повідомляла про те, що зафіксувала всього шість випадків зараження: два - в Ірані і по одному в Індії, Судані та В'єтнамі. Крім того, заражені комп'ютери у Франції, Нідерландах, Швейцарії та Україні, належать одній і тій же компанії або організації. Інші антивірусні компанії фіксували зараження в Австрії, Угорщині, Індонезії, Великобританії і ще кілька знову-таки в Ірані.

У виконуваному файлі Duqu міститься фотографія стикаються галактик У Symantec вважають , Що автори Duqu мали доступ до вихідного коду Stuxnet. Деякі частини Duqu дуже схожі на Stuxnet, однак компонентів, призначених для взаємодії з системою управління підприємством, в ньому немає. Замість них троян забезпечений засобами для збору інформації про комп'ютер і записи натискань на клавіші (keylogger).

Фрагмент, написаний на невідомій мові програмування, переховувався як раз в тій частині трояна, яка відрізняє Duqu від Stuxnet. Він завідував взаємодією між зараженої машиною і командним сервером Duqu. Сьомого березня "Лабораторія Касперського" звернулася до мережевого співтовариства і попросила допомогти визначити походження коду, який в компанії назвали "фреймворками Duqu":

У коді фреймворками Duqu простежуються явні особливості:

• Весь функціонал реалізують об'єкти.
• Таблиця функцій об'єкта знаходиться безпосередньо в його пам'яті і може бути змінена в процесі виконання.
• Немає явних відмінностей між класами, які можна було б віднести до будь-якої стандартної бібліотеці (зв'язкові списки, хеш-таблиці), і класами троянця.
• Об'єкти спілкуються між собою за допомогою прямих викликів їх методів, відкладених викликів і об'єктів для зворотного виклику по події.
• Не використовуєте стандартних бібліотек, при цьому активно використовуються функції Windows API.

Всі об'єкти є екземплярами будь-якого класу, ми виявили в коді 60 різних класів. Кожен об'єкт створюється за допомогою функції-конструктора, яка виділяє пам'ять, заповнює таблицю функцій і ініціалізує поля.

Розташування полів в пам'яті об'єкта залежить від конкретного класу. Наприклад, не у всіх класів таблиця функцій знаходиться на початку. При цьому у деяких класів бінарному сумісні таблиці функцій, але прямих вказівок на наявність у них загального класу-предка, як в інших об'єктно-орієнтованих мовах, не виявляється.

Об'єкти видаляються за допомогою функцій-деструкторів. Типовий деструктор видаляє об'єкти-поля, потім звільняє пам'ять самого об'єкта.

Методи класів можуть викликатися за вказівником з таблиці функцій (аналогічно «віртуальним» функцій C ++) або безпосередньо. У більшості об'єктно-орієнтованих мов методи отримують параметр «this», при цьому порядок передачі цього параметра зазвичай фіксований - в певному регістрі або параметрі в стеці. Однак для класів фреймворка Duqu цей порядок не фіксований - параметр може передаватися в будь-якому регістрі або в стеку.

Реалізація та утримання об'єктів в фреймворками Duqu не сумісні з об'єктами C ++, які використовуються в усіх інших компонентах Duqu. Однак є ще одна особливість, яка активно використовується у фреймворку, - парадигма подієво-орієнтованого програмування.

Якщо всі інші компоненти Duqu були написані на C ++, то для "фреймворк" виразно використовувався якийсь іншу мову програмування. У "Лабораторії Касперського" перебрали і відкинули безліч варіантів. Всі мови і компілятори, які вони зазнали, - Objective C, D, Go, Java, Ada, Python, Lua, Haskell, Erlang - генерували код, зовсім не схожий на код Duqu.

Дизасемблювати код Duqu: функція конструктора класу зв'язного списку

Звернення до товариства було вірним кроком. Більшість запропонованих ідей виявилися помилковими, але в підсумку комусь вдалося натрапити на зачіпку. Спочатку один з коментаторів припустив, що код все ж згенерований Visual Studio: в дизасемблювати коді простежувалися характерні особливості компілятора Microsoft. Однак це не C ++ і не звичайний Сі, а, як підказав хтось ще, один з об'єктно-орієнтованих діалектів Сі.

Сьогодні експерт "Лабораторії Касперського" відзвітував в блозі компанії про розгадку таємниці "фреймворками Duqu":

Після декількох експериментів з різними версіями MSVC і опціями компіляції мені вдалося відтворити код функції конструктора, про який я писав в попередньому пості, і отримати з цього коду бінарний код, що співпадає зі знайденим в Duqu.

При компіляції зазначеного вище коду на Сі з допомогою компілятора з поставки MSVC 2008 за опціями / O1 (оптимізація за розміром) і / Ob1 (розгортати тільки __inline функції) виходить машинний код, що співпадає з оригінальним кодом цієї функції в Duqu. Слід зауважити, що інші опції компіляції, а також зміна порядку операції і if / else блоків змінює кінцевий код; компілятор MSVC 2005 також генерує інший код. З цього випливає, що, швидше за все, Фреймворк Duqu було скомпільовано MSVC 2008 за опціями / O1 / Ob1 з вихідного тексту на мові С.

Відновлений вручну код конструктора класу зв'язного списку на мові С

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

Напрошуються два висновки. По-перше, авторство "Фреймворк Duqu" належить окремій групі розробників, інакше пояснити таку разючу відмінність "фреймворк" від інших компонентів нічим. По-друге, як зауважує Ігор Суменков з "Лабораторії Касперського", ця група, швидше за все, складається з професіоналів, який використовують напрацювання програмістів "старої школи" з багаторічним досвідом роботи.

Розв'язка трохи розчаровує. Сі з хитромудрим препроцесором не настільки цікавий, як невідомий мову програмування. Втім, навіть так ця історія залишається більш захоплюючою, ніж звичайні історії про віруси, - особливо історії того сорту, де текст перемежовується з асемблером.