Безопасность мобильного интернета изнутри и снаружи

    С развитием мобильных сетей развивается и мобильный интернет. Все привыкли к обычному интернету: витая пара, Ethernet, TCP/IP. А что же скрывает в себе интернет мобильный? Попробуем выяснить! В нашем исследовании мы коснемся общих принципов работы мобильного интернета, рассмотрим поближе GPRS Tunneling Protocol, поговорим о GRX-сети и обсудим некоторые практические подходы к безопасности мобильной пакетной сети.

    Как каждый из нас подключается к мобильному интернету? В принципе, необходимо знать только три параметра: APN, логин и пароль. APN — это точка доступа, через которую абонент может подключиться к необходимой ему услуге (WAP, MMS, Internet); у наших операторов она обычно выглядит как internet.<operator-name>.ru. Логин и пароль обычно простые: internet — internet или вроде того.

    Теперь, когда мы знаем необходимые параметры, мы можем подключаться к мобильному интернету! Как же происходит эта загадочная процедура? Происходит она в два этапа:

    1. GPRS Attach,
    2. PDP Context Activation.

    Рассмотрим подробнее каждый из них.

    GPRS Attach


    В процедуре GPRS Attach телефон начинает «общаться» с пакетной сетью оператора. Происходит аутентификация и авторизация пользовательского оборудования по следующим параметрам:

    IMSI (International Mobile Subscriber Identity, индивидуальный номер абонента) — для идентификации
    • абонента;
    • ключи, хранящаяся на SIM-карте – для аутентификации абонента;
    • проверка доступных абоненту сервисов (Internet, MMS, WAP) по записи в базе абонентов
    .
    Может также проверяться IMEI (International Mobile Equipment Identity — международный идентификатор мобильного оборудования). Этот идентификатор может использоваться для проверки по спискам краденого оборудования, и если конкретный IMEI находится в списке украденных, то в доступе к сети может быть отказано, либо даже сообщено «куда следует» :)

    После успешного завершения процедуры GPRS Attach начинается процедура PDP (Packet Data Protocol) Context Activation. Чтобы разобраться в этой процедуре, отвлечемся и определим некоторые понятия.
    SGSN (Serving GPRS Support Node, узел обслуживания абонентов GPRS) — устройство, реализующее основные функции обработки пакетных данных в мобильной сети.

    GGSN (GPRS Gateway Service Node, шлюзовой узел GPRS) — устройство, обеспечивающее передачу данных из сети оператора во внешние сети (например, в интернет). По сути может быть обычным маршрутизатором с поддержкой некоторых специфических функций.

    GTP (GPRS Tunneling Protocol) — стек протоколов, используемый в GPRS-, UMTS- и LTE-сетях.
    Итак, PDP Context Activation (схема сильно упрощена).



    Что же происходит при реализации этой схемы?

    1. Телефон отправляет запрос активации контекста на SGSN, в котором, в числе прочего, присутствуют логин, пароль и APN.
    2. SGSN, получив APN, пытается разрешить его на внутреннем DNS-сервере. Сервер разрешает предоставленный APN и возвращает адрес отвечающего за данный APN GGSN.
    3. По этому адресу SGSN отсылает запрос на создание PDP-контекста.
    4. GGSN проверяет на RADIUS-сервере предоставленные логин и пароль.
    5. Затем получает IP-адрес для нашего телефона.
    6. И всю необходимую для активации PDP-контекста информацию передает обратно на SGSN.
    7. SGSN завершает процедуру активации, отсылая на телефон данные, необходимые для установления соединения.

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

    Роуминг


    Немедленно возникает вопрос: как же это все работает в роуминге? Оказывается, что существует специальная сеть: GRX (Global Roaming Exchange) — сеть для обмена пакетными данными роуминговых абонентов мобильных сетей. Через нее и «бегает» весь наш трафик. Примерно вот так:



    1. Успешно доехав в теплые края, мы решили скачать любимый сериал. Включили телефон, начали подключаться к интернету (отправляем логин, пароль, APN).
    2. Зарубежный SGSN пытается разрешить предоставленный нами APN на своем DNS-сервере.
    3. DNS-сервер, не найдя у себя подобных записей, обращается к корневому DNS-серверу, который находится в GRX-сети.
    4. Корневой DNS-сервер направляет запрос к DNS-серверу в сети нашего родного оператора.
    5. Тот в свою очередь отвечает ему адресом нашего GGSN.
    6. Корневой DNS сообщает этот адрес DNS-серверу зарубежного оператора.
    7. Который в свою очередь сообщает этот адрес зарубежному SGSN.
    8. SGSN, зная адрес GGSN, направляет ему запрос на активацию PDP-контекста.
    9. GGSN, если соблюдены все условия (есть деньги на счету, указаны верные логин и пароль и т. д.), присылает подтверждение, SGSN его принимает и пересылает нашему телефону подтверждение на доступ в интернет.

    Что же мы видим? Видим мы, что пакеты с нашим любимым сериалом бегут через полмира от нашего оператора к оператору в теплой стране. Бегут они по специальной сети, завернутые в протокол GTP. И все переговоры между спецжелезками операторов ведутся по тому же GTP.

    И тут приходит идея: а не попробовать ли нам сообразить нечто подобное в лабораторных условиях? Построить свои SGSN и GGSN. А ну как придем к невероятным открытиям?

    SGSN + GGSN на коленке




    После длительных поисков выяснилось следующее.

    Существует ПО специального назначения, реализующее некоторые функции SGSN. Выглядит оно как скрипт под Linux, который способен эмулировать все необходимые процедуры (GPRS Attach и PDP Context Activation) и выдать в итоге готовый интерфейс для выхода в интернет, как будто бы мы воткнули 3G-модем. Узнав об этом, мы немедленно кинулись искать устройство, готовое взвалить на свои плечи функции GGSN. Оказалось, что популярный маршрутизатор Cisco 7200 вполне подходит.

    После недолгих манипуляций, настроек и тестов нас ждал успех.



    Стенд легко поднимал туннели, через которые был «виден» самый настоящий интернет. Мы тут же принялись смотреть, какие же пакеты ходят между нашими могучими SGSN и GGSN. Похожи ли они на настоящие? С замиранием сердца открываем дамп — и таки да! пакеты как настоящие.



    Аналогичные пакеты могут ходить в GRX-сети, и их вполне может подслушать злобный хакер. Что же он там увидит? Попробуем разузнать.

    Вопросы безопасности


    Протокол GTP бывает нескольких типов: GTP-U используется для непосредственной упаковки и передачи пользовательских данных, GTP-C для управления сессиями (именно с его помощью осуществляется процедура PDP Context Activation и прочие служебные процедуры); существует еще GTP’ (GTP Prime) — он используется для передачи биллинговой информации. GTP не поддерживает аутентификацию пиров и шифрование, работает поверх UDP. Что во всем этом интересного? Интересно тут практически все!

    Возьмем GTP-U и посмотрим, как выглядит туннель с пользовательскими данными. Туннели разделены параметром TEID (Tunnel Endpoint Identificator).



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

    А вот GTP-C. С удивлением обнаружив отсутствие какой-либо аутентификации или намеков на шифрование передаваемых данных, можно попробовать не только послушать, но и, извините, что-нибудь послать. Например «левые» запросы на установление или разрыв сессии.

    Попробуем таким образом наметить векторы возможных атак и рассмотрим их поближе.



    Вот, например, атака DNS flood. Злоумышленник отправляет большое количество запросов на разрешение APN нашего оператора. Все эти пакеты будут бомбардировать бедный операторский DNS, который не выдержит накала и вообще откажется передавать адрес GGSN кому-либо, вызывая глобальный DoS для абонентов.



    Или злоумышленник начнет отправлять собственноручно сформированные запросы на создание PDP-контекста. GGSN, увидев такой напор, вполне может и задуматься, а то и вовсе зависнуть. Что опять же приведет к отказу в обслуживании абонентов.

    А что, если попробовать вместо запросов на создание отправлять запросы на разрыв сессии?

    Например, вот так:



    Злобный хакер, подставляя адрес зарубежного SGSN, будет отсылать запросы на разрыв соединения. GGSN, подумав, что абонент докачал свой любимый сериал и хочет завершить интернет-сессию, удаляет у себя этот туннель, разрывая соединение.

    Набросав несколько векторов, обратим свой взор на реальные объекты, чтобы все это «потрогать». Наберем запрос «GGSN» в shodan. Вот кусок выданных результатов.



    Все это смахивает на реальные GGSN, выставленные в интернет.

    Или попробуем написать скрипт, посылающий запросы GTP-echo, да и пустить его гулять по интернету: вдруг кто откликнется. И откликающиеся находятся:



    Иногда даже с открытым telnet.



    В стандарте нового поколения под кодовым именем LTE все так же используется протокол GTP, а посему все вышеописанное актуально и будет актуальным в обозримом будущем.

    На сегодня все. До новых встреч!

    Хочу выразить благодарность отделу анализа безопасности сетевых устройств Positive Technologies за помощь в подготовке материала.

    Автор: Илья Сафронов, Positive Research.

    Comments 16

      +2
      Больше интересно, нельзя ли подняв так свой сервер получить нетарифицируемый доступ к мобильному интернету.
        +1
        Помнится, в начале нулевых ходил слух что если выставить APN на <secret.domain.ru> то трафик будет в 10 раз дешевле.
          0
          На сколько я помню, это была просто замена шлюза WAP на шлюз GPRS, который стоил как раз в ~10 раз дешевле(во всяком случае, в Украине).
          +1
          да, dns-тоннель. медленно, нудно, но бесплатно как правило, т.к. некоторые операторы не берут плату за днс-трафик code.kryo.se/iodine/ кто именно — надо опытным путём узнавать.
            0
            Правильные днс-сервера не позволят такой наглости :)
            0
            Нет. Оператор все равно траффик сосчитает.
            А еще не пустят на днс сервер вписать свой apn
              0
              А еще не пустят на днс сервер вписать свой apn
              А если я в качестве APN IP-адрес впишу?
                0
                APN всегда задается в формате internet.operator.ru.mncXXX.mccXXX.gprs, так называемый FQDN — fully qualified domain name, она (APN) не может быть IP адресом.
                  0
                  Еще вопрос
                  Если вспомнить то в настройках apn выглядит как просто internet
                  То откуда взять домен 1 и 2 уровня для него для обращения из вне (из роуминга)?

                  И тем более оставшиеся mcnXXX.mccXXX
                    +1
                    Оператор волен создавать любые APN (то, что идет до mncXXX.mccXXX.gprs), в том числе и просто internet, просто если брать на примере МТС или Билайн, то у себя в телефоне вы будете указывать internet.mts.ru и internet.beeline.ru, но возможны любые варианты.

                    Параметры MCC (Mobile Country Code, для России =250) и MNC (Mobile Network Code, для МТС =001, для Билайна = 099) являются частью уникального идентификатора абонента — IMSI и закреплены за СИМ-картой, т.е. IMSI начинается с таких цифр:

                    25001xxxxx или 25099xxxxxx

                    Поэтому, когда в роуминге начинается процесс GPRS Attach, абонент передает IMSI SGSNу роумингового партнера, который из нее берет параметры MNC и MCC и определяет, по своей таблице маршрутизации в протоколе SS7, куда отправить запрос к домашнему HLR абонента, где будет производиться его авторизация и аутенфикация, а далее начинается процесс PDP Context Activation, как и описано в статье. Т.е. SGSN берет APN из запроса абонента (например, internet.mts.ru), прибавляет к нему параметры MNC и MCC ( например mnc001.mcc250.gprs) и отправляет запрос в DNS для резолва имени APN в IP адрес GGSNа, который обслуживает данную APN.

                    В кратце, это выглядит так :)

                      0
                      Спасибо, теперь стало понятно.

                      А для мегафона точно настройки apn были именно internet, да и сейчас такой
              +1
              Хардкорная статья, спасибо.
                +2
                Пожалуйста!
                +3
                На практике наличие логина и пароля не является необходимым условием. В свою пакетную сеть оператор пускает только заведомо валидных клиентов, уже прошедших авторизацию в канальной сети. И даже правильный APN частенько не нужен, большинство российских сетей отрабатывают «неправильные» APN и выпускают абонента в сеть. Правда, часто за неправильный APN абонент платит больше денег, ОПСОСы такие ОПСОСы…
                Так же, процедура авторизации на AAA не используется, только accounting сообщения. В целом, и они не нужны для выхода в мир, но ААА как правило, есть, и используется для дополнительных услуг на пакетной сети (MMS, Premium rate content, всякие там мобильные балансы, автозаход в личный кабинет и т.д.)
                По поводу «голой ыпож» GRX в мире. Скриншот с несколькими ZTE девайсами в китае конечно умиляет. Не буду писать про конкурентов… Один хуавеевский NE40 в колумбии… Тоже намекает на уровень колумбийских операторов.
                Нормальные операторы не суют GRX без криптованных тунелей в мир.
                  0
                  Основной вопрос каким образом будет разрешен доступ к GRX? т.к. просто «прикинуться» оператором там вряд ли выйдет, к тому же шифрование между транзитными нодами тоже никто не отменял. Как по мне описанные атаки являются чисто теоретическими.
                    +1
                    Авторам — спасибо за статью!

                    Несколько дополнений:

                    1. При аутенфикации и авторизации абонента в процессе GPRS Attach, SGSN обращается к HLR (устройству в мобильных сетях, где хранится вся информация об абоненте) через Gr интерфейс, используя стек протоколов SS7

                    2. В процессе активации PDP контекста редко используется внешний DHCP сервер, в подавляющем большинстве, используется local-pool адресов APN самого GGSN

                    3. GTP-C протокол имеет механизм защиты от вторжения в сессию — существует поле Recovery, значение которого выбирается на этапе активация PDP контекста (Create PDP context request <-> Create PDP context response), если SGSN или GGSN получат сообщение GTP-C протокола, со значением Recovery поля отличного от согласованного раннее, они инициируют удаление PDP контекста для абонента в целях безопасности

                    Only users with full accounts can post comments. Log in, please.