У нашому останньому дослідженні ми виявили 3 різні вразливості в TinyCheck, інструмент з відкритим кодом, розроблений і опублікований Феліксом Еме, одним із експертів Kaspersky GReAT. Кожна з уразливостей сама по собі має високу серйозність. Після об’єднання в ланцюжок віддалений зловмисник може використати його, щоб отримати RCE (віддалене виконання коду) на віддаленій машині TinyCheck.
У двох словах, ми використовували облікові дані за замовчуванням TinyCheck для редагування двох розділів у файлі конфігурації:
- У першому ми додали зловмисне корисне навантаження, яке буде виконано пізніше через введення команди уразливості.
- У другому ми додали URL-адресу до списку, який спричинить РСРФ, який пізніше запустить зловмисне корисне навантаження з першого розділу.
Що таке TinyCheck
TinyCheck дозволяє користувачеві аналізувати мережу пристрою. Користувач може підключити свій пристрій до проксі WiFi TinyCheck, який буде фіксувати мережеву активність. Цю діяльність можна проаналізувати на наявність шкідливого трафіку, що проходить через мережу.
Оскільки ми маємо досвід роботи з проксі в Android, ми знали, що простий проксі не повинен мати особливих проблем з обробкою потенційно шкідливого трафіку. Але TinyCheck має більше можливостей, пропонуючи кращі можливості нюхання, ніж простий проксі-скрипт. Вихідний код доступний на GitHub що дозволило його дослідити.
TinyCheck має 3 відповідні сервіси:
- «Бекенд» — сервер Flask, відкритий для світу та захищений іменем користувача/паролем (базова авторизація). Сервер здебільшого зосереджений на редагуванні конфігурації.
- «Frontend» — сервер Flask, який працює на локальному хості, не має пароля, і його основна робота полягає в тому, щоб запускати/зупиняти/керувати захопленням мережі.
- «Спостерігачі» — служба сторожового контролю, яка переглядатиме список URL-адрес і надсилатиме до них HTTP-запит GET.
Уразливість №1 – Облікові дані за замовчуванням
Це найпростіша з 3 уразливостей, але важлива для всієї атаки. За замовчуванням TinyCheck поставляється з обліковими даними за замовчуванням «tinycheck” як ім’я користувача та пароль.
Наявність таких облікових даних за замовчуванням, не вимагаючи від користувача змінювати їх під час першого використання, становить непотрібний ризик.
Використовуючи облікові дані за замовчуванням, ми мали доступ до різноманітних кінцевих точок на «сервері», що дало нам ширшу поверхню для атаки.
Важливою кінцевою точкою, яку ми використаємо пізніше, була та, яка редагує файл конфігурації YAML.
https://tinycheck.local/config/edit/CATEGORY/KEY/VALUE
Докладніше про те, як ми його використовували, нижче.
Уразливість №2 – SSRF
Забуття запиту на стороні сервера (SSRF) — це завжди цікаво, і розробники або дослідники безпеки часто не помічають його. Використовуючи цю вразливість, ми змогли змусити сервер зробити HTTP-запит. Це корисно для обходу брандмауера або для доступу до внутрішньої мережі, яка раніше була недоступна.
Ми виявили, що сервер має список URL-адрес, збережених у файлі конфігурації YAML під watchers/iocs:
Використовуючи першу вразливість, ми змогли переписати список і змінити його на наші власні URL-адреси:
Цікаво, що тепер ми змогли змусити службу «спостерігачів» виконувати HTTP-запит GET на будь-яку URL-адресу, яку ми виберемо. Найважливіше те, що ми могли вразити «інтерфейсний» сервер під час його запуску localhost після перезавантаження служби «спостерігачів».
Знову ж таки, це дало нам ширшу поверхню для атаки, щоб охопити більше кінцевих точок і більше логіки, яку ми могли використовувати.
Уразливість №3 – ін’єкція команди
Ми почали досліджувати «frontend» сервер. Нехай вас не бентежить назва, це сервер Flask, а не просто інтерфейс JS.
Маючи цілий новий світ кінцевих точок від уразливості SSRF, ми перевірили класи обслуговування, функції та утиліти, які можуть бути використані.
Прочитавши вихідний код і заглибившись у стек викликів функцій, ми натрапили на цей код:
Popen("tshark -i {}".format(self.iface), shell=True)Popen це спосіб виклику підпроцесу в Python. The shell=True і format це частини, які можна використовувати, тобто команда, яка буде виконана, інтерпретуватиметься як рядок. Хоча початковий намір тут працює, якщо self.iface це просто рядок на кшталт «eth0», ми зрозуміли, що якби ми змогли вставити зловмисно створений рядок, ми б змогли запустити довільний код.
На щастя для нас, self.iface фактично було прочитано з файлу конфігурації під network/in розділу, його початкове значення має вказувати на мережевий інтерфейс.
self.iface = read_config("network/in")Подібно до вразливості SSRF, ми впровадили наше корисне навантаження, використовуючи ту саму кінцеву точку редагування конфігурації.
Сама ін’єкція була простою:
; whoami>/tmp/exploit.outЦе означає, що з нашим корисним навантаженням вихідна команда буде відформатована так:
Popen("tshark -i ; whoami>/tmp/exploit.out", shell=True)Справді, файл містив це слово root, що означає, що ми можемо взяти контроль над системою, оскільки сервер працює від імені root, а не від призначеного користувача з низькими привілейованими правами.
Але ми повинні були запустити цей код. Прямо зараз наше корисне навантаження було виконано саме тоді, коли користувач починає фіксувати мережеву активність через інтерфейс користувача.
Повний ланцюжок експлойтів
Щоб зв’язати все разом, нам потрібен був спосіб активації нашого корисного навантаження.
Ми зробили це, скориставшись SSRF для виклику однієї з локальних «інтерфейсних» кінцевих точок, яка запускає функцію захоплення мережі, тому нам не потрібно чекати, поки це зробить користувач.
Це викликало вразливий код служби «спостерігачів» і ін’єкцію команди, яка виконувалася з нашим зловмисним корисним навантаженням.
Розголошення команді безпеки Kaspersky
Розкриття вразливості команді безпеки Kaspersky стало надзвичайно хорошим досвідом для нас. Залишається від них за те, що вони дуже швидко зв’язалися з нами та отримали лідерство щодо продукту, Фелікс Еме, який усунув усі вразливості за день-два.
Хронологія розкриття інформації
- 2020-12-14: Детальний звіт надіслано [захищено електронною поштою]
- 2020-12-15: перша відповідь від команди безпеки продуктів Kaspersky
- 2020-12-18: усі вразливості виправлено + консультування щоб оновити до виправленої версії
- 2021-01-22: видано CVE
- 2021-02-11: опубліковано допис у блозі
Хочете почути більше?
Включено безкоштовну консультаційну зустріч.
