Смотрите, какой интересный документ. В нем много технических терминов без объяснения и канцелярита, поэтому попробую рассказать своими словами
( Read more... )
Начнем издалека. 1. Телефон регистрируется в сети, посылая LU (location update). Это происходит периодически, по истечению таймера, при смене location area, есть еще условия, это непринципиально сейчас. LU передается на HLR, тот обновляет данные абонента о местоположении и пересылает subscriber data на VLR. Тем самым в VLR обновляются все абонентские данные включая CAMEL subscription для SCP. Таким образом "пиратские данные" в VLR будут заменены корректными 2. IN-платформы используются для оказания интеллектуальных услуг связи. То есть то, что коммутатор сам не умеет, зато умеет выполнять инструкции. Найдя у абонента CAMEL подписку, коммутатор будет останавливать обработку звонка абонента в так называемых detection point'ах и передавать управление IN-платформе. Использование CAMEL не предполагает рутинга голоса в SCP. Говоря по-простому, это нахер не нужно. Обмен MSC-SCP сугубо служебный. Хотя да, IDP содержит полноценный объем данных об А и Б номере, локации абонента и так далее. Нужна эта информация для тарификации. На её основании SCP формирует обмен с SDP и принимает решение давать добро на продолжение звонка (continue или connect) или нет. Возможны еще временные соединения IVR для проигрывания сообщений и так далее.
Таким образом, если принять на веру написанное, получается, что умышленное изменение CAMEL-подписки ВРЕМЕННО приведет к тому, что внешний SCP будет уведомляться о том куда абонент звонил (или откуда принимал вызов, или отправлял ли смс - если фаза кэмэла поддерживает это). Но уж слушать его точно никто не сможет, кроме домашней СБ
... и если передать управление на внешний scp в detection point-е в самом начале (запамятовал правильные слова), то внешний scp может изменить номер, на который коммутируется звонок, ага?
Да, теоретически можно изменить Б-номер. Но вы себе последствия представляете? Вызов пойдет не туда, куда абонент хотел, а на совсем другой номер. Даже если допустить, что это некая транзитная система, которая далее пропустить вызов в нужном направлении, а сама просто запишет его, то будут следующие последствия: 1. В MSC CDR будет очевидно заметно, куда фактически был установлен вызов 2. Offline тарификация будет неверной 3. Возможно попадание звонка в отбросы на анализ дежурным по причине отсутствия CDR из "родного" SCP (назовём так, хоть это и не совсем корректно)
Кстати, вы еще забыли про такую мелочь, как наличие IN признаков у SIM карты. Иначе говоря, не всякая SIM карта может получить IN-подписку на HLR. По крайней мере у Ericsson это так. Поэтому при замене сим припэйдным абонентам этот аспект учитывается, и они получают симки конкретной серии. То есть, вот взять и удаленно приделать CAMEL всем подряд нельзя. Я уж не говорю о сетях, где CAMEL вовсе не используется .
Да, уши будут торчать отовсюду, и вопрос будет только в том, как быстро это будет замечено. Но если "игра стоит свеч" и вопрос стоит о том, чтобы "продержаться день-два", то почему бы и нет?
С другой стороны, можно не рисковать и собирать только метаданные.
Раз уж появился документы по ссылке и мы с вами вот тут это обсуждаем, тем или иным способом манипуляции были замечены :)
Да, и я согласен, что приделать camel всем подряд нельзя. В данном конкретном случае, если верить написанному, звезды расположились удачно, и у абонентов уже были IN-сервисы.
Я не читал ссылку, тяжко у меня с украинским ;), прочитал только вашу компиляцию вольную.
Кстати, вестись подобная атака если и может, то только на целевые номера. В противном случае, это потребует адовых временных и технологических затрат и будет очевидным образом заметно как массовый рост трафика на направлениях, которые были нетипичны. Скажем, чтобы заметить подобное, потребовались бы даже не дни, а часы, если проблема носит массовый характер.
Кстати, тут еще надо уточнить, а может ли "чужой" HLR вставлять данные в домашний VLR. Ведь абонент-то "дома", и не факт, что данный call flow вообще может состояться.
В общем, смотрите, НЕ у всех операторов GT VLR=GT MSC. Если теле2, как вы говорите, отправляла SRI-for-SM, то в ответе там содержится IMSI и GT MSC. Так вот insert subscriber data на MSC не пройдет.
Причем - вдогонку отмечу - что если на удаленной сети реализован перехват SRI для реализации захвата входящих смс-сообщений, то в ответ на SRI вернется GT SMSC. А для него ISD будет вообще изумлением :)))
Так что, сценарий реальный, но он очень целевой и содержит очень много "если".
вот про симкарту поподробнее. Чего это она не сможет, если HLR никак не привязан к типу карты, и на карте не хранится ничего, кроме IMSI. А подписка в HLR относится к связке IMSI-MSISDN, и больше ничего. То есть можно связать совершенно произвольные номера и навешать любых услуг.
Cим-карта вообще сначала грузится в AUC. Который как правило - часть HLR. Я точно не помню - не мой профиль - но на каком-то этапе, то ли при загрузке в AUC, то ли при загрузке в HLR указывается возможность использования IN в виде специальных флагов, привязанных именно к IMSI. Впрочем, это может быть специфично для оборудования Ericsson, с сетевыми элементами других вендоров я не работал. И тем не менее, "произвольно" любую сим с любым набором услуг не свяжешь, по крайней мере это не 100%.
Кстати, симка имси не содержит. icc id, насколько я помню, плюс свою часть ключей для авторизации при работе в сети. Но повторюсь, я не работал так плотно с этим, про начинку симки знаю немного
1. Телефон регистрируется в сети, посылая LU (location update). Это происходит периодически, по истечению таймера, при смене location area, есть еще условия, это непринципиально сейчас. LU передается на HLR, тот обновляет данные абонента о местоположении и пересылает subscriber data на VLR. Тем самым в VLR обновляются все абонентские данные включая CAMEL subscription для SCP. Таким образом "пиратские данные" в VLR будут заменены корректными
2. IN-платформы используются для оказания интеллектуальных услуг связи. То есть то, что коммутатор сам не умеет, зато умеет выполнять инструкции. Найдя у абонента CAMEL подписку, коммутатор будет останавливать обработку звонка абонента в так называемых detection point'ах и передавать управление IN-платформе. Использование CAMEL не предполагает рутинга голоса в SCP. Говоря по-простому, это нахер не нужно. Обмен MSC-SCP сугубо служебный. Хотя да, IDP содержит полноценный объем данных об А и Б номере, локации абонента и так далее. Нужна эта информация для тарификации. На её основании SCP формирует обмен с SDP и принимает решение давать добро на продолжение звонка (continue или connect) или нет. Возможны еще временные соединения IVR для проигрывания сообщений и так далее.
Таким образом, если принять на веру написанное, получается, что умышленное изменение CAMEL-подписки ВРЕМЕННО приведет к тому, что внешний SCP будет уведомляться о том куда абонент звонил (или откуда принимал вызов, или отправлял ли смс - если фаза кэмэла поддерживает это). Но уж слушать его точно никто не сможет, кроме домашней СБ
Reply
И вот тут уже его можно слушать.
Reply
1. В MSC CDR будет очевидно заметно, куда фактически был установлен вызов
2. Offline тарификация будет неверной
3. Возможно попадание звонка в отбросы на анализ дежурным по причине отсутствия CDR из "родного" SCP (назовём так, хоть это и не совсем корректно)
Кстати, вы еще забыли про такую мелочь, как наличие IN признаков у SIM карты. Иначе говоря, не всякая SIM карта может получить IN-подписку на HLR. По крайней мере у Ericsson это так. Поэтому при замене сим припэйдным абонентам этот аспект учитывается, и они получают симки конкретной серии. То есть, вот взять и удаленно приделать CAMEL всем подряд нельзя. Я уж не говорю о сетях, где CAMEL вовсе не используется .
Reply
С другой стороны, можно не рисковать и собирать только метаданные.
Раз уж появился документы по ссылке и мы с вами вот тут это обсуждаем, тем или иным способом манипуляции были замечены :)
Да, и я согласен, что приделать camel всем подряд нельзя. В данном конкретном случае, если верить написанному, звезды расположились удачно, и у абонентов уже были IN-сервисы.
Reply
Кстати, вестись подобная атака если и может, то только на целевые номера. В противном случае, это потребует адовых временных и технологических затрат и будет очевидным образом заметно как массовый рост трафика на направлениях, которые были нетипичны. Скажем, чтобы заметить подобное, потребовались бы даже не дни, а часы, если проблема носит массовый характер.
Кстати, тут еще надо уточнить, а может ли "чужой" HLR вставлять данные в домашний VLR. Ведь абонент-то "дома", и не факт, что данный call flow вообще может состояться.
Reply
Reply
Reply
Так что, сценарий реальный, но он очень целевой и содержит очень много "если".
Reply
И понятно, что не с улицы люди это делали, был доступ и к информации, и к какому-то оборудованию, как минимум.
Reply
Reply
А подписка в HLR относится к связке IMSI-MSISDN, и больше ничего. То есть можно связать совершенно произвольные номера и навешать любых услуг.
Reply
Кстати, симка имси не содержит. icc id, насколько я помню, плюс свою часть ключей для авторизации при работе в сети. Но повторюсь, я не работал так плотно с этим, про начинку симки знаю немного
Reply
И что значит "свою часть ключей для авторизации"? Что, где-то есть ещё какие-то части?
Reply
Reply
Reply
Reply
Leave a comment