Vector смс что это
Обновлено: 14.05.2024
Представим, что перед вами стоит задача организовать аутентификацию пользователя (в мобильном приложении, в первую очередь) так, как это сделано в Telegram/Viber/WhatsApp. А именно реализовать в API возможность осуществить следующие шаги:
- Пользователь вводит свой номер телефона и ему на телефон приходит СМС с кодом.
- Пользователь вводит код из СМС и приложение его аутентифицирует и авторизует.
- Пользователь открывает приложение повторно, и он уже аутентифицирован и авторизован.
Мне потребовалось некоторое количество времени, чтобы осознать, как правильно это сделать. Моя задача — поделиться наработанным с вами в надежде, что это сэкономит кому-то времени.
Мы поговорим о тех изменениях, которые следует проделать в API, о том, как реализовать одноразовые пароли на сервере, как обеспечить безопасность (в т.ч. защиту от перебора) и в какую сторону смотреть при реализации это функциональности на мобильном клиенте.
Изменения в API
В сущности требуется добавить три метода в ваше API:
1. Запросить СМС с кодом на номер, в ответ — токен для последующих действий.
Действие соответствует CREATE в CRUD.
Если всё прошло, как ожидается, возвращаем код состояния 200.
Если же нет, то есть одно разумное исключение (помимо стандартной 500 ошибки при проблемах на сервере и т.п. — некорректно указан телефон. В этом случае:
2. Подтвердить токен с помощью кода из СМС.
Действие соответствует UPDATE в CRUD.
Аналогично. Если всё ок — код 200.
Если же нет, то варианты исключений:
3. Форсированная отправка кода повторно.
Аналогично. Если всё ок — код 200.
Если же нет, то варианты исключений:
Помимо этого, каждый метод API, который требует аутентифицированного пользователя должен получать на вход дополнительный параметр token , который связан с пользователем.
Первый шаг. Проверить на себе
Сотрудник финтеха подает заявку на кредитную карту на своем сайте, держит телефон при себе и ждёт, когда ему позвонят левые компании с предложением взять кредит. Но так никто и не позвонил. Получается, проблемы нет? Финтех снова смотрит статистику обращений: жалобы клиентов на звонки сторонних компаний есть.
Хорошо, двигаемся дальше.
Особенности реализации одноразовых паролей
Вам потребуется хранить специальный ключ для проверки СМС-кодов. Существует алгоритм TOTP, который, цитирую Википедию:
OATH-алгоритм создания одноразовых паролей для защищенной аутентификации, являющийся улучшением HOTP (HMAC-Based One-Time Password Algorithm). Является алгоритмом односторонней аутентификации — сервер удостоверяется в подлинности клиента. Главное отличие TOTP от HOTP это генерация пароля на основе времени, то есть время является параметром[1]. При этом обычно используется не точное указание времени, а текущий интервал с установленными заранее границами (например, 30 секунд).
Пример кода на руби, чтобы было понятно о чём речь:
Алгоритм описан в стандарте RFC6238, и существует масса реализацией этого алгоритма для многих языков: для Ruby и Rails, для Python, для PHP и т.д..
Строго говоря, Telegram и компания не используют TOTP, т.к. при регистрации там, вас не ограничивают по времени 30-ю секундами. В связи с этим предлагается рассмотреть альтернативный алгоритм OTP, который выдает разные пароли, базируясь на неком счётчике, но не на времени. Встречаем, HOTP:
HOTP (HMAC-Based One-Time Password Algorithm) — алгоритм защищенной аутентификации с использованием одноразового пароля (One Time Password, OTP). Основан на HMAC (SHA-1). Является алгоритмом односторонней аутентификации, а именно: сервер производит аутентификацию клиента.
…
HOTP генерирует ключ на основе разделяемого секрета и не зависящего от времени счетчика.
HOTP описан в стандарте RFC4226 и поддерживается тем же набором библиотек, что представлен выше. Пример кода на руби:
Безопасность решения
Далее, самым очевидным вектором атаки является прямой перебор. Вот что пишут в параграфе 7.3 авторы стандарта HOTP (на котором базируется TOTP) на эту тему:
Truncating the HMAC-SHA-1 value to a shorter value makes a brute force attack possible. Therefore, the authentication server needs to detect and stop brute force attacks.
We RECOMMEND setting a throttling parameter T, which defines the maximum number of possible attempts for One-Time Password validation. The validation server manages individual counters per HOTP device in order to take note of any failed attempt. We RECOMMEND T not to be too large, particularly if the resynchronization method used on the server is window-based, and the window size is large. T SHOULD be set as low as possible, while still ensuring that usability is not significantly impacted.
Another option would be to implement a delay scheme to avoid a brute force attack. After each failed attempt A, the authentication server would wait for an increased T*A number of seconds, e.g., say T = 5, then after 1 attempt, the server waits for 5 seconds, at the second failed attempt, it waits for 5*2 = 10 seconds, etc.
The delay or lockout schemes MUST be across login sessions to prevent attacks based on multiple parallel guessing techniques.
Если кратко, то от прямого перебора алгоритм априори не защищает и надо такие вещи предотвращать на уровне сервера. Авторы предлагают несколько решений:
Отслеживать число неудачных попыток ввода кода, и блокировать возможность аутентификации по превышению некоторого максимального лимита. Лимит предлагают делать настолько маленьким, насколько ещё будет комфортно пользоваться сервисом.
Мнение, что можно полагаться только на то, что код живёт ограниченное число секунд, и будет безопасно, т.к. код сбрасывается — ошибочно. Даже, если есть фиксированное ограничение на число попыток в секунду.
Посмотрим на примере. Пусть код TOTP состоит из 6 цифр — это 1000000 возможных вариантов. И пусть разрешено вводить 1 код в 1 секунду, а код живёт 30 секунд.
Шанс, что за 30 попыток в 30 секунд будет угадан код — 3/100000
0.003%. Казалось бы мало. Однако, таких 30-ти секундных окон в сутках — 2880 штук. Итого, у нас вероятность угадать код (даже несмотря на то, что он меняется) = 1 — (1 — 3/100000)^2880
8.2%. 10 дней таких попыток уже дают 57.8% успеха. 28 дней — 91% успеха.
Так что надо чётко осознавать, что необходимо реализовать хотя бы одну (а лучше обе) меры, предложенные авторами стандарта.
Не стоит забывать и о стойкости ключа. Авторы в параграфе 4 обязывают длину ключа быть не менее 128 бит, а рекомендованную длину устанавливают в 160 бит (на данный момент неатакуемая длина ключа).
R6 — The algorithm MUST use a strong shared secret. The length of the shared secret MUST be at least 128 bits. This document RECOMMENDs a shared secret length of 160 bits.
Второй шаг. Проверить на контрольной группе
Собирается команда из 10 человек. Каждый подает заявку на кредит на сайте финтеха. Все договариваются, что два дня отвечают на звонки, несмотря на предупреждения WhoCalls, и стараются запоминать (записывать) информацию, которую им говорят.
Итог: примерно 30% участников контрольной группы поступили звонки от серьёзных и легальных организаций с предложением взять кредит у них. Кому-то позвонил робот, кому-то — сотрудник колл-центра одного уважаемого банка.
Значит, проблема есть. Хорошо, двигаемся дальше.
Изменения в схеме БД
Итого, в модели (или в таблице БД, если угодно) надо хранить:
- Телефон: phone (советую использовать библиотеки для унификации телефонного номера, вроде этой для Rails),
- Ключ для TOTP: otp_secret_key (читаете подробное README для выбранной библиотеки TOTP),
- Токен: token (создаете при первом запросе к API чем-нибудь типа SecureRandom),
- Ссылку на пользователя: user_id (если у вас есть отдельная таблица/модель, где хранятся данные пользователя).
Создание баз номеров
Другая возможная цель такого скрипта — сбор информации. Скрипт пытается восстановить пароль на разных сервисах. Если процесс запустился, аккаунт с таким телефонным номером существует. Его вносят в базу номеров.
Использовать базу могут как угодно. Например, статистику о владельцах дисконтных карт одной торговой сети передадут в другую — и вы начнете получать от них уведомления об акциях и скидках. Или через некоторое время вам позвонит «сотрудник банка» и попытается выманить данные карты.
Как защититься. Существуют сервисы, которые подменяют телефонные номера, поэтому доля паранойи не помешает. Если вам звонят и просят срочно назвать три цифры с обратной стороны карты, чтобы заблокировать списание денег, не верьте — даже если это звонок с номера банка, указанного на карте. Положите трубку и перезвоните в банк.
Еще вариант защиты — завести отдельную симкарту для регистрации на сайтах и больше нигде ее не использовать. Если на этот номер позвонят или напишут из банка, вы будете точно знать, что это мошенник.
От воров, хакеров и других нехороших ребят. Подпишитесь на рассылку, чтобы не пропустить важные статьиОбычная шутка
Самозащита от мошенников
Рассказываем о приемах, которые помогут не потерять деньгиПятый шаг. Разбор внешних интеграций по частям
БКИ. Финтех запрашивает у БКИ, есть ли у них услуга «получи данные клиентов, которые обратились за кредитом», на что получают ответ, что последние думают об этом, но услугу пока не запустили и, в принципе, здорово, что спросили, давайте проведем пилот с вами. Запрос был в конце 2019 года. В конце я напишу, в чём суть услуги БКИ.
SMS-шлюз. Финтех просто генерирует SMS с поздравлением c одобрением кредита, и bingo! — идут звонки от других банков на номера абонентов того самого сотового оператора, с кем у финтеха есть договор на проверку на спам. Звонки от уважаемых банков. Интересно.
Особенности реализации мобильного приложения
В случае Android полученный токен можно хранить в SharedPreferences (почему не AccountManager), а для iOS в KeyChain. См. обсуждение на SoF.
Четвёртый шаг. Проверить каждый контур
1 контур. Сама форма подачи заявки. ИТ финтеха генерирует фальшивые заявки от лица 20 человек, но не передает их дальше в кредитную машину, а оставляет на бэке заявки. Ждут два дня. Звонков нет. Контур чистый, двигаемся дальше.
2 контур. ИТ финтеха проталкивает заявки в кредитную машину, та стучится в БКИ и сотовому оператору. Проверяется гипотеза, что данные сливает сотрудник, который принимает решение по 10% заявок. Итог: звонки есть, но они есть как по заявкам, которые смотрел сотрудник, так и по тем, по которым система приняла решение автоматически.
Контур проверки сузился, значит, данные уходят из следующих источников:
сотовый оператор, проверяющий номера на мошенничество;
Но что было нетипично в этой истории, так это то, что звонки шли не всем клиентам.
Утечка паролей
Время от времени в руки злоумышленников попадают базы данных с паролями пользователей различных сервисов — из-за взломов, утечек и социальной инженерии. Пароль также могут украсть с помощью троянских программ или вирусов. Более того, вы сами могли нечаянно передать пароль мошенникам, например на поддельном сайте.
Дальше код подтверждения попытаются подобрать по уже описанной схеме.
Как защититься. Используйте для каждого сайта уникальный пароль. Это не так сложно, как кажется: например, добавьте к вашему обычному паролю несколько первых или последних символов из названия сайта. Так вы хотя бы защититесь от автоматического перебора, если мошенники украдут один из паролей.
Третий шаг. Аналитика и локализация контуров
Итак, что финтех имеет на текущий момент:
Действительно, идут звонки клиентам их компании с предложением взять кредит у конкурентов.
Звонки идут от известных компаний, значит, последние получают данные легально, но пока непонятно, как.
Звонят не всем клиентам.
Звонят после одобрения кредита финтехом.
Финтех разбивает подачу заявки на несколько контуров:
Сама форма подачи заявки на кредит. Что там есть? Так, есть «Яху. Метрика». Чисто теоретически, стоит счётчик с включенным веб-визором и каким-то ботом собираются персональные данные клиента под аккаунтом одного из сотрудников финтеха. Эту гипотезу отложили. Что еще? Данные кто-то берет с бэкенда заявки (до передачи в кредитную машину) и передает в сторонние компании под видом легальных «лидов».
Кредитная машина. У любой кредитной машины есть интеграция с несколькими бюро кредитных историй (далее — БКИ). Значит, чисто теоретически, бюро могут передавать информацию о клиентах. Также у кредитной машины есть интеграция с одним из сотовых операторов по проверке телефонных номеров клиентов, оформлены ли они на реальных людей, а не на «дропов» (проверка на мошенничество).
Сотрудник. Сотрудник имеет доступ к информации по примерно 10% заявок, которые поступают в серую зону.
SMS-шлюз. Каждому клиенту финтех присылает SMS "Поздравляем с одобрением кредита!"
Хорошо, пора двигаться дальше.
Заключение
Вышеописанный подход позволит вам в рамках вашего стека технологий реализовать указанную задачу. Если вас есть соображения по этому подходу или альтернативные подходы, то прошу поделиться в комментариях. Аналогичная просьба, если у вас есть примеры документации к безопасным
Шестой шаг. Завершение расследования
Поскольку у компании есть прямой контракт на проверку номеров на мошенничество с одним из сотовых операторов, и как раз были звонки его абонентам, то финтех просто задает вопрос: «Ребята, это что за дела? Вы почему передаете данные наших клиентов в сторонние банки?» Сотовый оператор честно и открыто отвечает, что есть такая модель бизнеса, и работает она так:
Сотовый оператор «читает» тематические SMS своих абонентов. В данном случае, про одобрение кредита. В онлайне оператор дообогащает информацию по абоненту данными из других источников (например, e-mail), и эти события легально передает компаниям, кому это интересно. По вполне официальному договору. А что с согласиями клиентов на передачу данных? Ну, во-первых, они передают только номер телефона (и иногда email), во-вторых, клиент при заключении договора с сотовым оператором уже дал все согласия (но здесь есть серая зона, если взяться за этот вопрос, то операторы будут не правы, всех согласий нет).
Триггеры срабатывают примерно на 20% абонентов, по кому успевает сработать событие.
Финтех договорился с сотовым оператором, что по его клиентам такой порог срабатываний триггеров будет ЗНАЧИТЕЛЬНО снижен или убран совсем, сотовый оператор пошел навстречу.
В завершение про БКИ — модель передачи клиентских данных такая:
Гражданин Иванов взял кредитную карту в банке РУСЬ. Банк отправил данный факт в БКИ.
РУСЬ подписывается в БКИ на событие, что если по Иванову пришел запрос в БКИ на проверку кредитной истории из других банков (например, Иванов решил взять потребительский кредит), то немедленно информируй об этом банк РУСЬ.
У Банка есть все персональные данные Иванова (помним, что он взял у РУСИ кредитную карту), после получения события он начинает предлагать Иванову прийти за потребом к нему.
Обзор векторов атак на мобильные телефоны
Ниже содержатся обзоры возможных векторов атак на мобильные телефоны без описания конкретных методик и действий. Основная задача поста — дать понять, что опасно, а что нет, и как можно защитить свои устройства. В качестве примеров используются известные работающие атаки на старые модели телефонов, либо варианты, закрытые уже почти на всех прошивках.
Можно ли прослушивать разговоры по мобильному телефону?
Да, можно. Сигнал шифруется, но, в целом, при перехвате сигнала прослушивание возможно. Чаще всего речь идёт о записи информации и последующей расшифровке, то есть работе не в реальном времени.
Для защиты сигнала используется три основных алгоритма: А3 для авторизации и защиты от клонирования, А8 для сервисных функций (генерации ключа), А5 — для шифрования речи. Самое интересное — в А5: у алгоритма есть две версии: первая используется в странах, где нет ограничения на технологии шифрования, вторая, менее стойкая и учитывающая региональные особенности — в других странах. По факту это означает что у нас и в большей части Европы сложность перебора ключа сильно падает.
Ещё одна уязвимость — это использование в некоторых странах не полноценного 64-битного ключа, а его аналога, где первые 10 бит заменяются нулями для совместимости с местными требованиями.
На практике для прослушивания телефона используется «чемоданчик» стоимостью около 20.000 долларов, который применяется для перехвата и расшифровки сигнала определённого абонента. Для исполнения атаки нужно находиться рядом с одним из собеседников, поэтому если за вами ходит странный парень с чемоданом — крепко задумайтесь.
Более простой способ прослушивания
Поскольку речь идёт об изъятии ключа, возможна более простая атака через физический доступ к SIM-карте. Карта вставляется в ридер, который делает около 140.000 обращений к ней, что позволяет получить ключ методом дифференциального криптоанализа. Процедура занимает около 8 часов и часто может вызвать срабатывание защиты SIM-карты (имеющей ограничение на количество обращений). Принцип защиты очень простой: не отдавайте свой телефон незнакомым людям на срок больше пары минут.
Замена станции
Ещё один способ дистанционной атаки — это установка ложной базовой станции, выполняющей ту же работу по перебору ключей удалённо. Процесс занимает около 10 часов (это в сумме, например, по часу в день — вполне реально). Наиболее вероятный сценарий — работа там, где нет сигнала. Пример атаки — ездить в одном вагоне метро с абонентом по полчаса в день. Тот же парень с чемоданом, следите за ним.
Как правильно менять SIM-карту
Если вы хотите уйти от спама или ещё чего-то более интересного, надо менять не только SIM-карту, но и сам телефон. Дело в том, что при каждом обращении к сети оператора, передаётся не только ключ карты, но и идентификатор телефона. Использование новой симки в старом телефоне или старой симки в новом в теории сразу нарушает анонимность.
Атака на навигационный модуль (WLAN)
Эта атака знакома тем, кто занимается безопасностью автомобилей. Мобильные терминалы часто используют MAC-адреса ближайших точек доступа для определения местоположения устройства (это Wi-Fi-точки и базовые станции). Можно установить аппаратуру, которая будет «вести» ваш терминал по городу, создавая нужные виртуальные станции — идеальная атака такого типа — это уход с маршрута и заезд туда, куда нужно злоумышленнику, например, при использовании мобильного телефона как навигатора. Атака похожа по исполнению на создание ложного GPS-сигнала, но требует куда менее специфическое оборудование.
Старые модели Nokia, Siemens, Motorola и LG подвержены атакам через SMS со специальными текстами. Используя определённые комбинации Unicode-символов можно удалённо отключить или «подвесить» многие модели старых телефонов и несколько — относительно новых. Разновидность этой атаки — вставка управляющих символов в SMS.
Телефон можно заблокировать DoS-атакой, посылая сервисные SMS в специальном «невидимом» формате. Речь идёт об использовании сервисного канала, собственно, на котором и был построен сервис SMS как таковой. Злоумышленник может сформировать невидимую SMS двумя типами: забив текст неотображаемыми символами (устройство не сможет раскодировать SMS и не покажет его): например, указать русскую кодировку для китайского языка — это не реальный пример, но есть реально «работающие» в этом плане языковые пары. Второй вариант — манипуляции с WAP-push. В отличие от обычного потока SMS, жертва атаки может даже не узнать, что телефон заблокирован — например, на переговорах, когда партнёр пытается дозвониться для передачи данных. Единственная индикация — некоторые телефоны при получении даже битых SMS включают подсветку.
Синие зубы
Bluetooth в стандартном режиме постоянно рассылает beacon'ы, что позволяет найти устройство со включенным каналом почти сразу. Скрытый блютуз, в теории, сканируется последовательными запросами около 3 лет, но на практике — за считанные минуты, потому что производители записывают в первый и последний октеты адреса свои идентификаторы и идентификаторы устройств. Отсканенный телефон можно подвергнуть атаке переполнением буфера или аналогом инъекции управляющего кода, как и в случае с SMS.
Следующая разновидность атаки — аутентификация в качестве гарнитуры по Bluetooth-каналу. Несмотря на то, что гарнитура считается read-only устройством, она вполне способна инициировать звонок с телефона, что приведёт к прослушиванию обычного разговора в помещении с помощью микрофона телефона.
В некоторых случаях доходит до того, что по «синезубому» каналу можно спокойно забирать адресную книгу, хранимые в телефоне SMS и другие данные. Или — ещё реже – производить операции записи, что должно порадовать параноиков.
Телефону при определённых усилиях можно представиться не только гарнитурой, но и компьютером, с которым происходит синхронизация. Интересная особенность — можно отдать vCalendar в формате, где дата выходит за пределы целочисленного типа — в старых моделях это обычно приводило к затиранию части системной области памяти и сбоям, лечащимся только перепрошивкой.
Сама гарнитура тоже может быть целью атаки: в ней есть микрофон, который часто интересно использовать злоумышленнику. При определённом наборе софта и железа можно спокойно представиться ей другим телефоном и получать данные с микрофона. Правда, надо подобрать PIN-код, но ситуация облегчается, если есть время на перебор. Большая часть пользователей гарнитур в дополнение не меняет забитый производителем PIN-код, что также облегчает атаку.
Шифрование NFC весьма надёжное, и критичных уязвимостей у протокола пока не нашлось. Поэтому пока единственная сколько-нибудь изученная атака, использующая NFC — это дублирование метки. Грубо говоря, злоумышленник считывает и дублирует метку киоска с газетами, а затем наносит её на киоск с шоколадками. Пользователь оплачивает шоколадку и тем самым передаёт данные устройству, содержащему дубль метки от газеты. Устройство отдаёт данные злоумышленнику, он получает газету.
Ещё некоторые прошивки первых NFC-устройств неверно парсят специально сконструированные метки с NDEF, содержащем заведомо неправильные данные, что также ведёт к аналогам инъекции кода или переполнению буфера. Возможны и соцнижиниринговые атаки, связанные с текстами в таких метках.
Решение — использовать возможности NFC там, где метки точно авторизованы — например, в метро. Сканировать NFC-метки в подворотнях не рекомендуется.
Интернет-атаки
Пожалуй, тут самое простое. Стандартный набор типа «не открывайте файлы от незнакомцев» и «не пользуйтесь почтой без SSL, когда сидите в кафе на открытом Wi-Fi» и так далее. Большая часть атак на высокоуровневые системы связана с установкой тех или иных программных «жучков»-троянов, умеющих снимать данные с камеры, микрофона и так далее.
Из интересных особенностей работы с сетью — есть возможность отправки специальной MMS в формате OMA/OTA для переконфигурирования телефона (так приходят настройки точки доступа от операторов) для замены DNS-сервера. Контроль над таким DNS позволяет получить всю историю посещений сайтов (но не трафик).
Основные векторы-2012
Если всё вышеперечисленное остаётся чем-то близким к кошмарам параноика (дорого и сложно в исполнении) и имеет смысл для атакующего только в достаточно экзотических случаях, есть область, которая создаёт всё больше и больше беспокойства. Речь о мобильных приложениях с дополнительными функциями.
В каждой экосистеме, связанной с мобильной ОС, можно найти примеры работающих «нечестных» приложений. Из наиболее ярких примеров – фонарик для Apple, который почему-то очень уверенно работал с передачей данных.
На данных векторах атаки социнжиниринг очень грамотно сочетается с реализацией различных уязвимостей софта, протоколов и железа. Пример – какой-либо эксплоит заворачивается в приложение-клон известного и начинает продаваться в магазине приложений системы.
Если в сегменте частных лиц закачка приложения может привести максимуму к неприятным эмоциям, то в корпоративном сегменте это настоящая огромная дыра: сотрудник ставит себе зловреда, а атакующий получает доступ ко всем корпоративным ресурсам, используя данный смартфон. Учитывая, что смартфоны часто очень плотно интегрируются в бизнес-среду, такие атаки вызывают всё больше и больше беспокойства – и становятся с каждым месяцем всё большей угрозой.
В качестве решения предлагается обучать пользователей (как мы знаем – не помогает на 100%), проводить модерацию приложений (но это тоже не 100% гарантия), ограничивать источники, например, только корпоративным «Маркетом» или же ставить антивирусы.
Сейчас основная тенденция — разрабатываются и внедряются решения управления мобильными устройствами сотрудников: это общие политики безопасности, жесткий контроль коммерческой информации, собственные наборы приложений, оперативные патчи, защищённые обменники медиаконтента и так далее.
Кто читает ваши SMS
Эту историю я услышал от своего друга из финтеха. История мне понравилась тем, что все мы стараемся защищать свои персональные данные, соблюдаем цифровую гигиену, но на самом базовом (я бы сказал, фундаментальном уровне) всё просто.
Итак, есть веб-сайт по приему заявок на потребительский кредит и кредитные карты. Клиент заходит на сайт, вбивает свои персональные данные и получает решение по кредиту. Упрощенная архитектура выглядит так:
Клиент подает заявку на кредит, она попадает в кредитную машину, основная часть заявок обрабатывается автоматически, примерно 10% из них относятся к «серой зоне» и поступают на ручную обработку: сотрудник смотрит заявку и решает — одобрить или отклонить. В случае одобрения, клиенту приходит SMS "Поздравляем с одобрением кредита!".
На одной из рабочих групп по разбору обращений клиентов сотрудники финтеха видят частотные тикеты вида: «не успел подать заявку, сразу начались звонки из банков и от брокеров с предложением взять кредит», «вы сливаете мою персуху», «что за помойка, не успел получить одобрение, пошли звонки из других банков». Сотрудники сначала решают, что это либо просто «выброс», либо такие обращения не частотные, либо это чьи-то шутки. Через месяц снова смотрят статистику обращений клиентов, и понимают, что "не показалось". Это проблема, с которой надо серьезно работать. Требуется расследование, и финтех его начинает.
Подозрительно: массовые смс с кодами активации от разных сервисов
С десятка номеров пришли однотипные смс, одно за другим — «Ваш код подтверждения…»:
Попробую разобраться, чего хотел автор этого скрипта. Некоторые варианты выглядят безобидно, другие в будущем могут стоить вам денег. Вот что приходит на ум:
Маскировка важного смс
Если увидели что-то подозрительное, пишите. Возможно, кто-то пытается украсть ваши деньги.
Попытка регистрации с подбором кода
Для рассылки спама с разводом и «мусорной» рекламой мошенники обычно создают аккаунты на чужое имя или используют взломанные. Смс с кодами активации могут говорить о том, что ваши аккаунты пытаются взломать — или зарегистрировать новые на ваш номер телефона.
При регистрации сервисы отправляют на указанный номер мобильного код проверки. Вводя этот код, вы подтверждаете, что номер принадлежит вам и вы соглашаетесь с регистрацией. У мошенника нет вашего телефона, но он может попытаться подобрать присланный вам код.
Чем длиннее код, тем сложнее это сделать. Например, если код состоит из четырех цифр, существует 10 тысяч разных вариантов, а если из шести — вариантов уже миллион.
Скрипт можно научить проверять все эти варианты и автоматически вводить коды проверки один за другим — от 000000 до 999999. Здесь все зависит от защиты сайта: ограничивает ли он количество попыток, если ограничивает, то сколько их. И можно ли повторить процедуру с тем же номером через какое-то время.
Чем больше попыток дает сайт, тем выше вероятность, что скрипт успеет подобрать код и подтвердить «вашу» учетную запись без доступа к телефону и тексту смс. Например, в 2017 году на «Хабре» писали про угон аккаунтов одного каршеринга.
Многие сайты защищены хуже, чем кажется. Специально для этой статьи я написал небольшой скрипт и попытался с его помощью подобрать шестизначный код подтверждения одной социальной сети. На удивление, сайт разрешил моему скрипту ввести больше ста разных кодов подтверждения — и только после этого сказал, что я слишком часто пытаюсь это сделать, и попросил подождать 10 минут.
Я не стал перезапускать скрипт. Но даже за одну попытку вероятность подбора — 100 к 1 000 000, то есть 0,01%. Если перебрать 10 тысяч номеров, один из них удастся подтвердить. А если длина кода всего четыре символа, то при тех же условиях хватит ста номеров, чтобы подобрать код к одному из них и получить доступ к подтвержденному аккаунту. После этого можно рассылать с него спам от чужого имени.
Как защититься. К сожалению, гарантированной защиты от такого взлома нет. Не исключено, что мошеннику удастся подобрать код и активировать аккаунт. Отдельная симкарта для интернета не поможет: мошенник все равно сможет зарегистрировать аккаунт на основную. Тут все зависит от безопасности конкретного сайта.
Если какие-то сайты вам важны или у вас уже есть там аккаунт, попробуйте сменить пароль или написать в техподдержку и описать ситуацию. Возможно, ваш аккаунт заблокируют и создадут новый или предложат какой-то другой вариант.
Читайте также: