Есть два типа операций в SS7, друг мой: безобидные... и те, что держат револьвер...

... Это, конечно, утрирование. Однако, как и герои спагетти-вестернов, операции в SS7 предстают перед нами в полном своем разнообразии и глубине, и иногда их сложно распарсить, а главное - обработать безопасно для абонента. Неверная обработка операций (команд) в SS7 (они же PDUs), несет за собой серьезные риски и потенциально может привести к угрозам уровня уязвимостей нулевого дня, открывая широкий спектр возможных атак.

За пригоршню эксплойтов

За последние несколько лет появилось несколько типов атак SS7 направленных на обход новых защитных механизмов и правил постепенно реализуемых на сети. Будучи не частым явлением на сети, новые типы таких атак возникают с завидной регулярностью, чего и следует ожидать от злоумышленников, спонсируемых как раз за разработку новых способов обхода защиты. Ниже приведена сводная таблица новых типов атак, зафиксированных за последние годы

Атаки направленные на обход защиты в SS7, зафиксированные с 2017 года
Имя/тип атаки	Уровень (протокол)	Первое объявление об обнаружении	Обнаружение в реальных условиях
Global Opcode	TCAP	Positive Technologies: HITB AMS SecConf- Май 2019	Середина 2019
Расширенный Application Context	TCAP	Enea: GSMA FASG Intelligence Report - Ноябрь 2022	Начало 2022
Удлиненный TCAP ID	TCAP	Symsoft/P1Sec: Webinar – Октябрь 2018	Середина 2022
Отсутствующий/неверный CdPA SSN	SCCP	Enea: GSMA FASG Intelligence Report – Ноябрь 2022	Начало/Середина 2023

Большинство перечисленных выше атак возникают на уровне протокола TCAP, который является частью стека SS7. Этот уровень в стеке превратился в привлекательную область для атак из-за своей истории, природы и, самое главное, структуры. Первая зафиксированная атака, использовавшая необычную технику кодирования внутри TCAP, была методом, известным как Global OpCode Encoding, обнаруженным и описанным в 2019 году. С тех пор множество новых методов и атак были обнаружены и публично представлены. Цель всех этих приёмов - попытаться обойти усиливающиеся методы защиты, которые мобильные операторы вводят в свои сигнальные сети. В последние месяцы подразделение Threat Intelligence Enea обнаружило новый вариант манипуляции TCAP, который вписывается в эту тенденцию эксплуатации.

Каждый байт на счету

Немного справочной информации. TCAP (Transaction Capabilities Application Part) - это уровень стека SS7, который переносит прикладные данные между узлами. Он кодируется в ASN.1 BER (Basic Encoding Rules), согласно ряду рекомендаций ITU.

Нотация ASN.1 была стандартизирована в 1984 году и является способом представления абстрактных объектов данных, широко используемым в отраслях, где необходимы «эффективные (низкая пропускная способность, низкая стоимость транзакции) компьютерные коммуникации». ASN.1 BER - это конкретный набор правил кодирования объектов ASN.1 и выделяется уровнем свободы в том, как эти объекты могут быть закодированы, в частности, объекты могут кодироваться более чем одним способом.

Это отличается от других правил кодирования ASN.1, таких как DER (Direct Encoding Rules), где существует только один допустимый способ кодирования объектов. С точки зрения безопасности, сочетание сложности (из-за требования к эффективности) и гибкости структуры делает этот уровень естественным выбором для атакующих, ищущих эксплойты кодирования, как показывает недавняя история атак, использующих TCAP.

Принцип всех методик некорректного кодирования TCAP одинаков: сформировать PDU неожиданным и, в некоторых случаях, легальным образом и надеяться, что такой PDU или часть его содержимого не будут декодированы защитными системами или фаерволом в целевой сети, что приведёт к обходу защиты.

Держи глаз на проводе, партнёр

Чтобы объяснить новый метод искажения TCAP, который был обнаружен нами в реальной сети, нужно коротко пройтись по тому, как именно строятся TCAP сообщения в ASN.1 BER. Строительными блоками TCAP являются Информационные Элементы (Information Elements, IE), которые всегда имеют три поля, появляющихся строго в таком порядке:

Тэг - он отличает один тип от другого и управляет интерпретацией значения.
Длина - указывает на длину содержимого значения.
Значение - это суть элемента, несущая основную информацию, которую элемент должен передать.

Структура типичного TCAP сообщения и его "Информационного элемента"

TCAP Information Elements можно разделить на два типа: Примитивные (Primitive) и Вложенные (Constructor). Отличие в том, что содержимое примитивных - это одно значение, тогда как у вложенных содержимое состоит из одного или нескольких IE (которые, в свою очередь, могут быть содержать другие вложенные IE и так далее).

Примитивные и вложенные "Информационные элементы"

Сочетая эти понятия, полное TCAP сообщение может состоять из множества разных частей. Ниже приведена детализированная структура типичного TCAP сообщения взятая из ITU Q.773.

Детализированная структура TCAP сообщения

Как показано на изображении выше, есть три именованные части: Транзакция, Диалоговая часть и Компонента. Мы не будем подробно разбирать все их функции здесь, но те части, которые нас интересуют сегодня - это наиболее вложенные IE, то есть компоненты вложенные в саму Компоненту. Эти части могут содержать информацию для различных уровней стека SS7, которые находятся выше TCAP - в данном случае это GSM-MAP. Одна из самых важных TCAP компонент называется Invoke - это операция, используемая для инициирования обработки в принимающем TCAP узле.

Таблица компонент для Invoke сообщения, согласно ITU Q.773

Его структура показана выше, и как видно, состоит из Вложенного IE, а затем ряда других Примитивных/Вложенных IE. Именно здесь, в кодировании одного из представленных выше Параметров, атакующие и расставили свои сети.

Человек без IMSI

Последний из обнаруженных нами аномальных способов кодирования TCAP фокусируется конкретно на кодировании определённого IE внутри компоненты Invoke.

По нашим наблюдениям, изменения атакующих затронули кодирование IE, содержащего поле IMSI - идентификатор пользователя, внутри операции PSI (ProvideSubscriberInfo). PSI - это команда GSM-MAP, инкапсулированная в TCAP. В злонамеренных целях она может использоваться для отслеживания местоположения, запрашивая у узла сети, получившего это сообщение, информацию о местоположении целевого абонента. Критическая часть операции PSI - это содержащееся в нем поле IMSI, поскольку это буквально цель слежки. Нормальная PSI компонента Invoke, содержащая IMSI, должна кодироваться следующим образом:

Это выглядит крайне запутанно для неподготовленного читателя, поэтому давайте разберём визуально.

Разбор TCAP компоненты включающей в себя атаку

Здесь много всего, что достойно отдельного объяснения, но в целом читатель может увидеть и сложность, и вариативность кодирования. Поля сами по себе просты, когда знаешь формат. По дампу можно понять, что представлена операция ProvideSubscriberInformation для конкретного IMSI, который мы в примере заменили на ряд FF, а информация, запрошенная в данной операции, включает в себя данные о местоположении, состоянии абонента (включён/выключен и т.д.) и его IMEI (International Mobile Equipment Identity).

Вроде бы, пока все в рамках нормы, однако мы наблюдали PSI-команды, закодированные следующим образом:

Визуально, если сравнить эту строку с предыдущей, внимательный читатель заметит, что она длиннее на один октет. В результате
чего некоторые поля имеют другую длину. В чём же разница? Оказывается, самое главное различие - в кодировании IMSI.

Обычно начало Вложенного IE (Constructor), содержащего IMSI, кодируется как: 30 12 80 08. Разберём это:

Октет	H G F E D C B A	Объяснение
30	0 0 1 1 0 0 0 0	Вложенный Тэг (Constructor) с универсальным кодированием (биты F и E = 1)
12		Длина оставшегося PDU (Тэг + IMSI + requestedInfo)
80	1 0 0 0 0 0 0 0	Примитивный (Primitive) Контекстуальный (Context-Specific) Тэг. Т. к. биты A - E в 0, то код тэга задается единственным октетом и равен 0
08		Длина IMSI

То, что мы наблюдали от атакующего, - это следующая последовательность: 30 13 9f 00 08. По сути, атакующий использует
малоизвестную технику расширения Тэга, который содержит IMSI:

Октет	H G F E D C B A	Объяснение
30	0 0 1 1 0 0 0 0	Вложенный Тэг с универсальным кодированием (биты F и E = 1)
13		Длина оставшегося PDU (Тэг + IMSI + requestedInfo)
9f	1 0 0 1 1 1 1 1	Примитивный Контекстуальный Тэг. Механизм расширения тэга при нехватке длины заключается в кодировании бит A - E в 1. Бит H, в таком случае, служит как индикация следующего расщирения тэга
00	0 0 0 0 0 0 0 0	Код тэга хранится в октетах A - G и равен 0. Бит H равный 0 означает, что далее расширений тэга нет
08		Длина IMSI

За несколько октетов больше

В этот момент у читателя может возникнуть сомнения по поводу происходящего, но если копнуть глубже, некоторые проблемы с ASN.1 BER становятся очевидными. Оказывается, существует способ расширить код Тэга в TCAP IE. Как объясняется в ITU Q.773, биты A – E первого октета Тэга обычно представляют код Тэга, так что коды Тэгов в диапазоне 00000 до 11110 (0 – 30 десятерично) могут быть представлены в одном октете. Но что если нужен код Тэга больше 30?

В этом случае спецификация TCAP описывает метод, когда если вы кодируете биты A – E как 11111, что указывает на то, что код Тэга расширяется на последующие октеты. А следующие октеты затем могут указывать, продолжается ли расширение, выставляя бит H как 0 или нет, в качестве индикатора продолжения. Если бит H расширяющего октета установлен в 0, то дополнительных октетов для этого тэга не ожидается.

Структура кодов тэга, согласно ITU Q.773

Полные детали механизма расширения описаны в разделе 4.1.2.23 ITU Q.773, но в нашем случае следующий октет равен 0, никакие биты не установлены, и дополнительных октетов для этого тэга не ожидается.

Если собираешься стрелять - стреляй. Не говори.

Итак, в чём вообще смысл того, что атакующие используют странный способ кодирования конкретного поля в конкретном пакете? Как уже говорилось, эта конкретная операция - PSI, широко используется для отслеживания местоположения. Мобильные операторы вполне законно используют его для своих абонентов, которые могут находиться в роуминге, для биллинга и управления передвижениями по сети, но пользоваться им должны только сами операторы.

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

Проще говоря, если источник не является домашней сетью, а IMSI принадлежит домашней сети, то PSI должен быть заблокирован. То, как именно делается эта блокировка, может различаться, но обычно это осуществляется через правила на фаерволе и другие проверки как можно ближе к границе сигнальной сети.

Если кодирование IMSI специально изменено, например расширением тэга, то средство защиты, которое полагается на корректное распознавание IMSI в ожидаемом формате, может не распознать его и, соответственно, не выполнить блокировку. Именно этого и добиваются атакующие: они формируют PDU так, чтобы защитные механизмы не сумели извлечь IMSI и решить, нужно ли блокировать запрос.

Как на этом зарабатывают злоумышленники

А теперь практическая сторона: зачем всё это атакующим? PSI часто используется для определения геолокации абонента. Запрос PSI, где в поле IMSI указан целевой абонент, заставляет сеть отправить ответ с местоположением этого абонента. Если злоумышленник может заставить свой PSI запрос пройти через защитные механизмы операторов, то он сможет получать местоположение абонента, не являясь легитимной домашней сетью этого абонента.

Это имеет очевидные последствия для приватности и безопасности пользователей и может использоваться в преступных целях: слежка, шантаж, планирование физического ущерба и т.д. Кроме того, подобные техники обхода могут быть использованы и для других типов команд, не только для PSI, расширяя арсенал атак, доступных злоумышленникам.

Последствия для операторов

Что это значит для операторов мобильной связи? Во-первых, что защита, основанная на предположении о «правильном» кодировании TCAP/ASN.1, уязвима. Свободная природа BER кодирования даёт пространство для легального кодирования, которое может обойти простые правила фильтрации. Поэтому операторы и поставщики защитного программного обеспечения должны предполагать, что атакующие будут экспериментировать с легальными, но неожиданными формами кодирования.

Во-вторых, защита должна переходить от простых строковых или бинарных проверок и опираться на глубокую декодирующую логику, которая действительно понимает ASN.1 BER и все допустимые вариации кодирования, а не просто ищет «ожидаемое» положение IMSI в байтовом потоке. Это значит более строгую, семантически ориентированную проверку, способную корректно распознать расширенные тэги и другие легальные, но неожиданные формы кодирования.

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

Операторам стоит подходить к защитным системам сигнального уровня с учётом того, что злоумышленники не будут довольствоваться очевидными трюками: они будут исследовать каждую возможность кодирования, которая позволяет обойти фильтры. Это требует более глубокого декодирования и анализа пакетов, а также постоянного обмена информацией об обнаруженных атаках и обновления механизмов защиты.

Хороший, Плохой, Расширенный: SS7 атака с использованием расширенных тэгов