Мне хотелось бы поведать сегодня итоги своего небольшого исследования, связанного с протоколом TACACS+, причём именно с пентестерской точки зрения. Использовать протокол по прямому мне не приходилось, так что каких-то тонкостей могу не упомянуть.

Что такое TACACS+

Terminal Access Controller Access-Control System Plus (TACACS+) — специальный протокол от Cisco для AAA (authentication, authorization, and accounting). То есть это протокол для централизованного управления доступом – чаще всего доступом именно к Cisco, но можно прикрутить что-то еще.

Итак, обычно поднимается один-два сервера с TACACS+ сервисом на 49 порту протокола TCP, а на всех устройствах настраивают его использование. Таким образом, когда пользователь хочет аутентифицироваться на свитче, роутере или другом устройстве, устройство пересылает его аутентификационные данные на TACACS+ сервер, где их проверяют, и принимается решение о разрешении доступа, о чём и сообщается в ответных пакетах



Удобно, централизовано. Можно настроить различные привилегии для различных пользователей на различных устройствах. Есть логирование доступа и действий на серверной стороне. Можно прикрутить поверх другую централизацию доступа, типа AD или LDAP'а. Есть open source реализации сервера (Cisco когда-то официально выложила код).

Атака №1

Первая «атака» больше похожа на некий трюк, чем на полноценную атаку, но может быть полезна в определённых ситуациях.

Итак, представим себе, что в ходе пентеста мы получили конфиг от циски (например, стянув его с TFTP-сервера). Это, конечно, хорошо, но даже если мы успешно набрутим локальную учётку от устройства, то мы не сможем залогиниться, так как устройство будет проверять учётку на TACACS+-сервере.

Но здесь стоит вспомнить типичную конфигурацию при подключении к TACACS+.
Представим себе, что с сервером TACACS+ что-то произошло и он недоступен для Cisco устройства, но админу может быть надо залогиниться на устройство, а он не может этого сделать. Для таких целей Cisco устройства поддерживают различные «виды» аутентификации, которые администратор должен указать при настройке.

Так, классическая конфигурация аутентификации для Cisco c TACACS+ выглядит следующим образом:

aaa authentication login default group tacacs+ local

Здесь нам важны последние два слова, которые указывают на то, что сначала аутентификация будет проверена с помощью TACACS+, а после – путем поиска в локальной базе юзеров. Причём, если юзер не найден в TACACS+, то он не будет проверяться и локально.

Суть же первой атаки заключается в том, что мы, как атакующие, DoS-им сервер TACACS+, после чего подключаемся к желаемому Cisco устройству используя локальную учётку. Причём DoS имеется в виду в более широком смысле – можно специальный пакет послать (когда-то находили) и большим количеством TCP-соединений…

Интро для атак 2 и 3

Перед тем как перейти к атакам 2 и 3, необходимо узнать ещё кое-что о протоколе TACACS+. Данные в протоколе передаются либо плейн-текстом, либо можно включить шифрование. Организуется оно на основе PSK (Pre-Shared Key), т.е. администратор сам указывает один ключ на TACACS+-сервере и всех подключающихся к нему клиентов (девайсов). Причём шифруются только пользовательские данные, заголовки TACACS+ не шифруется. Само шифрование, насколько мне известно, происходит следующим образом:
Зашифрованные данные (enc_data) представляют собой результат операции XOR с данными (data) и специальной строкой – pseudo_pad.

data^pseudo_pad=enc_data

pseudo_pad является последовательностью MD5 хешей.

pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]}

MD5-хеши создаются на основе данных из заголовков TACACS+-пакетов, плюс общий ключ (PSK), плюс предыдущий хеш (для первого MD5 его, соответственно, нет). Т.е.:

MD5_1 = MD5{session_id, key, version, seq_no}
MD5_2 = MD5{session_id, key, version, seq_no, MD5_1}
....
MD5_n = MD5{session_id, key, version, seq_no, MD5_n-1}

Где session_id – случайный идентификатор сессии; version – версия протокола; seq_no – инкрементируемый номер пакета; key – PSK.



И вроде как данные зашифрованы…

Атака №2

Итак, давайте конкретизируем задачу и уточним ситуацию. У нас есть устройство Cisco и сервер TACACS+. И мы можем получить зашифрованный TACACS+ трафик между ними (с помощью Man-in-the-Middle, например). Цель же наша – получить PSK, и с помощью него расшифровать трафик и получить валидные учётки.

Теперь давайте посмотрим, что мы можем сделать. Для начала, как мы видим, значение MD5 создаётся от нескольких значений, но только одно них мы точно не знаем – общий ключ, тогда как все остальные можно получить из заголовков TACACS+-пакета. Таким образом, если упросить задачу, то всё сводиться к тому, чтобы перебором (без этого никуда :) подобрать ключ. При этом MD5 можно брутить в оффлайне очень быстро. Но для этого нам нужно получить значение MD5_1.

Далее, мы должны вспомнить, что XOR – это обратимая операция. Т.е. если у нас была операция «data^pseudo_pad=enc_data», то «pseudo_pad=data^enc_data». При этом XOR – это простейшая операция и изменение части строки не влечет изменений в другой части строки. Получаем MD5_1 – это начальная часть pseudo_pad. Если точнее, 128 бит или 16 байт. И, таким образом, чтобы получить MD5_1, нам нужно знать первые 16 байт зашифрованных данных и 16 байт изначальных данных. И если зашифрованные данные мы имеем в любом количестве из трафика, то как нам получить 16 байт изначальных данных?

Важно отметить: формат отличается для запросов и ответов, а также для различных их видов (надо вспомнить, что TACACS+ — это AAA — Authentication, Authorization, Accounting).

Но общая закономерность у них сохраняется — случайные или неизвестные нам значения в первых 16 байтах почти отсутствуют.

Не буду углубляться в подробности и приведу лишь самый удобный пример. Это первый ответ от TACACS+-сервера. Он содержит в себе несколько полей с однозначным значением и строку приветствия от Cisco устройства для пользователя. А так как строку приветствия мы можем получить при подключении, то получается, что мы все значения знаем наверняка.



Таким образом, мы почти точно знаем, какие не зашифрованные данные находятся в пакете, что даёт возможность нам получить MD5_1 и уже локально брутить его. В случае успеха, мы сможем полностью расшифровать трафик.

Для упрощения задачи по парсингу пакета и выделению MD5_1, я набросал тулзеньку: tac2cat.py (как часть проекта TacoTaco, см. далее)

Атака №3

Про эти две атаки я рассказывал на недавней встрече Defcon Russia на CC’2015. И в добрых традициях нашей группы, в ходе дискуссии мне дали пару дельных советов. Один из них от заключался в том, чтобы посмотреть в сторону возможности bit flipping'а

Итак, сценарий последней атаки. У нас есть устройство Cisco и сервер TACACS+. Мы можем проводим активную Man-in-the-Middle атаку (т.е. можем менять трафик). Цель – «поломать всё»

Присмотревшись ещё раз к протоколу, выявились ещё две важные особенности. Первая заключалась в том, что у протокола отсутствовала проверка целостности. Т.е. если мы меняли какое-то значение у зашифрованного трафика, то это влияло на расшифрованный трафик (XOR же) и сервер его «съедал», не замечая изменений.

Вторая особенность была в формате пакетов. И для пакетов аутентификации, и для авторизации, при запросе разрешения основной ответ передаётся в первом байте ответа. Например, 0x01 – аутентификация успешна, 0x02 – не успешна.



Итого, нужно поменять всего один байт! В простейшем виде, мы должны выполнить следующее:

• Получить pseudo_pad данного байта, XOR’нув зашифрованный байт и известное нам значение (если мы вводим некорректные данные при аутентификации, то мы знаем, что в аутентификации будет нам отказано – т.е. значение будет 0x02)
• Повторно XOR’нуть pseudo_pad данного байта с байтом успешной аутентификации (0x01)
• Поменять данный байт в зашифрованном трафике.

Таким образом, в MitM-атаке мы будем отдавать разрешения на любые некорректные данные на авторизацию или аутентификацию. Причём, таким же способом мы обходим и аутентификацию на повышение привилегий на Cisco устройстве (enable пароль).

В итоге для реализации этой атаки была написана тулза – tacflip.py (как часть проекта TacoTaco)

Проверена работа её (обход аутентификации и авторизации) с 7200-циской в GNS3 и open source реализацией TACACS+-сервера – tac_plus.
Кусок конфига по TACACS+ выглядит следующим образом.

aaa authentication login default group tacacs+ local
aaa authentication enable default group tacacs+
aaa authorization exec default group tacacs+ local
tacacs-server host 192.168.182.136
tacacs-server directed-request
tacacs-server key 12345

А вот и небольшое демо-видео входа на устройство, повышения привилегий и выполнения команды.

Ситуация…

В 2000 году Solar Designer сделал интересный ресёрч протокола goo.gl/E2IGnk. Например, было обнаружена возможность replay-атак, или раскрытия длины пароля пользователя (из-за отсутствия padding’а), и кое-что ещё (bit flipping). Но практической реализации их в паблике я не нашел…

Но мой «ресёрч» этого протокола является лишь перечнем случайных взаимодействий с протоколом в течение долгого времени, а не целенаправленным исследованием. Из-за чего я забыл про итоги Solar Designer'а и кое-что заново переоткрыл.

Возможно, главным итогом моих трудов являются рабочие тулзы (пока в стадии беты).
Знакомьтесь — проект TacoTaco github.com/GrrrDog/TacoTaco

Итого:

Можно, наверное, посчитать, что протокол TACACS+ с его реализацией не даёт необходимого уровня защиты от MitM атак.

С другой стороны, данные атаки несколько затруднены, так как часто TACACS+ серверы располагаются в VLAN'ах, доступных только для администраторов и сетевого оборудования (вроде как рекомендации от Сisco). Но это уже другая задачка.