Как стать автором
Обновить

Комментарии 10

Заголовок слегка кликбейтный, уж извините.

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

А есть примеры?

Теперь уже можно сказать: такой взлом считался практически невозможным

Кем и когда он считался? В статье правильно написано — если создается канал от железки до железки, вполне логично предполагать, что удаленная железка может быть уязвима, что взломщики и продемонстрировали.

Сетевые инженеры, устанавливавшие и эксплуатировавшие платформу RBT, не уделили должного внимания ее безопасности, считая, видимо, что она находится во внутреннем периметре оператора.

Платформа RBT была вторым шагом, первым — GGSN или PGW (совершенно непонятно, что именно). Виновны во взломе не те, кто эксплуатировал RBT, а те, кто сделал GGSN/PGW c дырой.

Из статьи совершенно непонятно, зачем им было нужно «опенсорсное программное обеспечение для генерации сигнального траффика»? Там какой-то вдребезги урезанный линукс был, что ни список процессов не посмотреть, ни конфигурацию открыть, ни проверить, куда стоят SCTP-ассоциации? Можно сдампать CAP/INAP траффик опять же. У тебя рут, ты сервер можешь хоть в узел завязать, он не будет против.

Ну и да, если бы они ломали какой-нибудь ePDG, то можно было бы написать, что «нынче возможен взлом сотового оператора over WiFi». Потому, что радиоинтерфейс в данном случае — это всего лишь навсего канал.
А есть примеры?

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

Кем и когда он считался? В статье правильно написано — если создается канал от железки до железки, вполне логично предполагать, что удаленная железка может быть уязвима, что взломщики и продемонстрировали.

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

Из статьи совершенно непонятно, зачем им было нужно «опенсорсное программное обеспечение для генерации сигнального траффика»?

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

Допустим.

Операторами, т.к. они всегда утверждают что сегмент пользователей изолирован

Ау, дефолтные пароли на смотрящем во внешний мир GGSN, какая «изоляция сегмента пользователей»? Это даже не использование эксплойта, это адовая криворукость эксплуататоров железки!

. В данном случае канала от железки до железки быть не должно.

«Когда абонент подключается к мобильному интернету, его IP-сессия туннелируется от абонентского устройства, будь то смартфон, планшет или компьютер, подключенный через модем, до узла GGSN (в случае 2G/3G-сети) или до узла PGW (в случае LTE-сети). Когда пакетную сессию устанавливает злоумышленник, он может провести сканирование пограничного узла с целью поиска уязвимостей, найдя и проэксплуатировав которые он способен проникнуть глубже в опорную IP-сеть оператора.» (С)

Не будет канала — не будет пакетной сессии.

Для осуществления атак SS7 необходимо крафтить пакеты и направлять их на определенные сетевые элементы.

«С помощью этого ПО они просканировали внутреннюю сигнальную сеть и получили адреса сетевого окружения — HLR и MSC/VLR.»

Если доподлинно известно, что сетевой элемент взаимодействует с другим сетевым элементом, необязательно что-то там «сканировать», можно посмотреть конфигурацию используемого ПО и проанализировать входящий/исходящий траффик, в данном случае — протоколы стека SIGTRAN. Все равно все едет по SCTP, смотрим, куда стоят ассоциации, какие там в траффике Global Title-ы, и какие сообщения… исходя из сообщений, можно понять, где там регистры, а где коммутатор. А вот уже потом, зная все это, можно начинать крафтить пакетики для атаки.

p.s. почему MSC/VLR? Это две очень разные сущности.

В каких ss7 протоколах использовались дыры для попадания в граничный элемент? или GGSN входил в APN IP pool? не совсем

Судя по всему, криво IP сеть была настроена, в следствии чего они смогли просканировать GGSN или PGW и найти в нем уязвимость, опять же, связанную не с ss7, а скорее всего какую-то линуксовую/юниксовую.
Доступный SSH с дефолтным логином/паролем, отсутствие изоляции пользовательского сегмента.

Отсутствие изоляции пользовательского сегмента на GGSN — это нужно очень уж ухитриться. В таком случае про любую систему безопасности можно сказать, что она не гарантирует 100% защиты, потому что ее всегда может кто-то криво настроить. Человеческий фактор.

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

Что за уязвимости?
Самое интересное, как раз, как ломали GGSN/PGW. Невидимость GW для трафика клиентов, это одно из базовых требований, обычно его проверяют при каждой новой интеграции. А когда есть доступ к мобильной коре, то дальше можно делать все что угодно.
Самое интересное, как раз, как ломали GGSN/PGW.

Дефолтные пароли, открытый SSH. Это не взлом, это зашли в открытую настежь дверь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий