Не секрет, что платежные и другие финансовые сервисы предъявляют повышенные требования к безопасности. В связи с этим применяются комплексные меры по защите как самой системы, так и аккаунтов пользователей. Для того чтобы предотвратить возможность взлома и выведения системы из строя применяются различные средства такие как:
- всевозможные файерволы, сейчас очень популярны 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), но имеют схожую реализацию. Основной смысл заключается в том, что одноразовый пароль генерируется не только на основании секретного ключа, времени или счетчика, а с использованием всех ключевых данных транзакции, таких как сумма, валюта, получатель. В случае даже, если злоумышленник перехватит пароль, использовать для своих зловредных нужд он его не сможет. Тут все описано в деталях. Для внедрения данной фичи, мы контактировали с несколькими провайдерами, и сделали свой выбор.
Итак, пока вздохнули с облегчением… Ждем новые вызовы.
Комментарии (50)
Sordi
06.08.2015 14:45+2Многие используют Google Authenticator app, выходит что это ненадежно?
Hyast
06.08.2015 14:51+3С целями, для которых его разработал Гугл он успешно справляется, а именно для процесса аутентификации в Гугл сервисах. Если мы говорим о подтверждении платежной операции, то это как “микроскопом дверь открывать”:) Надеюсь, ясно, что я имел в виду.
DonRydell
06.08.2015 14:46+2Удалось ли поймать хакеров? Они же как-то выводили деньги.
Hyast
06.08.2015 14:55+2Поймать кого-то в таких случаях очень трудно, т.к. деньги выводятся на подготовленные для таких ситуаций аккаунты, созданные на фейковые документы или во внешние системы, а с появлением криптовалют отследить что-то иногда представляется невозможным.
BeLove
06.08.2015 14:48+1Когда высылается смска с паролем, то обычно показывается куда (кому) осуществляется перевод. И юзер на этом моменте может заметить подвох (конечно, если телефон не протроянен). В этом плюс смс и большой минус программных OTP (например, от Google).
Hyast
06.08.2015 15:00+3Это верно. Мы тоже на это надеялись, но есть несколько моментов: 1) ОТР в смс не привязан к данным и может быть ситуация, когда в СМС попадет “нужная” информация; 2) смс может быть перехвачено, дублировано и т.д. 3) Не все пользователи обращают внимание на что-то еще, кроме ОТР в таких смс. К тому же, смс имеет ограничение на длину сообщения, и не все параметры, которые могут быть подвергнуты атаке реально отобразить в одном сообщении, например баланс до и после транзакции и т.д.
ionicman
06.08.2015 15:46Господа, а как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?
Ну и в СМС можно сразу открытым текстом писать «перевод денег с вашего счета на Васю Пупкина» + в случае, если идет перевод денег на счет ранее никогда не используемый владельцем, дополнительно что-то делать — запрашивать еще одно подтверждение и т.д.
Пример: для несвязанных переводов (т.е. куда пользователь никогда не платил, и не известных системе (это не ерц, или там известные телекомы) — запрашивать доп. OTP ну и все.DonRydell
06.08.2015 15:58Господа, а как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?
Скорее всего, связь кодов подтверждения была не с транзакциями, а с телефоном пользователя, т.е. подтверждалась не сама транзакция, а то, что человек владеет телефоном.
ildarz
06.08.2015 16:17как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?
Если я всё верно понял, то не обязательно так. Схема может быть такая:
1. Юзер пытается сделать операцию «кинуть 100 рублей на телефон».
2. Вредонос анализирует этот запрос и формирует страничку, визуально выглядящую, как запрос кода подтверждения для этой операции…
3.… но в банк отправляет данные на запрос подтверждения для «кинуть все деньги на аккаунт Мистера Х»ionicman
06.08.2015 16:22Т.е. юзер делает операцию «кинуть 100 рублей на телефон» в фейковом интерфейсе, а бот в это время делает в реальном перевод на другой аккаунт?
Если так, то я не правильно понял ситуацию.
В этом случае спасает сообщение + двойное подтверждение, ибо врядли до этого юзер имел дело с аккаунтом данного мистера.
Есть еще одна штука, почему не читают сообщения с OTP — очень часто они засраны рекламой, если этого не было — пользователи были бы более внимательны.
Hyast
06.08.2015 16:25Господа, а как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?
Вы говорите о варианте 2 (см. статью), но в этом пункте описан просто один из возможных вариантов развития событий.
В нашей системе привязка OTP к транзакции существовала, но злоумышленниками была подделана часть важных параметров в самой транзакции.
Пример: для несвязанных переводов (т.е. куда пользователь никогда не платил, и не известных системе (это не ерц, или там известные телекомы) — запрашивать доп. OTP ну и все.
OTP и так запрашивался, какие дополнительные средства защиты Вы имеете в виду?ionicman
06.08.2015 16:32Грубо говоря следующие действия:
1) от имени юзера происходит операция, запрашивается OTP на нее
2) на телефон юзера приходит сообщение «Перевод XXX рублей на счет ZZZZ, если вы подтверждаете это, используйте код YYYY
3) пользователь не читает, вводит YYYY
4) система в банке проверяет, имел ли дело данный пользователь с этим счетом, если нет — генерит еще один OTP
5) приходит еще одна смс — вы не разу не работали с данным счетом и действительно хотите перевести на него XXX рублей? Для подтверждения используйте код CCCC
На второй раз пользователь очень вероятно, что поглядит текст СМС. Это не панаяцея, но думается, что большинство людей не попадутся.
Главное, что сообщение об отсутствии взаимодействия с данным счетом приходило именно вторым, не первым. Первое никогда не читают.Hyast
06.08.2015 16:45+1Думаю, что в предложенном подходе есть недостаток, т.к. Вы предлагаете использовать второй раз тот же самый фактор (смс-ки), а он может быть скомпрометирован. Надо использовать другой фактор, но среди пользователей не будет популярен такой “удобный сервис”.
Многие не включают даже простую двухфакторную аутентификацию, что говорить о таких сложных пируэтах )ionicman
06.08.2015 16:49Если таких вариантов не много (подозрительные транзакции) — я, к сожалению, не знаю статистики — но Вы знаете — может есть вариант обзванивать данных пользователей, до подтверждения транзакции со стороны банка ( т.е. после OTP от пользователя ).
Если же их много, то да, вопрос, как обойтись…
anmiles
07.08.2015 13:33Например, сбербанк присылает для подтверждения таким образом сконструированные смски, что пользователь никак не сможет их «не прочитать», ибо код находится в самом конце сообщения, а в превью сообщения, которое выводится в статус бар, попадают данные операции. То есть надо два раза «закрыть глаза» на текст, чтобы не заметить подставы.
vlivyur
07.08.2015 14:34При этом перевод с карты на карту выглядит как «Сбербанк Онлайн. Внимательно проверьте реквизиты операции: карта списания **** XXXX, карта зачисления **** YYYY, сумма ZZZZ RUB. Пароль для подтверждения данной операции — AAAA» и всё. Из этого длинного сообщения ценной информацией является только YYYY, а это всего 4 цифры. Хотя при оплатах через платёжные шлюзы смска выглядит вполне лаконично: «назначение (RUB сумма) пароль: цифры. Не сообщайте этот пароль никому, в том числе сотруднику Банка»
anmiles
07.08.2015 14:44Да, если был перевод на карту. Или что-нибудь поинформативнее, если это, скажем, оплата мобильного или каких-нибудь услуг. Я проверяю во всех случаях :)
А платёжные шлюзы… неужели их интерфейсы тоже уязвимы к взлому??
Dinir102
07.08.2015 20:24А я, когда приходит смс, смотрел в статус бар, пока он не прокрутит до кода подтверждения. Благо фильтровать информацию с сайтов умею и попадаюсь на зловреды ну максимум раз в пару месяцев. Теперь буду внимательным :)
anmiles
07.08.2015 20:31Кстати да, иногда тоже так делаю, если не тороплюсь никуда. Всё равно до конца долистает. И есть время дочитать и убедиться что всё ок :)
drMildrex
06.08.2015 16:30запрашивать доп. OTP ну и все
двойное подтверждение
Вы не могли бы привести реальные примеры, где на одну операции отправляется 2 OTP?
Я могу ошибаться, но с точки зрения пользователя это не очень удобно.ionicman
06.08.2015 16:36Любая защита — это вообще не удобно для пользователя.
Тут соблюдается баланс — в случае, если пользователь имеет отношение с публичными компаниями — OTP будет спрошен один раз. Это не доставит никаких неудобств.
В случае подозрения будет спрошено два раза — это во-первых даст возможность в случае проведения таки такого платежа, ткнуть, что Вас предупреждали два раза, во-вторых сильно повысит внимательность пользователя, но да, через его неудобство, увы.Hyast
06.08.2015 16:55Зачем все эти сложности? В статье описан более удобный и дешевый (ведь каждая дополнительная отправка SMS стоит денег) способ защиты, который позволяет избежать неудобств пользователя и дополнительных расходов системы, связанных с двойной отправкой OTP, и при этом отлично справляется с угрозами автозалива и реплейсмента.
ionicman
06.08.2015 17:09Вы про CWYS?
Там тоже не все гладко, если пользователь работает через фейковый интерфейс, то все данные за него формирует он.
Ну или я не понимаю технологию. Смотрите:
1) пользователь в фейкфейсе делает транзакцию на 100 рублей
2) в реальном интерфейсе делают перевод на 1000р — вся информация попадает в OTP, окей
3) пользователь вводит код (который от совсем другой операции) и подтверждает его
4) и где защита?Hyast
06.08.2015 18:01Есть несколько точек контроля: во-первых, в приложении отображается информация о том, куда реально уйдут деньги (как и для случая с смс); во-вторых, есть встроенные механизмы контроля целостности и согласованности данных фронтэнда и бекэнда, которые получают информацию по разным каналам; в-третьих, забегая наперед, генерация ОТР и подтверждение транзакции происходит в несколько этапов, при подмене данных между этапами взаимодействия, ОТР попросту будет не валиден.
Valle
06.08.2015 18:16Мне тоже интересно, но ответ я не понял. Зловред полностью контролирует клиентскую сторону, с точки зрения бэкенда все будет совершенно валидно — пользователь хочет перевести все деньги на другой аккаунт и зловред предоставил для этого все данные. Единственное что другое для клиента — это цифирьки подтверждения, но они не говорят, это ли перевод сотни на телефон или же обнуление аккаунта. Единственное что может пойти «не так» — это если код идет через смс где указаны реальные данные транзакции.
Sordi
06.08.2015 21:26-1Единственное что другое для клиента — это цифирьки подтверждения, но они не говорят, это ли перевод сотни на телефон или же обнуление аккаунта.
Да, они говорят серверу
Единственное что может пойти «не так» — это если код идет через смс где указаны реальные данные транзакции.
Для данного кейса этого достаточно для предотвращения кражи
Sordi
06.08.2015 21:152) в реальном интерфейсе делают перевод на 1000р — вся информация попадает в OTP, окей
В этом случае пользователь получит сообщение, что он переводит 1000р (кому и какой баланс) и пункт №3 не произойдет.ionicman
07.08.2015 19:56Изначально посыл был в том, что пользователи далеко не всегда читают то, что пришло с кодом подтверждения. Т.е. CWYS здесь ничем не лучше обычных OTP — про что я, собственно, Вам и написал :) И в данном случае он ничем не поможет, ИМХО. Пользователь тупо подтвердит транзакцию, ну да, зато теперь подписанную :)
ionicman
06.08.2015 16:39По поводу примеров.
Могу привести Райфазен, правда там было не совсем OTP ))
При подозрительной транзакции, после подтверждения со мной связались из банка, проверили меня секретным вопросом и уточнили, реально ли я хочу сделать данную транзакцию.
summeroff
06.08.2015 18:54+3Звонившие как нибудь подтвердили что они именно из банка вам звонят?
macik_spb
06.08.2015 22:02Да-да… пришла тут на днях СМСка «ваша карта скомпромитирована, срочно позвоните в сбербанк и городской номер +7812....»
Если бы не номер с которого пришла СМС — +44… я бы возможно дернулся позвонить или по крайней мере достать карту и посмотреть на ней номер Сбера (+8800...)
ionicman
07.08.2015 20:01Звонок был с номера банка, звонившая была моим менеджером этого банка (представилась, назвала ФИО и должность — я уже работал с ней в этом банке) и сказала секретную фразу банка — так что подтвердили 3 способами ;)
jamepock
06.08.2015 21:03Секретный вопрос — та ещё штука в плане безопастности. Достаточно много банков по дефолту ставят ответом фамилию, например.
gusak
07.08.2015 10:09-1Можно было сделать так:
1. Пользователь задает свой пароль для проведения транзакции\входа в кабинет и тп.
2. Выдается пользователю OTP.
3. Для подтверждения перевода пользователь вводить свой пароль + код с OTP.vlivyur
07.08.2015 10:20Это не спасёт от перевода денег по левым реквизитам самим пользователем (пользователь видит одно, а подтверждает совсем другое).
xBrowser
07.08.2015 12:32руководство компании компенсировало часть потерь пострадавшему
Почему только часть потерь и какую? Расскажите, пожалуйста, точку зрения компании в данной ситуации. Спустя какое время клиент пожаловался? Какую часть средств удалось «отбить» у злоумышленников? Как быстро надо сообщить в поддержку для того, чтобы успеть отменить транзакции? Детектирует ли какое-либо антивирусное ПО этот вид зловредов?Hyast
07.08.2015 14:06-1Почему только часть потерь и какую? Расскажите, пожалуйста, точку зрения компании в данной ситуации.
В РФ и большинстве других стран, в отличии от Японии, например, финансовые учреждения не несут ответственность за утерю пользователем средств с его счета. Вся ответственность лежит на самом пользователе. Следовательно, мы могли вообще не возмещать данному пользователю его потери. Но учитывая то, что этот юзер является нашим давним клиентом с большими оборотами и использовал все средства защиты, предлагаемые нашим сервисом, руководством компании было принято решение о возмещении большей части его потерь.
Какую часть средств удалось «отбить» у злоумышленников? Как быстро надо сообщить в поддержку для того, чтобы успеть отменить транзакции?
В нашей системе не поддерживается диспут и транзакции являются необратимыми. Клиент пожаловался в тот же день, часть украденных денег была заблокирована в партнерских платежках и возвращена, но основная часть была выведена злоумышленником в криптовалюты и дальнейший путь отследить не удалось.
Детектирует ли какое-либо антивирусное ПО этот вид зловредов?
Подобный софт затачивается конкретно под определенную систему и часто трудно диагностируем. В нашем случае антивирус пользователя не сработал.Valle
09.08.2015 21:02Что, это правда? А если стал жертвой card fraud, тоже нельзя транзакцию отменить? Но это же означает, что банковскими услугами в россии пользоваться нельзя т.к. есть риск потерять все сбережения по независящим от клиента причинам.
Hyast
10.08.2015 14:35+1Прямым приемом платежей с карт мы не занимаемся, работаем через партнеров. Потому вся ответственность за безопасность таких платежей переноситься на партнеров, у которых есть собственные специалисты по безопасности, anti-fraud фильтры, механизмы верификации и другие стандартные инструменты безопасности.
Shrike
18.08.2015 14:48В РФ и большинстве других стран, в отличии от Японии, например, финансовые учреждения не несут ответственность за утерю пользователем средств с его счета. Вся ответственность лежит на самом пользователе. Следовательно, мы могли вообще не возмещать данному пользователю его потери.
Да ну. По закону 161-ФЗ, банк должен доказать, что был факт утери. В противном случае он обязан возместить потери клиента.
Статья 9
13. В случае, если оператор по переводу денежных средств не исполняет обязанность по информированию клиента о совершенной операции в соответствии с «частью 4» настоящей статьи, оператор по переводу денежных средств обязан возместить клиенту сумму операции, о которой клиент не был проинформирован и которая была совершена без согласия клиента.
14. В случае, если оператор по переводу денежных средств исполняет обязанность по информированию клиента о совершенной операции в соответствии с «частью 4» настоящей статьи и клиент не направил оператору по переводу денежных средств уведомление в соответствии с «частью 11» настоящей статьи, оператор по переводу денежных средств не обязан возместить клиенту сумму операции, совершенной без согласия клиента.
15. В случае, если оператор по переводу денежных средств исполняет обязанность по уведомлению клиента — физического лица о совершенной операции в соответствии с «частью 4» настоящей статьи и клиент — физическое лицо направил оператору по переводу денежных средств уведомление в соответствии с «частью 11» настоящей статьи, оператор по переводу денежных средств должен возместить клиенту сумму указанной операции, совершенной без согласия клиента до момента направления клиентом — физическим лицом уведомления. В указанном случае оператор по переводу денежных средств обязан возместить сумму операции, совершенной без согласия клиента, если не докажет, что клиент нарушил порядок использования электронного средства платежа, что повлекло совершение операции без согласия клиента — физического лица.
Walis
12.08.2015 12:58+1Из ссылок в статье могу предположить, что у вас двухфакторная аутентификация от https://www.protectimus.com. Так ли это? И если да, то почему выбрали именно этот сервис? Кто еще предоставляет CWYS-решения по защите от автозалива?
Hyast
12.08.2015 16:20+1Вы правильно догадались, но не хотелось бы рекламировать тот или иной сервис, пусть люди решают сами. Если есть вопросы по процессу интеграции и выбору поставщика — напишите в личку, постараюсь ответить на все вопросы.
tgilartem
Интересная статья. О какой платежке идет речь?
Hyast
Спасибо, я старался. В статье я писал о репутационных рисках. Именно поэтому я не могу ответить на данный вопрос. Скажу одно: думаю, что о нас Вы слышали.