Русский
Русский
English
Статистика
Реклама

Citrix

Разбираем уязвимость в Citrix ADС, позволяющую за минуту проникнуть во внутреннюю сеть компании

08.07.2020 18:05:40 | Автор: admin
В конце прошлого года эксперт Positive Technologies обнаружил уязвимость CVE-2019-19781 в ПО Citrix ADC, которая позволяет любому неавторизованному пользователю выполнять произвольные команды операционной системы.

Под угрозой оказались около 80 тысяч компаний по всему миру. Ситуация усугубляется тем, что продукт Citrix ADC устанавливается на границе между внешней и внутренней сетью организации. Таким образом, после эксплуатации уязвимости, злоумышленник получает доступ сразу во внутреннюю сеть компании и имеет возможность развивать атаки на приватный сегмент сети.

В сегодняшнем материале автор исследования подробнее разберет уязвимость, детали ее обнаружения и эксплуатации. Поехали!

Что такое Citrix ADC


Citrix ADC программно ориентированное решение для доставки приложений и балансировки нагрузки, специально разработанное, чтобы повысить скорость работы традиционных, облачных и веб-приложений, независимо от того, где они размещены. Наибольшее распространение такие контроллеры уже получили в IT- и телеком-отраслях. Согласно прогнозам, к 2023 году спрос на ADC вырастет у финансовых и страховых компаний.

Насколько все серьезно


В ходе мониторинга актуальных угроз (threat intelligence) было установлено, что потенциально уязвимы не менее 80 000 компаний из 158 стран. На момент обнаружения уязвимости, в ТОП-5 по количеству таких организаций входили Соединенные Штаты Америки (абсолютный лидер более 38% всех уязвимых организаций расположены на территории США), Германия, Великобритания, Нидерланды, Австралия.

Россия находилась на 26-м месте рейтинга по общему числу потенциально уязвимых компаний различных секторов бизнеса всего более 300 организаций. Казахстан и Беларусь занимали 44-е и 45-е места по числу уязвимых компаний соответственно.

По данным на февраль 2020 года, в топ стран по количеству потенциально уязвимых организаций входили Бразилия (43% от числа компаний, в которых уязвимость была выявлена изначально), Китай (39%), Россия (35%), Франция (34%), Италия (33%) и Испания (25%). Лучшую динамику устранения уязвимости демонстрировали США, Великобритания и Австралия: в этих странах зафиксировано по 21% компаний, которые продолжали использовать уязвимые устройства и не принимали никаких мер защиты.



Обнаружение и эксплуатация


В самом начале исследования я обнаружил, что, используя Path Traversal, у неавторизованного пользователя есть возможность обращаться к статическим файлам, которые недоступны без авторизации (/vpn/../vpns/style.css). Это было найдено в ходе Black Box анализа Citrix ADC.



Поведение, описанное выше, заинтересовало меня, поэтому я решил найти образ Citrix ADC, запустить локально (спасибо за помощь моему коллеге Юрию Алейнову) и продолжить исследование с полным доступом к исходному коду приложения.

Прежде всего был проанализирован конфиг веб-сервера Apache (/etc/httpd.conf), который отвечает за веб-интерфейс данного приложения. Как мы видим на картинке ниже, пути, попадающие под паттерн /vpns/portal/scripts/.*\.pl$ обрабатываются функцией ModPerl::Registry. Получается, что есть возможность исполнять perl-скрипты из папки /netscaler/portal/scripts/ без авторизации.



После этого я начал анализировать скрипты, которые мы можем вызвать, перейдя по адресу /vpn/../vpns/portal/scripts/[scriptName].pl.



Практически в каждом скрипте вызывается функция csd модуля NetScaler::Portal::UserPrefs (/netscaler/portal/modules/NetScaler/Portal/UserPrefs.pm). Функция работает с HTTP заголовками NSC_USER и NSC_NONCE. Со вторым заголовком никаких интересных действий не совершается, а вот значение заголовка NSC_USER используется в качестве имени файла. Если файла (имя которого было передано, как значение заголовка NSC_USER) не существует, то данный файл создается с определенной структурой, а если он уже есть, то парсится и на его основе заполняется переменная $doc.



Получается, что если использовать path traversal в имени файла, то мы сможем создавать файл с расширением .xml в любом каталоге файловой системы, где у нас есть права на запись. Чтобы проверить это, отправим строку ../../../../tmp/myTestFile в качестве значение заголовка NSC_USER и проверим наличие файла в каталоге /tmp/.



На данном этапе у нас есть возможность создавать файл с расширением .xml, но нет возможности контролировать содержимое файла.

Обратим внимание на скрипт newbm.pl, который также находится в директории, которая нам интересна. Этот скрипт принимает POST-параметры и записывает в файл (имя которого указано в заголовке NSC_USER) значения таких параметров, как url, title и desc.



Теперь есть возможность не только создавать xml-файлы в произвольных местах, но и частично контролировать их содержимое.

Чтобы продолжить путь к RCE, обратимся снова к конфигу веб-сервера и заметим, что еще один путь (/vpns/portal/) обрабатывается perl-функцией NetScaler::Portal::Handler (/netscaler/portal/modules/NetScaler/Portal/Handler.pm)



Функция handler получает часть пути после последнего символа / в качестве имени файла, ищет его в папке /netscaler/portal/templates/ и пытается отрендерить данный файл, используя библиотеку Template Toolkit.



Таким образом, если мы сможем загрузить свой файл в папку с темплейтами, то сможем вызвать и его рендер.

Дальнейшую эксплуатацию осложняет тот факт, что библиотека Template Toolkit работает в таком режиме, что нельзя исполнить perl-код штатными методами. Например, не может быть использована директива [% PERL %].



Исходя из данных ограничений, я решил поискать уязвимости в стандартных плагинах библиотеки. Рассмотрим такой плагин, как Datafile (/usr/local/lib/perl5/site_perl/5.14.2/mach/Template/Plugin/Datafile.pm). Файл довольно маленький, поэтому сразу обращаем внимание на вызов стандартной функции open с двумя аргументами. Такое использование небезопасно и может привести к RCE.



Пробуем проэксплуатировать уязвимость локально и в качестве проверки создаем файл testRCE в папке /tmp/.



На данный момент у нас есть возможность создавать файлы в произвольных местах на системе, частично контролировать их содержимое и уязвимость в библиотеке Template Toolkit. Используем всё это для того, чтобы получить выполнение произвольных команд от неавторизованного пользователя.

Создаем в папке с темплейтами файл, рендер которого приведет к исполнению кода и созданию веб-интерпретатора командной строки.



Затем рендерим данный файл.



Обращаемся к скрипту (веб-шеллу), который мы создали ранее и выполняем произвольную команду OS.



Как защититься


Компания Citrix выпустила рекомендации по устранению данной уязвимости. Кроме того, производитель рекомендует пользователям незамедлительно обновить всех уязвимых версий ПО до рекомендуемых.

Для блокировки возможной атаки компании могут использовать межсетевые экраны уровня приложения. Например, PT Application Firewall обнаруживает такую атаку из коробки: систему следует перевести в режим блокировки опасных запросов для защиты в реальном времени. С учетом общего срока существования выявленной уязвимости (она актуальна с момента выхода первой уязвимой версии ПО, то есть с 2014 года) актуальность приобретает и выявление возможных фактов эксплуатации данной уязвимости (и соответственно, компрометации инфраструктуры) в ретроспективе.

Пользователи PT Network Attack Discovery начиная с 18 декабря 2019 года могут воспользоваться специальными правилами, детектирующими попытки эксплуатации данной уязвимости в режиме онлайн.

Автор: Михаил Ключников (@__mn1__), Positive Technologies

Timeline


  • 5 December, 2019 Reported to Citrix
  • 19 December, 2019 Released mitigation steps from Citrix
Подробнее..

Подводные камни при переходе на VDI что тестировать заранее, чтобы не было мучительно больно

30.06.2020 10:05:46 | Автор: admin
image

Задумывались когда-нибудь, что делает сканер с VDI-станцией? Сначала всё выглядит хорошо: он пробрасывается как обычное USB-устройство и прозрачно виден с виртуальной машины. Дальше юзер даёт команду на сканирование, и всё к чертям падает. В лучшем случае драйвер сканера, похуже через пару минут софт сканера, потом может поаффектить и других пользователей кластера. Почему? Потому что, чтобы получить пятимегабайтную сжатую картинку, нужно отправить через USB 2.0 на два-три порядка больше данных. Пропускная способность шины 480 Мбит/с.

Так что тестировать надо три вещи: UX, периферию и безопасность обязательно. Есть разница, как тестировать. Можно установить агентов локально, на каждой виртуальной рабочей станции. Это относительно бюджетно, но не показывает нагрузку на канал и не совсем верно считает нагрузку на процессор. Второй вариант развернуться в другом месте нужным количеством роботов-эмуляторов и начать их коннектить к реальным рабочим местам как настоящих пользователей. Добавится нагрузка от протокола передачи видеопотока экрана (точнее, изменённых пикселей), разбор и отправка сетевых пакетов, будут понятны нагрузки на канал. Канал вообще очень редко проверяется.

UX это скорость выполнения разных действий конечным пользователем. Есть пакеты тестов, которые нагружают инсталляцию сотнями пользователей и делают типичные для них действия: запускают офисные пакеты, читают PDF, браузят, редко-редко смотрят порно в рабочее время и так далее.

Довольно хороший пример того, почему такие тесты важны заранее, был в последней инсталляции. Там тысяча пользователей переезжает в VDI, у них офис, браузер и SAP. ИТ-отдел в компании развитый, поэтому есть культура нагрузочного тестирования перед внедрениями. По моему опыту, обычно заказчика приходится уговаривать на такое, потому что затраты большие, а польза не всегда очевидна. Есть же расчёты, где можно ошибиться? На деле такие тесты вскрывают места, где думали, но проверить не могли.

Инсталляция


Шесть серверов, конфигурация вот:

image

К СХД заказчика у нас доступа не было, предоставлялась она уже в виде места как сервис, фактически. Но мы знаем, что там all-flash. Какая именно all-flash, не знаем, но разделы по 10 ТБ. VDI VMware по выбору заказчика, поскольку стек ИТ-команде уже знаком, и всё довольно органично дополняется до целостной инфраструктуры. VMware очень подсаживает на свою экосистему, но если бюджета в закупке хватает годами можно не знать проблем. Но это часто очень большое если. У нас хорошая скидка, и заказчик об этом знает.

Начинаем тесты, потому что ИТ-команда не пускает в прод почти ничего без тестов. VDI это не та вещь, которую можно запустить, а потом принять. Пользователи загружаются постепенно, и с проблемами вполне можно столкнуться через полгода. Чего, естественно, никому не хочется.

450 юзеров в тесте, нагрузку генерируем локально. Робоюзеры делают разные действия одновременно, мы измеряем время каждой операции в течение нескольких часов работы:

image

image

image

Смотрим, как будут вести себя сервера, СХД. Сможет ли VDI создать нужное количество виртуальных рабочих мест и так далее. Поскольку заказчик не пошёл по пути гиперконвергенции, а взял флешовую СХД, нужно было проверять правильность сайзинга тоже.

image

image

image

image

image

image

Собственно, если что-то где-то тормозит нужно менять настройки VDI-фермы, в частности, распределение ресурсов между пользователями разных категорий.

Периферия


С периферией обычно три ситуации:

  • Заказчик просто говорит, что ничего не подключаем (ну, кроме гарнитур, они обычно видны из коробки). Последние примерно лет пять я очень-очень редко вижу гарнитуры, которые не подцепились бы сами по себе, и которые не подхватила бы VMware.
  • Второй подход берём и в рамках проекта внедрения VDI меняем периферию: берём протестированное нами и заказчиком поддерживаемое. Случай по понятным причинам редкий.
  • Третий подход прокидываем имеющееся железо.

Про проблему со сканерами вы уже знаете: нужно ставить промежуточный софт на рабочую станцию (тонкий клиент), который получает поток USB, сжимает картинку и отправляет в VDI. В силу ряда особенностей, это не всегда возможно: если на Win-клиентах (домашних компьютерах и тонких клиентах) всё хорошо, то для *nix-сборок обычно вендором VDI поддерживается какой-то конкретный дистрибутив и начинаются танцы с бубном, как и на Mac-клиентах. На моей памяти мало кто подключал локальные принтеры с Linux-инсталляций так, чтобы они на этапе отладки работали без постоянных звонков в поддержку. Но это уже хорошо, некоторое время назад даже просто чтобы работали.

Видеоконференцсвязь все заказчики рано или поздно хотят, чтобы это работало и работало хорошо. Если правильно спроектировали ферму, то это работает хорошо, если неправильно получаем ситуацию, когда у нас во время аудиоконференции растёт нагрузка на канал, плюс дополнительно помимо этого возникает проблема того, что картинка отображается плохо (full HD нет, лицо из 916 пикселей). Возникает очень сильная дополнительная задержка, когда появляется петля между клиентом, рабочей станцией VDI, сервером ВКС, оттуда вторым VDI и вторым клиентом. Правильно соединять сразу с клиента на сервер ВКС, что требует установки ещё одного дополнительного компонента.

USB-ключи с ними вообще проблем нет, смарт-карты и подобное, всё работает из коробки. Сложности бывают со сканерами штрихкодов, принтерами этикеток, станками (да, было и такое), кассами. Но всё решается. С нюансами и не без сюрпризов, но в конечном счёте решается.

Когда пользователь смотрит Ютуб с VDI-станции это самая плохая ситуация и для нагрузки, и для канала. Большинство решений предлагает HTML5 видео редирекшн. Сжатый файл передают на клиента, там показывает. Или же клиенту передаётся ссылка для прямой связи браузера и видеохостинга (это реже).

Безопасность


Безопасность обычно искрит на месте стыков компонентов и на клиентских устройствах. На стыках в одной экосистеме на словах всё должно работать хорошо. На практике так бывает процентах в 90 % случаев, и что-то всё равно надо доделывать. В последние годы очень удобной оказалась ещё одна покупка Вмвары они взяли в экосистему MDM для управления устройствами внутри компании. У ВМов появились недавно интересные сетевые балансировщики (бывший Avi Networks), которые позволяют закрыть вопрос распределения потоков через год после сдачи VDI, например. Ещё одна чисто вмварная особенность хорошая оптимизация филиалов благодаря их свежему шопингу, когда они взяли компанию VeloCloud, которая делает SD-WAN для филиальных сетей.

С точки зрения конечного пользователя, архитектура и вендор почти незаметны. Глобально важно то, что есть клиент под любое устройство, с планшета, мака, вин-тонкого клиента можно подключиться. Были клиенты даже для телевизоров, но сейчас их уже, к счастью, нет.

Особенность VDI-инсталляций сейчас в том, что у конечного пользователя дома просто нет компьютера. Часто есть слабый андроид-планшет (иногда даже с мышью или клавиатурой), либо же может вообще повезти и получить компьютер на Win XP. Которая, как вы можете догадаться, некоторое время не обновлялась. И не обновится никогда уже. Либо очень слабые машины, где клиент не ставится, приложения не работают, пользователь не может работать. По счастью, даже очень слабые устройства подходят (не всегда комфортно, но подходят), и это считается большим плюсом VDI. Ну а относительно безопасности надо тестировать компрометацию клиентских систем. Это случается достаточно часто.

В свете рекомендаций Роспотребнадзора по организации работы предприятий в условиях риска COVID-19, подключение к своим рабочим местам в офисе очень актуально. Похоже, что эта история надолго, и да, если вы думали про VDI можно начинать тестировать. Пригодится. Рекомендации лежат вот здесь, разъяснения вот тут. Важно, что с помощью VDI также можно переоборудовать помещения для соблюдения требований. Регулятором вводятся определённые нормы дистанцирования. Например, в офисе площадью 50 кв. м не может находиться более пяти сотрудников.

Ну а если есть вопросы по VDI не для комментариев вот моя почта: SSkryl@croc.ru.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru