Skip to main content

Loki в сетях IPv6 - это проще чем ты думал

Перед тем как перейти к уязвимостям IPv6 и атакам на них, неплохо бы посмотреть, какие есть инструменты в арсенале пентестера на этот счёт. До недавнего времени существовал только один набор утилит для проведения атак на протоколы IPv6 и ICMPv6. Это THC-IPV6 от незабвенного Марка ван Хаузера, того самого автора брут-форсера THC-hydra и массы других незаменимых инструментов. Именно он в 2005 году серьёзно заинтересовался темой IPv6 и вплотную занялся изучением этого протокола и до недавнего времени оставался первопроходцем, но в последнее время ситуация стала меняться. 

Всё больше исследователей сетевой безопасности обращают своё внимание на IPv6, и, соответственно, стали появляться и новые утилиты, такие как Loki и новые сканеры сетей, но на сегодня THC-IPV6 по-прежнему остаётся лучшим набором утилит для проникновения в сеть. В комплект его входит уже более 60 инструментов, разделённых на различные категории - от сканирования и MiTM до флудинга и фаззинга, но не будем забывать и реальную утилку scapy, позволяющую вручную создавать пакеты, с любыми заголовками, даже если таковые вариации не предусмотрены ни в одной RFC.

LOKI - ICMPv6 multicast или как посмотреть соседей по IPv6

Перед тем, как атаковать цель, нужно её хоть как-то обнаружить, поэтому стандартный пентест обычно начинается с поиска живых хостов, но здесь появляется проблема: мы не можем просканировать весь диапазон. Сканирование всего одной подсети затянется на годы, даже если отправлять миллион пакетов в секунду. Причина в том, что всего лишь одна подсеть /64 (или их ещё называют префиксами) больше, чем весь интернет сегодня, причём значительно больше. Поэтому самая серьёзная проблема с IPv6 - это обнаружение целей.

К счастью, выход есть. Вначале нужно будет найти подходящую AS (автономную систему), которая принадлежит цели (объекту пентеста). Сервисов, позволяющих искать по AS их владельцев, вполне достаточно, можно это делать прямо на сайтах региональных регистраторов (европейский регистратор - это RIPE NCC). Затем, зная номер AS, принадлежащей конкретной компании, можно уже искать выделенные ей IPv6 префиксы.

Самый удобный такой поисковый сервис предоставляет Hurricane Electric (bgp.he.net). В итоге можно найти несколько огромных подсетей, которые как мы убедились, нереально просканировать на предмет живых хостов. Поэтому нужно составлять список часто используемых адресов и проводить сканирование уже точно по ним.

Каким образом можно собрать такой словарь? Если проанализировать, как в компаниях, которые уже внедрили IPv6, назначаются адреса клиентам, то можно выделить три основные группы: автоконфигурация, ручное назначение адресов и DHCPv6.

Автоконфигурация может осуществляться тремя способами: на основе MAC адреса, с использованием privacy option (то есть в случайном порядке и, например, меняться раз в неделю) и fixed random (полностью случайным образом). В данной ситуации возможно сканировать только те адреса, что строятся на основе MAC адреса. В результате могут выйти подсети, сравнимые по размеру с IPv4 класса А, процесс работы с такими сетями не очень быстрый, но всё равно это уже вполне реально. Например, зная, что в целевой компании массово используются ноутбуки определенного производителя, можно строить сканирование, основываясь на знаниях о том, как будет формироваться адрес.

Если адреса задаются вручную, то они могут назначаться либо случайным образом, либо по некоему шаблону. Второе, естественно, в жизни встречается гораздо чаще. А шаблон вполне может быть ::1, ::2, ::3 или ::1001, ::1002, ::1003. Также иногда в качестве адреса используются порты служб, в зависимости от сервера: например, работающий Web-сервер может иметь адрес ::2:80.   

Если же брать DHCPv6, то в этом случае обычно адреса раздаются последовательно из пула (точно такое же поведение можно наблюдать и с обычным DHCPv4 сервером). Зачастую в DHCPv6 можно встретить пул вроде ::1000-2000 или ::100-200. Поэтому в итоге берём утилиту alive6 (она включена в комплект THC-IPV6 и, как и все рассматриваемые сегодня инструменты, по умолчанию входит в Kali Linux) и запускаем в таком виде:

alive6 - перебор пула DHCPv6

При таком обнаружении живых машин будет меняться только часть, отвечающая за адрес хоста. Используя такой подход, можно достаточно эффективно и в разумные временные рамки находить живые хосты в обнаруженных ранее подсетях IPv6.

Но и это ещё не всё - естественно, можно использовать и DNS. С приходом IPv6 никуда не делись трансферы DNS-зоны и брутфорсы DNS по словарю. Применив все эти техники вместе, можно обнаружить до 80% всех включенных в сеть хостов в заданном IPv6 префиксе, что очень даже хорошо. В случае же компрометации одного лишь хоста обнаружитьвсех его соседей не составит никакого труда при помощи мультикаста. Достаточно будет запустить ту же утилиту alive6, только уже с ключом -l или воспользоваться пакетом LOKI как показано на скриншоте.

Из свежих фич THC-IPV6, и в частности утилиты alive6, можно отметить возможность искать живые хосты, передавая в качестве шаблона для перебора целую IPv4 подсеть:
alive6 - шаблон IPv4 для перебора IPv6
Если же брать классическое сканирование, то здесь практически ничего не изменилось. Тот же Nmap, те же самые варианты сканирования портов, единственное отличие в том, что теперь сканировать можно только один хост за раз, но это вполне очевидное решение.    

Пожалуй, единственная дополнительная техника при сканировании портов - это сканирование IPv4 вначале, а затем получение IPv6 информации по этим хостам. То есть некое расширение поверхности атаки. Для этого можно использовать как вспомогательный модуль метасплоита ipv6_neighbor, так и отдельные сценарии ipv6_surface_analyzer. Работают они по схожему принципу - принимают на входе префикс IPv4, сканируют его, находят живые хосты, проверяют порты на открытость, а затем, определив MAC адрес, высчитывают по нему IPv6 адрес и уже пробуют работать по нему. Иногда это действительно помогает, но в некоторых случаях (privacy option) IPv6 адреса обнаружить не удается, даже несмотря на то, что они есть.

Comments

Popular posts from this blog

Сбербанк и дропы с площадки Dark Money, и кто кого?

Крупных открытых площадок в даркнете, специализирующихся именно на покупке-продаже российских банковских данных, обнале и скаме около десятка, самая большая из них – это Dark Money . Здесь есть нальщики, дропы, заливщики, связанный с ними бизнес, здесь льют и налят миллионы, здесь очень много денег, но тебе не стоит пока во все это суваться. Кинуть тут может любой, тут кидали и на десятки миллионов и на десятки рублей. Кидали новички и кидали проверенные люди, закономерности нету. Горячие темы – продажи данных, банковских карт, поиск сотрудников в скам и вербовка сотрудников банков и сотовых операторов, взлом аккаунтов, обнал и советы – какими платежными системы пользоваться, как не попасться милиции при обнале, сколько платить Правому Сектору или патрулю, если попались. Одна из тем – онлайн-интервью с неким сотрудником Сбербанка, который время от времени отвечает на вопросы пользователей площадки об уязвимостях системы банка и дает советы, как улучшить обнальные схемы. Чтобы пользова

Перехват BGP-сессии опустошил кошельки легальных пользователей MyEtherWallet.com

Нарушитель ( реальный заливщик btc и eth ) используя протокол BGP успешно перенаправил трафик DNS-сервиса Amazon Route 53 на свой сервер в России и на несколько часов подменял настоящий сайт MyEtherWallet.com с реализацией web-кошелька криптовалюты Ethereum . На подготовленном нарушителем клоне сайта MyEtherWallet была организована фишинг-атака, которая позволила за два часа угнать 215 ETH (около 137 тысяч долларов) на кошельки дропов. Подстановка фиктивного маршрута была осуществлена от имени крупного американского интернет-провайдера eNet AS10297 в Колумбусе штат Огайо. После перехвата BGP-сессии и BGP-анонса все пиры eNet, среди которых такие крупнейшие операторы, как Level3 , Hurricane Electric , Cogent и NTT , стали заворачивать трафик к Amazon Route 53 по заданному атакующими маршруту. Из-за фиктивного анонса BGP запросы к 5 подсетям /24 Amazon (около 1300 IP-адресов) в течение двух часов перенаправлялись на подконтрольный нарушителю сервер, размещённый в датацентре п

DDOS атаки на маршрутизатор и методы защиты Juniper routing engine

По долгу службы мне часто приходится сталкиваться с DDOS на сервера, но некоторое время назад столкнулся с другой атакой, к которой был не готов. Атака производилась на маршрутизатор  Juniper MX80 поддерживающий BGP сессии и выполняющий анонс сетей дата-центра. Целью атакующих был веб-ресурс расположенный на одном из наших серверов, но в результате атаки, без связи с внешним миром остался весь дата-центр. Подробности атаки, а также тесты и методы борьбы с такими атаками под катом.  История атаки Исторически сложилось, что на маршрутизаторе блокируется весь UDP трафик летящий в нашу сеть. Первая волна атаки (в 17:22) была как раз UDP трафиком, график unicast пакетов с аплинка маршрутизатора: и график unicast пакетов с порта свича подключенного к роутеру: демонстрируют, что весь трафик осел на фильтре маршрутизатора. Поток unicast пакетов на аплинке маршрутизатора увеличился на 400 тысяч и атака только UDP пакетами продолжалась до 17:33. Далее атакующие изменили стратегию и добавили к

Сброс BGP-сессии при помощи TCP Connection Reset Remote Exploit

Уже ни раз рассказывал о протоколе ТСР , так что повторятся особо не буду, напомню лишь основные положения: Transmission Control Protocol описывается в RFC 793 и преимуществом его является надежность передачи данных от одной машины к другому устройству по сети интернет. Это означает, что ТСР гарантирует надежность передачи данных и автоматически определит пропущенные или поврежденные пакеты. Что для нас важно из его конструкции? В общем виде заголовок ТСР пакета выглядит так: Программа передает по сети некий буфер данных, ТСР разбивает данные на сегменты и дальше упаковывает сегменты в наборы данных. Из наборов данных формируются пакеты и уже они передаются по сети. У получателя происходит обратный процесс: из пакетов извлекаются набор данных, его сегменты, затем сегменты передаются в ТСР стек и там проверяются, потом собираются и передаются программе. Sequence numbers Данные разбиваются на сегменты, которые отдельными пакетами направляются по сети получателю. Возможна ситуация, к

Как найти реального заливщика

Своего первого реального заливщика, который показал мне как можно скачать деньги в интернет с банковских счетов, я нашел случайно, когда еще трудился в Укртелекоме сменным инженером немного подрабатывая продавая трафик налево , но потом этот человек отошел от дел в связи со слишком уж скользкой ситуацией в данной сфере, и я решил поискать партнера на форумах, разместив рекламу на трёх электронных досках объявлений. Честно говоря поначалу даже был готов сразу закинуть 500 000 гривен в Гарант, но потом призадумался, а стоит ли? Ко мне начал обращаться народ обращается разных категорий 1. Дебильная школота, которая что-то любит повтирать про свою серьезность и просит закинуть 10 000 USD им на Вебмани в качестве аванса  2. Реальные мэны, которые  льют сразу большую сумму по SWIFT  без разговоров про гарантии и прочую шнягу, но после того, как им отдаёшь нал, они сразу пропадают, суть данных действий я так и не понял. зачем пропадать, если всё прошло гладко? 3. Мутные личност

Обзор внутренней инфраструктуры безопасности Google

Обычно компании предпочитают хранить в тайне особенности своей инфраструктуры безопасности, которая стоит на защите дата-центров, полагая, что раскрытие подобной информации может дать атакующим преимущество. Однако представители Google смотрят на этот вопрос иначе. На то есть две причины. Во-первых, публикация таких отчетов позволяет потенциальным пользователям Google Cloud Platform (GCP) оценить безопасность служб компании. Во-вторых, специалисты Google уверены в своих системах безопасности. На днях компания обнародовала документ Infrastructure Security Design Overview («Обзор модели инфраструктуры безопасности»), в котором Google достаточно подробно описала свои защитные механизмы. Инфраструктура разделена на шесть слоев, начиная от аппаратных решений (в том числе физических средств защиты), и заканчивая развертыванием служб и идентификацией пользователей. Первый слой защиты – это физические системы безопасности, которые просто не позволяют посторонним попасть в дата-центры. Эта част