3 Атаки на TACACS+ от Cisco

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

    Что такое TACACS+


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

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

    image

    Удобно, централизовано. Можно настроить различные привилегии для различных пользователей на различных устройствах. Есть логирование доступа и действий на серверной стороне. Можно прикрутить поверх другую централизацию доступа, типа 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-соединений…

    image

    Интро для атак 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.

    image

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

    Атака №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 устройства для пользователя. А так как строку приветствия мы можем получить при подключении, то получается, что мы все значения знаем наверняка.

    image

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

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

    image

    Атака №3


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

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

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

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

    image

    Итого, нужно поменять всего один байт! В простейшем виде, мы должны выполнить следующее:
    • Получить 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). Но это уже другая задачка.
    Digital Security
    Безопасность как искусство

    Похожие публикации

    Комментарии 10

      –1
      эх, если б у radius-а был аккаунтинг…
        +4
        Э? А куда он делся?
          0
          я что-то пропустил и на радиусе можно теперь смотреть какие команды кто вводил?
            0
            Команды чего? Radius используют для аутентификации, авторизации и аккаунтинга всяких интернетов и VPN. Но, в принципе, никто вам не мешает PAM к нему прикрутить.
              0
              ну… в статье речь идет про AAA на устройствах cisco в связке с tacacs+. Accounting в этом контексте означает, что t+ сервер пишет в лог кто из пользователей логинился и что делал (конкретно в логе можно посмотреть кто и какие комнды выполнял в cli), что сильно помогает решать конфликтные ситуации и инциденты.
              насколько я знаю, реализация accouting у cisco использует только tac+, поэтому в случае с радиусом — аккаунтинг не получится.
              вот я и спрашиваю — что-то изменилось и цыски могут писать лог cli в radius?
        0
        Классические ошибки конструирования шифров… Отсутствие защиты от MitM — без комментариев. Ну и использовать в качестве псевдо случайного генератора MD5 — тоже заводно.
          +1
          Мне кажется данный протокол является хорошим примером для понимания некоторых типовых атак.
            0
            А sessionId на основании чего генерится? И какая у него размерность? Мне кажется, тут еще возможна атака Many Time pad.
              0
              Случайное значение (4 байта) посылаемое клиентом (и возвращаемое сервером) на каждую операцию (AAA)
                0
                Это означает, что если не очень долго сидеть и смотреть на траффик, можно получить пару сообщений заксоренных с одним и тем же pseudo_pad. SessionId начнет дублироваться через 2^16 пакетов.

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

        Самое читаемое