🥇OceanLotus: обновление на зловреден софтуер за macOS

През март 2019 година в VirusTotal, популярен онлайн сервис за сканиране, беше качен нов образец на злонамерен софтуер за macOS от кибер групата OceanLotus. Изпълнимият файл на бекдора притежава същите възможности, както предишната версия на злонамерен софтуер, която разгледахме за macOS, но структурата му е променена и е по-трудно да бъде открита. За съжаление, не успяхме да намерим дроппер, свързан с този образец, така че все още не знаем вектора на заразяване.

Наскоро публикувахме пост за OceanLotus и как операторите се опитват да осигурят устойчивост, да ускорят изпълнението на кода и да минимизират следите от присъствието си в системите Windows. Също така е известно, че тази кибер група има компонент за macOS. В този пост подробно се описват промените в най-новата версия на злонамерен софтуер за macOS в сравнение с предишния вариант (описан от Trend Micro), а също така се разказва как при анализа може да се автоматизира декодирането на низове с помощта на IDA Hex-Rays API.

Анализ

В следващите три части се описва анализа на образеца с SHA-1 хеш E615632C9998E4D3E5ACD8851864ED09B02C77D2. Файлът се нарича flashlightd, антивирусните продукти на ESET го откриват като OSX/OceanLotus.D.

Антиотладка и защита от пясъчници

Като всички macOS бинарници на OceanLotus, образецът е опакован с UPX, но повечето инструменти за идентификация на опаковани файлове не го разпознават като такъв. Вероятно, защото те основно съдържат подпис, зависещ от наличието на низ „UPX“, освен това, Mach-O подписите се срещат по-рядко и не се обновяват толкова често. Тази особеност затруднява статичното откритие. Интересно е, че след разопаковането, точката на вход в началото на секцията __cfstring в сегмента .TEXT. В тази секция има атрибути flag, както е показано на изображението по-долу.

Фигура 1. Атрибутите на MACH-O секция __cfstring

Както е показано на фигура 2, местоположението на кода в секцията __cfstring позволява да се излъжат някои инструменти за дизасемблиране, показвайки кода като низове.

Фигура 2. Кодът на бекдора се определя от IDA като данни

След стартиране, бинарният файл създава поток като средство за защита от отладка, единствената цел на който е постоянно да проверява наличието на дебъгер. За това, потокът:

— Опитва се да открепи всякакъв дебъгер, извиквайки ptrace с PT_DENY_ATTACH като параметър на заявката
— Проверява дали са отворени определени изключителни портове, като извиква функция task_get_exception_ports
— Проверява дали е свързан отладчик, както е показано на изображението по-долу, с проверка на наличието на флаг P_TRACED в текущия процес

Рисунок 3. Проверка на свързването на отладчика чрез функцията sysctl

Ако стражевата схема открие присъствието на отладчик, се извиква функция exit. Освен това, образецът след това проверява средата, изпълнявайки две команди:

ioreg -l | grep -e "Manufacturer" и sysctl hw.model

След това образецът проверява връщаната стойност по твърдо кодирания списък на познати системи за виртуализация: acle, vmware, virtualbox или parallels. Накрая следващата команда проверява дали машината е една от следните “MBP”, “MBA”, “MB”, “MM”, “IM”, “MP” и “XS”. Това са кодовете на модела на системата, например “MBP” означава MacBook Pro, “MBA” – MacBook Air и т.н.

system_profiler SPHardwareDataType 2>/dev/null | awk '/Boot ROM Version/ {split($0, line, ":");printf("%s", line[2]);}'

Основни добавки

Въпреки че командите на бекдора не са се променили от времето на изследването на Trend Micro, забелязахме няколко други модификации. C&C сървърите, използвани в този образец, са доста нови, датата на създаване е 22.10.2018.

— daff.faybilodeau[.]com
— sarc.onteagleroad[.]com
— au.charlineopkesston[.]com

Ресурсният URL се е променил на /dp/B074WC4NHW/ref=gbps_img_m-9_62c3_750e6b35.
Първият пакет, изпратен на C&C сървъра, съдържа повече информация за хост машината, включително всички данни, събирани от командите в таблицата по-долу.

Освен това, промените в конфигурацията, образецът използва за мрежова филтрация не библиотеката libcurl, а външна библиотека. За да я намери, бекдорът се опитва да дешифрира всеки файл в текущата директория, използвайки AES-256-CBC с ключ gFjMXBgyXWULmVVVzyxy, допълнен с нули. Всеки файл се дешифрира и се запазва като /tmp/store, а опитът за зареждане като библиотека е направен с използването на функцията dlopen. Когато опитът за дешифриране доведе до успешен повик на dlopen, бекдорът извлича експортируемите функции Boriry и ChadylonV, които очевидно отговарят за мрежовото взаимодействие със сървъра. Нямаме дропер или други файлове от оригиналното местоположение на образеца, затова не можем да анализираме тази библиотека. Освен това, тъй като компонентът е шифрован, YARA правило, основано на тези низове, няма да съответства на файл, намерен на диска.

Както е описано в по-горе споменатата статия, се създава clientID. Този идентификатор е MD5 хеш на стойността, получена от една от следните команди:

— ioreg -rd1 -c IOPlatformExpertDevice | awk '\/IOPlatformSerialNumber\/ { split($0, line, """); printf("%s", line[4]); }'
— ioreg -rd1 -c IOPlatformExpertDevice | awk '\/IOPlatformUUID\/ { split($0, line, """); printf("%s", line[4]); }'
— ifconfig en0 | awk '\/ether \/{print $2}' (получаване на MAC адрес)
— неизвестна команда («x1ex72x0a«), която се използва в предишните примери

Преди хеширането на получената стойност се добавя символ «0» или «1», указващ наличието на root привилегии. Този clientID се съхранява в /Library/Storage/File System/HFS/25cf5d02-e50b-4288-870a-528d56c3cf6e/pivtoken.appex, ако кодът е изпълнен от root или в ~\/Library\/SmartCardsServices\/Technology\/PlugIns\/drivers\/snippets.ecgML в останалите случаи. Файлът обикновено е скрит с помощта на функцията _chflags, времевият му печат се променя с команда touch –t с произволно значение.

Дешифриране на низове

Както и в предишните версии, низовете са криптирани с използване на AES-256-CBC (шестнадесетичен ключ: 9D7274AD7BCEF0DED29BDBB428C251DF8B350B92 допълнен с нули, а IV е запълнен с нули) чрез функцията CCCrypt. Ключът е променен в сравнение с предишните версии, но, тъй като групата все още използва същия алгоритъм за криптиране на низове, дешифрирането може да бъде автоматизирано. Освен този пост, пускаме IDA скрипт, който използва Hex-Rays API за дешифриране на низовете, присъстващи в бинарния файл. Този скрипт може да помогне при бъдещ анализ на OceanLotus и анализа на съществуващите образци, които все още не сме успели да получим. В основата на сценария стои универсален метод за извличане на аргументите, предадени на функцията. Освен това, той търси назначенията на параметрите. Методът може да се използва повторно, за да се получи списък с аргументите на функцията и след това да се предаде на обратен повик (callback).

Знаейки прототипа на функцията decrypt, скриптът намира всички кръстосани препратки към тази функция, всички аргументи, след това дешифрира данните и поставя обикновения текст в коментар на адреса на кръстосаната препратка. За да работи правилно скриптът, трябва да бъде зададен потребителски алфабет, използван от функцията за декодиране на base64, и трябва да бъде определена глобална променлива, съдържаща дължината на ключа (в този случай DWORD, вижте рисунка 4).

Рисунка 4. Определение на глобалната променлива key_len

В прозоре Функция можете с десния бутон на мишката да извикате функцията за декриптиране и да кликнете „Извлечи и декриптирай аргументите“. Скриптът трябва да постави декриптираните редове в коментарите, както е показано на рисунка 5.

Рисунка 5. Декриптирания текст е поставен в коментарите

По този начин декриптираните редове удобно се разполагат заедно в прозореца на IDA xrefs за тази функция, както е показано на рисунка 6.

Рисунка 6. Xrefs към функцията f_decrypt

Финалната версия на скрипта можете да намерите на Github repository.

Извод

Както вече беше споменато, OceanLotus постоянно усъвършенстват и обновяват своя набор от инструменти. Този път кибергрупата е усъвършенствала зловредния софтуер за работа с потребителите на Mac. Кодът не е променен значително, но, тъй като много потребители на Mac игнорират продуктите за сигурност, защитата на зловредния софтуер от открития е второстепенна.

Продуктите на ESET вече откриха този файл в момента на проучването. Тъй като мрежовата библиотека, използвана за C&C комуникация, сега е криптирана на диска, точният мрежови протокол, използван от атакуващите, все още е неизвестен.