Captive apple com что это

Я использовал crummy AT & T (* coughAT & Tsymbollookslikedeathstarcough *) маршрутизатор для создания частной локальной сети. У него нет сервисов /DSL-соединений, потому что он не обнаруживает доступ в Интернет (естественно) и даст мне это всплывающее окно на Mac:

Это, как вы можете видеть, похоже, является окном Safari, которое является источником capive.apple.com. Поскольку у меня нет DSL-соединения, все разрешения DNS передаются на веб-хост маршрутизатора. Это означает, что каждые 5-10 минут я получаю это всплывающее окно. Соединение WiFi работает, но я получаю это раздражающее всплывающее окно, которое прерывает мою работу.

На iPhone у меня есть подобная проблема, хотя она более последовательна. В настройках -> Беспроводная связь дает мне эту же страницу с просьбой войти в систему. Я предполагаю, что это функция captive.apple.com. Я знаю, что такие места, как McDonalds или Starbucks, сделают это, чтобы убедиться, что вы заходите и купите что-то, прежде чем попасть в их WiFi.

Мой вопрос: как отключить это на Mac, чтобы мне больше не пришлось волноваться с этим всплывающим окном? IPhone является вторичной проблемой, но было бы неплохо иметь решение для этого. Будет ли запись /etc /hosts исправлена, или это сложнее, чем это?

OS X версия 10.11 El Capitan
2011 Mac Mini

Этичный хакинг и тестирование на проникновение, информационная безопасность

Что такое Captive Portal

С перехватывающим порталом (Captive Portal) вы можете столкнуться в аэропорту, гостинице, кондо, бизнес-центрах, также сейчас некоторые мобильные операторы организуют Wi-Fi точки доступа используя перехватывающие порталы – hotspot с авторизацией на web-интерфейсе.

Если вы не совсем понимаете, о чём идёт речь, то посмотрите на скриншот:

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

Перехватывающий Портал – это альтернативный способ (вместо пароля от сети Wi-Fi) ограничить круг пользователей. Благодаря такому подходу, имеется возможность гибко регулировать доступ к Интернет-сети (например, выдать учётные данные, которые действуют заданный промежуток времени), и мониторить активность конкретного пользователя.

Иногда для получения доступа достаточно ввести ПИН из бесплатного СМС сообщения, либо спросить на рисепшене логин и пароль. Но иногда доступ необходимо купить. Например, на скриншоте выше:

В этом сообщении сказано, что в данный момент я подключён к сети кондо i Space, чтобы использоваться службой Интернет-доступа, мне необходимо обратиться в офис i Space. Я не хочу туда обращаться, поскольку и без того знаю, что они мне скажут: «500 бат фо ван манс анлиметед». Не уверен, что мне нужен Интернет на таких условиях.

Быстрый взлом хот-спота с авторизацией на web-интерфейсе

Мы будем использовать hack-captive-portals – скрипт для взлома любых перехватывающих порталов (Captive Portal), использующий технику спуфинга MAC.

Если у вас Kali Linux, Ubuntu, Linux Mint, Debian или любые их производные, то установите пару пакетов:

Сам скрипт вы можете скачать следующим образом:

Но я немного доработал этот скрипт (на некоторых сетях разницы в работе не будет, но на некоторых работа будет намного стабильнее и намного быстрее за счёт пропуска явных пустышек).

Чтобы использовать мою версию, создайте файл hack-captive-mial.sh:

И скопируйте туда:

Сделайте файл исполняемым:

Или (если используете оригинальную версию):

И дожидайтесь результата.

Как только увидите строку

Значит для вас уже открыт интернет доступ!

Вновь проверяем пинг:

Пробуем открыть сайт (я захожу на SuIP.biz, чтобы заодно узнать «своего» Интернет-провайдера):

Как сделать сигнал Перехватывающего Портала (Captive Portal) доступным для других устройств

Независимо от того, как вы получили доступ (легально или не совсем), можно расшарить ваше Интернет-соединение для нескольких устройств. Можно даже открыть интернет доступ из виртуальной машины реальному компьютеру…

В принципе, я использую метод описанный в статье «Усиление сигнала Wi-Fi».

Само-собой, нам понадобится 2 Wi-Fi адаптера – один подключён к Перехватывающему Порталу, второй – раздаёт Интернет для «своих».

На предыдущем этапе – когда мы взламывали Перехватывающий Портал, вполне возможно, что мы использовали подключение с помощью Network Manager. Мы сократим количество непонятных зависаний и сбережём свои нервы, если будем выполнять последующие действия без использования NetworkManager.

Устанавливаем дополнительные пакеты, если у вас их ещё нет:

Теперь останавливаем NetworkManager:

Если вы работаете из виртуальной машины, то нужно отключить (виртуальное) проводное соединение, чтобы скрипт не запутался, когда будет искать дефолтный шлюз (если нужно, поменяйте eth0 на имя вашего ПРОВОДНОГО сетевого интерфейса):

Есть некоторые отличия от подключения к Точке Доступа из командной строки, описанного в статье «Усиление сигнала Wi-Fi», поскольку там мы подключались к точке доступа с шифрованием (с паролем), а теперь мы будем подключаться к открытой точке доступа (без пароля).

Создайте конфигурационный файл, к примеру, с именем wpa_sup.conf:

Скопируйте в него следующее (замените i_spac_5FL-2.4GHz на имя сети Перехватывающего Портала):

Подключаемся (замените wlan0 на имя вашего беспроводного интерфейса, используемого для подключения к перехватывающему порталу, если вы выбрали другое имя для конфигурационного файла, то напишите его вместо wpa_sup.conf):

Дождитесь появления примерно такой строки (должны быть слова CTRL-EVENT-CONNECTED — Connection to):

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

В этом месте запустите скрипт для взлома Captive Portal:

Дождитесь успешного завершения.

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

Запускается create_ap следующим образом:

Я хочу создать ТД с именем «HackWare» на интерфейсе wlan1, используя для Интернет-доступа интерфейс wlan0, тогда моя команда:

Если появилась строка

значит всё прошло успешно.

Командой выше создаётся ТД, подключение к которой не защищено паролем, если вы хотите создать защищённую паролем ТД, то используйте команду вида:

Например, чтобы моя ТД имела пароль MiAlrules я использую команду:

Если ваш беспроводной адаптер поддерживает IEEE 802.11n, то можно дополнительно использовать опцию —ieee80211n, которая включает IEEE 802.11n:

Поскольку все операции я выполнял в виртуальной машине, к которой подключены два USB Wi-Fi адаптера, то у виртуальной машины теперь Интернет есть, а у реального компьютера его нет. Но поскольку виртуальная машина запущена в ноутбуке со встроенной Wi-Fi картой, то мой реальный компьютер подключается к Точке Доступа, которую создаёт виртуальный компьютер:

Подключение произошло успешно и теперь на основном компьютере также есть Интернет:

Мне это кажется забавным: не существующий, виртуальный компьютер обеспечивает Интернетом реальный железный компьютер!

Также подключаю другие свои устройства (мобильные телефоны) к точке доступа из виртуальной машины:

Как работает Captive Portal (Перехватывающий Портал)

Чтобы понять, почему так легко обойти Перехватывающий Портал, а также увидеть другие способы обхода, нужно понять, как именно работает Captive Portal.

Как можно было уже увидеть – это открытая Точка Доступа, к которой может подключиться кто-угодно. Запомним это – у нас без всяких взломов уже имеется доступ к локальной сети. Если при словосочетании «локальная сеть» вам сразу приходит в голову слово «сниффинг» — то вы правы!

Сетевое оборудование настроено так, чтобы всех подключившихся перенаправлять на одну и туже веб-страницу, на которой размещены условия доступа к сети. На этой странице пользователь вводит ПИН из СМС или логин и пароль. Обычно для доступа к веб-странице перехватывающего портала используется протокол HTTP (а не HTTPS). Это связано с особенностями локальной сети – для локальных адресов невозможно получить валидные SSL сертификаты, а использование невалидных ничего не добавляет к безопасности, но при этом создаёт дополнительные проблемы.

Кстати, если вы подключились к Порталу и пытаетесь открыть что-то в веб-браузере, но у вас не происходит переадресация на веб-страницу Captive Portal, то вероятнее всего дело в том, что вы пытаетесь зайти на сайт с HTTPS протоколом – попробуйте открыть любой сайт на HTTP и вас всё-таки перебросит на страницу «входа»,

Чтобы пользователи не догадались использовать нестандартные порты (например, для подключения к VPN, использовать браузер Tor или прокси), то весь трафик на всех портах блокируется. Кроме трафика UDP на 53 порту – это необходимо чтобы пропускать запросы к DNS-серверу.

После того, как пользователь ввёл верные учётные данные, для его MAC-адреса и IP адреса открывается неограниченный доступ. Привязка идёт именно к MAC-адресу (либо к паре MAC-адрес и IP адрес), поскольку по-другому проблематично реализовать доступ для всего устройства. Современным компьютерам, а особенно мобильным устройствам, недостаточно браузера: телефоны используют разнообразные мессенджеры, многие программы пользуются сетью: онлайн игры, антивирусы для обновления баз, почтовый клиенты и т.д. Т.е. невозможно ограничится кукиз в веб-браузере или чем-то подобным: необходимо открывать полный доступ для сетевого интерфейса клиента, какой бы трафик и на каком бы порту ему не понадобился. Сетевые интерфейсы обладают уникальным идентификатором – MAC-адресом. Именно на основе него и «запоминается» устройство, которому разрешён доступ. Перехватывающий Портал может оставлять кукиз в веб-браузере, но они носят вспомогательный характер: например, для ускорения повторной аутентификации.

Здесь описана «сильная» конфигурация перехватывающего портала – с защитой «по полной». Конкретные реализации могут быть ещё слабее: например, для перенаправления на страницу Портала может использоваться DNS сервер, который на все запросы будет отвечать IP адресом Captive Portal, и при этом не будет должной фильтрации трафика. Как результат, такой Портал можно обойти просто использованием обычного VPN соединения, либо установкой в настройках DNS сервера в паре с браузером Tor и т.п.

Как обойти Captive Portal (Перехватывающий Портал)

Теперь, когда мы понимаем, на каких принципах основывается работа Captive Portal, очень хорошо видны его слабые места.

Первый метод обхода Captive Portal: кража MAC и IP адреса

Именно этот метод использует скрипт hack-captive-portals: он перехватывает IP и MAC от кого-либо, кто уже подключён и авторизован в перехватывающем портале.

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

Очень просто, но при этом ОЧЕНЬ эффективно. Обязательное требование – в локальной сети должен быть кто-нибудь, кто уже авторизовался в Перехватывающем Портале. В принципе, можно выписать несколько рабочих пар MAC-IP и подключаться даже когда «хозяев нет дома», но такие пары могут «протухать» — они могут быть действительны, например, только в течение суток (с момента аутентификации легитимным пользователем, а не с момента, когда мы узнали о них).

Тем не менее, это очень эффективный и самый универсальный метод.

Вы также можете взломать Перехватывающий Портал даже без скрипта: с помощью arp-scan исследуйте локальную сеть Портала, смену MAC делайте как описано в этой статье, а подменять IP можно прямо в графическом интерфейсе Network Manager. В нём же установите DNS сервер 8.8.8.8.

Второй метод обхода Captive Portal: использование UDP VPN на 53 порту

Обычно в перехватывающих порталах для пользователей, не прошедших аутентификацию, заблокированы все TCP и UDP порты. Все кроме одного – 53 UDP порта. При «обычной» работе сети, этот порт необходим для запроса к DNS серверам, чтобы преобразовать имена хостов в IP. Нужно начать с проверки, не выполняется ли спуфинг DNS запросов (обычно нет). Для этого выполните несколько раз команду dig для разных хостов, например, для получения IP хоста ya.ru:

Для получения IP хоста google.com

И т.д. – если результаты различные (а не, например, каждый раз 192.168.88.1 или другой локальный IP адрес), значит DNS запросы свободно проходят – порт 53 UDP открыт.

Через этот 53 порт можно настроить UDP прокси, VPN или другой туннель. Бесплатные UDP VPN на 53 порту можно найти прямо в Гугле.

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

Огромный плюс данного метода – нам не нужен клиент, который успешно аутентифицирован в Портале. Мы можем выполнять этот обход даже если мы подключены к Captive Portal в полном одиночестве. При первом методе, наш трафик учитывается и засчитывается в качестве израсходованного легитимным пользователем. Если трафик безлимитный – то никаких проблем нет. Если же трафик оплачивается по мегабайтам – то наши действия перестают быть простой шалостью и причиняют вполне конкретный имущественный вред конкретному человеку…

При использовании порта 53 UDP, прокаченный трафик не «вешается» ни на какого пользователя.

Третий метод обхода Captive Portal: кража учётных данных легитимных пользователей

Поскольку в Captive Portal мы находимся с другими пользователями в одной локальной сети, и данные для авторизации на Портале пересылаются по протоколу HTTP (а не HTTPS), то кажется вполне рабочей следующая схема:

• подключаемся к открытой сети
• запускаем ARP спуфинг
• запускаем сниффинг
• анализируем полученные данные: ищем в них логин и пароль

На практике, из-за особенностей построения сети Порталов (он может быть «заполнен» фейковыми пользователями, и эти фантомы сводят с ума такие программы как Bettercap) атака не всегда проходит успешно.

Менее инвазивный (и намного более удобный) метод предложен человеком с ником user100 на форуме Античат (соответствующая тема – авторский кейс в первом посту).

Мы воспользуемся фактом, что в открытых сетях трафик передаётся без шифрования. Т.е. мы не будем подключаться к сети, а будем использовать Airodump-ng для прослушивания трафика.

Останавливаем Network Manager и убиваем процессы, которые могут нам помешать:

Далее в командах, если нужно, замените имя wlan0 на имя вашего беспроводного интерфейса.

Переводим карту в режим монитора

Запускаем airodump-ng, чтобы узнать, на каком канале работает интересующая нас Точка Доступа:

Как можно увидеть на скриншоте имеется сразу несколько открытых ТД на разных частотах. Я выбираю ту, у которой сильнее сигнал (поскольку она и её клиенты должны быть ближе ко мне).

Теперь, когда мы увидели нужную информацию, запускаем airodump-ng ещё раз со следующими опциями:

• -w /root/open – эта опция для сохранения захваченных данных в файл
• —channel 10 – мы устанавливаем определённый канал, чтобы airodump постоянно прослушивала только его и не прыгала по другим каналам

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

Обращайте внимание на поле #Data. Если оно совсем не меняется, значит к точке доступа никто не подключён. Если оно меняется вяло – значит кто-то подключён, но не серфит по Инету.

Для анализа полученных данных, открываем файл захвата (у меня он называется /root/cap-01.cap) в программе Wireshark:

Для ускорения поиска используйте фильтры Wireshark.

• Фильтр, который показывает только данные, переданные методом POST:

• Фильтр, который показывает только данные, переданные методом GET:

• Фильтр для показа всего HTTP трафика (фильтр пишется строчными буквами!):

• Ещё один вариант показа всего HTTP трафика:

• Поиск запросов к определённому сайту (хосту):

• Поиск запросов к определённому сайту по части имени:

• Показать весь трафик с определённого IP

• Показать весь трафик на определённый IP

• Показать весь трафик, у которого в качестве источника ИЛИ пункта назначения указан определённый IP:

Чтобы ускорить процесс, я подключился с другого устройства и выполнил вход с произвольными данными: в качестве имени пользователя я указал 11111111, а в качестве пароля — 22222222.

Там различная полезная информация, но главной является строка:

К сожалению, вместо пароля там хеш 15b4c47a3e0e44b9e40db20ac1225023. Причём не просто хеш, в исходном коде видно, что к паролю перед преобразованием добавляется соль:

Адрес JavaScript файла: http://portal.cloud-hotspot.com/md5.js, в нём есть та самая функция hexMD5:

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

Можно сказать, что мне не повезло. Если вам удалось перехватить пароль в открытом виде – то всё отлично. Если же у вас похожая ситуация – когда пароль хешируется, то его всё равно можно использовать! Хотя это требует лишних действий с нашей стороны.

Серверу важно получить правильную строку, а каким образом она создана, он никак не проверяет. Т.е. мы можем просто отправить запрос с помощью curl, содержащий все необходимые данные и сервер прекрасно примет наш хеш вместо самого пароля, поскольку от других пользователей он также получает именно хеш (а не пароль, как это обычно реализовано на веб-сайтах, где хеш вычисляется на самом сервере).

Более того, чтобы каждый раз не использовать curl, можно создать простой HTML файл с правильной формой, которая будет отправлять все нужные данные, в том числе хеш. Этот файлик можно закинуть на телефон и выполнять вход в Портал и с него.

В любом случае необходимо будет правильно определить все передаваемые поля (удобно делать с помощью Burp Suite), в том числе скрытые, указывать правильного реферера, в случае необходимости, и т.д. Все эти проблемы являются решаемыми.

Минус данного метода:

• необходимо не только наличие легитимного пользователя, выполнившего вход в портал, но и застать тот момент, когда он выполняет вход
• если разрешено использовать учётные данные только для одного устройства, то возникнут проблемы, если вы и легитимный пользователь одновременно пытаетесь выходить в Интернет через Портал
• пароль может передаваться в виде хеша, что усложняет его использование

Плюсы данного метода:

• после захвата учётных данных, можно использовать Интернет в Портале даже если в нём нет легитимных пользователей
• если разрешено использовать учётные данные на нескольких устройствах, то можно выполнить вход сразу с нескольких компьютеров/телефонов

Заключение

Рассмотрены самые часто встречающиеся конфигурации Captive Portal – хот-спотов с авторизацией через веб-интерфейс. В заметке собраны самые эффективные методы их обхода. Тем не менее, имеются и другие варианты Перехватывающих Порталов, использующих для идентификации пользователей больше данных – для таких случаев описанные здесь методы взлома открытых хот-спотов могут не сработать.

Отлично во взломе хот-спотов с веб-входом себя показал скрипт hack-captive-portals: полная автоматизация и хорошие результаты.

Доброго времени суток!

Задача: нужна авторизация пользователей WiFi. На iOS требуется открыть портал авторизации не в CNA, а в Safari. Собственно, это у меня получилось. почти.

iOS при подключении к WiFi делает определенный запрос, ожидая получить определенный ответ. Если этот ответ подделать, то iOS решит, что интернет открыт. Но тогда не покажется CNA, а это плохо.

1. Первый запрос не подделываем. Возвращаем HTML, в котором есть ссылка, например, click me. Откроется CNA (мааааленький ограниченный браузер);

2. Остальные запросы подделываем, как будто отвечает сам apple.

Частично это сработало. Если нажать на ссылку из п.1, CNA закроется, а ссылка начнет открываться в Safari. Вроде время радоваться, но шиш! Запрос уходит через мобильную сеть, а от WiFi-сети iOS молча отключается.

Я понимаю сейчас задачу так: когда CNA уже на экране, заставить iOS думать, что доступ в Интернет через этот WiFi уже открыт. Тогда iOS не отключится от WiFi и запрос в браузере уже пойдет правильно и будет счастье! Как это сделать, пока не догнал(

Решение явно существует. В московском метро это сделали.

Люди, помогите! Нет возможности кататься по метро и снифить трафик((

P.S. Стандартый CNA не подходит, т.к. он закрывается и отключается от WiFi на каждый чих. В моем случае, пользвателю иногда требуется зайти в приложение SMS и затем вернуться на портал.

UPD. : в CNA есть кнопка "Готово". Если ее нажать, вместо ссылки, то iOS решает, что доступ в Интернет есть. Вероятно, нужно как-то сэмулировать нажатие этой кнопки при переходе по ссылке