В нашем последнем исследовании мы обнаружили 3 различные уязвимости в ТиниЧек, инструмент с открытым исходным кодом, разработанный и опубликованный Феликсом Эме, одним из лучших экспертов «Лаборатории Касперского». Каждая из уязвимостей сама по себе имеет высокую серьезность. После объединения в цепочку удаленный злоумышленник может использовать ее для получения RCE (удаленного выполнения кода) на удаленной машине TinyCheck.
Короче говоря, мы использовали учетные данные по умолчанию TinyCheck для редактирования двух разделов в конфигурационном файле:
- В первом мы добавили вредоносную полезную нагрузку, которая будет выполняться позже через командная инъекция уязвимость.
- Во втором мы добавили URL-адрес в список, который вызовет ССРФ, который позже вызовет вредоносную полезную нагрузку из первого раздела.
Что такое TinyCheck
TinyCheck позволяет пользователю анализировать сеть устройства. Пользователь может подключить свое устройство к прокси-серверу Wi-Fi TinyCheck, который будет фиксировать сетевую активность. Эта активность может быть проанализирована на наличие вредоносного трафика, проходящего через сеть.
Так как у нас есть опыт прокси в андроиде, мы знали, что у простого прокси не должно быть особых проблем с обработкой потенциально вредоносного трафика. Но TinyCheck более многофункционален, предлагая лучшие возможности перехвата, чем простой прокси-скрипт. Исходный код доступен на GitHub что дало возможность рассмотреть его.
TinyCheck имеет 3 соответствующих сервиса:
- «Бэкенд» — сервер Flask, открытый для всего мира и защищенный логином/паролем (базовая авторизация). Сервер в основном ориентирован на редактирование конфигурации.
- «Внешний интерфейс» — сервер Flask, который работает на локальном хосте, не имеет пароля, и его основная задача — запускать/останавливать/управлять захватом сети.
- «Наблюдатели» — служба наблюдения, которая будет перебирать список URL-адресов и выполнять для них HTTP-запрос GET.
Уязвимость №1 — учетные данные по умолчанию
Это самая простая из трех уязвимостей, но необходимая для всей атаки. По умолчанию 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. 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 Security
Сообщение об уязвимости команде безопасности «Лаборатории Касперского» стало для нас очень хорошим опытом. Спасибо им за то, что они очень быстро связались с нами и получили информацию о продукте, Феликс Эме, которые устранили все уязвимости за день-два.
Раскрытие Хронология
- 2020: Подробный отчет отправлен [электронная почта защищена]
- 2020: Первый ответ от группы безопасности продуктов «Лаборатории Касперского».
- 2020: Закрыты все уязвимости + консультирование перейти на пропатченную версию
- 2021 января 01 г.: выпущены CVE
- 2021: Опубликован пост в блоге
Хотите услышать больше?
Включена бесплатная консультационная встреча.
