Еще одна кража через SWIFT. Теперь в России


    UPD2. По данным Центробанка в 2017 году было похищено 339,5 млн.р. Нетрудно догадаться, что речь именно про Глобэкс. В обзоре FinCERT говорится: «В Банк России направлена информация об одной успешной атаке на рабочее место оператора системы SWIFT. Объем несанкционированных операций в результате данной атаки составил 339,5 миллиона рублей».

    UPD. Банк-жертва — Глобэкс. Размер украденного исчисляют десятками миллионов рублей.

    Один из российских банков стал жертвой кибератаки, направленной на кражу денег через международную межбанковскую систему платежей SWIFT. Про атаку известно, что она была произведена 15 декабря. Однако, название банка и размер ущерба пока не озвучиваются. Развитие атаки, организованной предположительно группировкой Cobalt, началось с рассылки вредоносного ПО за несколько недель до инцидента. Причем по сообщению заместителя начальника главного управления безопасности и защиты информации ЦБ Артема Сычева, хакеры получили широкий доступ к инфраструктуре и могли использовать и другие каналы вывода средств. Однако, их интересовал вывод средств в иностранный банк, поэтому целью хакеров стал доступ к SWIFT.

    Как сообщили в SWIFT, доказательств, что имел место несанкционированный доступ, нет. А значит, что вероятнее всего, был получен контроль над учетной записью оператора SWIFT. История уже знает несколько подобных случаев с банками из разных стран, в том числе нашумевший случай с ЦБ Бангладеш, где хакерам удалось украсть информацию, необходимую для авторизации при проведении транзакций. Тогда успели украсть $81 млн, а всего пытались вывести денег общей суммой в $951 млн. Аналогичная атака была предпринята в конце 2015 года на вьетнамский банк Tien Phon Bank, но тогда банк вовремя заблокировал операции на $1 млн. А в начале 2015 года было украден $9 млн из эквадорского Banco del Austro. Летом 2016 года было похищено $10 млн уже у украинского банка. Каждый раз злоумышленникам удается получить доступ к системе SWIFT обойдя защитные барьеры, реализованные в банках.

    Я немного в курсе активностей SWIFT и некоторых банков, так как для нескольких банков уже настраивал двухфакторную аутентификацию доступа к интерфейсам SWIFT. Поэтому расскажу, что вижу сам. После наиболее крупного хищения, произошедшего как раз в ЦБ Бангладеш, наметился достаточно устойчивый курс компании SWIFT на повышение безопасности доступа к сетям SWIFT и ее службам обмена сообщениями. Почти сразу одним из требований к дальнейшей сертификации, позволяющей использовать SWIFT, стало требование двухфакторной аутентификации. Эта мера должна останавливать злоумышленников, которым удалось перехватить пароль оператора. Причем банкам на первых порах достаточно было отчитаться, что они взялись реализовывать двухфакторную аутентификацию. Некоторые участники, чья активная сертификация истекала нескоро, вообще решили отложить какие-либо действия.
    Тем временем SWIFT в 2017 году была разработана программа информационной безопасности клиентов (Customer Security Programme) и были задокументированны организационные и технические рекомендации по информационной безопасности. Среди мер по безопасности такие, как защита физического доступа, разделение полномочий, регулярные обновления, ограничение доступа и, конечно, защита учетных записей. Теперь финансовые организации должны провести сначала самоаттестацию, а позже, надеюсь, и внешний аудит на предмет соответствия новым требованиям.

    Уже около года в SWIFT доступна собственная реализация двухфакторной аутентификации по одноразовым кодам. В качестве основы был взят открытый стандарт OATH TOTP, то есть одноразовые коды существуют в своем временном окне. Секретный seed отображается на мониторе оператора при регистрации в виде QR кода по аналогии с Google Authenticator. Кстати использовать в качестве генератора можно любое мобильное приложение, поддерживающее стандарт TOTP, в том числе тот же Google Authenticator. Мое мнение — замечательно, что SWIFT предлагает такое базовое решение. Но в их реализации есть и подводные камни. Для начала сам QR код, который содержит в себе основной секрет передается на ПК оператора и отображается на экране, а значит, может быть перехвачен или подсмотрен. Но большей проблемой является то, что сервера SWIFT обычно (и это тоже рекомендация) изолированы от локальной сети и просто не имеют доступа к NTP-серверам — источникам точного времени, так нужным для корректной работы TOTP. В итоге рассинхронизация токенов может произойти в самый непредсказуемый момент. Некоторые службы информационной безопасности, например, предпочитают использовать аппаратные генераторы одноразовых паролей, а не не смартфоны. Такое требование несовместимо с тем, что предлагает SWIFT. Есть в решении, предлагаемом SWIFT и другие недостатки, из-за которых некоторые финансовые организации выбирают стороннее решение, но, повторюсь, это все же лучше, чем ничего. В любом случае все описанное говорит о попытках SWIFT противостоять существующим угрозам, а не зарывать голову в песок.

    Замечу, что сейчас двухфакторная аутентификация требуется не только для учетной записи оператора, но и для остальных сервисов в защищенной сети SWIFT, например, RDP или SSH доступ к серверам.

    Не известно, соответствовала ли инфраструктура банка, который стал жертвой последней атаки, рекомендациям SWIFT, но я предполагаю, что нет. Судя по имеющейся в СМИ информации, ЦБ так же выдавал рекомендации этому банку по повышению уровню безопасности, но подробности вряд ли будут известны широкой общественности.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 45

      +1
      Из статьи неясно насколько удачной была атака. Или это тоже неизвестно?
        0
        В начале написал:
        название банка и размер ущерба пока не озвучиваются

        То есть судя по всему, деньги-то вывели, но сколько именно неизвестно.
          0
          Или деньги вывели, но банку пока стыдно признаться сколько. :-D
          0
          Жертва — банк Глобэкс. Ущерб — десятки миллионов рублей.
          Добавил апдейт в статью.
          0
          Но большей проблемой является то, что сервера SWIFT обычно (и это тоже рекомендация) изолированы от локальной сети и просто не имеют доступа к NTP-серверам — источникам точного времени, так нужным для корректной работы TOTP.


          Это не проблема. Атомный источник времени с NTP в закрытый контур и проблемы нет (либо gps-ntp). Цена копеечная. У гугла или фейсбука (не помню) такой в каждой стойке стоит.

            +1
            Gps-ntp подвержен атакам извне, все слышали, как у кремля навигатор показывает, что он находится во Внуково? Что же до атомного источника времени, это из пушки по воробьям, вроде это довольно дорогое удовольствие, но это не точно. Помимо прочего, использование такого локального NTP не решает других проблем, озвученных в статье. Как я понимаю, там отсутствует нормальная дистрибуция секрета, как минимум, а безопасность — это сугубо комплексная штука.
            В дополнение, я считаю, что использование времени в качестве части вектора инициализации само по себе ослабляет метод.
              0
              В дополнение, я считаю, что использование времени в качестве части вектора инициализации само по себе ослабляет метод.

              Только если сравнивать вариант где одни и те же биты берутся из времени или из случайного разделяемого секрета. Но в алгоритме TOTP время не заменяет биты разделяемого секрета, а подмешиваются к ним через криптографическую хеш-функцию. Такая операция никак не может ослабить метод, только усилить.

                0
                Не так. У нас есть по сути 2 варианта:
                1) счетчик, который зависит только от количества событий генерации OTP.
                2) счетчик, значение которого соответствует текущему времени, разделенному на фиксированный какой-то период (обычно 30 сек)

                Оба варианта замешиваются, но если счетчик доподлинно не известен злоумышленнику, то время он знает. Таким образом TOTP выходит слабее, так как неизвестных стало меньше.
                  0
                  Счетчик очень легко становится неизвестным не только злоумышленнику, но и пользователю. Фактически, его можно инкрементировать только после успешной аутентификации — из-за чего сгенерированный пароль в сценариях двухфакторной аутентификации перестает быть одноразовым.
                    0
                    Простите, но я совершенно не понял вашу мысль. Пользователь счетчик не знает, его знает токен и его знает сервер. Кейз с рассинхронизацией — если кто-то понажимал кнопку токена много раз, решается процедурой синхронизации, когда сервер получает 2 новых OTP сгенерированных подряд и находит, насколько далеко ушел счетчик.
                    Злоумышленник же ничего сделать не может, так как чтобы на сервере счетчик пошел вперед, необходимо успешно аутентифицироваться с использованием OTP.
                    Тоесть счетчик на самом токене всегда на шаг или много шагов опережает счетчик на сервере. Это нормально. А вот дважды использовать один и тот же OTP нельзя по определению, так что одноразовым никто не перестанет быть.

                    Это означает еще одну важную вещь, что в идеале токенов может быть только 1шт, в противном случае будут возникать события, когда счетчик на клоне токена ушел как бы назад, что по сути повод признать его скомпрометированным.
                    С TOTP клонов может быть сколько угодно и все они одновременно будут действующими. Небольшие флуктуации списываются на неточность часов и не говорят о компрометации.
                      0
                      когда сервер получает 2 новых OTP сгенерированных подряд и находит, насколько далеко ушел счетчик.

                      Таким способом легко устроить DoS.

                        0
                        От такого DoS относительно легко защититься. Можно ограничить глубину поиска вменяемым диапазоном, ограничить количество ресинхронизаций в минуту, заставить пройти предварительную аутентификацию по статическому паролю, отправив email со спец URL для подтверждения… способов много разных.
                        Да и операция не самая тяжелая сама по себе.
                0
                Что же до атомного источника времени, это из пушки по воробьям, вроде это довольно дорогое удовольствие, но это не точно.


                Недорогое, столько же как и gps (что там 1-3к вечнозеленых президентов для банка). В тот же чип вместо кварца вкатан например рубидий. gps можно заюзать только для первой синхронизации времени (все равно ее откуда-то нужно будет взять, а точнее спутников сейчас особо нечего), а затем отключить и жить только на атомных часах.

                Например железки symmetricom.

                В дополнение, я считаю, что использование времени в качестве части вектора инициализации само по себе ослабляет метод.


                Квантового шифрования для передачи ключей еще в нашей повседневности нету. Сотовая связь дырявая.

                TOTP хотя бы позволяет иметь оффлайновый генератор и встает вопрос только в первичной инициации, которую можно перезапускать раз в месяц например чтобы не подобрали ключ на основе прежде введенных данных (если нечасто коды используются). В принципе QR код тоже можно по почте получать курьером, хотя это менее надежно крипто-туннеля. Т.е. тут все упирается в первую пересылку которую можно осуществить хоть на вертолете с вооруженной охраной и чемоданчиком с самоуничтожением (тут заиграла музыка из Миссия Невыполнима).
                Оффлайновые коды имеют минус в их количестве. Т.е. возможно придеться часто их передавать, а это возможность утечки.
                  +2
                  Например железки symmetricom.

                  Спасибо, буду знать.
                  Но опять таки, точное время это далеко не все, что стоило бы поправить.

                  В принципе QR код тоже можно по почте получать курьером, хотя это менее надежно крипто-туннеля.

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

                  Оффлайновые коды имеют минус в их количестве. Т.е. возможно придеться часто их передавать, а это возможность утечки.

                  Передача OTPшек вряд ли поможет вскрыть секрет.
                  Что же до сравнения HOTP/TOTP, то по моему мнению HOTP сильнее, так как текущий счетчик неизвестен злоумышленнику.
                    0
                    Но опять таки, точное время это далеко не все, что стоило бы поправить.


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

                    Что же до сравнения HOTP/TOTP, то по моему мнению HOTP сильнее, так как текущий счетчик неизвестен злоумышленнику.


                    TOTP — это эволюция HOTP.
                    А как синхрить счетчик? Вот в банке глюканул компьютер и он потерял запомненный счетчик. Если ему прилетит номер счетчика от SWIFT, тогда это уже ничем не будет отличаться от TOTP (алгоритм то тот-же самый). А если не прилетит и придется заказывать его по другим каналам — то это уже простой в работе.
                      +1
                      TOTP — это эволюция HOTP.
                      А как синхрить счетчик? Вот в банке глюканул компьютер и он потерял запомненный счетчик. Если ему прилетит номер счетчика от SWIFT, тогда это уже ничем не будет отличаться от TOTP (алгоритм то тот-же самый). А если не прилетит и придется заказывать его по другим каналам — то это уже простой в работе.


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

                    Если это настолько точное устройство то отчего же просто на заводе при изготовлении не вшивать время сразу

                      +1
                      И жить пока батарейка не сядет? Атомные часы всего навсего дают импульс в единицу времени, который точно известен и не меняется в некотором диапазоне внешних факторов (которые тоже нужно обеспечить). Т.е. примерно как секундомер который сказал «прошла ровно 1 секунда». Все остальное — это уже софт который обрабатывает эту информацию и которому как раз нужна точка отсчета.
                        0
                        Батарейка для нужд часов может жить годами.
                        Поставить качественную батарейку в дорогущие атомные часы не проблема. Обеспечить два или три альтернативных питания также копейки.
                          0
                          Мне кажется, что вы путаете потребление кварцевых часов и атомных часов. Навскидку для кварцевых потребляемая мощность исчисляется в десятках микронов ватт, в то время как только сам чип атомных часов судя по сайту производителя имеет мощность в пределах 0,12 ватт. Разница в несколько (5!) порядков.
                0
                Если не ошибаюсь SWIFT долгое время был изолирован от Инета? Если так, то м.б. стоило продолжать изоляцию?
                  0
                  Дело в том, что оператор работает в SWIFT со своего рабочего компьютера, который обычно находится в локальной сети. Кстати, в качестве одного из уровня защиты SWIFT предлагает использовать еще так называемый jump server — промежуточный сервер, через который происходит доступ. Тогда оператор не обращается к защищаемым серверам напрямую, а взаимодействует с jump server'ом.
                    0
                    Я не про локальную сеть. Понятно, что всякому банку она нужна. Но, нпр., прихожу в один банк, как клиент, и говорю, на вашем сайте такая инфа. Мне отвечают: а мы не знаем. Я им: посмотрите. А они: нам Интернет закрыт по соображениям безопасности. М.б. и SWIFT нужно отключить от Интернета по соображениям безопасности?
                      +1
                      Кидать собственные кабели между странами? Делать собственную копию интернета на текущих магистралях? Боюсь все просто пошлют SWIFT и мгновенно появится более дешевый конкурент.
                        0
                        Я выше спросил:
                        Если не ошибаюсь SWIFT долгое время был изолирован от Инета?
                        Были системы связи только-SWIFT.
                          +2
                          По модему если только были. Но это все равно общие каналы связи. Сейчас связать все банки в мире через физически отдельную сеть нереально, бессмысленно, дорого и небезопасно. Да и и смысла нету т.к. все равно не сможешь расстыковаться с интернетом — пользователь на сайте банка сказал сделать перевод, оно ушло в процессинг, затем в SWIFT и далее… Стык никуда не денется.
                            0
                            Но это все равно общие каналы связи
                            Почему общие? Есть, нпр., услуги: выделенный канал связи, виртуальный канал связи, криптозащита. Есть стандарты, нпр., ISO/IEC 15408.
                              0
                              А почему вы думаете, что связь со свифтом идет просто так через интернет? Есть же аппаратные VPN. Интернет — это просто среда для передачи данных, но свифтовые сообщения всегда передаются по специально организованным каналам, я уверен. И операторы для этого не нужны.
                                0
                                А почему вы думаете, что связь со свифтом идет просто так через интернет?
                                Я пытаюсь понять: может какой-то хакер из дома со свифтом связаться или это физически невозможно?
                                  0
                                  Вряд ли из дома это возможно. Но если он уже взломал инфраструктуру банка, то может делать в сети что хочет. Единственное, что ему нужно, чтобы сделать перевод — получить статический пароль оператора SWIFT.
                                    0
                                    Извините не понял. Из дома можно взломать инфраструктуру банка и работать, как оператор SWIFT? (Как получен/угадан/подобран пароль — это другой вопрос. Предположим, что все пароли злоумышленник знает).
                                      0
                                      Вероятно, я не понимаю ваш вопрос, потому что он мне кажется наивным.
                                      Если вопросы такие:
                                      Можно ли взломать инфраструктуру банка из дома?
                                      Можно ли подключиться к SWIFT, если у вас есть логин/пароль и доступ к сети банка?
                                      То это зависит от квалификации злоумышленника.
                                      Если вы спрашиваете, можно ли имея пароль подключиться к SWIFT из дома, то конечно нет. Для этого вам все еще нужен доступ к сети SWIFT.
                                        0
                                        Вероятно, я не понимаю ваш вопрос, потому что он мне кажется наивным.
                                        Разве наивный вопрос трудно понять? Перечитайте ветку: когда такое разнообразие ответов — приходится упрощать вопрос до наивного в надежде получить полный, внятный и однозначный ответ. Но могу и не получать — мне было просто любопытно, но если здесь какая-то банковская/технологическая тайна, то не смею настаивать.
                                          0
                                          Перечитал. Мне кажется, что я ответил на ваш вопрос.
                                          Подключиться из дома имея только логин-пароль у вас не получится.
                  0
                  А где деньги? Я вот не понимаю. Все счета же привязаны к физическому или юридическому лицу. В конце концов банк всегда может отозвать транзакцию или swift такого не умеет?
                    +2
                    Всегда можно загнать деньги в казино в какой-нибудь диковинной стране. Вам, конечно, помогут власти с расследованием инцидента, но дней через 30 после запроса. Сами понимаете, деньги успеют из казино уйти, оставив заведению определенный процент. Казино выступает в роли миксера.
                      0
                      Все равно банк просто так наверное миллион баксов не выдаст в один день, кроме того есть наверное видеозаписи, на кого открыт счет, и т.д. Короче юридически должны быть не очень просто, а судя по новостям как будто биткоины украли — вжик, и с концами.
                      0
                      1. Если деньги уже на счете получателя, отправитель отозвать ничего не может.
                      2. В этой схеме денег на счете получателя нет, они мгновенно выводятся.
                      +1

                      Любопытны, конечно, технические детали и методы взлома. Автор, когда инфа появится, сделаете апдэйт?

                        0
                        Да, я слежу за этой темой. Сделаю обновление, если будет что-то интересное. Обычно общественности становится известно что-то вроде скупого «злоумышленники завладели учетной записью администратора».
                        0
                        А что удивляться то? Если 98% процентов банков имеют критические уязвимости… Загляните под капот любой банковской инфраструктуры и вы встретите дыры в стиле MS08-067, которые не патчатся десятилетиями.
                          0
                          С удовольствием почитал бы про двухфакторную аутентификацию RDP.
                          Или все по-старинке под паролем ходят?
                            0
                            Тут есть варианты.
                            1. После аутентификации всеми необходимыми факторами для вас становится доступен определенный порт определенного хоста.
                            Делается по разному, опишу опять же из своего опыта. Например, можно сделать отдельный веб-интерфейс для аутентификации. После удачного прохождения у пользователя появляется SSL-VPN до сервера доступа, который транслирует трафик на RDP хост. + при подключении автостартует mstsc с параметрами подключения. Бонусом можно настроить SSO, чтобы аутентификацию в RDP пользователь уже не производил.
                            2. RDP в браузере. Есть такой софт, который позволяет завернуть RDP в HTTP. Для этого обычно требуется только браузер, поддерживающий HTML5. Дальше, наверное, объяснять не нужно, так как задача сводится к тому, чтобы сделать 2FA для веб ресурса. SSO тут тоже возможно.
                            3. Насколько мне известно, Remote Gateway поддерживает протокол RADIUS, а, значит, позволяет использовать сервера аутентификации, которые тоже поддерживают RADIUS.
                            4. Слышал что-то про варианты, когда на RDP-хост устанавливаются какие-то проприетарные плагины от серверов аутентификации, но сам не использовал.
                            5. Если говорить про просто задачу двухфакторной аутентификации RDP, то можно использовать PKI-Аутентификацию.
                            0
                            Добавил уточненную информацию по сумме ущерба — 339,5 млн.р. Она стала известна из обзора FinCERT Банка России.
                              0
                              Насколько я помню из прочитанного по этой истории, местом атаки был канал между АБС и терминалом SWIFT. Вроде тех нескольких случаев с УФЭБС.

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