Статья Атаки на VoIP: подмена Caller ID

Если ты читаешь это, значит, ты уже достаточно долго крутишься в этой вселенной нулей и единиц, чтобы испытывать не просто любопытство, а стойкое, глубокое раздражение. Раздражение от лицемерия. От того, как устроен этот цифровой мир. Ты видишь красивую картинку - «защищённое соединение», «верифицированный номер», «технология блокировки спама». А потом смотришь под капот и видишь там скрепки, изоленту и табличку с надписью «НЕ ТРОГАТЬ, А ТО РАЗВАЛИТСЯ».

Ты, наверное, устал от двух типов «экспертов». Первые - паникёры из ящика, которые с дрожью в голосе рассказывают про «злобных хакеров», обманувших бабушку, но ни на миллиметр не погружаются в суть. Вторые - унылые технари с корпоративных воркшопов, сыплющие аббревиатурами вроде SIP, SS7, STIR/SHAKEN, но сводящие всё к скучным compliance-чеклистам. И те, и другие говорят о проблеме, но ни черта не говорят о системе, которая эту проблему порождает и пестует.

Мы не белые шляпы, продающие аудиты за бешеные деньги. Мы не чёрные шляпы, торгующиеся на чёрных рынках. Мы - те, кто смотрит на механизм. Нам интересно не «как украсть», а «как это СДЕЛАНО». Почему оно ломается? Где тут фундаментальный раскол между теорией безопасности и практикой эксплуатации?.

Мы будем говорить об эксплуатации архитектурного доверия. О том, что Caller ID Spoofing - это не взлом замка. Это ситуация, где дверь вообще не имеет замка, а есть только табличка «ПРОХОДИТЕ, ТОЛЬКО СВОИ». И вся игра заключается в том, чтобы понять, кто в этой системе считается «своим», и как под это подстроиться.

Ты и я - мы из того теста, для которого «потому что так работает» - не ответ. Это - вызов. Нам нужно дойти до корня, до самой первой строчки RFC, до первого решения инженера тридцатилетней давности, который выбирал между сложной криптографической аутентификацией каждого пакета и простой, быстрой передачей данных, чтобы всё «просто работало». Мы знаем, какой выбор он сделал. И теперь мы пожинаем плоды.

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

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

Это - мануал, справочник, исповедь. Это для тех, кто готов потратить вечер, чтобы наконец сложить пазл. Чтобы в следующий раз, услышав звонок с «номером банка», ты видел за ним не злобного хакера в капюшоне, а целую экосистему: твой SIP-провайдера, трёх транзитных операторов где-нибудь в Нидерландах, устаревшую сигнализацию SS7, жаждущего заработать агрегатора и слепое доверие твоего собственного телефона, который отображает то, что ему приказали.

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

Часть 1: Исторический глюк, или Почему мир построен на доверии к незнакомцу. Или «Как мы пришли к тому, что входящий звонок - это просто текстовое поле в UDP-пакете».​

Нужно вернуться в начало. Не на пять лет назад, а на полвека. В мир, где телефон был не приложением в смартфоне, а тяжёлой черной тушкой из бакелита, привинченной к стене. Мир PSTN (Public Switched Telephone Network) – публичной коммутируемой телефонной сети.

Представь себе огромную, идеально отлаженную механическую вселенную. «Закрытая система» – это ключевое слово. От твоего аппарата до междугородной станции тянулись медные пары, принадлежащие одному хозяину – обычно государственному монополисту (в Штатах – Bell System, у нас – МГТС). Сигнал управления звонком – куда звоним, кто звонит – передавался не в самом голосовом тракте, а по отдельным, служебным каналам сигнализации. Сначала это были банальные импульсы набора номера, потом – тоновые сигналы (DTMF), а для связи между станциями появились целые протоколы вроде SS7 (Signaling System No. 7).

SS7 – это нервная система старой телефонии. Отдельная, физически или логически выделенная сеть, по которой станции обмениваются сообщениями: «Привет, я станция А, хочу соединить абонента 123 с абонентом 456 на станции Б», «Соединение установлено», «Абонент положил трубку». В одном из таких служебных сообщений передавался и CLI (Calling Line Identification) – номер вызывающего абонента.

Первое и главное архитектурное решение, определившее будущее: в SS7 не было встроенной сквозной аутентификации и криптографии. Безопасность основывалась на физической и административной изоляции. Предполагалось, что если сообщение пришло по выделенному каналу от сопряжённой станции известного оператора, то ему можно доверять. Точка. Подменить CLI на уровне SS7, не имея физического доступа к этой закрытой сети оператора, было практически невозможно. Безопасность через обскурантизм. И она работала… пока система была маленьким, частным клубом.

А потом мир стал больше. Появились десятки операторов междугородной и международной связи. Появился peering – соглашения о взаимном обмене трафиком. И тут родился грех №1: доверие на уровне сетевых границ.

Крупный оператор «А» звонит оператору «Б» и говорит (через SS7): «Эй, у меня тут вызов от номера +74951234567 к твоему абоненту +74957654321». Оператор «Б» видел, что сообщение пришло от легитимного партнёра «А». У него не было ни механизма, ни, что важнее, бизнес-стимула проверять, а действительно ли этот вызов инициировал абонент с номером +74951234567. Может, это оператор «А» сам сгенерировал вызов? Или его кто-то взломал? Гипотеза не рассматривалась. Доверие было абсолютизировано. CLI стало не проверяемым фактом, а декларацией, которую один оператор принимал на слово от другого.

Теперь впрыгиваем в 90-е. Интернет взрывается. Голос поверх IP (VoIP) кажется святой Граалью: дёшево, гибко, не привязано к физическим линиям. Инженеры, опьянённые духом открытости и децентрализации RFC, создают протоколы. Главный из них для сигнализации – SIP (Session Initiation Protocol, RFC 3261 и куча дополнений).

SIP – дитя своего времени. Он создавался по образу и подобию HTTP – простого, текстового, расширяемого протокола. Посмотри на это:

HTTP-запрос:

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
From: user@mail.com

SIP-запрос (INVITE):

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: "Алиса" <sip:alice@atlanta.com>;tag=1928301774
To: <sip:bob@biloxi.com>
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: ...

Видишь сходство? From:, To:, Call-ID: – это просто заголовки. Как From: в email или User-Agent: в HTTP. Грех №2, фундаментальный и роковой: SIP был спроектирован для гибкости и функциональности, а не для аутентификации содержимого заголовков. Поле From: – это не проверенная учётная запись, а декларация отправителя. Твой софтфон или SIP-сервер спокойно позволит тебе написать там sip:god@heaven.org.

«Но погоди, – скажешь ты. – Неужели они были настолько наивны?» Не совсем. В SIP есть механизмы аутентификации, например, HTTP Digest Authentication (как в вебе). Когда ты регистрируешься на сервере провайдера, ты доказываешь, что ты – это sip:myrealnumber@provider.com. Но эта аутентификация привязана к сеансу регистрации или к конкретному запросу (например, INVITE). Она подтверждает, что «отправитель этого пакета имеет право пользоваться учётной записью X». Однако, ничто в протоколе не мешает авторизованному отправителю заявить в поле From: что он - кем угодно. Как если бы ты, имея паспорт на имя Иванова, при отправке письма мог в графе «обратный адрес» написать «Кремль, кабинет Путина». Почта-то письмо примет, если марки хватит.

И вот здесь мы подходим к самому сочному противоречию, к сердцевине лицемерия всей современной телефонии.

Провайдеры, операторы - они же не идиоты. Они знают об этой дыре. И многие из них на исходящих вызовах применяют нормализацию (исправление) поля From:. То есть, если ты авторизовался как sip:myreal@operator.com, то какой бы From: ты ни указал, твой оператор заменит его на твой реальный номер (+7495...) перед тем, как отправить вызов в мир. Проблема в трёх вещах:

1. Экономика: Нормализация - это дополнительные вычисления, логика. Дешёвые, «серые» операторы-агрегаторы, которые живут на том, чтобы продавать тонны минут максимально дёшево, этого не делают. Их бизнес-модель - «подключись к нам и шли что хочешь, мы просто перешлём». Они - рассадник. И они востребованы не только мошенниками, но и легальным бизнесом вроде кол-центров, которым нужно звонить «с местного номера» в другой стране. Дешевизна и удобство победили безопасность на рынке.
2. Легальные случаи спуфинга (да, они есть!):
   • Колл-центры и облачные АТС. Компания в Москве хочет, чтобы на телефоне клиента в Нью-Йорке светился местный американский номер. Их VoIP-оператор (уже легальный) как раз и подменяет российский номер на американский в поле From: или добавляет P-Asserted-Identity:. Это легальный спуфинг по договорённости с оператором.
   • Экстренные службы. При звонке с IP-АТС в службу 112 нужно передать реальный географический номер, а не внутренний короткий.
   • Услуги конфиденциальности. Некоторые операторы предлагают услугу скрытия или подмены номера для конкретного вызова (в России - «антиАОН»).
     Вот и получается, что технический механизм спуфинга - это легальная, платная фича для одних и дыра для других. Попробуй-ка отличить на уровне пакета «легальный» спуфинг колл-центра от «нелегального» спуфинга мошенника. Почти невозможно.
3. Наследие SS7: SIP не живёт в вакууме. Он стыкуется со старой PSTN через шлюзы. И что происходит? SIP-запрос с полем From: +74951234567 преобразуется в SS7-сообщение с CLI +74951234567. И это сообщение попадает в старую сеть, которая слепо доверяет CLI из SS7, потому что исторически он приходил только от «своих». Дыра из нового мира перетекает в старый, усиливаясь его слепым доверием.

Итог первой части, фундаментальный вывод:

Caller ID Spoofing - это не «взлом». Это - закономерное, системное следствие архитектурных решений, принятых десятилетия назад.

1. SS7 заложил слепое доверие между операторами.
2. SIP, как дитя открытого интернета, сделал идентификатор открытым текстовым полем, которое можно менять.
3. Экономика VoIP поощряет существование операторов, которые не проверяют это поле, чтобы быть дешевле и гибче.
4. Легальные бизнес-процессы (колл-центры) зависят от возможности подмены номера, что делает полное запрещение технически и экономически невозможным.

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

Понимая это, мы перестаём видеть в спуфинге магию или «гениальное злодейство». Мы видим системную халатность, возведённую в принцип работы. И с этой точки зрения мы теперь можем перейти к анатомии: как именно этим злоупотребляют, где конкретно лежат эти доверенные поля и как в них вписаться. Не для того чтобы это делать, а для того чтобы увидеть механизм во всей его убогой красоте и понять, где ставить заплатки.

Погнали дальше, вглубь пакетов.

---

Часть 2: Анатомия звонка. От твоего софтфона до телефона жертвы: карта доверия и точки её разрыва.​

Теперь, когда мы поняли, почему мир такой кривой, давай разберём как он работает. Не абстрактно, а буквально по пакетам. Представь, что ты - SIP-пакет с подменённым From:. Твоя миссия - пройти путь от злоумышленника до экрана телефона жертвы, не будучи разоблачённым и не словив 403 Forbidden или, что хуже, молчаливого отбоя.

Мы построим детальную карту этого путешествия. Каждый шаг - это проверка, фильтр, шлюз. Наша задача - понять логику каждого стража на этом пути.

Этап 0: Подготовка оружия - Твоё устройство (User Agent, UA)​

Здесь всё начинается. Ты - злоумышленник (или исследователь в лаборатории). У тебя есть:

• Софтфон: MicroSIP, Zoiper, Bria.
• Или IP-телефон: Yealink, Cisco, Grandstream.
• Или своё ПО: Скрипт на Python с библиотекой pjsip или sip.py, модифицированный Asterisk.

Что ты делаешь: Формируешь SIP-запрос INVITE. Это твой «паспорт» на путешествие. Давай разберём ключевые поля под микроскопом:

INVITE sip:+74950000000@operator-b.com SIP/2.0
Via: SIP/2.0/UDP 192.168.88.2:5060;branch=z9hG4bKnasd923
Max-Forwards: 70
From: "СБЕРБАНК" <sip:+74959999999@anydomain.com>;tag=asd8hj32
To: <sip:+74950000000@operator-b.com>
Call-ID: 12345aaa-6789@192.168.88.2
CSeq: 1 INVITE
Contact: <sip:attacker@192.168.88.2:5060>
Content-Type: application/sdp
Content-Length: 142
v=0
o=- 112233 112233 IN IP4 192.168.88.2
s=-
c=IN IP4 192.168.88.2
t=0 0
m=audio 10000 RTP/AVP 0
a=rtpmap:0 PCMU/8000

1. From: - Главное поле для спуфинга.Оно состоит из:
   • "СБЕРБАНК" - Display Name. Это то, что часто показывается на экране. Можно писать любую хуйню.
   • sip:+74959999999@anydomain.com - URI звонящего. +74959999999 - номер, который мы хотим подменить. anydomain.com - домен. Важно: домен здесь часто игнорируется операторами, они смотрят только на номер. Но иногда проверяют его соответствие сети отправителя.
   • tag= - рандомный идентификатор для диалога. На этом этапе неважен.
2. To: - Целевой номер. Должен быть правильным, иначе звонок никуда не придёт.
3. Via: - История маршрутизации. Добавляется каждым прокси. Здесь пока только твой IP и порт. Это поле может быть использовано для грубых проверок «откуда пришло».
4. Contact: - Адрес для обратной связи. Часто это твой реальный IP. Опасное поле! Умные системы защиты могут его анализировать и сравнивать с ожидаемым местоположением номера из From:. Если звонит «московский номер Сбера», а Contact указывает на хостинг в Нидерландах - тревога.
5. Call-ID: - Уникальный идентификатор вызова.
6. SDP (Session Description Protocol) в теле сообщения - описывает медиа-поток (голос). Здесь указан твой IP (c=IN IP4 192.168.88.2) и порт (m=audio 10000) для RTP. Ещё одна точка для анализа! Геолокация по IP медиа-сервера - сильный сигнал для фильтров.

Твои действия на этом этапе:

• Подменить From: URI на целевой фейковый номер.
• Подобрать правдоподобный Display Name.
• По возможности, подменить Contact: на что-то менее явно кричащее (например, на IP своего прокси или VPN). В некоторых софтфонах это поле жёстко привязано к настройкам учётной записи.
• Убедиться, что SDP указывает на доступный RTP-порт.

Вывод по этапу 0: Здесь ты абсолютно свободен. Твой UA отправит что угодно. Проблема начинается на следующем шаге.

---

Этап 1: Первый барьер - Твой SIP-провайдер (ITSP) или твой собственный сервер​

Это первый и главный фильтр. Ты отправляешь INVITE не напрямую в мир, а на SIP-сервер своего провайдера (например, sip.provider-a.com).

Что делает провайдер (в идеальном мире):

1. Аутентификация: Проверяет, кто ты. Чаще всего по IP-адресу (белый список) или по запросу на регистрацию/INVITE с логином и хэшем парря (Digest Auth). Допустим, твоя учётка - sip:myreal@provider-a.com.
2. Авторизация: Проверяет, можешь ли ты звонить на указанный номер To: (тарифы, ограничения).
3. Нормализация (Canonicalization) CLI: САМОЕ ВАЖНОЕ ДЕЙСТВИЕ. Хороший провайдер смотрит: «Пользователь myreal@provider-a.com звонит. В поле From: у него <sip:+74959999999@anydomain.com>. Но у нас в базе пользователю myreal присвоен номер +74951111111. Значит, пользователь пытается подделать CID. Исправляем.» И перезаписывает твоё поле From: на sip:+74951111111@provider-a.com.

Как обойти этот барьер? Вот где начинается практическая инженерия.

• Способ A: Найти «грязного» провайдера (агрегатора).Их бизнес - продавать дешёвые минуты. Часто они:
  • Не требуют регистрации, только IP-based аутентификацию (белый список). Купил доступ - шли трафик.
  • Не нормализуют From:. У них есть настройка типа trust_rpid = yes или rewrite_caller_id = no. Они транзитом передают твой заголовок дальше. Такие услуги ищут на теневых форумах, иногда под видом «операторских транков для колл-центров».
  • Практический инструмент (для поиска/проверки): Тестовый звонок через потенциального провайдера. Настроить свою Asterisk, отправить вызов с фейковым From: на свой же тестовый номер у другого оператора. Если CID прошёл - агрегатор «грязный». Записывай Wireshark-ом оба конца.
• Способ B: Использовать уязвимости или ошибки конфигурации.
  • Open Relay: Публичный SIP-прокси, забытый в интернете без аутентификации. Находится сканерами вроде sipvicious или Shodan (sip:5060). Отправил INVITE - он ретранслирует. Но такие сервера быстро попадают в чёрные списки (RBL).
  • Подмена в рамках аутентифицированной сессии: Если провайдер проверяет только REGISTER, но не проверяет From: в каждом INVITE, можно, будучи авторизованным как myreal, слать INVITE с любым From:. Редко, но бывает.
• Способ C: Работа через «доверенные» каналы.
  • Если ты - легальный колл-центр, ты договариваесь с провайдером: «Разреши мне звонить с номера +74959999999». Он добавляет тебя в ACL (Access Control List) и либо пропускает твой From:, либо сам добавляет доверенный заголовок - P-Asserted-Identity: (PAI).
    
    

    P-Asserted-Identity: "СБЕРБАНК" <sip:+74959999999>

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

Что происходит после провайдера:
Твой INVITE, пройдя (или обойдя) нормализацию, отправляется дальше. Провайдер смотрит на номер To:, определяет, через какого партнёра (транзитника) его дешевле всего отправить, и пересылает пакет. Он также добавляет свой собственный заголовок Via: (чтобы ответ мог вернуться) и может уменьшить Max-Forwards.

Ключевой момент этапа 1: Если ты преодолел нормализацию своего провайдера и твой фейковый From: (или, лучше, PAI) ушёл в сторону транзитного оператора - ты прошёл самый сложный рубеж. Дальше - почти автострада.

---

Этап 2: Автострада - Транзитные/Магистральные операторы (Transit Providers)​

Это «труба». Их задача - не вникать в суть, а перемещать тонны SIP-сообщений из точки A в точку B за деньги. Их инфраструктура - это высоконагруженные прокси (Kamailio, OpenSIPS) или софтсвичи (Asterisk, Freeswitch) в carrier-режиме.

Их логика проста:

1. Получить INVITE от IP-адреса партнёра (провайдера А).
2. Проверить, есть ли у этого партнёра деньги на счёте и активен ли peering.
3. Определить маршрут: кому из следующих партнёров отправить, чтобы попасть к оператору назначения (оператору Б). Используются маршрутные протоколы (ENUM, LRN) или статические правила.
4. Переслать пакет, добавив свой Via:.

Что они НЕ делают (в 99% случаев):

• Не проверяют соответствие From: или PAI реальному источнику.
• Не занимаются глубоким анализом SDP или геолокацией.
• Не блокируют вызовы по подозрительному CID, если это не оговорено контрактом (а с «грязными» агрегаторами такие пункты не пишут).

Почему? Потому что это стоит процессорного времени, добавляет задержку, и, главное, они за это не платят и не получают денег. Их KPI - uptime и объём пропущенных минут. Они -цифровая версия грузовой железной дороги: их не волнует, что в контейнере, лишь бы он был оплачен и имел правильную накладную.

Единственная точка отказа здесь: Если IP-адрес отправителя (провайдера А) попал в глобальный RBL (blacklist) за спам, транзитник может отфильтровать весь его трафик. Поэтому «грязные» агрегаторы часто меняют выходные IP-адреса или используют пулы адресов.

---

Этап 3: Последний рубеж - Оператор назначения (Terminating Operator)​

Это оператор, чей абонент получает вызов. У него абонент на руках, он несёт репутационные риски. Здесь снова могут быть фильтры, но их эффективность - лотерея.

Что делает оператор назначения, когда получает INVITE:

1. Определяет абонента: Смотрит на To:, находит его в своей базе, проверяет статус.
2. Выбирает, какой CID показывать (CRITICAL DECISION):У него в пакете теперь может быть целая палитра заголовков:
   • Стандартный From: (который мы подделали).
   • P-Asserted-Identity: (если его добавили и доверяют предыдущему оператору).
   • Remote-Party-ID: (устаревший аналог).
   • History-Info: (может содержать первоначальный CID).
   • Алгоритм выбора зависит от политик. Чаще всего: если есть доверенный PAI - показать его. Если нет - показать From:. Некоторые операторы могут показывать и то, и другое (например, «СБЕРБАНК <+7 495 999-99-99>»).
3. Применяет фильтры (если они есть):
   • Проверка STIR/SHAKEN: Если в заголовке Identity есть подпись, оператор проверяет её через централизованную PKI. Если подпись верна и уровень аттестации (A) - звонок получает «галочку». Если подписи нет или она неверна - может пометить как «Spam».
   • Репутационный анализ: Проверяет IP-адрес источника из самого верхнего Via по базам спама. Проверяет домен в From: URI. Сравнивает геолокацию номера From: (код страны, региона) с геолокацией исходного IP. Несоответствие - главный красный флаг. Звонок из Нигерии с московским номером.
   • Анализ паттернов: Необычно высокая частота вызовов с одного номера, короткая длительность, последовательный перебор номеров.
   • Внутренние чёрные списки: Номера, на которые жаловались абоненты.

Как операторы обходят свои же фильтры (легально и не очень):

• Использование местных прокси/шлюзов: Агрегатор может арендовать сервер в той же стране, что и подменяемый номер. Тогда геолокация IP совпадёт.
• Сотрудничество с «теневыми» операторами в стране назначения: Небольшой локальный оператор, который за взятку или долю пропускает спам-трафик, добавляя «правильные» PAI и IP.
• Атака на SS7: Если скомпрометировать сигнализацию на уровне SS7, можно заставить сеть оператора самой сгенерировать вызов с нужным CLI. Тогда все SIP-фильтры бессильны, так как звонок рождается «внутри» сети.

Практический инструмент для анализа политик оператора:
Создание тестовой инфраструктуры из нескольких SIM-карт разных операторов и отправка на них контролируемых вызовов через разных агрегаторов. Фиксировать, что именно отображается. Использовать GSM-шлюзы (например, на базе Osmocom) для детального анализа сигнализации. Это дорого и сложно, но даёт бесценные данные.

---

Этап 4: Финальная миля - Устройство абонента​

Даже если оператор пропустил вызов, последнее слово за устройством.

• Прошивка/ОС: iOS и Android имеют свои базы спама (на основе краудсорсинга). Они могут показать «Вероятно, спам» поверх «проверенного» номера.
• Сторонние приложения: «Кто звонит», «Яндекс.Телефон». Они имеют свои, часто более агрессивные, алгоритмы, основанные на big data. Могут определить, что номер +74959999999 принадлежит Сбербанку, но он никогда не совершает исходящих звонков клиентам, только принимает входящие. И пометить такой исходящий вызов как 100% мошеннический.
• Call Screening (Google Pixel): Автоматический ответчик, который просит представиться. Записывает ответ и показывает его тебе. Эффективно против ботов.

---

Итог анатомии: Карта уязвимостей​

Итак, где тонко, там и рвётся:

1. Стык между UA и первым оператором: Нормализация CID. Уязвимость - «грязные» агрегаторы.
2. Стык между операторами в цепочке: Передача доверенных заголовков (PAI). Уязвимость - компрометация оператора или сотрудничество с ним.
3. Логика оператора назначения: Алгоритм выбора CID для отображения и глубина фильтрации. Уязвимость - слабые или отсутствующие политики проверки геолокации/репутации.
4. На границе сетей (SIP-SS7): Преобразование протоколов. Уязвимость - атаки на SS7.
5. Человеческий фактор на устройстве: Готовность абонента доверять экрану. Уязвимость - отсутствие цифровой грамотности.

Понимая эту карту, ты больше не просто «подменяешь номер». Ты выбираешь маршрут, подбираешь инструменты и обходишь конкретные контрольно-пропускные пункты. Для защиты же нужно укреплять каждый из этих пунктов, создавая многослойную, «глубокую» оборону.

​

Часть 3: Инструментарий исследователя. От скриптов до серых магистралей.​

ВАЖНО: Использование этих инструментов для обмана, мошенничества или нарушения работы сетей незаконно и противоречит этике. Они приведены для понимания векторов атак и построения защиты.

Категория 1: Легкодоступные, «игрушечные» (для понимания принципа)​

1. Софтфоны с GUI:MicroSIP, Zoiper, X-Lite.
   • Что это: Пользовательские SIP-телефоны.
   • Как использовать для спуфинга: В настройках учётной записи есть поля «Display Name» и «User ID»/«Number». Меняя их, ты меняешь заголовки From: и Display-Name. Но: Твой SIP-провайдер почти наверняка перезапишет их на исходящей магистрали, если ты аутентифицируешься. Чтобы это сработало, нужно либо найти публичный SIP-сервер без аутентификации (редкость), либо настроить свою АТС (см. ниже).
   • Практическая ценность: Нулевая для реального мира. Отлично подходит для лабораторных экспериментов в локальной сети между двумя Asterisk-ами, чтобы увидеть, как ходят пакеты.
2. Командная строка: sipvicious, sipp, sipscan.
   • Что это: Наборы утилит для тестирования SIP-систем (легитимного пентеста).
     
     Пример с sipvicious (svwar):
     

     # Это не для спуфинга звонков, а для сканирования расширений на АТС.
     svwar -e1000-2000 -m INVITE sip:target.pbx.com

     
     
   • Как использовать для спуфинга: Прямого «спуфинга» они не делают, но sipp - мощнейший инструмент для генерации любого SIP-трафика, включая кастомные заголовки. Ты пишешь XML-сценарий, где явно указываешь все поля:
     
     

     <send>  <![CDATA[
         INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
         Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
         From: "ФСБ" <sip:007@fsb.ru>;tag=[call_number]
         To: <sip:[service]@[remote_ip]:[remote_port]>
         Call-ID: [call_id]
         CSeq: 1 INVITE
         Contact: <sip:[local_ip]:[local_port];transport=[transport]>
         Max-Forwards: 70
         Content-Type: application/sdp
         Content-Length: [len]
     
         v=0
         o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
         s=-
         c=IN IP[media_ip_type] [media_ip]
         t=0 0
         m=audio [media_port] RTP/AVP 0
         a=rtpmap:0 PCMU/8000
       ]]>
     </send>

     
     
   • Практическая ценность: Для целевого исследования конкретной АТС или оператора. Можно быстро проверить, отбрасывает ли система вызовы с неверными полями From:. Требует глубокого понимания SIP.

Категория 2: Сердцевина. Своя АТС (PBX)​

Развернуть свою АТС (Asterisk, Freeswitch, Kamailio) - это как получить свой собственный телефонный узел.

1. Asterisk (FreePBX как GUI-оболочка):Король opensource телефонии.
   • Что это: Полноценная АТС. Ты определяешь правила маршрутизации (dialplan), учётные записи, магистрали.
   • Как использовать для спуфинга:Всё дело в конфигурации магистрали (SIP trunk) к твоему провайдеру.
     • Сценарий 1 (грязный): Найти «open relay» или серого агрегатора, который предоставляет магистраль без аутентификации по IP или с простым паролем и без нормализации исходящего номера. В настройках магистрали в Asterisk (sip.conf или в FreePBX) ты указываешь параметр fromuser и fromdomain. Вот они - твои поля для спуфинга на исходящей магистрали.
       
       

       [my_grey_trunk]type=peer
       host=sip.grey-aggregator.com
       fromuser=74951234567 ; Подменяемый номер
       fromdomain=grey-aggregator.com
       secret=theirpassword
       context=from-trunk

       
       
     • Сценарий 2 (более тонкий): Использовать поле P-Asserted-Identity: через dialplan Asterisk. Можно установить его через переменную SIPADDHEADER в диалплане:
       
       

       exten => _X.,1,NoOp(Звонок наружу)same => n,Set(SIPADDHEADER=P-Asserted-Identity: <sip:74951234567@some-domain.com>)
       same => n,Dial(SIP/${EXTEN}@my_trusted_trunk)

       
       Сработает ли это, зависит от того, доверяет ли твой оператор твоей АТС и принимает ли такие заголовки.
   • Практическая ценность: Максимальная. Позволяет не просто отправить вызов, а построить целую инфраструктуру: IVR (автоответчик), запись, маршрутизацию. Именно так работают многие серые кол-центры.
2. Freeswitch:Более современная, гибкая и производительная, чем Asterisk, особенно для больших нагрузок.
   • Принцип тот же: Настройка профиля (sofia.conf.xml) и правил маршрутизации в dialplan для манипуляции заголовками. Часто используется в больших VoIP-сервисах.

Категория 3: Промышленный инструмент. SIP-агрегаторы и «транки»​

Это следующий уровень. Ты перестаёшь играть с одним вызовом и начинаешь думать о потоках.

• Где ищут: Теневые форумы, Telegram-каналы. Услуги называются «SIP trunk with CLI flexibility», «DID spoofing», «Origination services». Часто базируются в странах со слабым регулированием.
• Как это работает: Ты покупаешь у такого агрегатора не «номер», а право отправлять трафик. Они дают тебе credentials для подключения твоей АТС к их серверу. Их сервер подключён к десяткам магистральных операторов по всему миру. Их ключевая «фича» - они передают твой заголовок From: «как есть» дальше, в мир. Они делают это, потому что их клиенты - это и есть те самые «кол-центры», которым нужно звонить с локальных номеров в разных странах. Разница лишь в намерении.
• Стоимость: Цена за минуту, часто дороже легальных каналов, но дешевле, чем настраивать легальные отношения с каждым оператором в мире.
• Практическая ценность: Это «производственная» среда мошенников. Если ты администратор защищаемой сети, тебе нужно понимать, что звонок с «номером твоего банка» может физически идти с IP-адреса в Нидерландах, арендованного через такого агрегатора.

Категория 4: Атака на другой уровень: SS7 и диаметр​

Это уже высший пилотаж, требующий доступа к сигнальной сети оператора связи (SS7) или её IP-аналогу (Diameter в 4G/5G). Это не «подмена заголовка», это внедрение ложных сигнальных сообщений в саму нервную систему телефонии.

• Что такое SS7: Набор протоколов для управления звонками, SMS, roaming между операторами. Сеть SS7 строится на доверии между операторами.
• Как используется для спуфинга: Отправив определенное сигнальное сообщение (например, ISUP с нужными параметрами или MAP для пересылки SMS), можно заставить сеть оператора поверить, что звонок идёт с любого номера. Если у тебя есть доступ в сеть SS7 (купить у «серого» оператора или скомпрометировать), то подмена становится абсолютно прозрачной для всех последующих проверок на уровне SIP, потому что она происходит раньше.
• Инструменты: SS7Map, кастомные скрипты на Python с библиотеками вроде libss7. Требует глубокого знания TTCN, ASN.1 и сигнализации.
• Практическая ценность: Это ядерное оружие. Крайне сложно в обнаружении и защите. Защита от этого ложится на операторов связи и внедрение протоколов вроде STIR/SHAKEN (о нём ниже).

---

Часть 4: Защита. Как не стать жертвой и как защитить свою инфраструктуру.​

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

Уровень 1: Для пользователя (Вася с телефоном)​

1. Скептицизм - лучший антивирус. Номер на экране - это просто текст. Его доверять нельзя. Всегда перезванивай на официальный номер, взятый с сайта организации, а не с того, что тебе только что продиктовали.
2. Используй встроенные функции смартфона: Современные Android и iOS имеют встроенные определители спама, могут предупреждать о «возможном мошеннике». Включи их.
3. Приложения-ассистенты: В России есть «Кто звонит?» от Яндекс, «АнтиФрод» от МТС и аналоги. Они имеют огромные базы спам-номеров и пытаются определять спуфинг на основе косвенных признаков (частота звонков, время жизни номера).
4. Секретный вопрос: Договорись с близкими о кодовом слове или вопросе, который будете задавать при звонках по Sensitive вопросам.

Уровень 2: Для администратора корпоративной АТС/оператора​

Здесь начинается настоящая работа.

1. Входящие вызовы: Валидация и аутентификация.
   • STIR/SHAKEN (для Северной Америки и внедряется в других регионах):Это framework, который пытается решить проблему на глобальном уровне. Принцип:
     • STIR (Secure Telephony Identity Revisited) - набор протоколов.
     • SHAKEN (Signature-based Handling of Asserted information using toKENs) - архитектура внедрения.
     • Как работает: Оператор отправителя подписывает цифровой подписью информацию о звонке (номер отправителя, номер получателя, время) и вкладывает этот токен (Identity header) в SIP-сообщение. Оператор получателя проверяет эту подпись с помощью публичных ключей (честимый PKI). Если подпись валидна и уровень аттестации (Attestation) высок (A - оператор владеет номером и авторизовал абонента), номер можно доверять. Если подписи нет или она неверна - звонок помечается как «Spam» или блокируется.
     • Проблемы: Внедрение идёт медленно, особенно за пределами США. Многие операторы выдают низкий уровень аттестации (B, C), что не даёт уверенности. Для международных вызовов цепочка доверия может рваться.
   • Анализ сигнальной и медиа-информации:
     • Сравнение IP-адреса источника сигнализации (SIP) с ожидаемым диапазоном оператора. Если звонок «из Сбербанка» идёт с IP-адреса в Нигерии - явный признак спуфинга.
     • Проверка заголовков P-Asserted-Identity: против From:. Если PAI есть и отличается от From:, то From: - ложный.
     • Использование Asserted Identity в рамках собственной сети. Внутри своей организации настрой SIP-серверы так, чтобы они доверяли только PAI от определённых доверенных шлюзов, а From: игнорировали для входящих извне.
   • Дип-анализ через RTCP и RTP: Можно анализировать медиа-поток (голос). Задержка, джиттер, кодеки могут косвенно указывать на то, что вызов проходит через длинную цепочку некачественных прокси, что характерно для серых операторов.
2. Исходящие вызовы: Не будь частью проблемы.
   • Всегда включай нормализацию From: на своих исходящих магистралях. Твой сервер должен перезаписывать поле From: на номера, привязанные к учётной записи, с которой идёт вызов.
   • Жёсткая аутентификация. Никаких open relays. Используй сложные пароли, аутентификацию по IP (whitelist), если возможно.
   • Мониторинг трафика. Ищи аномалии: необычно высокий объём исходящих минут с одной учётной записи, звонки на номера в странах, с которыми у тебя нет бизнеса, быстрый набор множества последовательных номеров (wardialing).
3. Инструменты для защиты:
   • RTPengine, Kamailio с модулями secfilter: Позволяют фильтровать и нормализовать SIP-трафик.
   • Wireshark с фильтрами SIP/RTP: Твой лучший друг для анализа проблем. Научись читать SIP-транзакции.
   • Специализированные SIP-файрволы и SBC (Session Border Controller): Cisco CUBE, Audiocodes, Oracle ACME. Это профессиональные устройства/ВМ, которые ставятся на границе сети и занимаются именно безопасностью и нормализацией VoIP-трафика. Они могут проверять подписи STIR/SHAKEN, фильтровать по репутации IP, ограничивать скорость вызовов. Это must-have для любой серьёзной VoIP-инфраструктуры.

Уровень 3: Для регулятора и оператора связи (глобальный уровень)​

Это то, что должно поменяться системно.

• Обязательное внедрение STIR/SHAKEN или его аналогов (в РФ - возможно, будущая система на базе ЕСИА/СМЭВ?).
• Жёсткая ответственность операторов-агрегаторов за трафик, который они пропускают. Если с их IP-адресов идут миллионы спам-вызовов, их нужно отключать от peering.
• Аудит и сертификация операторов, имеющих доступ к сигнальным сетям (SS7).
• Создание единых баз «кривых» номеров и агрегаторов, используемых для спама, для оперативного блокирования на уровне всех операторов.

Часть 5: Будущее. Эволюция, а не исчезновение. Гонка вооружений, которую мы проигрываем на архитектурном уровне.​

Давай расставим точки над i сразу: Caller ID спуфинг в его нынешнем, «глупом» виде, возможно, и будут давить. Но сама концепция подмены идентификатора в реальном времени в доверенной среде НЕ ИСЧЕЗНЕТ. Она мутирует, перейдя на следующий уровень сложности.

Представь, что мы - вирус, а глобальная телеком-инфраструктура - организм. STIR/SHAKEN и прочие проверки - это антитела. Мы, вирус, просто начнём вырабатывать устойчивость. Не потому что мы злые гении, а потому что система даёт для этого возможности. Давай посмотрим на векторы этой эволюции.

Вектор 1: Атака на саму систему доверия (STIR/SHAKEN и аналоги)​

Сейчас все надежды возлагаются на эту криптографическую проверку. Но она - не серебряная пуля, а новый, более сложный замок. А где сложный замок, там и изощрённые отмычки.

• Компрометация ключей оператора (Attestation Level A):Самый страшный сценарий. Если злоумышленник получит доступ к приватному ключу оператора, имеющего право выдать высший уровень аттестации (A - «Мы знаем этого абонента, он наш, и мы авторизовали этот вызов»), то он сможет легально подписывать ЛЮБЫЕ номера этого оператора. Это не взлом SIP-прокси, это взлом самой основы PKI. Как это может произойти?
  • Внутренняя угроза: Инсайдер в операторе (или в компании, которая обслуживает его HSM - Hardware Security Module).
  • Атака на цепочку поставок: Компрометация ПО или оборудования, на котором генерируются ключи.
  • Социальная инженерия в регуляторах: Получение статуса оператора с правами аттестации A в стране со слабым регулированием. Такие «операторы-однодневки» могут стать фабриками по производству «верифицированного» спама.
  • Практический инструмент (для защиты!): Мониторинг Certificate Transparency логов для PKI телефонии. Внезапное появление нового оператора, выдающего огромное количество аттестаций A на номера, которые никогда не звонят, - красный флаг. Существуют исследовательские проекты, сканирующие эти логи, но это оружие крупного калибра для аналитиков угроз, а не для рядового админа.
• Злоупотребление низкими уровнями аттестации (B и C):Операторы часто выдают уровень B («Мы знаем, откуда вызов, но не гарантируем номер абонента») или C («Мы знаем только, откуда вызов вошёл в нашу сеть»). Для международных вызовов это вообще норма. Мошенник может:
  • Найти оператора, который за деньги предоставляет доступ к своему SIP-транку с возможностью отправлять вызовы с уровнем B/C.
  • Сфабриковать вызов так, чтобы он выглядел как легитимный международный звонок через такого оператора. На телефоне жертвы может отображаться галочка или пометка «Проверенный номер, но низкий уровень доверия» (как сейчас бывает «Возможен спам»). Большинство пользователей не понимают разницы между галочками. Доверие достигнуто.
  • Инструмент для исследования: Сервисы вроде youmail.com или hiya.com для США показывают, как выглядит проверка вызова. Нужно изучать, как разные операторы отображают разные уровни аттестации. Это можно делать, настраивая тестовые вызовы через лабораторные стенды с разными провайдерами.
• Разрыв цепочки доверия (Breakout Attacks): STIR/SHAKEN работает внутри домена доверия (например, в США). Что происходит на границе? Допустим, звонок идёт из страны, где STIR/SHAKEN нет. Он поступает к американскому оператору. Тот должен как-то его аутентифицировать. Часто используется упрощённая проверка по IP-адресу или паспорту оператора. Эти механизмы можно подделать. Точка входа - операторы-посредники в странах с слабым регулированием. Они становятся «прачечными» для спам-трафика, придавая ему видимость легитимного международного вызова.

Вектор 2: Конвергенция с другими технологиями обмана (Глубокая фальсификация)​

Это самый пугающий и неизбежный вектор. Голосовой фишинг (вишинг) станет гиперреалистичным.

• Голосовые DeepFake в реальном времени:Представь звонок от «твоего начальника» или «сына», который говорит: «У меня проблемы, срочно переведи деньги». Не робот, а его голос, с его интонациями, со всеми «эканьями» и смешками. Технологии вроде Resemble AI или ElevenLabs уже сейчас позволяют клонировать голос по 30-секундной записи (которую можно наскрести в соцсетях). В сочетании с подменённым номером в телефоне это будет оружием массового поражения.
  • Практическая контрмера (уже сейчас!): Внедрение в организациях кодовых слов или протоколов проверки для финансовых операций. Не «пароль», а ситуативный вопрос, ответ на который известен только двоим и который не найти в соцсетях («Как зовут нашу первую учительницу?», «Какой был цвет нашей первой машины?»). Это - социальная защита от технической атаки.
  • Техническая контрмера (в разработке): Анализ голосового потока на предмет артефактов генерации. Но это - arms race, аналогичная борьбе с ботами в играх.
• Видеоспуфинг для подтверждения: Следующий шаг - не только голос, но и видео в реальном времени. «Сын» в «скайпе» просит деньги. Технологически это уже на пороге. Защита здесь будет невероятно сложной.

Вектор 3: Смена целевой платформы​

Если телефония станет слишком «жёсткой», атаки сместятся туда, где идентификация ещё слабее.

• Мессенджеры (WhatsApp, Telegram, Signal): Подмена номера здесь сложнее, но не невозможна. А вот создание фейкового аккаунта, клонирующего контакты, и социальная инженерия - процветают. Верификация через «галочку» есть у единиц.
• Корпоративные коммуникаторы (Teams, Slack): Фишинг через поддельные каналы или письма с приглашением в «важный чат» - уже реальность. Идентификатор здесь - email или имя пользователя, которые тоже можно подделать или спуфить в рамках внутренней сети при плохой настройке.
• Умные колонки и голосовые ассистенты (Alexa, Google Home): Атаки на них - отдельная вселенная. Команды, неразличимые для человеческого уха, но понятные устройству. Подмена голоса владельца.

Вывод из этой части: Будущее спуфинга - это интегральный обман. Это не одна уязвимость в SIP, а комбинация: подменённый идентификатор + сгенерированный голос + утекшие из соцсетей данные о жертве + психологическое давление. Защита не может быть только технической. Она должна быть социотехнической. Нужно укреплять самое слабое звено - человека - через обучение и протоколы, и одновременно строить технические барьеры такой сложности, чтобы стоимость атаки становилась неоправданной для массового мошенничества.

---

Вывод: Не чинить дыры, а менять философию. Наш манифест.​

Мы пытаемся лечить рак аспирином. STIR/SHAKEN - это хороший, нужный аспирин. Он собьёт температуру (массовый дешёвый спам), но не убьёт опухоль. Опухоль - это экономическая модель, при которой дешевизна и скорость маршрутизации звонков всегда важнее их аутентичности. Это - архитектурные решения, зашитые в RFC, которые почти невозможно откатить. Это - тысячи мелких операторов по всему миру, для которых внедрение сложных проверок означает банкротство.

Что мы, как сообщество, можем сделать? Не ждать чуда от регуляторов и крупных корпораций. Действовать на своих уровнях.

1. Для исследователя/энтузиаста (наш уровень):
   • Строить лаборатории. Не для атак, а для понимания. Поднять Asterisk, Freeswitch, наладить трансляцию между ними, поставить SBC (FreeSBC, OpenSIPS). Прочувствовать, как течёт трафик. Словить пакеты Wireshark'ом и научиться читать их как книгу. Без этого ты слеп.
   • Изучать не только SIP, но и «старую гвардию» - SS7, SIGTRAN. Да, это сложно. Да, документации мало. Но именно там кроется абсолютная власть. Понимание этого даёт тебе карту всей игровой площадки.
   • Участвовать в opensource проектах по VoIP-безопасности. Kamailio, RTPengine, различные модули для анализа трафика. Писать скрипты для мониторинга аномалий.
   • Делиться знаниями, как это делаем мы сейчас. Создавать детальные, честные гайды. Разрушать мифы. Переводить сложное на человеческий язык.
2. Для сисадмина/инженера (практикующий уровень):
   • Отказаться от «оно и так работает». Настрой нормализацию исходящих номеров. Выключи все open relays. Внедри минимальный набор проверок для входящих вызовов: сравнение IP источника с репутационными базами (AbuseIPDB, спамхаусы), проверка несоответствия From и P-Asserted-Identity.
   • Агитировать за покупку SBC (Session Border Controller). Это не роскошь. Это обязательный элемент безопасности для любой компании, где телефония - не просто игрушка. Аргументируй это не страшилками, а техническим отчётом о возможных векторах.
   • Внедрять многофакторную аутентификацию для ВСЕХ критичных операций. Смена маршрутов, пополнение счёта у оператора, доступ к панели управления АТС. SMS-код - слабое звено (см. SS7, SIM-swap). Используй TOTP (Google Authenticator) или аппаратные ключи.
   • Учить пользователей. Не читать им мораль, а проводить короткие, ясные инструктажи: «Номер на экране - не гарантия. Если звонок из банка - положи трубку и перезвони сам по номеру с карты или сайта. У нас есть кодовое слово».
3. Для всех нас, как для культуры:
   • Бороться с цинизмом. Понимание уязвимостей не должно вести к мыслям в духе «всё пропало, всё сломано». Оно должно вести к ответственному строительству. Наша эмпатия - к системе, к тем, кто от неё страдает, и к тем, кто пытается её улучшить.
   • Требовать от вендоров и операторов прозрачности. Не «мы защищаем ваши звонки», а «мы используем STIR/SHAKEN с аттестацией уровня B для международных вызовов и применяем вот такие фильтры». Давить в сторону открытых стандартов и аудитов безопасности.
   • Принимать, что безопасность - это процесс, а не состояние. Сегодня твоя конфигурация защищена. Завтра появится новый агрегатор, новый вектор. Мониторинг, обновление, анализ - это рутина. Скучная, неблагодарная, но жизненно необходимая.

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

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

 

[skarz]

Спасибо за твой труд, было очень интересно