Двухфакторная аутентификация. Новые вызовы

    Вместо пролога: в данной статье речь пойдет о краже денег с аккаунтов пользователей платежных систем, различных клиент-банков и т.п.

    image


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

    • всевозможные файерволы, сейчас очень популярны 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), но имеют схожую реализацию. Основной смысл заключается в том, что одноразовый пароль генерируется не только на основании секретного ключа, времени или счетчика, а с использованием всех ключевых данных транзакции, таких как сумма, валюта, получатель. В случае даже, если злоумышленник перехватит пароль, использовать для своих зловредных нужд он его не сможет. Тут все описано в деталях. Для внедрения данной фичи, мы контактировали с несколькими провайдерами, и сделали свой выбор.

    Итак, пока вздохнули с облегчением… Ждем новые вызовы.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 51

      +3
      Интересная статья. О какой платежке идет речь?
        +4
        Спасибо, я старался. В статье я писал о репутационных рисках. Именно поэтому я не могу ответить на данный вопрос. Скажу одно: думаю, что о нас Вы слышали.
        +2
        Многие используют Google Authenticator app, выходит что это ненадежно?
          +3
          С целями, для которых его разработал Гугл он успешно справляется, а именно для процесса аутентификации в Гугл сервисах. Если мы говорим о подтверждении платежной операции, то это как “микроскопом дверь открывать”:) Надеюсь, ясно, что я имел в виду.
          +2
          Удалось ли поймать хакеров? Они же как-то выводили деньги.
            +2
            Поймать кого-то в таких случаях очень трудно, т.к. деньги выводятся на подготовленные для таких ситуаций аккаунты, созданные на фейковые документы или во внешние системы, а с появлением криптовалют отследить что-то иногда представляется невозможным.
            +1
            Когда высылается смска с паролем, то обычно показывается куда (кому) осуществляется перевод. И юзер на этом моменте может заметить подвох (конечно, если телефон не протроянен). В этом плюс смс и большой минус программных OTP (например, от Google).
              +3
              Это верно. Мы тоже на это надеялись, но есть несколько моментов: 1) ОТР в смс не привязан к данным и может быть ситуация, когда в СМС попадет “нужная” информация; 2) смс может быть перехвачено, дублировано и т.д. 3) Не все пользователи обращают внимание на что-то еще, кроме ОТР в таких смс. К тому же, смс имеет ограничение на длину сообщения, и не все параметры, которые могут быть подвергнуты атаке реально отобразить в одном сообщении, например баланс до и после транзакции и т.д.
              0
              Господа, а как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?

              Ну и в СМС можно сразу открытым текстом писать «перевод денег с вашего счета на Васю Пупкина» + в случае, если идет перевод денег на счет ранее никогда не используемый владельцем, дополнительно что-то делать — запрашивать еще одно подтверждение и т.д.

              Пример: для несвязанных переводов (т.е. куда пользователь никогда не платил, и не известных системе (это не ерц, или там известные телекомы) — запрашивать доп. OTP ну и все.
                0
                Господа, а как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?

                Скорее всего, связь кодов подтверждения была не с транзакциями, а с телефоном пользователя, т.е. подтверждалась не сама транзакция, а то, что человек владеет телефоном.
                  –2
                  Ну это очень и очень плохо с точки зрения безопасности. ИМХО.
                  0
                  как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?


                  Если я всё верно понял, то не обязательно так. Схема может быть такая:

                  1. Юзер пытается сделать операцию «кинуть 100 рублей на телефон».
                  2. Вредонос анализирует этот запрос и формирует страничку, визуально выглядящую, как запрос кода подтверждения для этой операции…
                  3.… но в банк отправляет данные на запрос подтверждения для «кинуть все деньги на аккаунт Мистера Х»
                    0
                    Т.е. юзер делает операцию «кинуть 100 рублей на телефон» в фейковом интерфейсе, а бот в это время делает в реальном перевод на другой аккаунт?

                    Если так, то я не правильно понял ситуацию.

                    В этом случае спасает сообщение + двойное подтверждение, ибо врядли до этого юзер имел дело с аккаунтом данного мистера.

                    Есть еще одна штука, почему не читают сообщения с OTP — очень часто они засраны рекламой, если этого не было — пользователи были бы более внимательны.
                    0
                    Господа, а как получилось что PIN/TAN/OTP от одной операции у Вас подходит к другой операции?

                    Вы говорите о варианте 2 (см. статью), но в этом пункте описан просто один из возможных вариантов развития событий.

                    В нашей системе привязка OTP к транзакции существовала, но злоумышленниками была подделана часть важных параметров в самой транзакции.

                    Пример: для несвязанных переводов (т.е. куда пользователь никогда не платил, и не известных системе (это не ерц, или там известные телекомы) — запрашивать доп. OTP ну и все.

                    OTP и так запрашивался, какие дополнительные средства защиты Вы имеете в виду?
                      0
                      Грубо говоря следующие действия:
                      1) от имени юзера происходит операция, запрашивается OTP на нее
                      2) на телефон юзера приходит сообщение «Перевод XXX рублей на счет ZZZZ, если вы подтверждаете это, используйте код YYYY
                      3) пользователь не читает, вводит YYYY
                      4) система в банке проверяет, имел ли дело данный пользователь с этим счетом, если нет — генерит еще один OTP
                      5) приходит еще одна смс — вы не разу не работали с данным счетом и действительно хотите перевести на него XXX рублей? Для подтверждения используйте код CCCC

                      На второй раз пользователь очень вероятно, что поглядит текст СМС. Это не панаяцея, но думается, что большинство людей не попадутся.
                      Главное, что сообщение об отсутствии взаимодействия с данным счетом приходило именно вторым, не первым. Первое никогда не читают.
                        +3
                        Я бы проклял такой сервис :)
                          0
                          А потерять все деньги? Что лучше?

                          Во-вторых, еще раз — в случае публичных компаний Вы вообще ничего не заметите — OTP будет один.
                          +1
                          Думаю, что в предложенном подходе есть недостаток, т.к. Вы предлагаете использовать второй раз тот же самый фактор (смс-ки), а он может быть скомпрометирован. Надо использовать другой фактор, но среди пользователей не будет популярен такой “удобный сервис”.

                          Многие не включают даже простую двухфакторную аутентификацию, что говорить о таких сложных пируэтах )
                            0
                            Если таких вариантов не много (подозрительные транзакции) — я, к сожалению, не знаю статистики — но Вы знаете — может есть вариант обзванивать данных пользователей, до подтверждения транзакции со стороны банка ( т.е. после OTP от пользователя ).

                            Если же их много, то да, вопрос, как обойтись…
                          • UFO just landed and posted this here
                              0
                              При этом перевод с карты на карту выглядит как «Сбербанк Онлайн. Внимательно проверьте реквизиты операции: карта списания **** XXXX, карта зачисления **** YYYY, сумма ZZZZ RUB. Пароль для подтверждения данной операции — AAAA» и всё. Из этого длинного сообщения ценной информацией является только YYYY, а это всего 4 цифры. Хотя при оплатах через платёжные шлюзы смска выглядит вполне лаконично: «назначение (RUB сумма) пароль: цифры. Не сообщайте этот пароль никому, в том числе сотруднику Банка»
                              • UFO just landed and posted this here
                                0
                                А я, когда приходит смс, смотрел в статус бар, пока он не прокрутит до кода подтверждения. Благо фильтровать информацию с сайтов умею и попадаюсь на зловреды ну максимум раз в пару месяцев. Теперь буду внимательным :)
                                • UFO just landed and posted this here
                          0
                          запрашивать доп. OTP ну и все

                          двойное подтверждение

                          Вы не могли бы привести реальные примеры, где на одну операции отправляется 2 OTP?
                          Я могу ошибаться, но с точки зрения пользователя это не очень удобно.
                            0
                            Любая защита — это вообще не удобно для пользователя.
                            Тут соблюдается баланс — в случае, если пользователь имеет отношение с публичными компаниями — OTP будет спрошен один раз. Это не доставит никаких неудобств.
                            В случае подозрения будет спрошено два раза — это во-первых даст возможность в случае проведения таки такого платежа, ткнуть, что Вас предупреждали два раза, во-вторых сильно повысит внимательность пользователя, но да, через его неудобство, увы.
                              0
                              Зачем все эти сложности? В статье описан более удобный и дешевый (ведь каждая дополнительная отправка SMS стоит денег) способ защиты, который позволяет избежать неудобств пользователя и дополнительных расходов системы, связанных с двойной отправкой OTP, и при этом отлично справляется с угрозами автозалива и реплейсмента.
                                0
                                Вы про CWYS?
                                Там тоже не все гладко, если пользователь работает через фейковый интерфейс, то все данные за него формирует он.

                                Ну или я не понимаю технологию. Смотрите:
                                1) пользователь в фейкфейсе делает транзакцию на 100 рублей
                                2) в реальном интерфейсе делают перевод на 1000р — вся информация попадает в OTP, окей
                                3) пользователь вводит код (который от совсем другой операции) и подтверждает его
                                4) и где защита?
                                  0
                                  Есть несколько точек контроля: во-первых, в приложении отображается информация о том, куда реально уйдут деньги (как и для случая с смс); во-вторых, есть встроенные механизмы контроля целостности и согласованности данных фронтэнда и бекэнда, которые получают информацию по разным каналам; в-третьих, забегая наперед, генерация ОТР и подтверждение транзакции происходит в несколько этапов, при подмене данных между этапами взаимодействия, ОТР попросту будет не валиден.
                                    0
                                    Мне тоже интересно, но ответ я не понял. Зловред полностью контролирует клиентскую сторону, с точки зрения бэкенда все будет совершенно валидно — пользователь хочет перевести все деньги на другой аккаунт и зловред предоставил для этого все данные. Единственное что другое для клиента — это цифирьки подтверждения, но они не говорят, это ли перевод сотни на телефон или же обнуление аккаунта. Единственное что может пойти «не так» — это если код идет через смс где указаны реальные данные транзакции.
                                      –1
                                      Единственное что другое для клиента — это цифирьки подтверждения, но они не говорят, это ли перевод сотни на телефон или же обнуление аккаунта.

                                      Да, они говорят серверу
                                      Единственное что может пойти «не так» — это если код идет через смс где указаны реальные данные транзакции.

                                      Для данного кейса этого достаточно для предотвращения кражи
                                    0
                                    2) в реальном интерфейсе делают перевод на 1000р — вся информация попадает в OTP, окей

                                    В этом случае пользователь получит сообщение, что он переводит 1000р (кому и какой баланс) и пункт №3 не произойдет.
                                      0
                                      Изначально посыл был в том, что пользователи далеко не всегда читают то, что пришло с кодом подтверждения. Т.е. CWYS здесь ничем не лучше обычных OTP — про что я, собственно, Вам и написал :) И в данном случае он ничем не поможет, ИМХО. Пользователь тупо подтвердит транзакцию, ну да, зато теперь подписанную :)
                                0
                                По поводу примеров.
                                Могу привести Райфазен, правда там было не совсем OTP ))

                                При подозрительной транзакции, после подтверждения со мной связались из банка, проверили меня секретным вопросом и уточнили, реально ли я хочу сделать данную транзакцию.
                                  +3
                                  Звонившие как нибудь подтвердили что они именно из банка вам звонят?
                                    0
                                    Да-да… пришла тут на днях СМСка «ваша карта скомпромитирована, срочно позвоните в сбербанк и городской номер +7812....»
                                    Если бы не номер с которого пришла СМС — +44… я бы возможно дернулся позвонить или по крайней мере достать карту и посмотреть на ней номер Сбера (+8800...)
                                      0
                                      Звонок был с номера банка, звонившая была моим менеджером этого банка (представилась, назвала ФИО и должность — я уже работал с ней в этом банке) и сказала секретную фразу банка — так что подтвердили 3 способами ;)
                                    • UFO just landed and posted this here
                                    –1
                                    Можно было сделать так:
                                    1. Пользователь задает свой пароль для проведения транзакции\входа в кабинет и тп.
                                    2. Выдается пользователю OTP.
                                    3. Для подтверждения перевода пользователь вводить свой пароль + код с OTP.
                                      0
                                      Это не спасёт от перевода денег по левым реквизитам самим пользователем (пользователь видит одно, а подтверждает совсем другое).
                                      0
                                      руководство компании компенсировало часть потерь пострадавшему

                                      Почему только часть потерь и какую? Расскажите, пожалуйста, точку зрения компании в данной ситуации. Спустя какое время клиент пожаловался? Какую часть средств удалось «отбить» у злоумышленников? Как быстро надо сообщить в поддержку для того, чтобы успеть отменить транзакции? Детектирует ли какое-либо антивирусное ПО этот вид зловредов?
                                        –1
                                        Почему только часть потерь и какую? Расскажите, пожалуйста, точку зрения компании в данной ситуации.

                                        В РФ и большинстве других стран, в отличии от Японии, например, финансовые учреждения не несут ответственность за утерю пользователем средств с его счета. Вся ответственность лежит на самом пользователе. Следовательно, мы могли вообще не возмещать данному пользователю его потери. Но учитывая то, что этот юзер является нашим давним клиентом с большими оборотами и использовал все средства защиты, предлагаемые нашим сервисом, руководством компании было принято решение о возмещении большей части его потерь.

                                        Какую часть средств удалось «отбить» у злоумышленников? Как быстро надо сообщить в поддержку для того, чтобы успеть отменить транзакции?

                                        В нашей системе не поддерживается диспут и транзакции являются необратимыми. Клиент пожаловался в тот же день, часть украденных денег была заблокирована в партнерских платежках и возвращена, но основная часть была выведена злоумышленником в криптовалюты и дальнейший путь отследить не удалось.

                                        Детектирует ли какое-либо антивирусное ПО этот вид зловредов?

                                        Подобный софт затачивается конкретно под определенную систему и часто трудно диагностируем. В нашем случае антивирус пользователя не сработал.
                                          0
                                          Что, это правда? А если стал жертвой card fraud, тоже нельзя транзакцию отменить? Но это же означает, что банковскими услугами в россии пользоваться нельзя т.к. есть риск потерять все сбережения по независящим от клиента причинам.
                                            0
                                            А теперь банки предлагают застраховать операции по картам всего за пару тысяч рублей в год. Уверяют что всё-всё вернут при любых несанкционированных операциях.
                                              0
                                              А если не застраховать, то не вернут?
                                              +1
                                              Прямым приемом платежей с карт мы не занимаемся, работаем через партнеров. Потому вся ответственность за безопасность таких платежей переноситься на партнеров, у которых есть собственные специалисты по безопасности, anti-fraud фильтры, механизмы верификации и другие стандартные инструменты безопасности.
                                                +1
                                                А, тогда ясно, спасибо. Вроде как централизированный биткоин.
                                              0
                                              В РФ и большинстве других стран, в отличии от Японии, например, финансовые учреждения не несут ответственность за утерю пользователем средств с его счета. Вся ответственность лежит на самом пользователе. Следовательно, мы могли вообще не возмещать данному пользователю его потери.


                                              Да ну. По закону 161-ФЗ, банк должен доказать, что был факт утери. В противном случае он обязан возместить потери клиента.

                                              Статья 9
                                              13. В случае, если оператор по переводу денежных средств не исполняет обязанность по информированию клиента о совершенной операции в соответствии с «частью 4» настоящей статьи, оператор по переводу денежных средств обязан возместить клиенту сумму операции, о которой клиент не был проинформирован и которая была совершена без согласия клиента.

                                              14. В случае, если оператор по переводу денежных средств исполняет обязанность по информированию клиента о совершенной операции в соответствии с «частью 4» настоящей статьи и клиент не направил оператору по переводу денежных средств уведомление в соответствии с «частью 11» настоящей статьи, оператор по переводу денежных средств не обязан возместить клиенту сумму операции, совершенной без согласия клиента.

                                              15. В случае, если оператор по переводу денежных средств исполняет обязанность по уведомлению клиента — физического лица о совершенной операции в соответствии с «частью 4» настоящей статьи и клиент — физическое лицо направил оператору по переводу денежных средств уведомление в соответствии с «частью 11» настоящей статьи, оператор по переводу денежных средств должен возместить клиенту сумму указанной операции, совершенной без согласия клиента до момента направления клиентом — физическим лицом уведомления. В указанном случае оператор по переводу денежных средств обязан возместить сумму операции, совершенной без согласия клиента, если не докажет, что клиент нарушил порядок использования электронного средства платежа, что повлекло совершение операции без согласия клиента — физического лица.
                                            +1
                                            Из ссылок в статье могу предположить, что у вас двухфакторная аутентификация от https://www.protectimus.com. Так ли это? И если да, то почему выбрали именно этот сервис? Кто еще предоставляет CWYS-решения по защите от автозалива?
                                              +1
                                              Вы правильно догадались, но не хотелось бы рекламировать тот или иной сервис, пусть люди решают сами. Если есть вопросы по процессу интеграции и выбору поставщика — напишите в личку, постараюсь ответить на все вопросы.
                                              0
                                              Я думаю, что с помощью совместного (связанного) использования капчи и СМС с кодом подтверждения(инструкцией) можно гарантировано обезопасить клиента от автозалива и реплейсера.
                                              Вот простенький пример, сделанный на скорую руку, иллюстрирующий суть идеи:
                                              1. на странице банка(платежной системы) информация выводится в виде картинки примерно такого вида
                                              image
                                              2. по СМС приходит инструкция примерно следующего содержания:
                                              Для подтверждения перевода на сумму ХХХХХ.ХХ со счета ЯЯЯЯ на счет ОООО введите сумму первых 3-х зеленых цифр а затем с 3-й по 8-ю красную цифру

                                              Цветовая схема капчи и условия ввода в инструкции должны быть индивидуальными для каждой операции, и подобраны так, чтобы исключить анализ цветовой схемы и содержания условий ввода по данным введенной пользователем.
                                              Условие ввода должно включать в себя важные (ключевые) данные о переводе. То есть в него должны войти цифры из суммы перевода и номеров счетов участников.

                                              Если выполнить все эти условия, то будет крайне затруднительно (на мой взгляд — невозможно) использовать код полученный выполнением инструкции из СМС для перевода не соответствующего указанному на картинке.

                                              ЗЫ: данная схема не учитывает вариант, когда телефон пользователя также скомпрометирован.

                                              Only users with full accounts can post comments. Log in, please.