Организация доступа в сеть WI-FI московского метрополитена с точки зрения безопасности

в 13:43, , рубрики: безопасность, информационная безопасность

Введение

В данном исследовании проанализирована схема работы беспроводной сети московского метрополитена с точки зрения обычного пользователя. В рамках тестирования использовался телефон на Android. Случаи, когда телефон не был ни разу авторизован в сети, рассматриваются в ограниченном формате.

Процесс подключения

При подключении к сети WI-FI происходит следующее:

Происходит первоначальная ассоциация устройства с WI-FI точкой. Затем устройство устанавливает TCP соединение c сервером Google.

image
Рисунок 1: установление TCP соединения

Далее телефон на Android проверяет необходимость авторизации в сети, путем отправки GET запроса на сервер Google. Если приходит ответ – авторизация не требуется, если не приходит – требуется авторизация, если происходит редирект на веб-страницу авторизации, телефон отображает ее.

image
Рисунок 2: проверка на необходимость авторизации

Шлюз, в свою очередь, на любой http-запрос отвечает, подменяя ответы запрашиваемого сервера на редирект к странице авторизации.

image
image
Рисунок 3: редирект на страницу авторизации

Далее мы жмем кнопку «войти в интернет». Вот сам пакет, видно, что он идет на адрес из private сегмента:

image
Рисунок 4: пакет с запросом на авторизацию wi-fi.ru

А сам запрос выглядит следующим образом:

GET / HTTP/1.1
Host: wi-fi.ru
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 5.1.1; HUAWEI MT7-L09 Build/HuaweiMT7-L09) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.83 Mobile Safari/537.36
Referer: https://login.wi-fi.ru/am/UI/Login?org=mac&service=coa&client_mac=66-a0-f6-dd-d2-9e&ForceAuth=true
Accept-Encoding: gzip, deflate, sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: adfoxUserID=19:154848341; _ym_uid=1449217853212630314; _ym_isad=1; device_type=mobile; surf_prev_url=undefined; surf_curr_url=http://wi-fi.ru/; crtg_rta=; _mtp=0:ijk1njsr:69XJtN~ZNVIaYHb4OT3NHAOjPvLS50k4; _ga=GA1.2.1994719851.1449217854; amlbcookie=01; t=AQIC5wM2LY4SfcxCV1htnKzHF3mtmXJCDcvGniOTgqxvUMc.*AAJTSQACMDIAAlNLABQtNTkwNDE0MjY2MjYxNzMzMzgwOAACUzEAAjAx*
If-None-Match: W/"74f5335bcd0524bfcd031469fc9c52e5"

Анализ

Видно, что в качестве параметра в том числе передается MAC адрес нашего устройства. Это наводит на мысль, что мак адрес является идентификатором, и именно по нему сеть понимает, оплачен у нас интернет или нет. Нужно отметить, что адреса login.wi-fi.ru и wi-fi.ru доступны в том числе и из публичного интернета. Это позволяет нам проверить любой MAC адрес на его статус. Выглядит это следующим образом:

MAC адрес, который не бывал в метро:

image
Рисунок 5: MAC адрес, ни разу не бывавший в метро

MAC адрес, который не оплатил интернет:

image
Рисунок 6: MAC не оплатил интернет

MAC адрес, который оплатил интернет, попадает на страницу с ошибкой (так как мы не внутри сети), но потом успешно автоматически перенаправляется на wi-fi.ru:

image
Рисунок 7: ошибка при подключении

image
Рисунок 8: успешное подключение

Выяснилось, что при авторизации сервер отдает на страницу тип подключаемого MAC адреса:

image
Рисунок 9: группы, к которым принадлежит наш MAC

В том числе видно, что если у нас в группе прописан mosmetro_premium, значит мы счастливый обладатель оплаченного интернета.

Тест

Для автоматизации поиска различных типов MAC адресов был написан скрипт на Python: https://bitbucket.org/guardyteam/metro

C его помощью была найдена парочка «оплаченных» адресов:

image
Рисунок 10: «оплаченные» адреса

И в экспериментальных целях непосредственно в метро был подменен MAC тестового устройства на «оплаченный»:

sudo ifconfig en0 ether xx:xx:xx:xx:xx:xx

И все успешно завелось, без регистрации и смс.

Автор: hollow1

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js