Двухфакторная аутентификация. Новые вызовы
Вместо пролога: в данной статье речь пойдет о краже денег с аккаунтов пользователей платежных систем, различных клиент-банков и т.п.
Не секрет, что платежные и другие финансовые сервисы предъявляют повышенные требования к безопасности. В связи с этим применяются комплексные меры по защите как самой системы, так и аккаунтов пользователей. Для того чтобы предотвратить возможность взлома и выведения системы из строя применяются различные средства такие как:
- всевозможные файерволы, сейчас очень популярны WAF (Web Application Firewall),
- дублирование ключевых элементов системы,
- репликация данных; токенизация различных этапов работы системы,
- аппаратное шифрование при помощи HSM (Hardware Security Modules).
С точки зрения защиты аккаунта пользователя и его операций применяются как обычная парольная защита, так и другие средства:
- ограничение доступа по IP-адресу,
- кодовые карты, платежные пароли, PINы,
- биометрия,
- проверка окружения пользователя.
И конечно же инструменты двухфакторной аутентификации, ЭЦП (Электронная цифровая подпись) и бесконтактные токены — генераторы OTP (One-Time Password).
Я всегда считал, что двухфакторная аутентификация — панацея, чуть ли не от всех возможных уязвимостей в процессе аутентификации пользователя. Следуя последним трендам безопасности, как мы думали на тот момент, своим пользователям для аутентификации в нашей платежной системе мы рекомендовали использовать аппаратные токены (TOTP, его называют «токеном по-времени») ведущих мировых поставщиков или программный Authenticator от Google. Для подтверждения платежных операций (транзакций) использовались упомянутые выше токены, а для тех у кого их не было — мы требовали ввод одноразового пароля из SMS. Такая защита казалась нам абсолютно надежной, но если бы это было действительно так, то данной статьи не было бы…
Не буду долго ходить вокруг да около, перейду к делу. Однажды, на суппорт пришла заявка от разъяренного пользователя о том, что у него «обнулен» аккаунт, другими словами выведены все средства. После проведения первичного расследования мы увидели из истории операций, что все средства в штатном режиме за несколько транзакций были выведены на разные аккаунты самим пользователем. До этого никакой связи (операций) между пользователем и этими аккаунтами не имелось. После более детального рассмотрения и анализа всех данных, выяснилось, что этот пользователь стал жертвой «Автозалива» и «Реплэйсера».
Немного теории, собранной на просторах Интернета:
Автозалив — инжект с административной панелью, выполняющий автоматизированные и координированные действия в аккаунте жертвы исходя из положения/ситуации в аккаунте. Эта вредоносная программа собирает данные аккаунта, смотрит какие счета есть в аккаунте и отправляет данные в административную панель. В панели расположена таблица дропов и их состояния, примечания, данные счетов куда переводить средства, и в каком объеме, чтобы обойти лимиты и не вызвать подозрение. Панель на основании автоматических правил или посредством ручной координации выбирает дропа и выдаёт инжекту. Дальше несколько альтернативных вариантов:
вариант 1) инжект отображает пользователю окно с текстом на подобии «Подождите идёт проверка данных», а сам скрытно выполняет действия, приводящие к заливу денег на дропа, путем «кликанья» на нужные ссылки внутри аккаунта и заполнения форм запрашиваемых системой. В случае, если запрашивается ТАН/OTP/PIN код и прочее для завершения перевода, автозалив выдаёт фэйк-страницу холдеру с запросом этого самого кода, но уже под своим предлогом (разводом). Холдер вводит данные в фэйк, автозалив использует эти данные для продолжения/завершения залива.
вариант 2) инжект ждет, когда пользователь захочет выполнить легальную транзакцию для которой будет запрошен ТАН/OTP/PIN код, но этим кодом будет подтверждена нелегальная транзакция — залив денег на дропа.
После чего холдер допускается в аккаунт, на котором уже срабатывает реплэйсер.
Реплэйсер — программный код, нацеленный на скрытие данных перевода, сделанного автозаливом. Другими словами, подмена баланса — это скрытие перевода из истории переводов и прочие манипуляции нацеленные на то, чтобы холдер не заметил перевод. В нашем случае холдер видит фейковый баланс и фейковую легальную транзакцию.
В нашей системе есть различные средства многоуровневых проверок, например, сверка баланса и суммы транзакций пользователя, а также сверки балансов в нашей системе и внешних, и ряд других. Все это не помогло в данном случае, т.к. транзакция не взялась «из воздуха» и выглядела как вполне обычная.
Мы, конечно, слышали о различных типах атак и на практике часто сталкиваемся с разного рода фродом, но тут были мягко сказать удивлены. Хотя средства были «слиты» с аккаунта пользователя, для того чтобы избежать репутационных последствий руководство компании компенсировало часть потерь пострадавшему. Это было связано еще и с тем, что он был добросовестным клиентом с хорошими оборотами, и главное, у него были установлены все имеющиеся на тот момент средства защиты из нашего арсенала.
После некоторых поисков мы обнаружили, что подобный обход двухфакторной аутентификации уже хорошо известен, и для борьбы с этой уязвимостью многие передовые провайдеры предлагают схожие решения, они называются по разному (подпись данных, CWYS (Confirm What You See), но имеют схожую реализацию. Основной смысл заключается в том, что одноразовый пароль генерируется не только на основании секретного ключа, времени или счетчика, а с использованием всех ключевых данных транзакции, таких как сумма, валюта, получатель. В случае даже, если злоумышленник перехватит пароль, использовать для своих зловредных нужд он его не сможет. Тут все описано в деталях. Для внедрения данной фичи, мы контактировали с несколькими провайдерами, и сделали свой выбор.
Итак, пока вздохнули с облегчением… Ждем новые вызовы.
