sms-угроза

АЛЕКСЕЙ ВИКТОРОВИЧ ЛУКАЦКИЙ

Спецвыпуск: Хакер, номер #070, стр. 070-018-6

В случае с локальным спамом (в рамках одного оператора через протокол SMPP) блокировать его можно на уровне SMS-центра, при наличии соответствующей возможности. В случае, если сообщение приходит из сети другого оператора (например, роумингового), то с его стороны SMS также посылается через SMSC, а вот внутри сети получателя оно проходит через MSC и затем напрямую, минуя локальный SMSC, направляется на мобильный телефон получателя. Для решения этой задачи необходимо контролировать ОКС7. Причем блокировать этот протокол невозможно – без него нарушится вся работа сети. Необходимо уметь фильтровать ОКС7. Для реализации этой задачи можно использовать интеграцию STP (например, Cisco ITP) с внешними антиспамовыми решениями. К числу таких решений можно отнести LogicaCMG, Openmind Networks, eServ Global или Ferma SAS (SMS Anti-Spam Screening).

SAS – это межсетевой экран для фильтрации SMS в реальном времени, разрешающий или блокирующий сообщения, посылаемые или принимаемые любым из абонентов мобильного оператора. В качестве критериев отсечения спама используются:

- КЛЮЧЕВЫЕ СЛОВА;

- АДРЕС ОТПРАВИТЕЛЯ;

- IMSI ПОЛУЧАТЕЛЯ;

- ЧИСЛО ОТПРАВЛЯЕМЫХ АБОНЕНТОМ СООБЩЕНИЙ;

- ЭВРИСТИЧЕСКИЙ АНАЛИЗ;

- «ЧЕРНЫЙ»/«БЕЛЫЙ» СПИСОК.

[пара фраз о DoS.]

Первое, что приходит на ум, размышляя о SMS DoS'е – это сгенерировать огромный поток коротких сообщений, которые должны «завалить» центр SMSC. Эту тему достаточно давно обсуждают специалисты, а после появления в ноябре прошлого года статьи «Exploiting Open Functionality in SMS-Capable Cellular Networks» шумиха поднялась вновь. Кто-то говорит, что в статье написана правда, кто-то утверждает, что это «гнилая сенсация», и на практике реализовать описанные в статье методы невозможно (или они не сработают).

Но факт есть факт: посылка большого числа сообщений может вызвать определенные проблемы в работе SMSC. Как минимум потому, что SMSC лицензируется по числу сообщений в секунду, и превышение определенного порога не позволит SMSC обрабатывать новые сообщения. Можно выдвинуть еще одну гипотезу, которую на практике не проверяли. Если применить идею атаки «Ping of Death» (посылка большого числа перекрывающихся фрагментов по протоколу ICMP, совокупная длина которых превышает максимальный размер IP-пакета в 64 килобайта), то работоспособность SMSC может быть также нарушена. И еще одна гипотеза – посылка разбитых на фрагменты «длинных» SMS-сообщений, которые будут храниться в SMSC, пока он не получит все фрагменты. Если одного из фрагментов «по случайности» не хватит, и число таких «длинных» SMS'ок будет значительным, то SMSC также может быть выведен из строя из-за нехватки ресурсов.

Есть также стойкое подозрение, что протоколы для обработки SMS разрабатывались без учета требований безопасности, и манипуляция полями SMS-сообщений может привести к печальным последствиям. Например, сообщение «hello» абоненту с телефоном 66677789 в рамках протокола EMI/UCP будет выглядеть следующим образом: ^B01/00045/O/30/66677789///1//////68656C6C6F/CE^C. Второе поле (00045) определяет длину пакета. Если SMSC «доверяет» данному полю и не перепроверяет его, то изменение значения в нем позволяет реализовать атаку «переполнение буфера». Интересный эффект может возникнуть, если модифицировать третье поле «тип операции» (O – для операции, R - для результата) и четвертое поле «операция» (например, 30 – передача сообщения). Отсутствие «защиты от дурака» может привести к нарушению работоспособности SMSC.