Обзор
Во многих компаниях, ежедневная процедура включает ежедневный приход в офис для работы на компьютере вашей компании, находясь в безопасности внутри корпоративной сети. Время от времени, работнику может потребоваться специальный доступ вне офиса, и он будет подключаться к сети компании удаленно, используя один из нескольких доступных инструментов.
Однако, после начала пандемии COVID-19, этот распорядок дня изменился. В Check Point, как и во многих других компаниях по всему миру, подавляющее большинство работы теперь выполняется удаленно, в основном из дома. Этот переход от локального к внешнему виду работы означает, что ИТ-решения для удаленного подключения к корпоративной сети теперь используются как никогда. Это также означает, что любая уязвимость безопасности в этих решениях будет иметь гораздо большее влияние, так как компании полагаются на эту технологию для поддержания функционирования своего бизнеса.
Apache Guacamole (https://guacamole.apache.org/) - это популярная инфраструктура для удаленной работы, с более чем 10 миллионами загрузок докеров ()https://hub.docker.com/r/guacamole/guacamole по всему миру. В нашем исследовании, мы обнаружили, что Apache Guacamole уязвим к нескольким критическим уязвимостям Reverse RDP (https://research.checkpoint.com/2019/reverse-rdp-attack-code-execution-on-rdp-clients/), а также подвержен влиянию нескольких новых уязвимостей, обнаруженных в FreeRDP (https://www.freerdp.com/). Короче говоря, эти уязвимости позволяют злоумышленнику, который уже успешно скомпрометировал компьютер внутри организации, начать атаку на шлюз Guacamole, когда ничего не подозревающий работник пытается подключиться к зараженной машине. Затем злоумышленник может получить полный контроль над сервером Guacamole, а также перехватывать и контролировать все другие связанные сеансы.
В этом короткой видео-демонстрации, мы демонстрируем, как нам удалось эксплуатировать эти уязвимости и успешно взять на себя управление шлюзом Guacamole и всеми подключенными сеансами:
Введение в Apache Guacamole
Заинтригованные этим переходом к работе в основном из дома, мы решили, что технологические решения для удаленной работы станут интересной темой для исследования. И действительно, сразу же, наш ИТ-отдел просил нас рассмотреть одно из таких решений Apache Guacamole. Как упоминалось ранее, это один из наиболее заметных инструментов на рынке. Мало того, что многие организации используют этот продукт для подключения к своим сетям, многие продукты для обеспечения доступности и безопасности сети также встроили Apache Guacamole в свои собственные продукты. Этот список включает в себя: Jumpserver Fortress (https://www.jumpserver.org/), Quali (https://www.quali.com/), Fortigate (https://forum.fortinet.com/tm.aspx?m=171727), и этот список можно продолжить.
После некоторой разведки мы нарисовали базовый эскиз рекомендуемой сетевой архитектуры, как показано на Рисунке 1:
По сути, сотрудник использует браузер для подключения к интернет-серверу своей компании, проходит процедуру аутентификации и получает доступ к своему корпоративному компьютеру. В то время как сотрудник использует только свой браузер, сервер guacamole выбирает один из поддерживаемых протоколов (RDP, VNC, SSH и так далее) и использует клиент с открытым исходным кодом для подключения к конкретному корпоративному компьютеру. После подключения, сервер guacamole действует как посредник, который передает события назад и вперед, переводя их из выбранного протокола в специальный "протокол Guacamole", и наоборот.
Теперь, когда мы понимаем, как выглядит архитектура, вот несколько многообещающих векторов атак:
Нужен ли нам 0-Day ?
Прежде чем мы углубимся в код, давайте кратко остановимся на FreeRDP. В нашем предыдущем исследовании Reverse RDP Attack (https://research.checkpoint.com/2019/reverse-rdp-attack-code-execution-on-rdp-clients/), мы обнаружили несколько критических уязвимостей в этом RDP-клиенте, которые подвергли его атаке со стороны вредоносного RDP-сервера. Другими словами, вредоносный корпоративный компьютер может взять под контроль ничего не подозревающий клиент FreeRDP, который подключается к нему. У нас даже был базовый PoC для одной из наших уязвимостей (CVE-2018-8786)(https://cpr-zero.checkpoint.com/vulns/cprid-2007/), и мы продемонстрировали удаленное выполнение кода (RCE).
Глядя на выпущенные версии Apache Guacamole, мы видим, что только в версии 1.1.0, выпущенной в конце января 2020 года, добавлена поддержка последней версии FreeRDP (2.0.0). Зная, что наши уязвимости в FreeRDP были исправлены только в версии 2.0.0-rc4, это означает, что все версии, выпущенные до января 2020 года, используют уязвимые версии FreeRDP.
Мы могли бы остановиться здесь и оценить высокую вероятность того, что большинство компаний еще не обновили до последних версий и уже могут быть атакованы с использованием этих известных 1-Days. Однако, мы решили еще раз найти уязвимости в протоколе RDP, а точнее:
Вдобавок ко всему, наши условия эксплоита - возможность работать на установках по умолчанию, используя только те функции, которые включены по умолчанию и, надеюсь, не требуют взаимодействия с клиентом. Давайте начнем.
В поисках новых уязвимостей
Знакомство с кодом FreeRDP и с RDP в целом действительно помогло во время этого аудита безопасности. Мы быстро начали искать уязвимости.
Примечание: поскольку Apache не использовал соотношение 1:1 между нашими зарегистрированными уязвимостями (CPR-ID) и выпущенными ими CVE-ID, мы будем в основном ссылаться на их уязвимости (более точным) CPR-ID. Чтобы передать сообщения между RDP-соединением и клиентом, разработчики реализовали собственное расширение для каналов RDP по умолчанию. Один такой канал отвечает за аудио с сервера, поэтому неудивительно, что он называется rdpsnd (RDP Sound).
Однако, как это часто бывает, точка интеграции между сервером guacamole и FreeRDP оказалась подверженной ошибкам. Входящие сообщения оборачиваются объектами wStream FreeRDP, и данные должны анализироваться с использованием API этого объекта. Однако, как видно на Рисунке 2, разработчики забыли принудительно установить, что объект входящего потока должен содержать количество байтов, соответствующее объему, объявленному пакетом.
Отправляя вредоносное сообщение канала rdpsnd, вредоносный RDP-сервер может заставить клиента думать, что пакет содержит огромное количество байтов, которые фактически являются байтами памяти самого клиента. Это, в свою очередь, приводит к тому, что клиент отправляет ответ на сервер с этими байтами, и предоставляет RDP-серверу массивный примитив раскрытия информации, типа heartbleed.
В том же канале RDP, другое сообщение имеет аналогичную уязвимость. На этот раз он отправляет данные типа Out-of-Bounds подключенному клиенту, а не обратно на сервер RDP.
Хотя эта утечка полезна, она отправляет информацию клиенту, и мы надеемся создать эксплойт, даже не зная, что шлюз подвергся атаке.
CPR-ID-2143 – What a surprise, an Information Disclosure
Мы были заинтригованы, чтобы найти дополнительный канал, guacai, отвечающий за звуковые сообщения. Этот канал отвечает за "Аудио вход", отсюда и название guacai. Хотя этот канал уязвим примерно к той же уязвимости, что и предыдущий канал, по умолчанию этот канал отключен.
На этом этапе нашего исследования, мы обнаружили 3 основных уязвимости раскрытия информации, которых должно быть более чем достаточно для обхода ASLR (рандомизации расположения адресного пространства). Однако, нам все еще нужна уязвимость повреждения памяти, чтобы завершить нашу цепочку эксплойтов. Чувствуя себя застрявшими, мы снова пошли посмотреть на FreeRDP, надеясь найти уязвимости, которые мы могли упустить в нашем предыдущем исследовании.
FreeRDP, наш старый друг
С тех пор, как мы последний раз смотрели его, в RDP-клиент не было внесено много изменений; исправленная версия до сих пор является самой последней на сегодняшний день. Как всегда при поиске уязвимостей, давайте сначала разберемся с ключевой "особенностью" дизайна в типе wStream, используемом этим клиентом. На Рисунке 5 мы можем видеть поля этой структуры:
Это классический пример простой потоковой обёртки:
Перед тем, как данное поле будет проанализировано из входного потока, должна быть сделана проверка, чтобы убедиться, что поток достаточно велик для его хранения. Такую проверку можно увидеть на рисунке 6:
Мы не можем не подчеркнуть, насколько важна эта проверка ввода. Каждый раз, когда поле анализируется или пропускается, поле указателя продвигается соответствующим образом. Позже, когда следующая проверка выполняется, это выглядит так:
Как только поле указателя пройдет конец входящего пакета, это вычисление не будет выполнено, и поэтому будет возвращено огромное значение без знака, которое должно представлять отрицательное количество оставшихся байтов. Одним словом, пропустите одну проверку, а остальные будут бесполезны. Этот интересный дизайн делает FreeRDP очень уязвимым для уязвимостей вида чтения за пределами, как мы вскоре выяснили.
Прежде чем представить эти уязвимости я, важно отметить, почему мы заботимся о них. Обычно, чтение полезно только в том случае, если оно возвращает байты чтения тем или иным способом злоумышленнику. В противном случае, чтение может использоваться как способ сбоя программы, когда она пытается получить доступ к не отображенным страницам в памяти. Сценарий атаки Apache Guacamole является особенным, потому что мы держим оба конца соединения. Если, например, байты памяти анализируются как графические обновления на экране, эти обновления все равно будут отправлены подключенному клиенту.
В этом сценарии, атаки каждая уязвимость может, вероятно, превратиться в слабое, но все же полезное раскрытие информации.
CPR-ID-2145 & CPR-ID-2146 – Out-of-Bounds Reads in FreeRDP
Вспоминая интересный недостаток дизайна в объекте wStream, все, что нам нужно было сделать, - это искать операции чтения, которые не поддерживаются проверками. Это сработало довольно хорошо, и мы обнаружили две такие уязвимости: CPR-ID-2145 и CPR-ID-2146.
Однако, сообщая о них поставщику, мы обнаружили, что они оба уже были зарегистрированы двумя отдельными группами. Поскольку они являются дубликатами, они должны быть приписаны их законным исследователям, даже если мы представили их только несколько часов спустя.
Поэтому мы решили, что более целесообразно позволить другим командам представить свои выводы, и удалили подробности о них из нашего блога.
Нам нужно повреждение памяти ...
На данный момент мы обнаружили 5 уязвимостей, которые могут служить примитивами раскрытия информации в нашей атаке. Тем не менее, мы еще не нашли ни одной уязвимости повреждения памяти. Поиск таких уязвимостей во FreeRDP был довольно неприятным, так как каждый раз, когда у нас было преимущество, проверка блокировала его.
Этот пост в популярном профиле Zensploitation в Твиттере (@zensploitation) в значительной степени обобщает наши ощущения на данный момент в нашем исследовании:
В этот момент, мы решили, что зашли слишком далеко, чтобы просто сдаться. Мы решили еще раз взглянуть на guacamole-сервер, и на этот раз все заработало
CPR-ID-2144 – At last, a Memory Corruption
Протокол RDP выставляет разные "устройства" как отдельные "каналы", по одному для каждого устройства. К ним относятся канал rdpsnd для звука, cliprdr для буфера обмена и так далее. Как уровень абстракции, сообщения канала поддерживают фрагментацию, которая позволяет их сообщениям иметь длину до 4 ГБ. Для правильной поддержки каналов rdpsnd и rdpdr (Device Redirection) разработчики guacamole-server добавили дополнительный уровень абстракции, реализованный в файле: guac_common_svc.c. На Рисунке 9 показана обработка фрагментации, реализованная в этом файле:
Мы видим, что первый фрагмент должен содержать фрагмент CHANNEL_FLAG_FIRST, и при обработке поток распределяется в соответствии с общей объявленной длиной всего сообщения.
Однако что произойдет, если злоумышленник отправит фрагмент без этого флага? Кажется, что он просто добавляется к предыдущему оставшемуся потоку. На данный момент, это выглядит как многообещающая уязвимость Dangling-Pointer. Теперь нам нужно только проверить, не забыли ли разработчики установить его в NULL, когда предыдущее фрагментированное сообщение завершило свою обработку.
На Рисунке 10 ясно показано, что после того, как фрагментированное сообщение завершает повторную сборку и продолжает анализироваться, оно освобождается. И это все. Никто не устанавливает указатель на NULL!
Вредоносный RDP-сервер может отправлять фрагмент сообщения не в очереди, в котором используется ранее освобожденный объект wStream, что фактически превращается в уязвимость UAF. Кроме того, wStream - это самый мощный объект, который мы могли бы надеяться получить для такой уязвимости, поскольку он может использоваться для произвольной записи, если в поле указателя задан желаемый адрес памяти. Кроме того, у нас есть полезная уязвимость раскрытия информации в канале rdpsnd сразу после использования нашего поврежденного объекта wStream. С некоторыми усилиями, специально созданный объект wStream может превратить нашу первоначальную уязвимость в более мощный примитив эксплойта произвольного чтения.
Наконец, удаленное выполнение кода (RCE)
Как описано ранее, с помощью уязвимостей CVE-2020-9497 и CVE-2020-9498 нам удалось реализовать наши примитивы эксплойтов произвольного чтения и произвольной записи. Используя эти два мощных примитива, мы успешно реализовали эксплойт удаленного выполнения кода (RCE), в котором вредоносный корпоративный компьютер (наш RDP-сервер) может взять под контроль процесс guacd, когда удаленный пользователь запрашивает подключение к своему (зараженному) компьютеру.
Но путешествие здесь не заканчивается. Процесс guacd обрабатывает только одно соединение и работает с низкими привилегиями. Традиционно, на этом этапе нам нужна уязвимость повышения привилегий(PE), чтобы захватить весь шлюз. И действительно, во время скоординированного раскрытия с Apache один из вопросов, которые задавали сопровождающие, заключался в том, действительно ли этот сценарий атаки возможен. Можем ли мы каким-то образом принять все соединения в шлюзе только с одного процесса guacd?
Давайте разберемся.
Apache Guacamole – глубокое погружение
Если мы углубимся в архитектуру сети шлюза Guacamole, которую мы видели ранее, мы увидим следующее:
Для повышения привилегий мы фокусируемся на этих двух компонентах:
guacamole-client
Компонент guacamole-client отвечает за веб-сервер, который выполняет аутентификацию пользователя. Этот веб-сервер содержит конфигурации, необходимые для каждого сеанса пользователя, и хранит такую информацию, как:
После успешной аутентификации клиента, клиент guacamole инициирует сеанс протокола Guacamole с сервером Guacamole, чтобы создать соответствующий сеанс для клиента. Это делается путем подключения к серверу guacamole через TCP-порт 4822 (по умолчанию), который прослушивает процесс guacd.
После создания сеанса, клиент-guacamole передает информацию только между сервером guacamole и браузером клиента.
guacamole-server
Согласно документации Apache: "guacd - это сердце guacd". После запуска, guacd прослушивает TCP-порт 4822 и ожидает входящих инструкций от клиента guacamole. Важно отметить, что связь через этот порт не использует аутентификацию или шифрование (SSL может быть включен, но он не используется по умолчанию). По этой причине, мы добавили два брандмауэра на Рисунке 12, которые должны отвечать за ограничение доступа к этому TCP-порту, позволяя подключаться только guacamole-клиенту.
Когда соединение установлено, guacd создает новый поток и вызывает функцию, которая отвечает за запуск протокола Guacamole. На данный момент есть два варианта пользователя:
Дополнительное примечание: Мы используем термин соединение вместо сеанса, поскольку этот термин используется Guacamole для обозначения соединения с данным компьютером. Каждый компьютер имеет одно соединение, и несколько пользователей могут использовать одно и то же соединение. Не существует "пользовательского сеанса", поскольку весь проект основан на соединении Guacamole с данным компьютером, и пользователи просто присоединяются к соединениям.
Первый вариант, безусловно, наиболее широко используемый. В этом случае, для вновь созданного соединения генерируется случайный уникальный идентификатор (UUID), и для него создается процесс fork(). Отображение между UUID и новым процессом сохраняется в словаре в памяти, называемом proc-map, и UUID отправляется обратно клиенту guacamole. Важно отметить, что порожденный процесс немедленно отбрасывает свои разрешения, прежде чем он инициирует соединение с компьютером внутри сети.
Второй вариант довольно уникален и, вероятно, был реализован таким образом, чтобы несколько пользователей могли совместно использовать одно соединение и работать вместе. В этом случае, пользователь запрашивает присоединение к существующему соединению, предоставляя UUID соединения. Чтобы различать пользователей, пользователь, создавший соединение, является "владельцем", а другим пользователям для "владельца" установлено значение false. Эта опция также включает возможность подключения только для чтения для пользователей, которые не помечены как "владелец".
Для поддержки присоединения пользователей порожденный процесс для данного соединения наследует пару сокетов для связи с родительским процессом guacd.В то время как основной поток инициализирует требуемый клиент, например FreeRDP для соединения RDP, другой поток ожидает сообщений от родительского процесса, сигнализируя нашему процессу, что новый пользователь попросил присоединиться к соединению.
Процесс guacd действует как менеджер соединений, который порождает процессы для каждого соединения, и в то же время также реализует основную логику для этих порожденных процессов. По этой причине отныне мы будем называть родительский процесс guacd основным процессом.
Повышение привилегий - шаг за шагом
Шаг # 0 - Возьмите один процесс guacd
У нас уже есть рабочий эксплойт для этой части.
Шаг # 1 - Masquerade as the guacamole-client
Хотя процесс guacd, который мы контролируем, является только процессом с низкими привилегиями, который выполняется внутри шлюза, он все еще имеет несколько полезных привилегий. Для начала, запуск на шлюзе позволяет нам подключаться к основному процессу через TCP-порт 4822. Поскольку основной процесс не ожидает аутентификации через этот порт, ничто не мешает нам подключиться к нему и контролировать процесс точно так же, как это делает обычный guacamole-клиент.
Шаг # 2 - Собирайте секреты из нашей памяти
Это ключевой выбор дизайна для нас для эксплоита. Так как исполняемый файл guacd содержит логику как основного процесса, так и процессов для каждого соединения, при создании нового процесса соединения используется только fork(). Этот оператор повторяется: используется только fork() без execve ()!
Что это значит? Разветвленный процесс содержит весь снимок памяти своего родителя, и этот снимок заменяется новым образом при вызове execve(). Без этого важного вызова дочерний процесс наследует все адресное пространство памяти своего родителя. Это включает:
Это означает, что наш процесс имеет отображение proc-map, которое сопоставляет UUID каждого секретного соединения с соответствующим процессом. Нам нужно только найти эту структуру данных в нашей памяти, и у нас будут все текущие активные UUID.
Расположение самой proc-карты было чисто техническим. В нашем эксплойте, мы нашли его, прочитав файл макета памяти нашего proc из /proc/<pid>/maps. Структура данных настолько велика, что mmap() была выделена в автономное выделение памяти, и поэтому у нее есть собственная запись в файле.
Шаг # 3 - Присоединиться ко всем сессиям
Мы уже убедили основной процесс в том, что мы можем инициировать запросы по протоколу гуакамоле, и теперь мы даже знаем, какие запросы запрашивать. Наш следующий шаг - запросить присоединение к каждому из существующих соединений, указав их теперь известные UUID.
Удивительно, но атрибут сеанса "только для чтения" устанавливается клиентом guacamole. Это означает, что, хотя мы не являемся владельцами соединений, мы все равно можем отключить бит привилегии "только для чтения" для нашего присоединяющегося пользователя и получить полные разрешения для соединения. Кроме того, кроме сообщения журнала в основном процессе, как видно на Рисунке 14, нет никаких видимых признаков того, что другой пользователь только что присоединился к соединению.
Шаг # 4 - Повторение
Если вы уделяли пристальное внимание, вы, возможно, заметили недостаток в нашем плане атаки: наш процесс guacd имеет устаревшее изображение отображение proc-map. Любой сеанс, который начинается после того, как мы были порождены, будет обновляться только на proc-map и поэтому не будет доступен в нашем устаревшем образе памяти.
Этот недостаток имеет простое решение. Каждый выбранный интервал, скажем, 5 минут, мы можем отправлять первичному процессу команду на запуск нового RDP-соединения и подключение к нашей зараженной машине в сети. Таким образом, новый guacd порождается, и теперь содержит обновленную версию proc-map. Используя наш оригинальный эксплойт, мы также можем атаковать этот процесс и "обновить" нашу версию proc-map.
Вот полная цепочка эксплойтов, RCE + PE, в действии:
Хронология раскрытия
Заключение
Мы продемонстрировали новый взгляд на сценарий Reverse RDP Attack, который мы первоначально представили в начале 2019 года. Хотя пользователи обычно думают о клиенте RDP ... ну ... как о клиенте, сценарий Apache Guacamole учит нас иначе. В стандартном случае злоумышленник может использовать уязвимость в клиенте для получения контроля над одним корпоративным компьютером. Однако при развертывании в шлюзе такие уязвимости оказывают гораздо более серьезное влияние на организацию.
Хотя переход к удаленной работе из дома является необходимостью в эти трудные времена пандемии COVID-19, мы не можем пренебрегать последствиями таких удаленных подключений для безопасности. Используя Apache Guacamole в качестве примера, мы смогли успешно продемонстрировать, как скомпрометированный компьютер внутри организации можно использовать для управления шлюзом, который обрабатывает все удаленные сеансы в сети.
Получив контроль над шлюзом, злоумышленник может прослушивать все входящие сеансы, записывать все используемые учетные данные и даже запускать новые сеансы для управления остальными компьютерами в организации. Когда большая часть организации работает удаленно, эта точка опоры равносильна получению полного контроля над всей организационной сетью.
Мы настоятельно рекомендуем всем убедиться в том, что все серверы обновлены и что любая технология, используемая для работы на дому, полностью исправлена, чтобы блокировать такие попытки атаки. В нашем случае, в течение 24 часов с момента обнаружения уязвимостей и доказательства того, что они действительно могут быть использованы, мы внедрили исправление безопасности и стали первой производственной средой, защищенной от этой уязвимости безопасности, что обеспечило безопасное удаленное подключение наших сотрудников.
Источник: https://research.checkpoint.com/2020/apache-guacamole-rce/
Автор перевода: yashechka
Переведено специально для портала xss.pro (c)
Во многих компаниях, ежедневная процедура включает ежедневный приход в офис для работы на компьютере вашей компании, находясь в безопасности внутри корпоративной сети. Время от времени, работнику может потребоваться специальный доступ вне офиса, и он будет подключаться к сети компании удаленно, используя один из нескольких доступных инструментов.
Однако, после начала пандемии COVID-19, этот распорядок дня изменился. В Check Point, как и во многих других компаниях по всему миру, подавляющее большинство работы теперь выполняется удаленно, в основном из дома. Этот переход от локального к внешнему виду работы означает, что ИТ-решения для удаленного подключения к корпоративной сети теперь используются как никогда. Это также означает, что любая уязвимость безопасности в этих решениях будет иметь гораздо большее влияние, так как компании полагаются на эту технологию для поддержания функционирования своего бизнеса.
Apache Guacamole (https://guacamole.apache.org/) - это популярная инфраструктура для удаленной работы, с более чем 10 миллионами загрузок докеров ()https://hub.docker.com/r/guacamole/guacamole по всему миру. В нашем исследовании, мы обнаружили, что Apache Guacamole уязвим к нескольким критическим уязвимостям Reverse RDP (https://research.checkpoint.com/2019/reverse-rdp-attack-code-execution-on-rdp-clients/), а также подвержен влиянию нескольких новых уязвимостей, обнаруженных в FreeRDP (https://www.freerdp.com/). Короче говоря, эти уязвимости позволяют злоумышленнику, который уже успешно скомпрометировал компьютер внутри организации, начать атаку на шлюз Guacamole, когда ничего не подозревающий работник пытается подключиться к зараженной машине. Затем злоумышленник может получить полный контроль над сервером Guacamole, а также перехватывать и контролировать все другие связанные сеансы.
В этом короткой видео-демонстрации, мы демонстрируем, как нам удалось эксплуатировать эти уязвимости и успешно взять на себя управление шлюзом Guacamole и всеми подключенными сеансами:
Введение в Apache Guacamole
Заинтригованные этим переходом к работе в основном из дома, мы решили, что технологические решения для удаленной работы станут интересной темой для исследования. И действительно, сразу же, наш ИТ-отдел просил нас рассмотреть одно из таких решений Apache Guacamole. Как упоминалось ранее, это один из наиболее заметных инструментов на рынке. Мало того, что многие организации используют этот продукт для подключения к своим сетям, многие продукты для обеспечения доступности и безопасности сети также встроили Apache Guacamole в свои собственные продукты. Этот список включает в себя: Jumpserver Fortress (https://www.jumpserver.org/), Quali (https://www.quali.com/), Fortigate (https://forum.fortinet.com/tm.aspx?m=171727), и этот список можно продолжить.
После некоторой разведки мы нарисовали базовый эскиз рекомендуемой сетевой архитектуры, как показано на Рисунке 1:
По сути, сотрудник использует браузер для подключения к интернет-серверу своей компании, проходит процедуру аутентификации и получает доступ к своему корпоративному компьютеру. В то время как сотрудник использует только свой браузер, сервер guacamole выбирает один из поддерживаемых протоколов (RDP, VNC, SSH и так далее) и использует клиент с открытым исходным кодом для подключения к конкретному корпоративному компьютеру. После подключения, сервер guacamole действует как посредник, который передает события назад и вперед, переводя их из выбранного протокола в специальный "протокол Guacamole", и наоборот.
Теперь, когда мы понимаем, как выглядит архитектура, вот несколько многообещающих векторов атак:
Нужен ли нам 0-Day ?
Прежде чем мы углубимся в код, давайте кратко остановимся на FreeRDP. В нашем предыдущем исследовании Reverse RDP Attack (https://research.checkpoint.com/2019/reverse-rdp-attack-code-execution-on-rdp-clients/), мы обнаружили несколько критических уязвимостей в этом RDP-клиенте, которые подвергли его атаке со стороны вредоносного RDP-сервера. Другими словами, вредоносный корпоративный компьютер может взять под контроль ничего не подозревающий клиент FreeRDP, который подключается к нему. У нас даже был базовый PoC для одной из наших уязвимостей (CVE-2018-8786)(https://cpr-zero.checkpoint.com/vulns/cprid-2007/), и мы продемонстрировали удаленное выполнение кода (RCE).
Глядя на выпущенные версии Apache Guacamole, мы видим, что только в версии 1.1.0, выпущенной в конце января 2020 года, добавлена поддержка последней версии FreeRDP (2.0.0). Зная, что наши уязвимости в FreeRDP были исправлены только в версии 2.0.0-rc4, это означает, что все версии, выпущенные до января 2020 года, используют уязвимые версии FreeRDP.
Мы могли бы остановиться здесь и оценить высокую вероятность того, что большинство компаний еще не обновили до последних версий и уже могут быть атакованы с использованием этих известных 1-Days. Однако, мы решили еще раз найти уязвимости в протоколе RDP, а точнее:
Вдобавок ко всему, наши условия эксплоита - возможность работать на установках по умолчанию, используя только те функции, которые включены по умолчанию и, надеюсь, не требуют взаимодействия с клиентом. Давайте начнем.
В поисках новых уязвимостей
Знакомство с кодом FreeRDP и с RDP в целом действительно помогло во время этого аудита безопасности. Мы быстро начали искать уязвимости.
Примечание: поскольку Apache не использовал соотношение 1:1 между нашими зарегистрированными уязвимостями (CPR-ID) и выпущенными ими CVE-ID, мы будем в основном ссылаться на их уязвимости (более точным) CPR-ID. Чтобы передать сообщения между RDP-соединением и клиентом, разработчики реализовали собственное расширение для каналов RDP по умолчанию. Один такой канал отвечает за аудио с сервера, поэтому неудивительно, что он называется rdpsnd (RDP Sound).
Однако, как это часто бывает, точка интеграции между сервером guacamole и FreeRDP оказалась подверженной ошибкам. Входящие сообщения оборачиваются объектами wStream FreeRDP, и данные должны анализироваться с использованием API этого объекта. Однако, как видно на Рисунке 2, разработчики забыли принудительно установить, что объект входящего потока должен содержать количество байтов, соответствующее объему, объявленному пакетом.
Отправляя вредоносное сообщение канала rdpsnd, вредоносный RDP-сервер может заставить клиента думать, что пакет содержит огромное количество байтов, которые фактически являются байтами памяти самого клиента. Это, в свою очередь, приводит к тому, что клиент отправляет ответ на сервер с этими байтами, и предоставляет RDP-серверу массивный примитив раскрытия информации, типа heartbleed.
В том же канале RDP, другое сообщение имеет аналогичную уязвимость. На этот раз он отправляет данные типа Out-of-Bounds подключенному клиенту, а не обратно на сервер RDP.
Хотя эта утечка полезна, она отправляет информацию клиенту, и мы надеемся создать эксплойт, даже не зная, что шлюз подвергся атаке.
CPR-ID-2143 – What a surprise, an Information Disclosure
Мы были заинтригованы, чтобы найти дополнительный канал, guacai, отвечающий за звуковые сообщения. Этот канал отвечает за "Аудио вход", отсюда и название guacai. Хотя этот канал уязвим примерно к той же уязвимости, что и предыдущий канал, по умолчанию этот канал отключен.
На этом этапе нашего исследования, мы обнаружили 3 основных уязвимости раскрытия информации, которых должно быть более чем достаточно для обхода ASLR (рандомизации расположения адресного пространства). Однако, нам все еще нужна уязвимость повреждения памяти, чтобы завершить нашу цепочку эксплойтов. Чувствуя себя застрявшими, мы снова пошли посмотреть на FreeRDP, надеясь найти уязвимости, которые мы могли упустить в нашем предыдущем исследовании.
FreeRDP, наш старый друг
С тех пор, как мы последний раз смотрели его, в RDP-клиент не было внесено много изменений; исправленная версия до сих пор является самой последней на сегодняшний день. Как всегда при поиске уязвимостей, давайте сначала разберемся с ключевой "особенностью" дизайна в типе wStream, используемом этим клиентом. На Рисунке 5 мы можем видеть поля этой структуры:
Это классический пример простой потоковой обёртки:
Перед тем, как данное поле будет проанализировано из входного потока, должна быть сделана проверка, чтобы убедиться, что поток достаточно велик для его хранения. Такую проверку можно увидеть на рисунке 6:
Мы не можем не подчеркнуть, насколько важна эта проверка ввода. Каждый раз, когда поле анализируется или пропускается, поле указателя продвигается соответствующим образом. Позже, когда следующая проверка выполняется, это выглядит так:
Как только поле указателя пройдет конец входящего пакета, это вычисление не будет выполнено, и поэтому будет возвращено огромное значение без знака, которое должно представлять отрицательное количество оставшихся байтов. Одним словом, пропустите одну проверку, а остальные будут бесполезны. Этот интересный дизайн делает FreeRDP очень уязвимым для уязвимостей вида чтения за пределами, как мы вскоре выяснили.
Прежде чем представить эти уязвимости я, важно отметить, почему мы заботимся о них. Обычно, чтение полезно только в том случае, если оно возвращает байты чтения тем или иным способом злоумышленнику. В противном случае, чтение может использоваться как способ сбоя программы, когда она пытается получить доступ к не отображенным страницам в памяти. Сценарий атаки Apache Guacamole является особенным, потому что мы держим оба конца соединения. Если, например, байты памяти анализируются как графические обновления на экране, эти обновления все равно будут отправлены подключенному клиенту.
В этом сценарии, атаки каждая уязвимость может, вероятно, превратиться в слабое, но все же полезное раскрытие информации.
CPR-ID-2145 & CPR-ID-2146 – Out-of-Bounds Reads in FreeRDP
Вспоминая интересный недостаток дизайна в объекте wStream, все, что нам нужно было сделать, - это искать операции чтения, которые не поддерживаются проверками. Это сработало довольно хорошо, и мы обнаружили две такие уязвимости: CPR-ID-2145 и CPR-ID-2146.
Однако, сообщая о них поставщику, мы обнаружили, что они оба уже были зарегистрированы двумя отдельными группами. Поскольку они являются дубликатами, они должны быть приписаны их законным исследователям, даже если мы представили их только несколько часов спустя.
Поэтому мы решили, что более целесообразно позволить другим командам представить свои выводы, и удалили подробности о них из нашего блога.
Нам нужно повреждение памяти ...
На данный момент мы обнаружили 5 уязвимостей, которые могут служить примитивами раскрытия информации в нашей атаке. Тем не менее, мы еще не нашли ни одной уязвимости повреждения памяти. Поиск таких уязвимостей во FreeRDP был довольно неприятным, так как каждый раз, когда у нас было преимущество, проверка блокировала его.
Этот пост в популярном профиле Zensploitation в Твиттере (@zensploitation) в значительной степени обобщает наши ощущения на данный момент в нашем исследовании:
В этот момент, мы решили, что зашли слишком далеко, чтобы просто сдаться. Мы решили еще раз взглянуть на guacamole-сервер, и на этот раз все заработало
CPR-ID-2144 – At last, a Memory Corruption
Протокол RDP выставляет разные "устройства" как отдельные "каналы", по одному для каждого устройства. К ним относятся канал rdpsnd для звука, cliprdr для буфера обмена и так далее. Как уровень абстракции, сообщения канала поддерживают фрагментацию, которая позволяет их сообщениям иметь длину до 4 ГБ. Для правильной поддержки каналов rdpsnd и rdpdr (Device Redirection) разработчики guacamole-server добавили дополнительный уровень абстракции, реализованный в файле: guac_common_svc.c. На Рисунке 9 показана обработка фрагментации, реализованная в этом файле:
Мы видим, что первый фрагмент должен содержать фрагмент CHANNEL_FLAG_FIRST, и при обработке поток распределяется в соответствии с общей объявленной длиной всего сообщения.
Однако что произойдет, если злоумышленник отправит фрагмент без этого флага? Кажется, что он просто добавляется к предыдущему оставшемуся потоку. На данный момент, это выглядит как многообещающая уязвимость Dangling-Pointer. Теперь нам нужно только проверить, не забыли ли разработчики установить его в NULL, когда предыдущее фрагментированное сообщение завершило свою обработку.
На Рисунке 10 ясно показано, что после того, как фрагментированное сообщение завершает повторную сборку и продолжает анализироваться, оно освобождается. И это все. Никто не устанавливает указатель на NULL!
Вредоносный RDP-сервер может отправлять фрагмент сообщения не в очереди, в котором используется ранее освобожденный объект wStream, что фактически превращается в уязвимость UAF. Кроме того, wStream - это самый мощный объект, который мы могли бы надеяться получить для такой уязвимости, поскольку он может использоваться для произвольной записи, если в поле указателя задан желаемый адрес памяти. Кроме того, у нас есть полезная уязвимость раскрытия информации в канале rdpsnd сразу после использования нашего поврежденного объекта wStream. С некоторыми усилиями, специально созданный объект wStream может превратить нашу первоначальную уязвимость в более мощный примитив эксплойта произвольного чтения.
Наконец, удаленное выполнение кода (RCE)
Как описано ранее, с помощью уязвимостей CVE-2020-9497 и CVE-2020-9498 нам удалось реализовать наши примитивы эксплойтов произвольного чтения и произвольной записи. Используя эти два мощных примитива, мы успешно реализовали эксплойт удаленного выполнения кода (RCE), в котором вредоносный корпоративный компьютер (наш RDP-сервер) может взять под контроль процесс guacd, когда удаленный пользователь запрашивает подключение к своему (зараженному) компьютеру.
Но путешествие здесь не заканчивается. Процесс guacd обрабатывает только одно соединение и работает с низкими привилегиями. Традиционно, на этом этапе нам нужна уязвимость повышения привилегий(PE), чтобы захватить весь шлюз. И действительно, во время скоординированного раскрытия с Apache один из вопросов, которые задавали сопровождающие, заключался в том, действительно ли этот сценарий атаки возможен. Можем ли мы каким-то образом принять все соединения в шлюзе только с одного процесса guacd?
Давайте разберемся.
Apache Guacamole – глубокое погружение
Если мы углубимся в архитектуру сети шлюза Guacamole, которую мы видели ранее, мы увидим следующее:
Для повышения привилегий мы фокусируемся на этих двух компонентах:
guacamole-client
Компонент guacamole-client отвечает за веб-сервер, который выполняет аутентификацию пользователя. Этот веб-сервер содержит конфигурации, необходимые для каждого сеанса пользователя, и хранит такую информацию, как:
После успешной аутентификации клиента, клиент guacamole инициирует сеанс протокола Guacamole с сервером Guacamole, чтобы создать соответствующий сеанс для клиента. Это делается путем подключения к серверу guacamole через TCP-порт 4822 (по умолчанию), который прослушивает процесс guacd.
После создания сеанса, клиент-guacamole передает информацию только между сервером guacamole и браузером клиента.
guacamole-server
Согласно документации Apache: "guacd - это сердце guacd". После запуска, guacd прослушивает TCP-порт 4822 и ожидает входящих инструкций от клиента guacamole. Важно отметить, что связь через этот порт не использует аутентификацию или шифрование (SSL может быть включен, но он не используется по умолчанию). По этой причине, мы добавили два брандмауэра на Рисунке 12, которые должны отвечать за ограничение доступа к этому TCP-порту, позволяя подключаться только guacamole-клиенту.
Когда соединение установлено, guacd создает новый поток и вызывает функцию, которая отвечает за запуск протокола Guacamole. На данный момент есть два варианта пользователя:
Дополнительное примечание: Мы используем термин соединение вместо сеанса, поскольку этот термин используется Guacamole для обозначения соединения с данным компьютером. Каждый компьютер имеет одно соединение, и несколько пользователей могут использовать одно и то же соединение. Не существует "пользовательского сеанса", поскольку весь проект основан на соединении Guacamole с данным компьютером, и пользователи просто присоединяются к соединениям.
Первый вариант, безусловно, наиболее широко используемый. В этом случае, для вновь созданного соединения генерируется случайный уникальный идентификатор (UUID), и для него создается процесс fork(). Отображение между UUID и новым процессом сохраняется в словаре в памяти, называемом proc-map, и UUID отправляется обратно клиенту guacamole. Важно отметить, что порожденный процесс немедленно отбрасывает свои разрешения, прежде чем он инициирует соединение с компьютером внутри сети.
Второй вариант довольно уникален и, вероятно, был реализован таким образом, чтобы несколько пользователей могли совместно использовать одно соединение и работать вместе. В этом случае, пользователь запрашивает присоединение к существующему соединению, предоставляя UUID соединения. Чтобы различать пользователей, пользователь, создавший соединение, является "владельцем", а другим пользователям для "владельца" установлено значение false. Эта опция также включает возможность подключения только для чтения для пользователей, которые не помечены как "владелец".
Для поддержки присоединения пользователей порожденный процесс для данного соединения наследует пару сокетов для связи с родительским процессом guacd.В то время как основной поток инициализирует требуемый клиент, например FreeRDP для соединения RDP, другой поток ожидает сообщений от родительского процесса, сигнализируя нашему процессу, что новый пользователь попросил присоединиться к соединению.
Процесс guacd действует как менеджер соединений, который порождает процессы для каждого соединения, и в то же время также реализует основную логику для этих порожденных процессов. По этой причине отныне мы будем называть родительский процесс guacd основным процессом.
Повышение привилегий - шаг за шагом
Шаг # 0 - Возьмите один процесс guacd
У нас уже есть рабочий эксплойт для этой части.
Шаг # 1 - Masquerade as the guacamole-client
Хотя процесс guacd, который мы контролируем, является только процессом с низкими привилегиями, который выполняется внутри шлюза, он все еще имеет несколько полезных привилегий. Для начала, запуск на шлюзе позволяет нам подключаться к основному процессу через TCP-порт 4822. Поскольку основной процесс не ожидает аутентификации через этот порт, ничто не мешает нам подключиться к нему и контролировать процесс точно так же, как это делает обычный guacamole-клиент.
Шаг # 2 - Собирайте секреты из нашей памяти
Это ключевой выбор дизайна для нас для эксплоита. Так как исполняемый файл guacd содержит логику как основного процесса, так и процессов для каждого соединения, при создании нового процесса соединения используется только fork(). Этот оператор повторяется: используется только fork() без execve ()!
Что это значит? Разветвленный процесс содержит весь снимок памяти своего родителя, и этот снимок заменяется новым образом при вызове execve(). Без этого важного вызова дочерний процесс наследует все адресное пространство памяти своего родителя. Это включает:
Это означает, что наш процесс имеет отображение proc-map, которое сопоставляет UUID каждого секретного соединения с соответствующим процессом. Нам нужно только найти эту структуру данных в нашей памяти, и у нас будут все текущие активные UUID.
Расположение самой proc-карты было чисто техническим. В нашем эксплойте, мы нашли его, прочитав файл макета памяти нашего proc из /proc/<pid>/maps. Структура данных настолько велика, что mmap() была выделена в автономное выделение памяти, и поэтому у нее есть собственная запись в файле.
Шаг # 3 - Присоединиться ко всем сессиям
Мы уже убедили основной процесс в том, что мы можем инициировать запросы по протоколу гуакамоле, и теперь мы даже знаем, какие запросы запрашивать. Наш следующий шаг - запросить присоединение к каждому из существующих соединений, указав их теперь известные UUID.
Удивительно, но атрибут сеанса "только для чтения" устанавливается клиентом guacamole. Это означает, что, хотя мы не являемся владельцами соединений, мы все равно можем отключить бит привилегии "только для чтения" для нашего присоединяющегося пользователя и получить полные разрешения для соединения. Кроме того, кроме сообщения журнала в основном процессе, как видно на Рисунке 14, нет никаких видимых признаков того, что другой пользователь только что присоединился к соединению.
Шаг # 4 - Повторение
Если вы уделяли пристальное внимание, вы, возможно, заметили недостаток в нашем плане атаки: наш процесс guacd имеет устаревшее изображение отображение proc-map. Любой сеанс, который начинается после того, как мы были порождены, будет обновляться только на proc-map и поэтому не будет доступен в нашем устаревшем образе памяти.
Этот недостаток имеет простое решение. Каждый выбранный интервал, скажем, 5 минут, мы можем отправлять первичному процессу команду на запуск нового RDP-соединения и подключение к нашей зараженной машине в сети. Таким образом, новый guacd порождается, и теперь содержит обновленную версию proc-map. Используя наш оригинальный эксплойт, мы также можем атаковать этот процесс и "обновить" нашу версию proc-map.
Вот полная цепочка эксплойтов, RCE + PE, в действии:
Хронология раскрытия
Заключение
Мы продемонстрировали новый взгляд на сценарий Reverse RDP Attack, который мы первоначально представили в начале 2019 года. Хотя пользователи обычно думают о клиенте RDP ... ну ... как о клиенте, сценарий Apache Guacamole учит нас иначе. В стандартном случае злоумышленник может использовать уязвимость в клиенте для получения контроля над одним корпоративным компьютером. Однако при развертывании в шлюзе такие уязвимости оказывают гораздо более серьезное влияние на организацию.
Хотя переход к удаленной работе из дома является необходимостью в эти трудные времена пандемии COVID-19, мы не можем пренебрегать последствиями таких удаленных подключений для безопасности. Используя Apache Guacamole в качестве примера, мы смогли успешно продемонстрировать, как скомпрометированный компьютер внутри организации можно использовать для управления шлюзом, который обрабатывает все удаленные сеансы в сети.
Получив контроль над шлюзом, злоумышленник может прослушивать все входящие сеансы, записывать все используемые учетные данные и даже запускать новые сеансы для управления остальными компьютерами в организации. Когда большая часть организации работает удаленно, эта точка опоры равносильна получению полного контроля над всей организационной сетью.
Мы настоятельно рекомендуем всем убедиться в том, что все серверы обновлены и что любая технология, используемая для работы на дому, полностью исправлена, чтобы блокировать такие попытки атаки. В нашем случае, в течение 24 часов с момента обнаружения уязвимостей и доказательства того, что они действительно могут быть использованы, мы внедрили исправление безопасности и стали первой производственной средой, защищенной от этой уязвимости безопасности, что обеспечило безопасное удаленное подключение наших сотрудников.
Источник: https://research.checkpoint.com/2020/apache-guacamole-rce/
Автор перевода: yashechka
Переведено специально для портала xss.pro (c)
Последнее редактирование модератором:
