Отже, на нашу думку - в Україні, якоюсь спецслужбою, якоїсь держави була проведена спецоперація, основною ціллю якої була демонстрація можливості перетворити світову економіку в "радіоактивний попіл", за допомогою застосування кіберзброї. І вторинною метою було нанесення шкоди політиці і економіці саме України.
Весь світ говорить про атаку на Україну (основний вектор атаки) новим штамом ransomware, відомого як Petya, NonPetya, etc. Відразу викладемо основну ідею цієї статті і далі перейдемо до її обґрунтування, підтверджуючи кожне припущення фактами. Отже, на нашу думку - в Україні, якоюсь спецслужбою, якоїсь держави була проведена спецоперація, основною ціллю якої була демонстрація можливості перетворити світову економіку в "радіоактивний попіл", за допомогою застосування кіберзброї. І вторинною метою було нанесення шкоди політиці і економіці саме України.
Cui Prodest?
Тут нехай кожен для себе вирішить. В результаті чого були зроблені саме такі висновки? Подивимося на факти чим була атакована Україна.
У антивірусну лабораторію штам вірусу Petya ransomware потрапив ще в 2016 році і був успішно описаний нашою секвенцією (малварне сімейство). Забігаючи вперед зазначу той факт, що комерційні компанії, захищені нашим антивірусним рішенням, в цій епідемії не постраждали.
Вранці, 27 червня 2017 року розпочинається масове зараження комп'ютерних мереж державних і комерційних організацій. За 5-6 годин було уражено до 30% [2] компаній різних форм власності. В цей день до нас надійшли перші зразки нового, як ми на початку вважали, штаму вірусу Petya.
В результаті дослідження коду вірусу фахівцями нашої компанії були встановлені наступні факти та фактори роботи шкідника (далі йде суто технічна частина, не фахівці можуть цей момент перегорнути).
Існує три модифікації цього вірусу (з прив'язкою до історії виникнення даного шкідника), так звані:
- Red Petya - найперша варіація (версія), яку змогли подолати завдяки тому, що в коді реалізації алгоритму Salsa20 існувала помилка/прорахунок програмістів, з огляду на яку криптостійкість падала в рази, що дозволило отримати доступ до коду.
Сенс полягав у тому, що використовуваний крипто-вектор був зменшений компілятором рівно два рази, що призводило до «обертання» не 32 бітних значень, а 16 бітних. Як підсумок, значущі розряди в кріптоключа були лише парні. Також були допущені інші помилки, що дало змогу за допомогою генетичного алгоритму обчислити кріптоключ за 30 секунд.
- Green Petya - друга реалізація (версія), яка усунула попередній «баг» у коді. Однак як виявилося, не всі проблеми коду були усунені і існувала помилка в реалізації перекладу LittleEndian -> BigEndian, яка зменшувала криптостійкість. В даному випадку на отримання ключа витрачалося близько 3-х днів.
- Golden Petya - остання з реалізацій (версія), що й атакувала інформаційні системи приблизно 17 липня 2016 року. У цій версії усунутий і цей «недолік», мало того, число «Сигма», яке використовується для ініціалізації матриці шифровки також було видозмінено.
Перше ж поверхневе вивчення вірусу показало, що даний продукт намагається мімікрувати під Petya. Ретельне ж вивчення привело нашу команду до висновку про те, що спроби написати вірус, схожим на Petya, зроблені нарочито непрофесійно. Ми спеціально виділяємо це твердження, так як вважаємо, що тим самим світовій спільноті був донесений головний меседж цієї атаки.
Отже, перша новина:
При знаходженні певних процесів в пам'яті вірус, замість того, щоб встановити в бутсектор шифрувальник, просто знищує бутсектор на ньому. Це можна побачити за наступною ознакою: perfc_1 (точка входу) виконує всередині себе InitProcess, який в свою чергу виконує FindoutSomeProcesses, ця функція обчислює хеші з імен процесів. При наявності деяких з них виставляється флаг. Цей флаг впливає на поведінку:
if ( !(badFlag & 8) || (result = InstallEncryptor()) != 0 )
result = CorruptVolume();
Тобто при наявності певного процесу, або помилки установки, перші 10 секторів затираються «сміттям».
Друга новина:
Вірус передбачає, що отримає достатньо привілеїв користуючись «ядерним» експлойтом, однак при недостатку прав все ж намагається завдати шкоди, шифруючи файли на диску. Як виявилося, він дбайливо викладає файл README.TXT в кореневому каталозі диска, або щодо свого розташування. В який, як виявилося, в текстовому вигляді потрапляє ключ шифрування файлів. Також його можна знайти в бінарному вигляді в тілі трояна:
.text:10001BF3 03C push offset pszString "MIIBCgKCAQEAxP/VqKc0yLe9JhVqFMQGwUITO6W"...
.text:10001BF8 040 call edi ; CryptStringToBinaryW
.text:10001CC9 034 push dword ptr [esi+14h] ; hKey
.text:10001CCC 038 call edi ; CryptExportKey
.text:10001CCE 020 test eax, eax
.text:10001CD0 020 jz short loc_10001D21
.text:10001CD2 020 mov esi, ds:CryptBinaryToStringW
.text:10001CD8 020 lea eax, [ebp+pcchString]
.text:10001CDB 020 push eax ; pcchString
.text:10001CDC 024 push ebx ; pszString
.text:10001CDD 028 push 1 ; dwFlags
.text:10001CDF 02C push [ebp+pdwDataLen] ; cbBinary
.text:10001CE2 030 mov [ebp+pcchString], ebx
.text:10001CE5 030 push [ebp+pbBinary] ; pbBinary
.text:10001CE8 034 call esi ; CryptBinaryToStringW
Так як ключ використовується в симетричному варіанті, то їм же можна зашифровані файли і розшифрувати, але це за умови, що не виконається фінальна частина шифрування (в бутсекторі).
Третя новина:
Як уже говорилося, помилок в коді багато, з яких:
1. ОС Windows повинна бути встановлена на диск C :.
2. При наявності файлу C:\Windows\perfc.dat самокопіювання трояна не відбудеться і як наслідок, не буде зараження.
Четверта новина:
Нас довго мучило питання, чому, для двох необхідних ключів для дешифрування файлів використовуються випадкові числа, адже за правилами асиметричного шифрування, для отримання гідного кріптоключа на сервер повинен бути переданий ключ, зав'язаний на загальний відкритий ключ. Але як виявилося, дані, які копіюються з основної частини в бутсектор, всього лише фікція. Спочатку ми припускали, що робота криптоалгоритму знаходиться в бутсекторе, але ж там не так багато місця для цього.
Ще раз вивчивши аргументи, наведені в статті https://securelist.com/petya-the-two-in-one-trojan/74609/ ми переконалися в тому, що даних для остаточного висновку недостатньо і вирішили ще раз проаналізувати роботу нового Petya. Більш детальний аналіз показав, на наш подив, що це різновид Golden Petya, перероблена під Red Petya, мало того, з обрізаними частинами.
Висновок:
1. Частина коду, яка відповідає за малювання «черепа» обрізана, це можна бачити по функції, яка наведена нижче:
seg000:86E0 PrintSkuLLAndWait proc near; CODE XREF: MainWindow+6p
seg000:86E0
seg000:86E0 var_1 = byte ptr -1
seg000:86E0
seg000:86E0 000 enter 4, 0
seg000:86E4 006 push si
seg000:86E5 008 xor si, si
seg000:86E7 008 mov [bp+var_1], 0
seg000:86EB 008 jmp short @@SkipSkuLL
seg000:86ED ; ---------------------------------------------------------------------------
seg000:86ED 008 call GetTimeOfDay
seg000:86F0 008 lea cx, [si+1]
seg000:86F3 008 cmp ax, cx
seg000:86F5 008 jbe short loc_8715
seg000:86F7 008 mov si, ax
seg000:86F9 008 cmp [bp+var_1], 1
seg000:86FD 008 jnz short loc_8703
seg000:86FF 008 mov al, 0C0h ; 'L'
seg000:8701 008 jmp short loc_8705
seg000:8703 ; ---------------------------------------------------------------------------
seg000:8703
seg000:8703 loc_8703: ; CODE XREF: PrintSkuLLAndWait+1Dj
seg000:8703 008 mov al, w_red
seg000:8705
seg000:8705 loc_8705: ; CODE XREF: PrintSkuLLAndWait+21j
seg000:8705 008 push ax
seg000:8706 00A call PrintSkuLL
seg000:8709 00A pop bx
seg000:870A 008 cmp [bp+var_1], 1
seg000:870E 008 sbb al, al
seg000:8710 008 neg al
seg000:8712 008 mov [bp+var_1], al
seg000:8715
seg000:8715 loc_8715: ; CODE XREF: PrintSkuLLAndWait+15j
seg000:8715 008 call CheckFroKeyPresed
seg000:8718 008 or al, al
seg000:871A 008 jz short loc_86ED
seg000:871C
seg000:871C @@SkipSkuLL: ; CODE XREF: PrintSkuLLAndWait+Bj
seg000:871C 008 push w_red ; color
seg000:871E 00A call ClearScreenAndSetCursor
seg000:8721 00A pop bx
seg000:8722 008 pop si
seg000:8723 006 leave
seg000:8724 000 retn
seg000:8724 PrintSkuLLAndWait endp ;
Як ми бачимо, безумовний перехід (86EB) переставлено таким чином, що його відображення не відбудеться ніколи.
Досвідчений слідчий відразу ж зверне увагу на те, що якби цей код був написаний авторами оригінального Petya, то компілятор цей шматок коду просто б виключив. Але у даному випадку це говорить про те, що в код вмішались треті особи, у яких початкового коду не було. Тому вони внесли зміни у бінарний код вірусу Petya.
2. Параметр функції, що відповідає за зміну кольору, в деяких місцях виправлений. Так, після успішного введення коду, екран повинен був стати жовтим, як в Gold Petya:
seg000:8212 CodeAcceptedScreen proc near
seg000:8212 000 push yellow; color
seg000:8214 002 call ClearScreenAndSetCursor
seg000:8217 002 pop bx
seg000:8218 000 push offset aPleaseRebootYourComputer ; string
seg000:821B 002 call PrintString
seg000:821E 002 pop bx
seg000:821F 000 retn
seg000:821F CodeAcceptedScreen endp
Однак, в інших місцях цей колір був поміняний на червоний.
3. Ну і тепер найголовніше. Ті, хто це запустив і не хотіли відновлення даних. Ще раз звернемося до статті https://securelist.com/petya-the-two-in-one-trojan/74609/
У ній видно, що всередині так званого Onion Sector передається чотири параметри, останній з яких ec_data. Тут, особливо не вдаючись в криптографію, можна сказати, що це і є основа для відновлення стану диска. Без цих даних сервер вимагачів ніколи не відновить пароль від диска.
Так ось, в цьому самому місці завжди були присутні нулі, а той код, який «вимагачі» видають за персональний ключ шифрування і який в попередніх версіях формувався на підставі криптографічних операцій, тепер формується за спрощеною програмою:
.text:100015AC 9AC push 3Ch ; dwLen
.text:100015AE 9B0 lea eax, [ebp+personalKey]
.text:100015B4 9B0 push eax ; pbBuffer
.text:100015B5 9B4 call GenerateRandom
Висновок, процедуру відновлення даних ніхто не збирався робити і зловмисники, судячи по всьому, не ставили це метою або це великий баг цього вірусу!?
4. Ну і нарешті таблиця «Сигма» складається з значень з Petya Gold:
seg000:96DA 01C mov [bp+var_11], 31h ; '1'
seg000:96DE 01C mov [bp+var_10], 6Eh ; 'n'
seg000:96E2 01C mov [bp+var_F], 76h ; 'v'
seg000:96E6 01C mov [bp+var_E], 61h ; 'a'
seg000:96EA 01C mov [bp+var_D], 6Ch ; 'l'
seg000:96EE 01C mov [bp+var_B], 64h ; 'd'
seg000:96F2 01C mov [bp+var_A], 20h ; ' '
seg000:96F6 01C mov [bp+var_9], 73h ; 's'
seg000:96FA 01C mov [bp+var_8], 33h ; '3'
seg000:96FE 01C mov [bp+var_7], 63h ; 'c'
seg000:9702 01C mov [bp+var_6], 74h ; 't'
Підводячи підсумки по вище викладеному, можливо зробити наступні висновки:
- Відсутній механізм відновлення зашифрованих даних і зловмисники не мали мети це робити.
- Частина коду була написана непрофесійно.
- Використовувався декомпілятор. Ми знайшли достатньо доказів того, що даний код був запозичений.
Пропустивши технічну частину і перейшовши до аналізу можливо зробити висновки, що у «авторів» сильно поспішали в написанні частини коду, а це значить, що терміни «випуску» вірусу були скорочені і було завдання «випустити» шкідника до конкретної дати.
Якщо подивитися на календар, то найближчою великою світовою подією є саміт G-20, що починається 7 липня, в рамках якого, мабуть, відбудеться зустріч між главами держав США і Росії.
Здійснюючи невеликий екскурс в історію, на думку спадає одна весела історія, яку хотілося б згадати:
У 1966 році в СРСР приїжджав президент Франції Шарль де Голль і Леонід Брежнєв показував йому пуск міжконтинентальної балістичної ракети. Для цього була проведена спеціальна операція [1] під назвою «Пальма -1». "Така ж ракета і на Париж націлена?" - нібито запитав приголомшений видовищем де Голль. Брежнєв посміхнувся і поспішив "втішити" генерала: "Не турбуйтеся. Не ця" ...
В результаті цієї спеціальної операції в, тому ж році, Франція за рішенням де Голля вийшла з військової організації НАТО, а штаб НАТО довелося перевести з Парижа до Брюсселя
І так перейдемо до нашої теми, виходячи з логіки роботи стандартних антивірусів які мають, на сьогоднішній день, максимальне поширення по світовому ринку, автори вірусу знали, що дана епідемія буде зупинена протягом проміжку часу від 4-х годин і до 2-х діб. Стільки часу потрібно на написання сигнатур провідними антивірусними вендорами і поновлення відповідних баз.
Автори вірусу могли обійти блок на поширення шкідника методом перекріптовки коду, але не зробили цього.
За інформацією від https://labsblog.f-secure.com/2017/06/29/petya-i-want-to-believe/ використовуються експлойти, які були куплені в лютому 2017 року, тобто до того моменту, коли Shadow Brokers виставила ці коди в безкоштовний доступ. Це говорить про те, що розробники або їхні шефи спокійно витрачають великі суми грошей, що виражаються в сотнях тисяч доларів.
Розробники вірусу слідують алгоритму розробки софта і видно, що частина коду, що відповідає за поширення і шифровку файлів виконано на високому професійному рівні, а ось частина, що відповідає за монетизацію вірусу, виконана зухвало непрофесійно.
Перераховані вище факти говорять про те, що ми зіткнулися з вірусом написаним професійною групою осіб, які не обмежених у фінансуванні. Це може говорити лише про те, що отримання грошей було ширмою для даної атаки. Причому цей факт навіть і не намагалися прикрити.
Це виглядає цілком розумним тільки в одному випадку - якщо це неприкрита загроза з боку Російських спецслужб світовій спільноті. І при цьому полігон України був обраний невипадково. З одного боку Путін «карає» Україну за її погану поведінку, з іншого боку дозволяє світовій антивірусної індустрії підготуватися до цієї атаки і не допустити серйозного поширення на інших територіях. На даний факт так само вказує відсутність заміни коду шифрувальника своїми перепакованими деривативами, так як впровадження механізму перепаковки вірусу призвело б до неможливості антивірусними компаніями зупинки даного зараження, що у свою чергу привело б до колапсу світової економіки.
На те, що автори вірусу спочатку впровадили механізми зупинки поширення вірусу говорить так само ось цей текст - 98% sure that the name is is perfc.dll Create a file in c: windows called perfc with no extension and #petya #Nopetya will not run!
Запустивши показово даний вірус в українські інформаційні мережі, Росія тим самим показує, що вона підготувалася до наступного кроку гібридної війни. У разі погроз з боку світової спільноти про посилення проти Росії санкцій, наприклад, у вигляді відключення банківської системи від Свіфта, Путін або його соратники можуть повідомити про те, що група патріотично налаштованих хакерів, природно не мають ніякого відношення до урядових служб Росії, можуть з патріотичних почуттів повністю впустити світову економічну систему.
Чи може хто-небудь цю загрозу дійсно здійснити? На жаль такий сценарій можливий і це твердження вже не з області фантастики. Давайте гіпотетично розглянемо атаку таким вірусом - назвемо його МегаЦарьБомба. Береться алгоритм даної проведеної атаки і з вірусу забираються всі баги. Ось що, теоретично, отримаємо:
- Поширювана МегаЦарьБомба буде перепаковуватися раз в 10 хвилин. Це буде збивати статичну сигнатуру більшості антивірусних продуктів.
- Будуть використані 0-day експлойти, які розроблені атакуючими у власних лабораторіях, так і куплені на чорному ринку.
- Точка з яких почнеться поширення МегаЦарьБомби буде не одна, як у випадку з Україною, а їх буде десятки тисяч.
- МегаЦарьБомба НЕ буде морочитися з шифруванням файлів. Вона буде просто безповоротно видаляти файли і «вбивати» машину, так званий екран смерті.
- Недавній випадок виплати викупу південнокорейською хостинг-компанією в розмірі 1 млн. доларів показує, що і сервера на платформі Лінукс також схильні до зараження шифрувальником даних, а значить буде і лінукс версія МегаЦарьБомби.
У разі проведення такої атаки, виходячи зі статистики, отриманої в Україні [2], можна припустити, що буде заражено до 30% всіх комп'ютерних мереж в світі, що призведе до однозначного колапсу не тільки світової економіки, а й до повного всепоглинаючому інформаційного хаосу зі усіма витікаючими наслідками.
Отже, що якщо на саміті G-20 хтось комусь буде загрожувати відключенням Свіфта, в разі поганої поведінки, то цей хтось може показати фото на своєму смартфоні де будуть стояти пару симпатичних фігуристих дівчат з написами на джинсах - Не смішіть наші МегаЦарьБомби.
Звіт підготовлений аналітичним відділом компанії Romad Cyber Systems Inc.
P.S. У наступній статті ми торкнемося питання відновлення інформаційних систем після подібних атак, а головну увагу приділимо питанню - як не допустити і блокувати подібні атаки на Ваші інформаційні системи, опишемо методи і засоби, за допомогою яких можливо домогтися гідного інформаційного захисту.
[1]. Хромова Є.Б. Шарль де Голль в СРСР: до ювілею візиту 1966 року / Вісник Пермського національного дослідницького політехнічного університету. Культура. Історія. Філософія. Право. - 2016. - № 3. - с.30-40. Khromova E.B. Charles de Gaulle in USSR: the anniversary of the visit in 1966. Bulletin of Perm National Research Polytechnic University. Culture. History. Philosophy.Law. 2016. No. 3. Pp. 30-40. [2]. https://forum.pravda.com.ua/index.php?topic=971772.0;viewresults