Кібервійна України з Росією триває, оскільки угруповання UAC-0099 посилює свою кампанію кібершпигунства проти українських підприємств. Використовуючи серйозну вразливість у популярному програмному забезпеченні WinRAR, група організовує складні атаки для розгортання шкідливого програмного забезпечення Lonepage, що базується на VBS і здатне віддалено виконувати команди та викрадати дані.
UAC-0099 використовують вразливість в WinRar
У більшості останніх атак UAC-0099 зосередився на використанні вразливості WinRAR (CVE-2023-38831, оцінка CVSS: 7.8), що свідчить про складний підхід до кібератак. Ця вразливість WinRAR, широко використовуваного інструменту для стиснення файлів, дозволяє зловмисникам впроваджувати шкідливий код в системи, які нічого не підозрюють. Експлойт передбачає використання підроблених архівів, що саморозпаковуються (SFX), і спеціально створених ZIP-файлів, призначених для обходу традиційних заходів безпеки і доставки шкідливого програмного забезпечення Lonepage безпосередньо в серце цільової системи.
Вектори атаки через WinRAR:
Архіви, що саморозпаковуються: Зловмисники поширюють SFX-файли, які містять шкідливі ярлики LNK, замасковані під звичайні документи DOCX. Ці файли, використовуючи знайомі іконки, такі як Microsoft WordPad, спонукають жертв до ненавмисного запуску шкідливих скриптів PowerShell, які встановлюють Lonepage.
Маніпуляції з ZIP-файлами: UAC-0099 також використовує ZIP-архіви, спеціально створені для використання вразливості WinRAR. Ці файли розроблені так, щоб запускати вразливість, яка через низку недосконалостей у програмі дозволяє виконання довільного коду.
Ланцюг вразливості в WinRAR
Хто такі UAC-0099?
Угруповання UAC-0099, вперше виявлене українською командою реагування на кіберінциденти CERT-UA у червні 2023 року, передусім націлене на українських робітників, які працюють у міжнародних компаніях. Їх тактика, хоч і не є інноваційною, виявилася ефективною для компрометації критично важливої інформації з широкого кола державних організацій та медіа-структур. Нещодавній аналіз Deep Instinct виявив тривожну тенденцію: постійний фокус групи на шпигунстві, що ставить під загрозу не лише організації, а й окремих осіб, які в них працюють.
Що таке Lonepage?
Lonepage – це бекдор, що використовується UAC-0099 у кампаніях кібершпигунства. Він призначений для прихованого проникнення в цільові системи та встановлення зв’язку з командно-контрольним сервером (C2). Після встановлення Lonepage може отримувати та виконувати подальші шкідливі інструкції з цього сервера.
Можливості Lonepage включають розгортання додаткового корисного навантаження, такого як клавіатурні шпигуни, викрадачі даних та інструменти для створення знімків екрана. Універсальність і здатність адаптуватися до різних середовищ роблять цього шкідника значною загрозою, здатною непомітно отримувати конфіденційну інформацію та здійснювати довготривале спостереження за скомпрометованими системами.
Рекомендації та пом’якшення наслідків
Оскільки зловмисники продовжують вдосконалювати свою тактику, організаціям, особливо тим, що мають зв’язки з Україною, вкрай важливо випереджати ці загрози за допомогою ефективних практик безпеки, безперервного навчання та надійного технологічного захисту. Боротьба з кіберзлочинністю триває, і обізнаність є першим кроком до захисту нашого цифрового майбутнього.
Ось кілька порад:
Переконайтеся, що все програмне забезпечення, особливо широко поширені програми, такі як WinRAR, мають найновіші виправлення безпеки.
Проводьте регулярні тренінги для співробітників, щоб навчити їх розпізнавати спроби фішингу та підозрілі додатки до електронних листів.
Впроваджуйте передові рішення з безпеки, включаючи брандмауери, антивірусні програми та системи виявлення вторгнень.
Виконуйте регулярний аналіз системи безпеки та постійно відстежуйте мережевий трафік на наявність ознак незвичайної активності.
Нагадаю, ми також писали про те, що Tencent та китайська поліція провели спільну операцію проти розробників ігрових читів.
Проблема mhypro2.sys відома як мінімум з 2020 року, і фахівці з інформаційної безпеки вже давно звертаються до виробників античит-систем взагалі, оскільки більшість таких рішень працюють на рівні кільця 0, що навряд чи можна вважати безпечним.
У випадку з mhypro2.sys звернення фахівців не вплинули, сертифікат підпису коду не був відкликаний, а значить, програму як і раніше можна встановлювати на Windows, не піднімаючи тривоги. Гірше того, з 2020 року на GitHub доступні одразу два PoC-експлойти і докладний опис того, як можна використовувати античит з режиму користувача для читання/запису пам’яті ядра з привілеями режиму ядра, завершення певних процесів і так далі.
У нещодавньому звіті Trend Micro говориться, що хакери зловживають драйвером з липня 2022 року та використовують його для відключення правильно налаштованих рішень безпеки.
Cхема обходу налаштувань безпеки за допомогою драйвера
Аналітики пишуть, що у вивченому ними прикладі зловмисники використовували secretsdump і wmiexec проти цільової машини, а потім підключаються до контролера домену RDP, використовуючи вкрадені облікові дані адміністратора.
Першою дією хакерів на зламаній машині було перенесення mhyprot2.sys на робочий стіл разом із шкідливим виконуваним файлом kill_svc.exe, який використовувався для встановлення драйвера. Потім зловмисники завантажили файл avg.msi, який, у свою чергу, завантажив та виконав наступні чотири файли:
logon.bat – запускає HelpPane.exe, “вбиває” антивірус та інші служби, запускає svchost.exe;
HelpPane.exe– маскується під файл Microsoft Help and Support, що виконується, аналогічний kill_svc.exe, оскільки встановлює mhyprot2.sys і «вбиває» антивірусні служби;
У цьому інциденті хакери тричі намагалися зашифрувати файли на cкомпрометованій робочій станції, але безуспішно. Тим не менш, антивірусні служби були успішно вимкнені. У результаті зловмисники просто перенесли logon.bat на робочий стіл, запустивши його вручну і все запрацювало.
До кінця атаки хакери завантажили драйвер, програму-вимагач і файл kill_svc.exe, що виконується, в загальний мережевий ресурс для масового розгортання, прагнучи заразити якомога більше робочих станцій.
Trend Micro попереджає, що хакери можуть продовжувати використовувати античит-модуль, тому що навіть якщо виробник усуне вразливість, старі версії mhypro2.sys все одно використовуватимуться, а модуль можна інтегрувати в будь-яке шкідливе ПЗ. У той же час експерти зазначають, що хоча модулі підпису коду, які виступають як драйвери пристроїв, можуть бути використані для зловживань, ці випадки досі рідкісні.
На момент написання цієї статті сигнатура коду для mhyprot2.sys була дійсна. Для атаки Genshin Impact не потрібно встановлювати на пристрій жертви. Використання драйвера не залежить від гри.” – попередження від Trend Micro.
У відповідь на публікацію цього звіту відомий експерт з інформаційної безпеки Кевін Бомонт зазначив у Twitter, що адміністратори можуть захиститися від цієї загрози, заблокувавши хеш «0466e90bf0e83b776ca8716e01d35a8a2e5f96d3», який відповідає вразливому драйверу.
Дослідники кібербезпеки попереджають, що вразливість віддаленого виконання коду (RCE) у веб-інтерфейсі GitLab, як і раніше, активно експлуатується хакерами, наражаючи на небезпеку велику кількість екземплярів сервісу.
Вразливість CVE-2021-22205, відноситься до невірної валідації наданих користувачем зображень, що дозволяє виконувати довільний код, що міститься в них. Цій до цієї загрози вразливі як версії GitLab Community Edition (CE) так і GitLab Enterprise Edition (EE) , починаючи з версії 11.9. Патч, який виправляє цю проблему, випустили 14 квітня 2021 року для версій 13.8.8, 13.9.6 та 13.10.3.
В одній з реальних атак, що були описані HN Security минулого місяця, на загальнодоступному сервері GitLab (що належить неназваному клієнту), було зареєстровано два облікові записи, що отримали права адміністратора. Підвищення їх привілеїв було зроблено шляхом віддаленого виконання команд, що міститься в завантажених через цю прогалину в безпеці заражених зображеннях.
Незважаючи на те, що вразливість спочатку розглядалася лише як автентифіковане віддалене виконання коду та отримала бал CVSS 9.9, 21 вересня 2021 його значення було підвищено до 10.0. Причина в тому, що скористатися цією лазівкою можуть і неавтентифіковані зловмисники.
Повідомлення від користувача на форумі GitLab про знайдену вразливість
Зміна в оцінці вразливості за шкалою CVSS, звичайно, виявилася незначною, але той факт, що вразливість можуть експлуатувати і неавтентифіковані особи, має велике значення для захисників”, – повідомив фахівець із кібербезпеки з Rapid7 у попередженні, опублікованому в понеділок.
Незважаючи на те, що патчі доступні вже більше півроку, з 60,000 вразливих користувачів GitLab повноцінно проти RCE-атак захистилися лише 21%, а близько 50% все ще залишаються для них вразливими.
Зважаючи на можливість саме неавтентифікованої експлуатації вразливості, очікується подальше зростання активності зловмисників, що говорить про бажане якнайшвидше оновлення користувачами GitLab до останньої версії.
Крім того, в ідеалі сервіс GitLab краще не розкривати для загальної мережі”, – рекомендують дослідники. – «Якщо вам потрібен доступ до свого екземпляра через інтернет, то розгляньте можливість його огородження за допомогою VPN».
GitLab закликає користувачів якнайшвидше встановити оновлення порушених версій, а також надав обхідний шлях для тих, хто не може оновити прошивку. Платформа порекомендувала відключити функцію імпорту GitLab на вкладці «Видимість та керування доступом» у меню «Налаштування» після автентифікації з правами адміністратора. На даний момент не відомо, чи ця вразливість використовується в атаках.
Cynerio, компанія, яка надає закладам охорони здоров’я послуги платформи іінтернету речей в сфері охорони здоров’я, нещодавно опублікувала звіт про поточний стан кібер безпеки підключених медичних пристроїв у лікарнях усіх типів. У дослідницькому звіті компанії щодо галузі охоплюються широкотематичні питання. Звіт також містить підсумування результатів дослідження та його методологію.
«Протягом десятиліть у медичній сфері догляду за пацієнтами завдяки пристроям інтернету речей та їх викоританню спостерігалися покращення в її роботі. Проте зі збільшенням кількості цих пристроїв зросла і кількість загроз, вразливостей і точок експулуатації комп’ютерних мереж медичних закладів,» — йдеться у доповіді компанії Cynerio.
Статистика безпечності пристроїв інтернету речей у сфері охорони здоров’я
Інформація в цьому звіті базується на аналізі компанією більш ніж 10 мільйонів пристроїв інтернету речей і медичних пристроїв інтернету речей, зібраних із поточних реалізацій продуктів Cynerio у понад 300 лікарнях та інших медичних установах у США та по всьому світі, дані з яких при аналізі були повністю анонімізовані дослідницькою командою компанії.
У вступі до звіту фахівці надали статистичні дані з різних ресурсів щодо поточного стану кібербезпеки в галузі охорони здоров’я. І згідно зібраних статистичних даних:
Минулого року атаки програм-вимагачів коштували лікарням майже 21 мільярд доларів США (Компанія Comparitech);
Середні збитки лікарень становлять 8 мільйонів доларів США за кожну атаку програми-вимагача, і лікарням потрібно 278 днів, щоб повністю відновити свою роботу після неї. (Звіт Emsisoft: The State of Ransomware in the US);
Сфера охорони здоров’я стала лідером серед найбільш прибуткових жертв програм-вимагачів, обігнавши другі місця на 100–200%. Фахівці з кібербезпеки кажуть, що персональна медична інформація (PHI) може бути в 50 разів більш ціннішою з точки зору прибутку для кіберзлочинців, ніж викрадені банківські картки на чорному ринку.
На що націлені кіберзлочинці в галузі охорони здоров’я?
IoT (Інтернет речей). Фахівці використовують цей термін на позначення будь-яких мережевих пристроїв або інших устаткувань, які не можна вважати традиційними інформаційними технологіями (ІТ). Сюди відносяться дверні смарт замки, VOIP-телефони та камери спостереження. Але комп’ютери чи сервери не належать до цієї категорії.
IoMT (Інтернет медичних речей). Такі апарати використовуються в лікарнях в безпосередніх медичних цілях. Найпоширеніші види включають: глюкометри, кардіомонітори, внутрішньовенні насоси та апарати МРТ. Можливо, десять років тому у них не було так багато різноманітних інтернет-з’єднань, але сьогодні їхня кількість значна.
OT (Операційні технології). OT означає апаратне забезпечення, програмне забезпечення та комунікаційні системи, які допомагають керувати великомасштабним промисловим обладнанням та устаткуванням. У лікарнях це зазвичай такі пристрої, як електричні мережі, ліфти, системи HVAC (опалення, вентиляції та кондиціонування).
Підключені пристрої. Пристрої цієї категорії набагато простіші за згадані вище. Приклади включають кавоварку або вимикач світла.
Які найпоширеніші вразливості пристроїв Інтернету речей у сфері охорони здоров’я?
Якщо ви читали минулорічні заголовки новин з кібербезпеки, вам могло здатися, що найпоширенішими уразливими місцями в таких пристроях є Ripple20 або URGENT/11. Проте все навпаки, найпоширеніші з них набагато очевидніші та пов’язані з поганою елементарною кібергігієною, як-от використання стандартних паролів та налаштувань. Потенційні зловмисники можуть легко знайти в Інтернеті інструкції до пристроїв і, звісно, першою чергою спробувати найочевиднішу річ: паролі та налаштування за замовчуванням. Також у більш ніж половини пристроїв Інтернету речей у сфері охорони здоров’я є одна критична вразливість.
Рейтинг найпоширеніших вразливостей в медичних пристроях інтернету речей
Підсумування результатів дослідження
Внутрішньовенні насоси є найпоширенішим пристроєм інтернету речей у сфері охорони здоров’я та мають найвищий ступінь ризику. Насоси для внутрішньовенного введення складають 38% від усіх пристроїв інтернету речей в медичних закладах. І вражаюча кількість в 73% має вразливість, яка може поставити під загрозу доступність послуг, конфіденційність даних або безпеку пацієнтів.
53% пристроїв інтернету речей та медичних пристроїв інтернету речей містять критичні вразливості. Більше половини підключених медичних та інших пристроїв інтернету речей у лікарнях мають одну добре відому критичну вразливість. Факт, що ставить під загрозу конфіденційність даних, доступність послуг та безпеку пацієнтів. Третина приліжкових пристроїв інтернету речей тих, які безпосередньо використовуються у догляді за пацієнтами, і ті, від яких пацієнти найбільше залежать, мають визначений критичний ризик.
Urgent11 та Ripple20 отримали найбільше заголовків, але найпоширеніші ризики для кібер безпеки пристроїв — це проста недбалість до кібергігієни. Найпоширеніші пристрої медичних пристроїв інтернету речей та звичайних пристроїв інтернету речей часто мають паролі та налаштування за замовчуванням, які зловмисники можуть знайти без особливих зусиль. Їм просто потрібно знайти інструкції для конкретних пристроїв онлайн. Також варто додати, що зазначені вразливості Urgent11 і Ripple20 торкнулися лише 10 відсотків пристроїв із векторами атак, експлуатацію яких зазвичай складно проводити.
“Найпідключеніші” пристрої в лікарнях (у відсотковому співвідношенні від загальної кількості усіх пристроїв IoT/IoMT)
Деякі критичні пристрої інтернету речей у медичній сфері працюють із застарілими версіями Windows. Хоча пристрої, які працюють під управлінням старішої версії Windows, ніж Windows 10, становлять невелику частину інфраструктури інтернету речей типової лікарні, вони використовуються в одних з найбільш критичних відділах. Оскільки самі версії Windows в таких пристроях вже давно віджили своє, цей факт створює значний ризик для пацієнтів, які ними користуються. Але проблема в тому, що заміна машин, на яких працюють ці версії, у більшості випадків займе надто багато років.
Більшість медичних пристроїв інтернету речей використовуються настільки регулярно, що їх складно вчасно оновлювати. Майже 80% пристроїв інтернету речей у сфері охорони здоров’я щомісяця й навіть частіше використовуються для догляду за пацієнтами, що означає, що у них майже немає часу простою і на те, щоб служба кібер безпеки лікарні проаналізувала їх на предмет ризиків і можливих атак, застосувала останні доступні виправлення та здійснила сегментацію для захисту пристроїв у мережі.
На завершення фахівці окреслили майбутні можливі рішення щодо покращення безпеки пристрої інтернету речей в медицині. За їхніми словами, те, що спеціалісти почали визначати та усувати вектори ризику, які вже експлуатуються зловмисниками є першим дієвим кроком до впровадження вкрай необхідних заходів безпеки.
Нещодавно Наталі Сільванович з команди Google Project Zero опублікувала пост, де пояснила деталі двох знайдених вразливостей в програмі для відеодзвінків Zoom. Компанію було ще раніше повідомлено. Вона дала детальний аналіз вразливостей, які полягали в переповненні буфера та витоку інформації; обидва виправлені 24 листопада 2021 року. Перша вразливість торкнулася як клієнтів Zoom, так і серверів MMR, а друга могла використовуватися зловмисниками лише на серверах MMR.
У контексті вона згадала про атаку нульовогу кліку в клієнті Windows Zoom, яка була продемонстрована на торішньому Pwn2Own і показала фахівцям, що у Zoom дійсно є можливість повної віддаленої атаки. Уразливостям було присвоєно відповідні ідентифікації CVE-2021-34423 і CVE-2021-34424.
Фахівець каже, що вона не робила жодних попередніх спроб протестувати Zoom, оскільки вважала, що його зламуватимуть менше в порівнянні з іншим подібним програмним забезпеченням. Вона пояснила, що в більшості типів такого програмного забезпечення користувач лише повинен прийняти дзвінок або відхилити його, тоді як у Zoom дзвінки плануються заздалегідь і приєднатися до них можна за допомогою електронного запрошення.
Тож вона продовжила думку, що у випадку з Zoom, користувачу потрібно зробити кілька кліків, щоб запустити потенційну атаку. Але минулорічний Pwn2Own довів протилежне.
Користувацький інтерфейс в Zoom
Після Pwn2Own Сільванович вирішила придивитися до Zoom. У дописі, опублікованому командою Google Project Zero, вона дала огляд поверхні атаки Zoom, детально розповіла про суть вразливостей і додала можливі варіанти рішення для такого програмного забезпечення, як Zoom щодо того як покращити безпеку своїх користувачів.
Масштаб поверхні атаки
Фахівець переглянула поверхню атаки Zoom з точки зору використання її клієнтом. Основною особливістю програмного забезпечення є багатокористувацькі конференц-дзвінки, які називаються зустрічами, що дозволяють користувачам мати кілька послуг, як-от спільний доступ до екрана, текстові повідомлення під час розмови, відео та аудіо. Крім того, Zoom надає можливість встановити повнофункціональні клієнти, які можна використовувати на різних платформах, таких як iPhone, Android, Linux, Mac і Windows.
Окрім клієнта, який можна встановити, користувачі можуть приєднуватися до зустрічей через посилання браузера, але у них буде менше доступного функціоналу. Найостанніший варіант, доступний для користувачів, щоб приєднатися до зустрічі в Zoom, — це набрати номер телефону, вказаний у запрошенні, і слухати лише аудіо зустрічі.
Zoom Contacts
Також користувачі можуть використовувати Zoom Contacts, які дозволяють спілкуватися окремо за допомогою повідомлень або відео. Тут ви можете просто почати дзвінок, і інша особа може прийняти його або відхилити. Дослідник назвав цю конкретну частину інтерфейсу клієнта поверхнею атаки нульового кліку Zoom. Але це не означає, що зловмисник не може просто запросити свою жертву приєднатися до зустрічі, навіть якщо для цього потрібно буде продовжити жертву, щоб зробити кілька кліків.
Небезпека може бути не стільки для окремих користувачів, скільки для публічних зустрічей в Zoom або вебінарів, платної функції в Zoom, коли велика група невідомих учасників приєднується до односторонньої відеоконференції. Оскільки відкритий характер цих функцій дозволяє зловмиснику приєднуватися без будь-яких обмежень, в основному ми маємо на увазі ідентифікацію будь-кого конкретного відвідувача, Zoom можна розглядати як “Землю Обіцянок”, до прикладу фішерів. Але не тільки безпосередньо клієнти Сільванович каже, а й дані, передані через зустріч, також можуть бути під загрозою, тому що під час зустрічі наскрізне шифрування вимикається за замовчуванням.
Огляд функції обміну повідомленнями в Zoom
Спочатку Сільванович почала роботу з дослідження поверхні атаки нульового кліку. Тут, провівши деякі технічні спостереження, вона не виявила жодних слідів вразливостей. Потім вона вирішила спостерегти, як Zoom використовує дані, надані через XMPP, відкритий протокол зв’язку, розроблений для обміну миттєвими повідомленнями (IM), інформації про присутність та підтримку списку контактів.
У Zoom він використовується здебільшого для спілкування між клієнтами Zoom за межами зустрічей, наприклад для обміну повідомлень і створення каналів, а також для сигналізації (налаштування виклику), коли контакт із Zoom запрошує інший контакт Zoom на зустріч.
Витративши деякий час на аналіз шляхів коду, фахівець тут також не виявила жодних помилок. Вона зауважує, що даний факт сам собою цікавий, оскільки Тійс Алкемаде і Даан Кеупер опублікували звіт, в якому описували вразливість знайдену там, де вона її особисто не знайшла. Слід зазначити, що дослідження було зосереджено виключно на клієнтському програмному забезпеченні Zoom, оскільки інші методи приєднання викликів працюють із наявними функціями пристрою.
Обробка RTP в Zoom
Наступне, на що звернула увагу Сільванович, це те, як клієнти Zoom обробляють аудіо- та відеоконтент. Як зазвичай і у всіх інших системах відеоконференцій, Zoom використовує транспортний протокол реального часу (RTP) для передачі цих даних. І під час дослідження в цій області вона помітила, що і сервер MMR, і клієнти Zoom обробляють велику кількість пакетів, які здається не належать ні до RTP, ні до XMPP. І саме тут вона наткнулася на вищезгадані вразливості.
Хоча дослідниці не вдалося повністю провести експлойт з використанням вразливостей, вона все ж змогла використати їх у інші неповні способи експлуатації. На її ж думку справжні зловмисники скористалися б вразливістю в повній мірі. Говорячи про Zoom RTP Processing, спеціалістка привітала включення ASLR в процес Zoom MMR і сказала, що для Zoom важливо продовжувати покращувати надійність коду MMR.
Висновки
Наприкінці Сільванович назвала кілька факторів, які, на її думку, значною мірою винуваті виявленим помилкам. І саме ці фактори зазвичай створюють проблеми у всіх програмах для відеоконференцій, як-от Zoom. Перше, на що вона звертає увагу, це великий обсяг коду в програмному забезпеченні. Було кілька частин коду, функціональність яких важко визначити. Багато класів, які можна було б десеріалізувати, здавалося, не використовуються взагалі. Великий обсяг коду ускладнює аналіз програмного забезпечення дослідниками безпеки і в той же час збільшує поверхню атаки, в якій код потенційно може містити вразливості.
Інша річ, що створює труднощі, – це використання багатьох власних форматів і протоколів. Вона пояснює, що іноді досліднику доводиться створювати інструменти для маніпулювання конкретними інтерфейсами програмного забезпечення, але з запатентованими речами при проведенні маніпуляцій потрібно більше часу, ніж потрібно. Не кажучи вже про 1500 доларів США вартості ліцензії; обидва фактори означають, що програмне забезпечення не так часто досліджують, як це повинно бути.
Закритий характер програмного забезпечення Zoom також ускладнює роботу дослідників безпеки. Багато систем відеоконференцій використовують програмне забезпечення з відкритим кодом, WebRTC або PJSIP. Звісно, вони не позбавлені проблем, але, принаймні, аналізувати їх набагато простіше.
Але все-таки найбільшою проблемою на думку фахівця була відсутність ASLR на сервері Zoom MMR. Вона пояснює, що річ є , мабуть, найважливішою в усуненні та запобіганні експлуатації пошкодження пам’яті, особливо коли інші засоби захисту залежать від цього на певному рівні. І в переважній більшості програм його не слід було б відключати, як це зараз видно з поточної спостережуваної ситуації. Звичайно, додає вона, постачальники використовують заходи безпеки, передбачені платформами, для яких вони пишуть програмне забезпечення.
Але були ідеї зменшити сприйнятливість програмного забезпечення до вразливостей, пов’язаних із пошкодженням пам’яті, шляхом вибору мов, безпечних для пам’яті, та впровадженням покращених засобів відновлення пам’яті. Тим не менш, вона вважає, що все програмне забезпечення, написане для платформ, які підтримують ASLR, повинно мати його (та інші основні засоби відновлення пам’яті) увімкненим.
17 грудня 2021 року у своєму блозі Google Open Source Insights Team прояснили всю ситуацію довкола вразливості Apache Log4j. Вони пояснили, в чому полягає вразливість і який поточний прогрес у виправленні проблем екосистеми з відкритим кодом JVM. Також команда поділилася своїми думками про те, скільки часу може знадобитися, щоб цю вразливість було виправлено в усій екосистемі та на чому слід зосередитися далі.
9 грудня спільнота інформаційної безпеки дізналася про існування вразливості, яка має великий ступінь серйозності та потенційну широту впливу. Десятки тисяч програмних пакетів (артефактів, як вони називаються в екосистемі Java) і проектів використовують популярний інструмент журналювання, log4j, який, як виявилося, має в собі вразливість. Як пояснюють спеціалісти,вразливість дозволяє віддалено виконувати код, використовуючи функцію пошуку JNDI, відкриту бібліотекою журналювання log4j. У багатьох версіях бібліотеки експлуатована функція існувала за замовчуванням.
Виправлення вразливості Apache Log4j займе трохи часу
Не так давно розкриті вразливості log4j торкнулися понад 35 000 пакетів Java, що становить понад 8% репозиторію Maven Central. Оскільки репозиторій є найбільшим сховищем пакетів Java, це стало значною проблемою для багатьох фахівців індустрії програмного забезпечення. Фахівці зазначають, що 8% є величезним показником для екосистеми, в той час як середнє число для результату консультацій Maven Central складає 2%, з медіаною менше 0,1%. Хоча згадані числа не охоплюють всі пакети Java, наприклад безпосередньо розподілені бінарні файли.
На момент публікації було зафіксовано майже п’ять тисяч виправлених артефактів. І понад 30 000 артефактів, багато з яких залежать від іншого артефакту, і все ще чекають на виправлення. Команда завважує, що вони зараховували артефакт як виправлений, якщо він мав принаймні одну вражену версію, і було випущено більш стабільну виправлену версію (відповідно до семантичних версій). У випадку log4j артефакт вважається виправленим, якщо він був оновлений до версії 2.16.0 або вище і не залежить більше від log4j.
Дві серйозні проблеми заважають процесу виправлення
Хоча в цілому ситуація зрозуміла, фахівці вказують на дві істотні проблеми щодо її усунення. Перше це той факт, що багато артефактів опосередковано залежать від log4j. А ті, що мають пряму залежність, становлять близько 7000 вражених артефактів. В першому факті будь-яка з його версій залежить від ураженої версії log4j-core або log4j-api, описаних в CVE. Тобто це непряма залежність або транзитивна залежність, що означає, тавтологічно сказано, залежності власних залежностей.
Весь цей набір залежностей створює значні перешкоди у виправленні, якщо прослідкувати все це в ланцюжках залежностей. Тоді все стає зрозумілим: чим глибше вразливість, тим більше потрібно перебрати ланцюжків, щоб її усунути. Згідно з гістограмою графіків залежностей у більш ніж 80% пакетів вразливість залягає глибше ніж на один рівень. У більшості це п’ять рівнів нижче, а в деяких – навіть дев’ять. Процес виправлення в таких випадках вимагає спочатку перейти до найглибших залежностей, і далі поступово по всій кроні.
Візуалізація прямих та непрямих залежностей
Відкритий діапазон дає можливість вибрати останню версію
Інша складність полягає у виборах на рівні екосистеми в алгоритмі розв’язання залежностей та умовах специфікації вимог. Практика відрізняється від такої, як в npm, де звичайно вказуються відкриті діапазони для вимог залежностей. Відкриті діапазони дають можливість вибрати останню випущену версію, яка задовольняє вимоги залежностей, тим самим виводячи в перший список оновленні версії. Користувачі отримують виправлену версію одразу після випуску виправлення, процес, який генерує залежності швидше.
«В екосистемі Java звичайною практикою є указання вимог до «м’яких» версій — точні версії, які використовуються алгоритмом розділення, якщо жодна інша версія того самого пакета не з’являється раніше на графіку залежностей. Виправлення часто вимагає додаткових дій з боку розробників, щоб оновити вимоги залежностей до виправленої версії», — також писала команда Open Source Insights щодо цього у своєму блозі.
В цьому питанні команда радить спільноті увімкнути автоматичне оновлення залежностей та додати засоби підсилення безпеки. Вони також надали список з 500 вражених пакетів з транзитивною залежністю. На думку фахівців, визначення пріоритетності цих пакетів полегшить зусилля з виправлення та згодом розблокує більшу частину спільноти. Команда подякувала користувачам, які оновили свої версії log4j.
На питання, скільки часу знадобиться, щоб повністю виправити все, команда висловилася неоднозначно. Якщо розглядати всі публічно доступні критичні рекомендації, що впливають на пакети Maven, то процес може зайняти деякий час. Вони кажуть, що менше половини (48%) артефактів, на які вплинула вразливість, було виправлено. Але що стосується log4j, то все здається багатообіцяючим: приблизно 13% було виправлено.
Двоє дослідників виявили проблему вразливості в Windows 10, яка допускає виконання коду в Windows 10 через IE11/Edge Legacy і MS Teams, активовану введенням аргументу в уніфікований ідентифікатор ресурсів за замовчуванням у Windows 10/11 для ms-officecmd: URI. У своєму звіті, опублікованому у власному блозі дослідників, вони подають розгорнуте висвітлення своїх висновків і додають оригінальний звіт зроблений в MSRC. Лукас Ейлер і Фабіан Броунлайн спочатку відправили результати своєї роботи в Майкрософт через https://msrc.microsoft.com/ 10 березня цього року, але компанія відхилила роботу, пояснивши, що «[..] ваш звіт, схоже, описує випадок соціальної інженерії[.. ]”.
Виявлена вразливість дозволяє виконання віддаленого коду
У блозі вони пояснили, що відмова була помилково зроблена. А після повторного звернення Майкрософт знову розглянула звіт і присвоїла описаній вразливості класифікацію «Критична, віддалене виконання коду». Проте в реєстр вразливостей її не було внесено і жодних попереджень для користувачів не було опубліковано. У наступній заяві Майкрософт пояснила свої дії:
« На жаль, щодо даного звіту не було опубліковано попереджень для користувачів чи саму вразливість внесено до реєстру. Причина полягає в тому, що більшість вразливостей вносяться в реєстр для пояснення нашим користувачам, чому певні виправлення надсилаються через Windows Update і чому їх слід інсталювати. Зміни на веб-сайтах, завантаження через Defender або через Store зазвичай не вносяться до реєстру.
Дослідники склали список модливих атак з використання вразливості
Взагалі, вразливість знаходиться в обробнику URI за замовчуванням у Windows 10 і може бути використана з різних програм. Тобто, коли користувач Windows 10 натискає шкідливе посилання «ms-officecmd:» у будь-якій програмі, довільні команди можуть виконуватися на комп’ютері жертви або відвідує шкідливий веб-сайт за допомогою Edge. Експлуатація через інші браузери змушує жертву клікнути на непримітне діалогове вікно підтвердження. З іншого боку, шкідливий URI може бути надісланий через настільну програму, яка виконує небезпечну обробку URL-адрес. У своїй публікації дослідники вказують, що окрім прямого RCE через –gpu-launcher можливі кілька інших сценаріїв атаки:
Введення аргументів, що стосуються програми, напр. перемикач /l у Word, щоб завантажити надбудову з шляху UNC. (хоча дослідники перевірили, що шляхи UNC отримані, вони не оцінили ефект завантаження шкідливих надбудов Office);
Введення параметра –host-rules для повного Electron MitM (повторний контроль над маркерами аутентифікації та повідомленнями Teams);
Введення параметра –inspect=0.0.0.0:1234 для створення локального сервера налагодження вузла за допомогою програми Electron. Потім зловмисник у локальній мережі може приєднатися до порту й використовувати нейтів код (також перевірено дослідниками зі Skype як експеримент).
Крім того, з’явилася можливість ще двох атак
Крім того, окрім введення аргументів, вони виявили можливість наступних двох атак:
Запуск Outlook із URL-адресою у форматі C:/…/some.exe/ (додаткова похила риска для проходження перевірки AppBridge.dll) змушує Outlook аналізувати посилання як посилання на локальний файл і переспрямовувати на/відкривати/виконати файл . Саме тому його можна включити в поведінку автоматичного завантаження Chrome для отримання довільного виконання коду після видачі попередження безпеки;
Запуск Outlook із веб-адресою як параметром, що відкриває цю веб-сторінку в Outlook, створюючи можливість для фішингових атак.
Хоча згідно з програмою MS Bounty результати могли би бути кваліфіковані до отримання винагороди в 50 тисяч доларів, замість цього вони отримали лише 5 тисяч доларів. Компанія випустила патч через 5 місяців, але, за словами дослідників, «не змогла належним чином вирішити проблему введення основного аргументу». Дослідники кажуть, що експлойт все ще присутній у Windows 11, і, враховуючи, скільки обробників URI має Windows, є можливість,що вони також вразливі.
24 листопада 2021 року дослідники з SafeBreach Labs опублікували дослідження щодо нової виявленої кібер загрози можливо іранського походження, в якій задіяно експлойт Microsoft MSHTML Remote Code Execution (RCE). Зловмисники атакуюють жертв за допомогою розширюваної оболонки від Майкрософт PowerShell. ShadowChasing вперше повідомила про загрозу нового PowerShortShell на своїй сторінці в Twitter. Однак спеціалістам не вдалося одразу отримати хеш/код PowerShell Stealer, оскільки він тривалий час був недоступний у загальнодоступних репозитаріях шкідливих програм.
hi threat why did you use it 😀 ITW:858404225565c80972ba66d2c612e49f filename:جنایات خامنه ای.docx URL: hxxp://hr.dedyn.io/word.html hxxp://hr.dedyn.io/word.cab hxxp://hr.dedyn.io/1.ps1 hxxp://hr.dedyn.io/upload.aspx?fn= hxxp://hr.dedyn.io/upload2.aspx pic.twitter.com/fHsgAshCNc
Дослідники кажуть, що з новим PowerShortShell могли оперувати іранські хакери
У своєму дослідженні SafeBreach Labs зробила аналіз повного ланцюга атаки, деталізувала виконання фішингових атак, які вперше почалися в липні цього року. Але найважливіше, зі слів самих дослідників, їм вдалося отримати код PowerShell Stealer, який отримав назву PowerShortShell. Скрипт був названий ними саме так через свою структуру, він містив трохи більше 150 рядків. Проте незважаючи на це, скрипт PowerShell дозволяв зловмиснику отримати доступ до широкого спектру інформації: файлів облікових записів в Телеграм, знімків екрана та оточення жертви.
«Майже половина жертв зафіксована у Сполучених Штатах. Виходячи з вмісту документа Microsoft Word, який звинувачує лідера Ірану у «короновірусній різанині» та характеру зібраних даних, ми припускаємо, що жертвами можуть бути іранці, які живуть за кордоном і можуть розглядатися як загроза ісламському режиму в Ірані», SafeBreach Labs пише у своєму дослідженні.
У своїх атаках зловмисник за допомогою PowerShortShell користався CVE-2021-40444. Це вразливість віддаленого виконання коду Microsoft Office MSHTML, яка дозволяє жодних макросів і вимагає лиш одноразового схвалення «відображення вмісту». Дослідники вважають, що атаки можуть бути пов’язані з ісламським режимом Ірану, судячи з використання методу нелегального доступу до облікового запису Telegram. Rampant Kitten, Infy і Ferocious Kitten, іранські хакерські угрупування, також використовували його. Цікаво, що в даному випадку застосовувалось досить виняткове використання експлойту, тому що більшістю все ж застосовуються трюки соціальної інженерії.
Атака пройшла у двоє етапів
Сама атака з використанням PowerShortShell складалася з двох етапів: спочатку проведення фішингу, а потім розсилання електронних листів зі шкідливими вкладеннями. Дві хвилі фішингових атак мали місце в липні 2021 року, коли хакери “виловлювали” у жертв дані для входу у їхні аккаунти Instagram та Gmail. Для цього використовували той самий сервер C2 Deltaban[.]dedyn[.]io. Зловмисники змаскували фішингову HTML-сторінку під справжнє туристичне агентство deltaban.com. Клік на який перенаправляв натомість на коротку іранську URL-адресу: https://yun[.]ir/jcccj. Ця URL-адреса виводила вікно з рядками для введення даних для входу у Гугл аккаунт [.]dedyn[.]io/Social/Google_Finish. Домен було зареєстровано у липні 2021 року.
Хакери замаскувалися під справжнє туристичне агенство
Зловмисники скидали таким чином викрадені облікові дані у файл out.txt, який будь-хто міг запросто переглянути у відкритому доступі. Друга фішингова кампанія зачепила Instagram. Тут облікові дані також відправлялися до того самого файлу out.txt. Усі фішингові, C2 та сервери зараження виходили з 95.217.50.126.
Те, що отримували жертви в одному з електронних листів
У свою чергу, експлойт-атака почалася 15 вересня 2021 року. Жертва отримувала електронний лист із документом Winword написаний фарсі. Перший документ під назвою Mozdor.docx. містив декілька зображень іранських солдатів. У другому із заголовком جنایات خامنه ای.docx (Злочини Хаменеї.docx) йшлося: «Один тиждень з Хаменеї; Скаржіться на винуватців короновірусної різанини, за яку винен і лідер». У ньому також були прикріпленні посилання на іранський новинний сайт та обліковий запис журналістки IranWire у Twitter. Файли Word підключалися до хакерського сервера, запускали шкідливий html, а потім перекидали dll (динамічно-з’єднувальна бібліотека) до каталогу %temp%. Файл Mozdor.docx містив експлойт у файлі document.xml.rels. Він виконував mshtml:http://hr[.]dedyn[.]io/image.html, а другий документ виконував mshtml:http://hr.dedyn.io/word.html. Ексфільтрація файлів Telegram здійснювалася до”https://hr.dedyn.io/upload2.aspx”. Дослідникам не вдалося знайти конкретних жертв атак, але вони оформили карту їх найбільшої кількості на основі отриманих даних. Найбільше було зареєстровано в США, Російській Федерації та Нідерландах.
