какие компоненты входят в ipsec framework
Загадочный IPsec
IPsec — сложный стек протоколов. На клиентской стороне он обычно автоматизирован, что в сочетании с его названием легко может вызвать у пользователя ощущение полной безопасности. Однако не всегда оправданное. Только IPsec из протоколов, пригодных для организации VPN, поддерживают все сетевые ОС, поэтому у тебя есть неплохой шанс с ним столкнуться. И чтобы быстро настраивать соединения и правильно оценивать их безопасность, нужно понимать, как работает протокол.
Из чего состоит IPsec?
IPsec — это не один протокол, а три или четыре, смотря как считать. В OpenVPN и других решениях на основе TLS все просто: устанавливается соединение по TCP или UDP, согласовываются параметры, а затем передаются данные.
В IPsec за согласование параметров и собственно передачу данных отве‐ чают разные протоколы. В Linux, BSD и многих специализированных ОС маршрутизаторов туннель можно настроить вручную, без помощи управляющего протокола.
AH и ESP
Три основных компонента безопасности — доступность, аутентичность и конфиденциальность. IPsec может обеспечивать аутентичность, при этом ничего не делая для конфиденциальности.
Протокол AH (Authentication Header) добавляет в пакет специальный заголовок с контрольной суммой. На практике он используется редко, поскольку никак не способствует конфиденциальности.
Тем не менее его можно встретить в приложениях, где важна только аутентичность. К примеру, протокол маршрутизации OSPFv2 использовал пароли и суммы MD5 для защиты от поддельных анонсов, а его наследник OSPFv3 не включает никакой функциональности для защиты — вместо этого предлагается использовать IPsec в транспортном (прозрачном) режиме и с одной подписью AH без шифрования.
ESP (Encapsulated Security Payload) шифрует содержимое пакета и добавляет хеши. Его можно использовать в двух режимах — транспортном и туннельном. Это сейчас в сетях IPv4 любой VPN немыслим без маршрутизации частных (серых) адресов через туннель, поскольку со внешним миром хосты общаются через NAT. Но IPsec старше NAT и изначально шифровал только полезную нагрузку пакетов, не трогая заголовки, — это и есть транспортный режим.
В туннельном режиме ESP шифрует весь пакет и передает его как полезную нагрузку, на другой стороне он извлекается, расшифровывается и маршрутизируется дальше.
Что интересно, оба они не работают поверх TCP или UDP, а используют отдельные номера протоколов IP. Во всяком случае, по умолчанию — ESP может быть инкапсулирован в UDP для работы через NAT, но об этом позже.
Фреймворк для управляющих протоколов — ISAKMP
Общие принципы согласования настроек безопасности описывает ISAKMP (Internet Security Association and Key Management Protocol). Он описан в RFC 2408.
ISAKMP не является законченным сетевым протоколом. Это фреймворк, который описывает требования к безопасной работе протоколов обмена настройками безопасных соединений, терминологию и общий формат пакетов, но ничего не говорит о конкретных протоколах обмена ключами, шифрования и прочего — это остается на совести реализаций.
Именно из ISAKMP происходят термины Phase 1 и Phase 2, которые часто можно встретить в интерфейсе настройки маршрутизаторов и в описаниях настроек для подключения. Phase 1 — согласование параметров безопасного обмена данными о настройках. Phase 2 — согласование параметров собственно защиты передаваемого трафика хостов или приложений.
Самая популярная и практически единственная реализация ISAKMP — IKE.
Управляющий протокол — IKE
IKE (Internet Key Exchange) — реальный управляющий протокол IPsec на основе ISAKMP. На практике можно сказать, что Phase 1 — согласование настроек IKE, а Phase 2 — согласование настроек ESP.
В UNIX‐подобных системах IKE — это единственная часть стека IPsec, которая работает в виде обычного процесса. Само шифрование реализовано в ядре, и демон IKE передает ему параметры после согласования со второй стороной. В Linux это происходит через netlink или команды ip xfrm.
Подсистема XFRM в Linux обычно ассоциируется с IPsec, но может выполнять и другие преобразования, например сжатие полезной нагрузки.
Популярные пакеты «для IPsec» вроде StrongSWAN и LibreSWAN реализуют именно IKE.
Согласование настроек шифрования
В IKE есть возможность предложить второй стороне несколько вариантов на выбор, и соединение будет установлено, если у обеих сторон найдется хотя бы один совпадающий вариант. Это общий принцип работы протоколов обмена ключами, TLS работает так же, но в TLS периодически удаляют поддержку устаревших алгоритмов. В IKE безопасность выбора алгоритмов остается на совести пользователя. Заведомо уязвимые DES и MD5 из протокола официально не исключены и до сих пор поддерживаются многими реализациями.
С каждым туннелем ассоциировано одно или несколько «предложений» (proposals). Предложения обрабатываются до первого совпадения. Отсюда следствие: вполне возможна ситуация, когда зловредный (или безответственно настроенный) сервер предложит клиенту устаревшие алгоритмы, а неаккуратно настроенный клиент согласится. У некоторых клиентов вообще может не быть возможности выбрать алгоритмы вручную, а особо ленивые админы любят делать для всех клиентов один большой proposal со всеми мыслимыми алгоритмами. Сортировать алгоритмы по надежности стандарт не обязывает, и стороны вполне могут договориться на шифр полувековой давности.
Более того, официально поддерживается null cipher — опция не шифровать трафик вообще.
Чтобы убедиться в безопасности настроек, в идеале нужно немного понимать принципы криптографии и следить за новостями. Тем не менее можно привести ряд рецептов.
В IKE вполне можно использовать разные наборы алгоритмов для Phase 1 и Phase 2. Смысла в этом немного, но возможность имеется.
Diffie-Hellman и PFS
Параметр PFS ранее я оставил без внимания, так как эта штука была мне не совсем понятна, когда рассказывал про объединение сетей с помощью L2TP/IPsec на Mikrotik и Keenetic Ultra II. Восполним недостающие знания.
PFS (Perfect Forward Secrecy) — рекомендуемая опция, которую многие оставляют выключенной, а зря, особенно если используется pre‐shared key.
В этом режиме из ключей обеих сторон генерируется периодически обновляемый сессионный ключ и согласуется с помощью алгоритма Диффи-Хеллмана (DH). В предельно упрощенной формулировке он основан на том, что возвести число в степень просто, а вычислить логарифм гораздо сложнее. При использовании PFS, если кто‐то получит доступ к общему ключу, он не сможет расшифровать им перехваченный трафик, в этом и суть forward secrecy. Подобранный ключ от одной сессии также не поможет рас‐ шифровать последующие, при условии, что числа достаточно большие, именно поэтому DH1024 и DH1536 стали небезопасны — современное железо уже достаточно быстрое для их взлома.
Параметр Phase2 lifetime (ESP lifetime) указывает, как часто должен меняться ключ. Время жизни ключа — чисто локальный параметр, который не согласуется через IKE и может оказаться разным на разных сторонах. Если твои туннели IPsec сначала передают трафик, а потом вдруг перестают работать, проверь, совпадает ли время жизни ключа на обеих сторонах.
Security Associations (SA)
В отличие от OpenVPN или wireguard, IPsec сам по себе не создает никаких виртуальных интерфейсов. Во времена его зарождения у каждого хоста в интернете был публичный адрес и никакой потребности в виртуальных сетях с отдельной адресацией просто не было. Виртуальными интерфейсами занимаются отдельные протоколы, например L2TP или GRE, а IPsec только шифрует их трафик. Многие платформы поддерживают VTI — ассоциированный с соединением IPsec виртуальный интерфейс, но на деле это всего лишь автоматизированная настройка IPIP поверх IPsec.
Вместо туннелей IPsec оперирует еще более абстрактными сущностями — security associations. Они не являются сетевыми соединениями, это просто наборы параметров, которые указывают, какой трафик и как шифровать. К примеру, «трафик из 192.168.1.0/24 в 10.1.0.0/24 зашифровать AES‐128 и добавить сумму SHA1».
Security associations существуют на обеих сторонах независимо и не могут оборваться сами по себе, в отличие от сетевых соединений. Если ты видишь на своей стороне живую SA, это еще не значит, что трафик нормально пойдет на вторую сторону туннеля. Не забывай проверять, что все на самом деле работает. Чтобы вторая сторона могла узнать, что у тебя происходит, нужно настроить dead peer detection (для IKEv1) или использовать IKEv2, где есть liveness check.
В случае с dead peer detection не забывай проверять, что параметры на обеих сторонах совпадают, иначе можно надолго остаться с туннелем, который только выглядит как живой.
NAT TRAVERSAL
IPsec появился до NAT и в своем чистом виде работать за NAT не может. Эту возможность к нему прикрутили позже. Сам ESP — отдельный протокол IP с номером 50. Для работы за NAT его инкапсулируют в UDP. В этом случае IKE и инкапсулированный ESP используют один порт — UDP/4500.
Изначально от NAT страдали пользователи клиентских соединений вроде L2TP и IPsec. Популярность облачных платформ, где вместо присвоения хостам публичных адресов эти адреса раздают через 1:1, NAT сделала эту проблему актуальной и для соединений между маршрутизаторами.
При этом может возникнуть неожиданная проблема: если на другой стороне туннель настроен на фиксированный адрес, даже если NAT traversal поддерживается, соединение не заработает.
Дело в том, что в пакетах IKE присутствует идентификатор хоста. По умолчанию большинство реализаций используют в качестве идентификатора адрес интерфейса, с которого отправляются пакеты, и в случае с NAT он перестает совпадать с адресом источника, когда пакеты доходят до второй стороны.
Решение простое: никто не обязывает использовать идентификатор по умолчанию. В него можно прописать вообще любую строку, иногда даже необходимо, к примеру если у второй стороны нет фиксированного адреса или используется x.509.
Например, в StrongSWAN:
IKEv1 vs IKEv2
У IKE есть две версии — IKEv1 и IKEv2. IKEv2 получила сколько‐нибудь широкое распространение только в последние несколько лет, и то не везде, но у нее есть ряд ощутимых преимуществ.
В IKEv1 на каждую пару локальных и удаленных адресов нужна была отдельная SA. К примеру, если хостам 192.168.1.1 и 192.168.1.2 нужен доступ через туннель к 10.1.0.1 и 10.1.0.2, демон IKE создаст четыре отдельные SA. IKEv2 в этом смысле более гибкая.
В IKEv2 также окончательно удален aggressive mode, в котором параметры Phase 1 и Phase 2 передавались одновременно. Значительная часть реализаций, впрочем, давно перестала его поддерживать и в IKEv1 из‐за очевидных проблем с безопасностью такого подхода.
Если обе стороны поддерживают IKEv2, лучше использовать именно ее. Если интересно почитать стандарт, она описана в RFC 5996.
Заключение
Надеюсь, если IPsec был для тебя загадочным, теперь принципы его работы стали понятнее. Не забывай, что безопасность параметров шифрования на твоей совести и что не все конфликты настроек обнаружатся автоматически.
Если тебе будет интересно, в следующий раз я напишу о типичных ошибках в настройке и способах определить, что пошло не так, даже если конфиг второй стороны недоступен, а админы некомпетентны.
/ статья из журнала ХАКЕР (06) 2019 /
Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.
Анатомия IPsec. Проверяем на прочность легендарный протокол
В современном мире различные VPN-технологии используются повсеместно. Некоторые (например, PPTP) со временем признаются небезопасными и постепенно отмирают, другие (OpenVPN), наоборот, с каждым годом наращивают обороты. Но бессменным лидером и самой узнаваемой технологией для создания и поддержания защищенных частных каналов по-прежнему остается IPsec VPN. Иногда при пентесте можно обнаружить серьезно защищенную сеть с торчащим наружу лишь пятисотым UDP-портом. Все остальное может быть закрыто, пропатчено и надежно фильтроваться.
В такой ситуации может возникнуть мысль, что здесь и делать-то особо нечего. Но это не всегда так. Кроме того, широко распространена мысль, что IPsec даже в дефолтных конфигурациях неприступен и обеспечивает должный уровень безопасности. Именно такую ситуацию сегодня и посмотрим на деле. Но вначале, для того чтобы максимально эффективно бороться c IPsec, нужно разобраться, что он собой представляет и как работает. Этим и займемся!
IPsec изнутри
Перед тем как переходить непосредственно к самому IPsec, неплохо бы вспомнить, какие вообще бывают типы VPN. Классификаций VPN великое множество, но мы не будем глубоко погружаться в сетевые технологии и возьмем самую простую. Поэтому будем делить VPN на два основных типа — site-to-site VPN-подключения (их еще можно назвать постоянные) и remote access VPN (RA, они же временные).
Первый тип служит для постоянной связи различных сетевых островков, например центрального офиса со множеством разбросанных филиалов. Ну а RA VPN представляет собой сценарий, когда клиент подключается на небольшой промежуток времени, получает доступ к определенным сетевым ресурсам и после завершения работы благополучно отключается.
Нас будет интересовать именно второй вариант, так как в случае успешной атаки удается сразу же получить доступ к внутренней сети предприятия, что для пентестера достаточно серьезное достижение. IPsec, в свою очередь, позволяет реализовывать как site-to-site, так и remote access VPN. Что же это за технология и из каких компонентов она состоит?
Стоит отметить, что IPsec — это не один, а целый набор различных протоколов, которые обеспечивают прозрачную и безопасную защиту данных. Специфика IPsec состоит в том, что он реализуется на сетевом уровне, дополняя его таким образом, чтобы для последующих уровней все происходило незаметно. Основная сложность состоит в том, что в процессе установления соединения двум участникам защищенного канала необходимо согласовать довольно большое количество различных параметров. А именно — они должны аутентифицировать друг друга, сгенерировать и обменяться ключами (причем через недоверенную среду), а также договориться, с помощью каких протоколов шифровать данные.
Именно по этой причине IPsec и состоит из стека протоколов, обязанность которых лежит в том, чтобы обеспечить установление защищенного соединения, его работу и управление им. Весь процесс установления соединения включает две фазы: первая фаза применяется для того, чтобы обеспечить безопасный обмен ISAKMP-сообщений уже во второй фазе. ISAKMP (Internet Security Association and Key Management Protocol) — это протокол, который служит для согласования и обновления политик безопасности (SA) между участниками VPN-соединения. В этих политиках как раз и указано, с помощью какого протокола шифровать (AES или 3DES) и с помощью чего аутентифицировать (SHA или MD5).
Две основные фазы IPsec
Итак, мы выяснили, что вначале участникам нужно договориться, с помощью каких механизмов будет создано защищенное соединение, поэтому теперь в дело вступает протокол IKE. IKE (Internet Key Exchange) используется для формирования IPsec SA (Security Association, те самые политики безопасности), проще говоря — согласования работы участников защищенного соединения. Через этот протокол участники договариваются, какой алгоритм шифрования будет применен, по какому алгоритму будет производиться проверка целостности и как аутентифицировать друг друга. Нужно заметить, что на сегодняшний день существует две версии протокола: IKEv1 и IKEv2. Нас будет интересовать только IKEv1: несмотря на то что IETF (The Internet Engineering Task Force) впервые представили его в 1998 году, он по-прежнему еще очень часто используется, особенно для RA VPN (см. рис. 1).
Рис. 1. Cisco ASDM VPN Wizard
Что касается IKEv2, первые его наброски были сделаны в 2005 году, полностью описан он был в RFC 5996 (2010 год), и лишь в конце прошлого года он был объявлен на роль стандарта Интернет (RFC 7296). Более подробно про различия между IKEv1 и IKEv2 можно прочитать во врезке. Разобравшись с IKE, возвращаемся к фазам IPsec. В процессе первой фазы участники аутентифицируют друг друга и договариваются о параметрах установки специального соединения, предназначенного только для обмена информацией о желаемых алгоритмах шифрования и прочих деталях будущего IPsec-туннеля. Параметры этого первого туннеля (который еще называется ISAKMP-туннель) определяются политикой ISAKMP. Первым делом согласуются хеши и алгоритмы шифрования, далее идет обмен ключами Диффи-Хеллмана (DH), и лишь затем происходит выяснение, кто есть кто. То есть в последнюю очередь идет процесс аутентификации, либо по PSK-, либо по RSA-ключу. И если стороны пришли к соглашению, то устанавливается ISAKMP-туннель, по которому уже проходит вторая фаза IKE.
На второй фазе уже доверяющие друг другу участники договариваются о том, как строить основной туннель для передачи непосредственно данных. Они предлагают друг другу варианты, указанные в параметре transform-set, и, если приходят к согласию, поднимают основной туннель. Важно подчеркнуть, что после его установления вспомогательный ISAKMP-туннель никуда не девается — он используется для периодического обновления SA основного туннеля. В итоге IPsec в некоем роде устанавливает не один, а целых два туннеля.
Как обрабатывать данные
Теперь пару слов про transform-set. Нужно ведь как-то шифровать данные, идущие через туннель. Поэтому в типовой конфигурации transform-set представляет собой набор параметров, в которых явно указано, как нужно обрабатывать пакет. Соответственно, существует два варианта такой обработки данных — это протоколы ESP и AH. ESP (Encapsulating Security Payload) занимается непосредственно шифрованием данных, а также может обеспечивать проверку целостности данных. AH (Authentication Header), в свою очередь, отвечает лишь за аутентификацию источника и проверку целостности данных.
Например, команда `crypto ipsec transform-set SET10 esp-aes` укажет роутеру, что transform-set с именем `SET10` должен работать только по протоколу ESP и c шифрованием по алгоритму AES. Забегая вперед, скажу, что здесь и далее мы будем использовать в качестве цели маршрутизаторы и файрволы компании Cisco. Собственно с ESP все более-менее понятно, его дело — шифровать и этим обеспечивать конфиденциальность, но зачем тогда нужен AH? AH обеспечивает аутентификацию данных, то есть подтверждает, что эти данные пришли именно от того, с кем мы установили связь, и не были изменены по дороге. Он обеспечивает то, что еще иногда называется anti-replay защитой. В современных сетях AH практически не используется, везде можно встретить только ESP.
Параметры (они же SA), выбираемые для шифрования информации в IPsec-туннеле, имеют время жизни, по истечении которого должны быть заменены. По умолчанию параметр lifetime IPsec SA составляет 86 400 с, или 24 ч.
В итоге участники получили шифрованный туннель с параметрами, которые их всех устраивают, и направляют туда потоки данных, подлежащие шифрованию. Периодически, в соответствии с lifetime, обновляются ключи шифрования для основного туннеля: участники вновь связываются по ISAKMP-туннелю, проходят вторую фазу и заново устанавливают SA.
Режимы IKEv1
Мы рассмотрели в первом приближении основную механику работы IPsec, но необходимо заострить внимание еще на нескольких вещах. Первая фаза, помимо всего прочего, может работать в двух режимах: main mode или aggressive 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 (см. рис. 2) — это имя записи, которая содержит в себе набор политик для данного IPsec-подключения. Это уже одна из фич, специфичных оборудованию Cisco.
Рис. 2. Tunnel group name
Двух фаз оказалось недостаточно
Казалось бы, что получается и так не слишком простая схема работы, но на деле все еще чуть сложнее. Со временем стало ясно, что только одного PSK недостаточно для обеспечения безопасности. Например, в случае компрометации рабочей станции сотрудника атакующий смог бы сразу получить доступ ко всей внутренней сети предприятия. Поэтому была разработана фаза 1.5 прямо между первой и второй классическими фазами. К слову, эта фаза обычно не используется в стандартном site-to-site VPN-соединении, а применяется при организации удаленных VPN-подключений (наш случай). Эта фаза содержит в себе два новых расширения — Extended Authentication (XAUTH) и Mode-Configuration (MODECFG).
XAUTH — это дополнительная аутентификация пользователей в пределах IKE-протокола. Эту аутентификацию еще иногда называют вторым фактором IPsec. Ну а MODECFG служит для передачи дополнительной информации клиенту, это может быть IP-адрес, маска, DNS-сервер и прочее. Видно, что эта фаза просто дополняет ранее рассмотренные, но полезность ее несомненна.
IKEv2 vs IKEv1
Оба протокола работают по 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-шлюз просто забывает о нем. Без этого механизма при каждом запросе от кого угодно VPN-шлюз бы пытался сгенерировать DH-ключ (что достаточно ресурсоемкий процесс) и вскоре бы столкнулся с проблемами. В итоге за счет того, что все операции теперь требуют подтверждения от другой стороны соединения, на атакуемом устройстве нельзя создать большое количество полуоткрытых сессий.
Выходим на рубеж
Наконец-то разобравшись с особенностями работы IPsec и его компонентов, можно переходить к главному — к практическим атакам. Топология будет достаточно простой и в то же время приближенной к реальности (см. рис. 3).
Рис. 3. Общая схема сети
Первым делом нужно определить наличие IPsec VPN шлюза. Сделать это можно, проведя сканирование портов, но здесь есть небольшая особенность. ISAKMP использует протокол UDP, порт 500, а между тем дефолтное сканирование с помощью Nmap затрагивает только TCP-порты. И в результате будет сообщение: `All 1000 scanned ports on 37.59.0.253 are filtered`.
Создается впечатление, что все порты фильтруются и как бы открытых портов нет. Но выполнив команду
убеждаемся в том, что это не так и перед нами действительно VPN-устройство.
Атакуем первую фазу
Теперь нас будет интересовать первая фаза, aggressive-режим и аутентификация с использованием pre-shared key (PSK). В этом сценарии, как мы помним, VPN-устройство или отвечающая сторона отправляет хешированный PSK инициатору. Одна из самых известных утилит для тестирования протокола IKE — это ike-scan, она входит в состав дистрибутива Kali Linux. Ike-scan позволяет отправлять IKE сообщения с различными параметрами и, соответственно, декодить и парсить ответные пакеты. Пробуем прощупать целевое устройство:
Рис. 4. Ike-scan aggressive mode
Ключ `-A` указывает на то, что нужно использовать aggressive-режим, а `-M` говорит о том, что результаты следует выводить построчно (multiline), для более удобного чтения. Видно, что никакого результата не было получено. Причина состоит в том, что необходимо указать тот самый идентификатор, имя VPN-группы. Разумеется, утилита ike-scan позволяет задавать этот идентификатор в качестве одного из своих параметров. Но так как пока он нам неизвестен, возьмем произвольное значение, например 0000.
Рис. 5. Ike-scan ID
В этот раз видим, что ответ был получен (см. рис. 5) и нам было предоставлено довольно много полезной информации. Достаточно важная часть полученной информации — это 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.
Рис. 6. Ike-scan payload
Преодолеваем первые сложности
Казалось бы, хеш получен и можно пробовать его брутить, но все не так просто. Когда-то очень давно, в 2005 году, на некоторых железках Сisco была уязвимость: эти устройства отдавали хеш, только если атакующий передавал корректное значение ID. Сейчас, естественно, встретить такое оборудование практически невозможно и хешированное значение присылается всегда, независимо от того, правильное значение ID отправил атакующий или нет. Очевидно, что брутить неправильный хеш бессмысленно. Поэтому первая задача — это определить корректное значение ID, чтобы получить правильный хеш. И в этом нам поможет недавно обнаруженная уязвимость.
Дело в том, что существует небольшая разница между ответами во время начального обмена сообщениями. Если кратко, то при использовании правильного имени группы происходит четыре попытки продолжить установление VPN-соединения плюс два зашифрованных пакета второй фазы. В то время как в случае неправильного ID в ответ прилетает всего лишь два пакета. Как видим, разница достаточно существенная, поэтому компания SpiderLabs (автор не менее интересного инструмента Responder) разработала сначала PoC, а затем и утилиту IKEForce для эксплуатации этой уязвимости.
В чем сила IKE
Установить IKEForce в произвольный каталог можно, выполнив команду
Работает она в двух основных режимах — режиме вычисления `-e` (enumeration) и режиме брутфорса `-b` (bruteforce). До второго мы еще дойдем, когда будем смотреть атаки на второй фактор, а вот первым сейчас и займемся. Перед тем как начать непосредственно процесс определения ID, необходимо установить точное значение transform-set. Мы его уже определили ранее, поэтому будем указывать опцией `-t 5 2 1 2`. В итоге выглядеть процесс нахождения ID будет следующим образом:
Рис. 7. IKEForce enumeration
В результате достаточно быстро удалось получить корректное значение ID (рис. 7). Первый шаг пройден, можно двигаться дальше.
Получаем PSK
Теперь необходимо, используя правильное имя группы, сохранить PSK-хеш в файл, сделать это можно с помощью ike-scan:
И теперь, когда правильное значение ID было подобрано и удалось получить корректный хеш PSK, мы можем наконец-то начать офлайн-брутфорс. Вариантов такого брутфорса достаточно много — это и классическая утилита psk-crack, и John the Ripper (с jumbo-патчем), и даже oclHashcat, который, как известно, позволяет задействовать мощь GPU. Для простоты будем использовать psk-crack, который поддерживает как прямой брутфорс, так и атаку по словарю:
Рис. 8. Psk-crack
Но даже успешно восстановить PSK (см. рис. 8) — это только половина дела. На этом этапе нужно вспомнить про то, что дальше нас ждет XAUTH и второй фактор IPsec VPN.
Расправляемся со вторым фактором IPsec
Итак, напомню, что XAUTH — это дополнительная защита, второй фактор аутентификации, и находится он на фазе 1.5. Вариантов XAUTH может быть несколько — это и проверка по протоколу RADIUS, и одноразовые пароли (OTP), и обычная локальная база пользователей. Мы остановимся на стандартной ситуации, когда для проверки второго фактора используется локальная база пользователей. До недавнего времени не существовало инструмента в публичном доступе для брутфорса XAUTH. Но с появлением IKEForce эта задача получила достойное решение. Запускается брутфорс XAUTH достаточно просто:
Рис. 9. IKEForce XAUTH
При этом указываются все найденные ранее значения: 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, логин и пароль второго фактора. После чего само подключение происходит одной командой:
Отключение тоже достаточно простое:
Проверить работоспособность подключения можно, используя команду `ifconfig tun0`.
Рис. 10. VPNC
Как построить надежную защиту
Защита от рассмотренных сегодня атак должна быть комплексной: нужно вовремя устанавливать патчи, использовать стойкие pre-shared ключи, которые по возможности вовсе должны быть заменены на цифровые сертификаты. Парольная политика и другие очевидные элементы ИБ также играют свою немаловажную роль в деле обеспечения безопасности. Нельзя не отметить и тот факт, что ситуация постепенно меняется, и со временем останется только IKEv2.
Что в итоге
Мы рассмотрели процесс аудита RA IPsec VPN во всех подробностях. Да, безусловно, задача эта далеко не тривиальна. Нужно проделать немало шагов, и на каждом из них могут поджидать трудности, но зато в случае успеха результат более чем впечатляющий. Получение доступа к внутренним ресурсам сети открывает широчайший простор для дальнейших действий. Поэтому тем, кто ответствен за защиту сетевого периметра, необходимо не рассчитывать на готовые дефолтные шаблоны, а тщательно продумывать каждый слой безопасности. Ну а для тех, кто проводит пентесты, обнаруженный пятисотый порт UDP — это повод провести глубокий анализ защищенности IPsec VPN и, возможно, получить неплохие результаты.
Впервые опубликовано в журнале Хакер #196.
Автор: Александр Дмитренко, PENTESTIT