Проверяем защищенность корпоративных VPN-соединений. Атаки на IPSec.
Social Engineering
При проведении пентеста, отделенной категорией в качестве объектов тестирования, стоят корпоративная сеть и как ее подчасть защищенные каналы связи. Даже не большие компании могут иметь какие-то удаленные точки, склады, микро филиалы, представительства или армию сотрудников вынужденных работать удаленно. И конечно же это не может пройти незамеченным мимо аудитора. И вот под прицел среди прочего попадают VPN-соединения.
Из самого названия вытекает, что эти конекты являются защищенными, что на первый взгляд вряд ли сулит какой-то профит. Но! Как из практики известно нет ничего абсолютно безопасного! И вот даже в "надежном" протоколе IPSec, служащим уже много лет основной для построения VPN, есть потенциальные бреши, которые можно использовать нам на руку. В сегодняшем выпуске мы как раз и поговорим о том, как можно будет тестануть IPSec на защищенность!
Скажу сразу, это не будет легко, и вариантов взлома по указанной методе с течением времени становится все меньше и меньше, но вдруг тебе улыбнется удача!
Почему именно IPSec?
У некоторых читателей может закрасться в уме два закономерных вопроса - первый, а почему мы рассматриваем именно атаки на IPSec? Ведь по мимо этого классического протокола есть еще и другие варианты реализации (L2TP, PPTP, DA) на базе которых можно построить VPN-туннель. А!? А все очень просто, к примеру некоторые реализации, как то PPTP признаются небезопасными и постепенно уходят в прошлое, а другие, как-то OpenVPN, таки наоборот, с каждым годом показывают рост. Но сколько бы времени не прошло, бессменным лидером и самой узнаваемой технологией для создания и поддержания защищенных частных каналов по-прежнему остается IPsec VPN.
И вопрос второй - IPSec уже изначально разрабатывался для обеспечения безопасного соединения и в виду этого "по умолчанию" является защищенным каналом связи! Так можно ли здесь что-то с ним сделать!? Ага.. Так иногда при пентесте корпоративной сети можно обнаружить серьезно защищенную сеть с торчащим в Интернет лишь 500-м UDP-портом. А все остальное может быть закрыто, пропатчено и надежно фильтроваться.
Абсолютная безопасность!? Но это не всегда так! И вот в сегодняшнем материале мы рассмотрим именно такую ситуацию! Но вначале, для того чтобы максимально эффективно атаковать IPsec, нам нужно разобраться, что он из себя представляет и как работает.
Ну, погнали!
Минимум начальных знаний об IPsec.
И так, Википедия говорит:
IPsec (сокращение от англ. IP Security) — набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP. Позволяет осуществлять подтверждение подлинности (аутентификацию), проверку целостности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в сети Интернет. В основном, применяется для организации VPN-соединений.
Используемые порты:
Protocol: UDP, port 500 (for IKE, to manage encryption keys)
Protocol: UDP, port 4500 (for IPSEC NAT-Traversal mode)
Protocol: ESP, value 50 (for IPSEC)
Protocol: AH, value 51 (for IPSEC)
Так же важно заметить, что IPsec является набором стандартов Интернета и своего рода «надстройкой» над IP-протоколом. И его ядро составляют три протокола:
- Authentication Header (АН) обеспечивает целостность передаваемых данных, аутентификацию источника информации и функцию по предотвращению повторной передачи пакетов
- Encapsulating Security Payload (ESP) обеспечивает конфиденциальность (шифрование) передаваемой информации, ограничение потока конфиденциального трафика.
- Internet Security Association and Key Management Protocol (ISAKMP) — протокол, используемый для первичной настройки соединения, взаимной аутентификации конечными узлами друг друга и обмена секретными ключами.
По мимо этого одним из ключевых понятий является Security Association (SA), то есть набором параметров, характеризующим устанавливаемое соединение. Например, это используемые алгоритм шифрования и хэш-функция, секретные ключи, номер пакета и тому подобное.
Сами VPN-подключения будем делить на два основных типа — site-to-site VPN (их еще можно назвать постоянные) и remote access VPN (RA, они же временные).
Первый тип служит для постоянной связи различных сетевых островков, например центрального офиса со множеством разбросанных филиалов. Ну а RA VPN представляет собой сценарий, когда клиент подключается на небольшой промежуток времени, получает доступ к определенным сетевым ресурсам и после завершения работы благополучно отключается.
Нас будет интересовать именно второй вариант, так как в случае успешной атаки удается сразу же получить доступ к внутренней сети предприятия, что для пентестера достаточно серьезное достижение. IPsec, в свою очередь, позволяет реализовывать как site-to-site, так и remote access VPN. Что же это за технология и из каких компонентов она состоит?
Две основные фазы IPsec.
Итак, мы выяснили, что вначале участникам нужно договориться, с помощью каких механизмов будет создано защищенное соединение, поэтому теперь в дело вступает протокол IKE. Так IKE (Internet Key Exchange) используется для формирования IPsec SA (Security Association, те самые политики безопасности), проще говоря — согласования работы участников защищенного соединения. Через этот протокол участники договариваются, какой алгоритм шифрования будет применен, по какому алгоритму будет производиться проверка целостности и как аутентифицировать друг друга.
Нужно заметить, что на сегодняшний день существует две версии протокола: IKEv1 и IKEv2. Нас будет интересовать только IKEv1: несмотря на то что IETF (The Internet Engineering Task Force) впервые представили его в 1998 году, он по-прежнему еще очень часто используется, особенно для RA VPN
Что касается IKEv2, первые его наброски были сделаны в 2005 году, полностью описан он был в RFC 5996 (2010 год), и лишь в конце прошлого года он был объявлен на роль стандарта Интернет (RFC 7296).
Разобравшись с IKE, возвращаемся к фазам IPsec. В процессе первой фазы участники аутентифицируют друг друга и договариваются о параметрах установки специального соединения, предназначенного только для обмена информацией о желаемых алгоритмах шифрования и прочих деталях будущего IPsec-туннеля. Параметры этого первого туннеля (который еще называется ISAKMP-туннель) определяются политикой ISAKMP. Первым делом согласуются хеши и алгоритмы шифрования, далее идет обмен ключами Диффи-Хеллмана (DH), и лишь затем происходит выяснение, кто есть кто. То есть в последнюю очередь идет процесс аутентификации, либо по PSK-, либо по RSA-ключу. И если стороны пришли к соглашению, то устанавливается ISAKMP-туннель, по которому уже проходит вторая фаза IKE.
На второй фазе уже доверяющие друг другу участники договариваются о том, как строить основной туннель для передачи непосредственно данных. Они предлагают друг другу варианты, указанные в параметре transform-set, и, если приходят к согласию, поднимают основной туннель. Важно подчеркнуть, что после его установления вспомогательный ISAKMP-туннель никуда не девается — он используется для периодического обновления SA основного туннеля. В итоге IPsec в некоем роде устанавливает не один, а целых два туннеля.
Уязвимость в режиме IKEv1.
Мы рассмотрели в первом приближении основную механику работы IPsec, но необходимо заострить внимание еще на нескольких вещах. Первая фаза, помимо всего прочего, может работать в двух режимах: main mode или aggressive mode.
Первый вариант (main mode) мы уже рассмотрели выше, но нас интересует как раз aggressive mode. В этом режиме используется три сообщения (вместо шести в main-режиме). При этом тот, кто инициирует соединение, отдает все свои данные разом — что он хочет и что умеет, а также свою часть обмена DH. Затем ответная сторона сразу завершает свою часть генерации DH. В итоге в этом режиме, по сути, всего два этапа. То есть первые два этапа из main mode (согласование хешей и обмен DH) как бы спрессовываются в один.
В результате этот режим значительно опаснее!!! по той причине, что в ответ приходит много технической информации в plaintext’е. И самое главное — VPN-шлюз может прислать хеш пароля, который используется для аутентификации на первой фазе (этот пароль еще часто называется pre-shared key или PSK).
Ну а все последующее шифрование происходит без изменений, как обычно. Почему же тогда этот режим по-прежнему используется? Дело в том, что он намного быстрее, примерно в два раза. Отдельный интерес для пентестера представляет тот факт, что aggressive-режим очень часто используется в RA IPsec VPN.
Еще одна небольшая особенность RA IPsec VPN при использовании агрессивного режима: когда клиент обращается к серверу, он шлет ему идентификатор (имя группы). Tunnel group name — это имя записи, которая содержит в себе набор политик для данного IPsec-подключения. Это уже одна из фич, специфичных оборудованию Cisco.
Сравнение режимов IKEv1 vs IKEv2.
Оба протокола работают по UDP-порту с номером 500, но между собой несовместимы, не допускается ситуация, чтобы на одном конце туннеля был IKEv1, а на другом — IKEv2. Вот основные отличия второй версии от первой:
В IKEv2 больше нет таких понятий, как aggressive- или main-режимы.
В IKEv2 термин первая фаза заменен на IKE_SA_INIT (обмен двумя сообщениями, обеспечивающий согласование протоколов шифрования/хеширования и генерацию ключей DH), а вторая фаза — на IKE_AUTH (тоже два сообщения, реализующие собственно аутентификацию).
Mode Config (то, что в IKEv1 называлось фаза 1.5) теперь описан прямо в спецификации протокола и является его неотъемлемой частью.
В IKEv2 добавился дополнительный механизм защиты от DoS-атак. Суть его в том, что прежде, чем отвечать на каждый запрос в установлении защищенного соединения (IKE_SA_INIT) IKEv2, VPN-шлюз шлет источнику такого запроса некий cookie и ждет ответа. Если источник ответил — все в порядке, можно начинать с ним генерацию DH. Если же источник не отвечает (в случае с DoS-атакой так и происходит, эта техника напоминает TCP SYN flood), то VPN-шлюз просто забывает о нем.
Практика.
Наконец-то разобравшись с особенностями работы IPsec и его компонентов, можно переходить к главному — к практическим атакам. Топология будет достаточно простой и в то же время приближенной к реальности.
Первым делом нужно определить наличие IPsec VPN шлюза. Сделать это можно, проведя сканирование портов, но здесь есть небольшая особенность. ISAKMP использует протокол UDP, порт 500, а между тем дефолтное сканирование с помощью Nmap затрагивает только TCP-порты. И в результате будет сообщение: "All 1000 scanned ports on 37.59.0.253 are filtered".
Создается впечатление, что все порты фильтруются и как бы открытых портов нет. Но выполнив команду
nmap -sU --top-ports=20 37.59.0.253 Starting Nmap 6.47 ( http://nmap.org ) at 2018-08-21 16:20 GMT Nmap scan report for 37.59.0.253 Host is up (0.066s latency). PORT STATE SERVICE 500/udp open isakmp
убеждаемся в том, что это не так и перед нами действительно VPN-устройство.
Атака на первую фазу
Теперь нас будет интересовать первая фаза, aggressive-режим и аутентификация с использованием pre-shared key (PSK). В этом сценарии, как мы помним, VPN-устройство или отвечающая сторона отправляет хешированный PSK инициатору. Одна из самых известных утилит для тестирования протокола IKE — это ike-scan (репозиторий, описание), она входит в состав дистрибутива Kali Linux.
Ike-scan позволяет отправлять IKE сообщения с различными параметрами и, соответственно, декодить и парсить ответные пакеты. Пробуем прощупать целевое устройство:
root@kali:~# ike-scan -M -A 37.59.0.253 0 returned handshake; 0 returned notify
Ключ `-A` указывает на то, что нужно использовать aggressive-режим, а `-M` говорит о том, что результаты следует выводить построчно (multiline), для более удобного чтения. Видно, что никакого результата не было получено. Причина состоит в том, что необходимо указать тот самый идентификатор, имя VPN-группы. Разумеется, утилита ike-scan позволяет задавать этот идентификатор в качестве одного из своих параметров. Но так как пока он нам неизвестен, возьмем произвольное значение, например 0000.
root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 37.59.0.253 Aggressive Mode Handshake returned
В этот раз видим, что ответ был получен и нам было предоставлено довольно много полезной информации. Достаточно важная часть полученной информации — это transform-set. В нашем случае там указано, что «Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK».
Все эти параметры можно указывать и для утилиты ike-scan с помощью ключа `--trans`. Например `--trans=5,2,1,2` будет говорить о том, что алгоритм шифрования 3DES, хеширование HMAC-SHA, метод аутентификации PSK и второй тип группы DH (1024-bit MODP). Посмотреть таблицы соответствия значений можно по этому адресу. Добавим еще один ключ (`-P`), для того чтобы вывести непосредственно пейлоад пакета, а точнее хеш PSK.
root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 -P
Казалось бы, хеш получен и можно пробовать его брутить, но все не так просто. Когда-то очень давно, в 2005 году, на некоторых железках Сisco была уязвимость: эти устройства отдавали хеш, только если атакующий передавал корректное значение ID. Сейчас, естественно, встретить такое оборудование практически невозможно и хешированное значение присылается всегда, независимо от того, правильное значение ID отправил атакующий или нет. Очевидно, что брутить неправильный хеш бессмысленно. Поэтому первая задача — это определить корректное значение ID, чтобы получить правильный хеш. И в этом нам поможет недавно обнаруженная уязвимость.
Дело в том, что существует небольшая разница между ответами во время начального обмена сообщениями. Если кратко, то при использовании правильного имени группы происходит четыре попытки продолжить установление VPN-соединения плюс два зашифрованных пакета второй фазы. В то время как в случае неправильного ID в ответ прилетает всего лишь два пакета. Как видим, разница достаточно существенная, поэтому компания SpiderLabs разработала сначала PoC, а затем и утилиту IKEForce (репозиторий, описание) для эксплуатации этой уязвимости.
Ломаем IKE.
Установить IKEForce в произвольный каталог можно, выполнив команду
git clone https://github.com/SpiderLabs/ikeforce
Работает она в двух основных режимах — режиме вычисления `-e` (enumeration) и режиме брутфорса `-b` (bruteforce). До второго мы еще дойдем, когда будем смотреть атаки на второй фактор, а вот первым сейчас и займемся. Перед тем как начать непосредственно процесс определения ID, необходимо установить точное значение transform-set. Мы его уже определили ранее, поэтому будем указывать опцией `-t 5 2 1 2`. В итоге выглядеть процесс нахождения ID будет следующим образом:
python ikeforce.py 37.59.0.253 -e -w wordlists/group.txt -t 5 2 1 2
В результате достаточно быстро удалось получить корректное значение ID. Первый шаг пройден, можно двигаться дальше.
Получаем PSK.
Теперь необходимо, используя правильное имя группы, сохранить PSK-хеш в файл, сделать это можно с помощью ike-scan:
ike-scan -M -A --id=vpn 37.59.0.253 -Pkey.psk
И теперь, когда правильное значение ID было подобрано и удалось получить корректный хеш PSK, мы можем наконец-то начать офлайн-брутфорс. Вариантов такого брутфорса достаточно много — это и классическая утилита psk-crack, и John the Ripper, и даже oclHashcat, который, как известно, позволяет задействовать мощь GPU. Для простоты будем использовать psk-crack, который поддерживает как прямой брутфорс, так и атаку по словарю:
psk-crack -d /usr/share/ike-scan/psk-crack-dictionary key.psk
Но даже успешно восстановить PSK — это только половина дела. На этом этапе нужно вспомнить про то, что дальше нас ждет XAUTH и второй фактор IPsec VPN.
Удар по XAUTH.
Итак, напомню, что XAUTH — это дополнительная защита, второй фактор аутентификации, и находится он на фазе 1.5. Вариантов XAUTH может быть несколько — это и проверка по протоколу RADIUS, и одноразовые пароли (OTP), и обычная локальная база пользователей. Мы остановимся на стандартной ситуации, когда для проверки второго фактора используется локальная база пользователей. До недавнего времени не существовало инструмента в публичном доступе для брутфорса XAUTH. Но с появлением IKEForce эта задача получила достойное решение. Запускается брутфорс XAUTH достаточно просто:
python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2 [+]Program started in XAUTH Brute Force Mode [+]Single user provided - brute forcing passwords for user: admin [*]XAUTH Authentication Successful! Username: admin Password: cisco
При этом указываются все найденные ранее значения: ID (ключ `-i`), восстановленный PSK (ключ `-k`) и предполагаемый логин (ключ `-u`). IKEForce поддерживает как грубый перебор логина, так и перебор по списку логинов, который может быть задан параметром `-U`. На случай возможных блокировок подбора есть опция `-s`, позволяющая снизить скорость брутфорса. К слову, в комплекте с утилитой идут несколько неплохих словарей, особенно полезных для установления значения параметра ID.
Ломимся во внутреннюю сеть.
Теперь, когда у нас есть все данные, остается последний шаг — собственно проникновение в локальную сеть. Для этого нам понадобится какой-нибудь VPN-клиент, которых великое множество. Но в случае Kali можно без проблем воспользоваться уже предустановленным — VPNC. Для того чтобы он заработал, нужно подкорректировать один конфигурационный файл — `/etc/vpnc/vpn.conf`. Если его нет, то нужно создать и заполнить ряд очевидных параметров:
IPSec gateway 37.59.0.253
IPSec ID vpn
IPSec secret cisco123
IKE Authmode psk
Xauth Username admin
Xauth password cisco
Здесь мы видим, что были использованы абсолютно все найденные на предыдущих шагах данные — значение ID, PSK, логин и пароль второго фактора. После чего само подключение происходит одной
root@kali:~# vpnc vpn
Отключение тоже достаточно простое:
root@kali:~# vpnc-disconnect
Проверить работоспособность подключения можно, используя команду `ifconfig tun0`.
Вот и все! Мы обманули эту защиту! Достойная награда за тяжкие усилия.
Какие есть еще потенциальные уязвимости?
Мы знаем, что в основе криптографического алгоритма в IPSec может быть выбран 3DES. И вот, сенсационная новость, есть пруф-концепты атаки на 3DES, а значит под угрозой может оказаться и IPSec!
Исследователи информационной безопасности Картикеян Баргаван (Karthikeyan Bhargavan) и Гаетан Лоран (Gaëtan Leuren) разработали атаку на шифры 3DES и Blowfish. Например, с ее помощью можно получить использующиеся для аутентификации cookie из зашифрованного 3DES HTTPS-трафика, а также восстанавливать имена пользователей и пароли из зашифрованного с помощью Blowfish трафика, передаваемого через VPN.
Атака, которая получила название SWEET32, посвящен отдельный сайт, ее подробности и демо-видео исследователи планируют представить на конференции ACM Conference on Computer and Communications Security.
В чем проблема?
Криптографические протоколы вроде TLS, SSH, IPsec и OpenVPN используют алгоритмы блочного шифрования (AES, Triple-DES, Blowfish). Таким образом обеспечивается шифрование передаваемых между клиентом и сервером данных. Данные при этом разбиваются на блоки фиксированной длины, каждый из которых шифруется отдельно. Более старые шифры вроде Triple-DES и Blowfish используют размер блока равный 64 битам, а AES использует размер блока 128 бит.
Короткая длина блока делает шифр уязвимым к «атакам дня рождения». Исследователи заявляют о том, что подобные атаки встречаются для 64-битных шифров протоколов TLS и OpenVPN. Подобные алгоритмы шифрования используются огромным количеством ресурсов в интернете.
Как защититься?
Защита от рассмотренных в сегодняшнем материале атак должна быть комплексной. Так нужно вовремя устанавливать патчи к IOS, и вообще по возможности ставить новое сетевое оборудование, использовать стойкие pre-shared ключи, а что лучше вместо них так это цифровые сертификаты. Ну и конечно же юзать только IKEv2.
Вот общий чек-лист:
Не используйте Agressive Mode!
Если нет необходимости, не используйте road-warrior mode.
В механизме аутентификации (Auth algorithm) ни в коем случае не используйте MD5 хеши, малая криптостойкость этого алгоритма давно доказана.
Используйте выделенные каналы, выданные вашим провайдером, только для вашей сети.
По умолчанию, ID хостов являются их внешние адреса, меняйте умолчания на FQDN или e-mail.
По возможности не используйте Xauth.
Используйте Racoon2, использующий IKEv2 (поддерживает и первую версию)
Ну а для тех, кто проводит пентесты, обнаруженный пятисотый порт UDP — это повод провести глубокий анализ защищенности IPsec VPN и, возможно, получить неплохие результаты.
Дополнительные материалы
IPSec — протокол защиты сетевого трафика на IP-уровне
Немного о VPN_ протоколы для удаленного доступа
Атака SLOTH, затрагивающая протоколы TLS 1.2, SSH и IKE/IPsec с MD5 и SHA-1.
Секретные доклады АНБ указывают на небезопасность SSH, PPTP, IPSec и TLS
Атака SWEET32: Исследователи обнаружили новый способ взлома шифров 3DES и Blowfish
Новый тип атаки против шифров 3DES и Blowfish
Social Engineering - Канал посвященный психологии, социальной инженерии, профайлингу, НЛП, Хакингу, Анонимности и безопасности в сети интернет, Даркнету и все что с ним связано. Добро пожаловать ;-)
S.E.Book - Литература социального инженера.
@Social_Engineering_bot - Бот обратной связи.
