Topic: Двухфакторная аутентификация. Новые вызо (Read 757 times)
Ух, шайтан. Вот извращенцы.
Двухфакторная аутентификация. Новые вызовы
...
Я всегда считал, что двухфакторная аутентификация — панацея, чуть ли не от всех возможных уязвимостей в процессе аутентификации пользователя. Следуя последним трендам безопасности, как мы думали на тот момент, своим пользователям для аутентификации в нашей платежной системе мы рекомендовали использовать аппаратные токены (TOTP, его называют “токеном по-времени”) ведущих мировых поставщиков или программный Authenticator от Google. Для подтверждения платежных операций (транзакций) использовались упомянутые выше токены, а для тех у кого их не было — мы требовали ввод одноразового пароля из SMS. Такая защита казалась нам абсолютно надежной, но если бы это было действительно так, то данной статьи не было бы…
Не буду долго ходить вокруг да около, перейду к делу. Однажды, на суппорт пришла заявка от разъяренного пользователя о том, что у него “обнулен” аккаунт, другими словами выведены все средства. После проведения первичного расследования мы увидели из истории операций, что все средства в штатном режиме за несколько транзакций были выведены на разные аккаунты самим пользователем. До этого никакой связи (операций) между пользователем и этими аккаунтами не имелось. После более детального рассмотрения и анализа всех данных, выяснилось, что этот пользователь стал жертвой “Автозалива” и “Реплэйсера”.
Немного теории, собранной на просторах Интернета:
Автозалив — инжект с административной панелью, выполняющий автоматизированные и координированные действия в аккаунте жертвы исходя из положения/ситуации в аккаунте. Эта вредоносная программа собирает данные аккаунта, смотрит какие счета есть в аккаунте и отправляет данные в административную панель. В панели расположена таблица дропов и их состояния, примечания, данные счетов куда переводить средства, и в каком объеме, чтобы обойти лимиты и не вызвать подозрение. Панель на основании автоматических правил или посредством ручной координации выбирает дропа и выдаёт инжекту. Дальше несколько альтернативных вариантов:
вариант 1) инжект отображает пользователю окно с текстом на подобии «Подождите идёт проверка данных», а сам скрытно выполняет действия, приводящие к заливу денег на дропа, путем “кликанья” на нужные ссылки внутри аккаунта и заполнения форм запрашиваемых системой. В случае, если запрашивается ТАН/OTP/PIN код и прочее для завершения перевода, автозалив выдаёт фэйк-страницу холдеру с запросом этого самого кода, но уже под своим предлогом (разводом). Холдер вводит данные в фэйк, автозалив использует эти данные для продолжения/завершения залива.
вариант 2) инжект ждет, когда пользователь захочет выполнить легальную транзакцию для которой будет запрошен ТАН/OTP/PIN код, но этим кодом будет подтверждена нелегальная транзакция — залив денег на дропа.
После чего холдер допускается в аккаунт, на котором уже срабатывает реплэйсер.
Реплэйсер — программный код, нацеленный на скрытие данных перевода, сделанного автозаливом. Другими словами, подмена баланса — это скрытие перевода из истории переводов и прочие манипуляции нацеленные на то, чтобы холдер не заметил перевод. В нашем случае холдер видит фейковый баланс и фейковую легальную транзакцию.
В нашей системе есть различные средства многоуровневых проверок, например, сверка баланса и суммы транзакций пользователя, а также сверки балансов в нашей системе и внешних, и ряд других. Все это не помогло в данном случае, т.к. транзакция не взялась “из воздуха” и выглядела как вполне обычная.
...
После некоторых поисков мы обнаружили, что подобный обход двухфакторной аутентификации уже хорошо известен, и для борьбы с этой уязвимостью многие передовые провайдеры предлагают схожие решения, они называются по разному (подпись данных, CWYS (Confirm What You See), но имеют схожую реализацию. Основной смысл заключается в том, что одноразовый пароль генерируется не только на основании секретного ключа, времени или счетчика, а с использованием всех ключевых данных транзакции, таких как сумма, валюта, получатель. В случае даже, если злоумышленник перехватит пароль, использовать для своих зловредных нужд он его не сможет. Тут все описано в деталях. Для внедрения данной фичи, мы контактировали с несколькими провайдерами, и сделали свой выбор.
Читать всю статью полностью: http://habrahabr.ru/post/264287/
...
Я всегда считал, что двухфакторная аутентификация — панацея, чуть ли не от всех возможных уязвимостей в процессе аутентификации пользователя. Следуя последним трендам безопасности, как мы думали на тот момент, своим пользователям для аутентификации в нашей платежной системе мы рекомендовали использовать аппаратные токены (TOTP, его называют “токеном по-времени”) ведущих мировых поставщиков или программный Authenticator от Google. Для подтверждения платежных операций (транзакций) использовались упомянутые выше токены, а для тех у кого их не было — мы требовали ввод одноразового пароля из SMS. Такая защита казалась нам абсолютно надежной, но если бы это было действительно так, то данной статьи не было бы…
Не буду долго ходить вокруг да около, перейду к делу. Однажды, на суппорт пришла заявка от разъяренного пользователя о том, что у него “обнулен” аккаунт, другими словами выведены все средства. После проведения первичного расследования мы увидели из истории операций, что все средства в штатном режиме за несколько транзакций были выведены на разные аккаунты самим пользователем. До этого никакой связи (операций) между пользователем и этими аккаунтами не имелось. После более детального рассмотрения и анализа всех данных, выяснилось, что этот пользователь стал жертвой “Автозалива” и “Реплэйсера”.
Немного теории, собранной на просторах Интернета:
Автозалив — инжект с административной панелью, выполняющий автоматизированные и координированные действия в аккаунте жертвы исходя из положения/ситуации в аккаунте. Эта вредоносная программа собирает данные аккаунта, смотрит какие счета есть в аккаунте и отправляет данные в административную панель. В панели расположена таблица дропов и их состояния, примечания, данные счетов куда переводить средства, и в каком объеме, чтобы обойти лимиты и не вызвать подозрение. Панель на основании автоматических правил или посредством ручной координации выбирает дропа и выдаёт инжекту. Дальше несколько альтернативных вариантов:
вариант 1) инжект отображает пользователю окно с текстом на подобии «Подождите идёт проверка данных», а сам скрытно выполняет действия, приводящие к заливу денег на дропа, путем “кликанья” на нужные ссылки внутри аккаунта и заполнения форм запрашиваемых системой. В случае, если запрашивается ТАН/OTP/PIN код и прочее для завершения перевода, автозалив выдаёт фэйк-страницу холдеру с запросом этого самого кода, но уже под своим предлогом (разводом). Холдер вводит данные в фэйк, автозалив использует эти данные для продолжения/завершения залива.
вариант 2) инжект ждет, когда пользователь захочет выполнить легальную транзакцию для которой будет запрошен ТАН/OTP/PIN код, но этим кодом будет подтверждена нелегальная транзакция — залив денег на дропа.
После чего холдер допускается в аккаунт, на котором уже срабатывает реплэйсер.
Реплэйсер — программный код, нацеленный на скрытие данных перевода, сделанного автозаливом. Другими словами, подмена баланса — это скрытие перевода из истории переводов и прочие манипуляции нацеленные на то, чтобы холдер не заметил перевод. В нашем случае холдер видит фейковый баланс и фейковую легальную транзакцию.
В нашей системе есть различные средства многоуровневых проверок, например, сверка баланса и суммы транзакций пользователя, а также сверки балансов в нашей системе и внешних, и ряд других. Все это не помогло в данном случае, т.к. транзакция не взялась “из воздуха” и выглядела как вполне обычная.
...
После некоторых поисков мы обнаружили, что подобный обход двухфакторной аутентификации уже хорошо известен, и для борьбы с этой уязвимостью многие передовые провайдеры предлагают схожие решения, они называются по разному (подпись данных, CWYS (Confirm What You See), но имеют схожую реализацию. Основной смысл заключается в том, что одноразовый пароль генерируется не только на основании секретного ключа, времени или счетчика, а с использованием всех ключевых данных транзакции, таких как сумма, валюта, получатель. В случае даже, если злоумышленник перехватит пароль, использовать для своих зловредных нужд он его не сможет. Тут все описано в деталях. Для внедрения данной фичи, мы контактировали с несколькими провайдерами, и сделали свой выбор.
Читать всю статью полностью: http://habrahabr.ru/post/264287/
Jump to: