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, но я предполагаю, что нет. Судя по имеющейся в СМИ информации, ЦБ так же выдавал рекомендации этому банку по повышению уровню безопасности, но подробности вряд ли будут известны широкой общественности.
Комментарии (41)
Gasaraki
19.12.2017 14:14Но большей проблемой является то, что сервера SWIFT обычно (и это тоже рекомендация) изолированы от локальной сети и просто не имеют доступа к NTP-серверам — источникам точного времени, так нужным для корректной работы TOTP.
Это не проблема. Атомный источник времени с NTP в закрытый контур и проблемы нет (либо gps-ntp). Цена копеечная. У гугла или фейсбука (не помню) такой в каждой стойке стоит.
klebed
19.12.2017 14:43+1Gps-ntp подвержен атакам извне, все слышали, как у кремля навигатор показывает, что он находится во Внуково? Что же до атомного источника времени, это из пушки по воробьям, вроде это довольно дорогое удовольствие, но это не точно. Помимо прочего, использование такого локального NTP не решает других проблем, озвученных в статье. Как я понимаю, там отсутствует нормальная дистрибуция секрета, как минимум, а безопасность — это сугубо комплексная штука.
В дополнение, я считаю, что использование времени в качестве части вектора инициализации само по себе ослабляет метод.mayorovp
19.12.2017 15:15В дополнение, я считаю, что использование времени в качестве части вектора инициализации само по себе ослабляет метод.
Только если сравнивать вариант где одни и те же биты берутся из времени или из случайного разделяемого секрета. Но в алгоритме TOTP время не заменяет биты разделяемого секрета, а подмешиваются к ним через криптографическую хеш-функцию. Такая операция никак не может ослабить метод, только усилить.
klebed
19.12.2017 15:20Не так. У нас есть по сути 2 варианта:
1) счетчик, который зависит только от количества событий генерации OTP.
2) счетчик, значение которого соответствует текущему времени, разделенному на фиксированный какой-то период (обычно 30 сек)
Оба варианта замешиваются, но если счетчик доподлинно не известен злоумышленнику, то время он знает. Таким образом TOTP выходит слабее, так как неизвестных стало меньше.mayorovp
19.12.2017 15:37Счетчик очень легко становится неизвестным не только злоумышленнику, но и пользователю. Фактически, его можно инкрементировать только после успешной аутентификации — из-за чего сгенерированный пароль в сценариях двухфакторной аутентификации перестает быть одноразовым.
klebed
19.12.2017 17:20Простите, но я совершенно не понял вашу мысль. Пользователь счетчик не знает, его знает токен и его знает сервер. Кейз с рассинхронизацией — если кто-то понажимал кнопку токена много раз, решается процедурой синхронизации, когда сервер получает 2 новых OTP сгенерированных подряд и находит, насколько далеко ушел счетчик.
Злоумышленник же ничего сделать не может, так как чтобы на сервере счетчик пошел вперед, необходимо успешно аутентифицироваться с использованием OTP.
Тоесть счетчик на самом токене всегда на шаг или много шагов опережает счетчик на сервере. Это нормально. А вот дважды использовать один и тот же OTP нельзя по определению, так что одноразовым никто не перестанет быть.
Это означает еще одну важную вещь, что в идеале токенов может быть только 1шт, в противном случае будут возникать события, когда счетчик на клоне токена ушел как бы назад, что по сути повод признать его скомпрометированным.
С TOTP клонов может быть сколько угодно и все они одновременно будут действующими. Небольшие флуктуации списываются на неточность часов и не говорят о компрометации.
Deosis
20.12.2017 08:31когда сервер получает 2 новых OTP сгенерированных подряд и находит, насколько далеко ушел счетчик.
Таким способом легко устроить DoS.
klebed
20.12.2017 08:47От такого DoS относительно легко защититься. Можно ограничить глубину поиска вменяемым диапазоном, ограничить количество ресинхронизаций в минуту, заставить пройти предварительную аутентификацию по статическому паролю, отправив email со спец URL для подтверждения… способов много разных.
Да и операция не самая тяжелая сама по себе.
Gasaraki
19.12.2017 15:20Что же до атомного источника времени, это из пушки по воробьям, вроде это довольно дорогое удовольствие, но это не точно.
Недорогое, столько же как и gps (что там 1-3к вечнозеленых президентов для банка). В тот же чип вместо кварца вкатан например рубидий. gps можно заюзать только для первой синхронизации времени (все равно ее откуда-то нужно будет взять, а точнее спутников сейчас особо нечего), а затем отключить и жить только на атомных часах.
Например железки symmetricom.
В дополнение, я считаю, что использование времени в качестве части вектора инициализации само по себе ослабляет метод.
Квантового шифрования для передачи ключей еще в нашей повседневности нету. Сотовая связь дырявая.
TOTP хотя бы позволяет иметь оффлайновый генератор и встает вопрос только в первичной инициации, которую можно перезапускать раз в месяц например чтобы не подобрали ключ на основе прежде введенных данных (если нечасто коды используются). В принципе QR код тоже можно по почте получать курьером, хотя это менее надежно крипто-туннеля. Т.е. тут все упирается в первую пересылку которую можно осуществить хоть на вертолете с вооруженной охраной и чемоданчиком с самоуничтожением (тут заиграла музыка из Миссия Невыполнима).
Оффлайновые коды имеют минус в их количестве. Т.е. возможно придеться часто их передавать, а это возможность утечки.klebed
19.12.2017 15:29+1Например железки symmetricom.
Спасибо, буду знать.
Но опять таки, точное время это далеко не все, что стоило бы поправить.
В принципе QR код тоже можно по почте получать курьером, хотя это менее надежно крипто-туннеля.
Вся беда в том, что если QR с секретом показать на скомпрометированной машине — то пиши пропало. Это решено в основной массе промышленных серверах аутентификации, хотя и требует установки «родных моб. приложений», зато секрет передается в приложение напрямую.
Оффлайновые коды имеют минус в их количестве. Т.е. возможно придеться часто их передавать, а это возможность утечки.
Передача OTPшек вряд ли поможет вскрыть секрет.
Что же до сравнения HOTP/TOTP, то по моему мнению HOTP сильнее, так как текущий счетчик неизвестен злоумышленнику.Gasaraki
19.12.2017 16:04Но опять таки, точное время это далеко не все, что стоило бы поправить.
Видя как порой делается безопасность в околовоенных сферах и коммерческих крупных, понимаешь что частенько безопасность там делают не знающие люди, а удобные. А уж банковский сектор так вобще консервативен и жаден до ужаса и там как обычно «пока гром не грянет, а если и грянет то вдруг пронесет»
Что же до сравнения HOTP/TOTP, то по моему мнению HOTP сильнее, так как текущий счетчик неизвестен злоумышленнику.
TOTP — это эволюция HOTP.
А как синхрить счетчик? Вот в банке глюканул компьютер и он потерял запомненный счетчик. Если ему прилетит номер счетчика от SWIFT, тогда это уже ничем не будет отличаться от TOTP (алгоритм то тот-же самый). А если не прилетит и придется заказывать его по другим каналам — то это уже простой в работе.klebed
19.12.2017 17:12TOTP — это эволюция HOTP.
А как синхрить счетчик? Вот в банке глюканул компьютер и он потерял запомненный счетчик. Если ему прилетит номер счетчика от SWIFT, тогда это уже ничем не будет отличаться от TOTP (алгоритм то тот-же самый). А если не прилетит и придется заказывать его по другим каналам — то это уже простой в работе.
TOTP и HOTP это вариации одного по сути алгоритма, разница в основном в источнике счетчика. Если счетчик слетел, то его синхронизируют вводом двух последовательных OTP.
Если все совсем сломалось, то надо просто заново персонализировать мобильный токен (по сути создать новый), благо это делается при наличии правильного софта — за считанные минуты. Ниоткуда ничего прилететь не может, это не так работает.
FyvaOldj
20.12.2017 07:41gps можно заюзать только для первой синхронизации времени (все равно ее откуда-то нужно будет взять, а точнее спутников сейчас особо нечего), а затем отключить и жить только на атомных часах.
Если это настолько точное устройство то отчего же просто на заводе при изготовлении не вшивать время сразу
Gasaraki
20.12.2017 18:27И жить пока батарейка не сядет? Атомные часы всего навсего дают импульс в единицу времени, который точно известен и не меняется в некотором диапазоне внешних факторов (которые тоже нужно обеспечить). Т.е. примерно как секундомер который сказал «прошла ровно 1 секунда». Все остальное — это уже софт который обрабатывает эту информацию и которому как раз нужна точка отсчета.
third112
19.12.2017 14:19Если не ошибаюсь SWIFT долгое время был изолирован от Инета? Если так, то м.б. стоило продолжать изоляцию?
nmk2002 Автор
19.12.2017 14:33Дело в том, что оператор работает в SWIFT со своего рабочего компьютера, который обычно находится в локальной сети. Кстати, в качестве одного из уровня защиты SWIFT предлагает использовать еще так называемый jump server — промежуточный сервер, через который происходит доступ. Тогда оператор не обращается к защищаемым серверам напрямую, а взаимодействует с jump server'ом.
third112
19.12.2017 15:46Я не про локальную сеть. Понятно, что всякому банку она нужна. Но, нпр., прихожу в один банк, как клиент, и говорю, на вашем сайте такая инфа. Мне отвечают: а мы не знаем. Я им: посмотрите. А они: нам Интернет закрыт по соображениям безопасности. М.б. и SWIFT нужно отключить от Интернета по соображениям безопасности?
Gasaraki
19.12.2017 16:07+1Кидать собственные кабели между странами? Делать собственную копию интернета на текущих магистралях? Боюсь все просто пошлют SWIFT и мгновенно появится более дешевый конкурент.
third112
19.12.2017 16:15Я выше спросил:
Если не ошибаюсь SWIFT долгое время был изолирован от Инета?
Были системы связи только-SWIFT.Gasaraki
19.12.2017 21:39По модему если только были. Но это все равно общие каналы связи. Сейчас связать все банки в мире через физически отдельную сеть нереально, бессмысленно, дорого и небезопасно. Да и и смысла нету т.к. все равно не сможешь расстыковаться с интернетом — пользователь на сайте банка сказал сделать перевод, оно ушло в процессинг, затем в SWIFT и далее… Стык никуда не денется.
third112
20.12.2017 11:35Но это все равно общие каналы связи
Почему общие? Есть, нпр., услуги: выделенный канал связи, виртуальный канал связи, криптозащита. Есть стандарты, нпр., ISO/IEC 15408.klebed
20.12.2017 12:15А почему вы думаете, что связь со свифтом идет просто так через интернет? Есть же аппаратные VPN. Интернет — это просто среда для передачи данных, но свифтовые сообщения всегда передаются по специально организованным каналам, я уверен. И операторы для этого не нужны.
third112
20.12.2017 12:37А почему вы думаете, что связь со свифтом идет просто так через интернет?
Я пытаюсь понять: может какой-то хакер из дома со свифтом связаться или это физически невозможно?nmk2002 Автор
20.12.2017 12:54Вряд ли из дома это возможно. Но если он уже взломал инфраструктуру банка, то может делать в сети что хочет. Единственное, что ему нужно, чтобы сделать перевод — получить статический пароль оператора SWIFT.
third112
20.12.2017 14:50Извините не понял. Из дома можно взломать инфраструктуру банка и работать, как оператор SWIFT? (Как получен/угадан/подобран пароль — это другой вопрос. Предположим, что все пароли злоумышленник знает).
nmk2002 Автор
20.12.2017 15:07Вероятно, я не понимаю ваш вопрос, потому что он мне кажется наивным.
Если вопросы такие:
Можно ли взломать инфраструктуру банка из дома?
Можно ли подключиться к SWIFT, если у вас есть логин/пароль и доступ к сети банка?
То это зависит от квалификации злоумышленника.
Если вы спрашиваете, можно ли имея пароль подключиться к SWIFT из дома, то конечно нет. Для этого вам все еще нужен доступ к сети SWIFT.third112
20.12.2017 15:48Вероятно, я не понимаю ваш вопрос, потому что он мне кажется наивным.
Разве наивный вопрос трудно понять? Перечитайте ветку: когда такое разнообразие ответов — приходится упрощать вопрос до наивного в надежде получить полный, внятный и однозначный ответ. Но могу и не получать — мне было просто любопытно, но если здесь какая-то банковская/технологическая тайна, то не смею настаивать.nmk2002 Автор
20.12.2017 16:01Перечитал. Мне кажется, что я ответил на ваш вопрос.
Подключиться из дома имея только логин-пароль у вас не получится.
Demon_i
20.12.2017 02:04А где деньги? Я вот не понимаю. Все счета же привязаны к физическому или юридическому лицу. В конце концов банк всегда может отозвать транзакцию или swift такого не умеет?
Areso
20.12.2017 08:19Всегда можно загнать деньги в казино в какой-нибудь диковинной стране. Вам, конечно, помогут власти с расследованием инцидента, но дней через 30 после запроса. Сами понимаете, деньги успеют из казино уйти, оставив заведению определенный процент. Казино выступает в роли миксера.
orcy
20.12.2017 12:00Все равно банк просто так наверное миллион баксов не выдаст в один день, кроме того есть наверное видеозаписи, на кого открыт счет, и т.д. Короче юридически должны быть не очень просто, а судя по новостям как будто биткоины украли — вжик, и с концами.
krabdb
20.12.2017 09:171. Если деньги уже на счете получателя, отправитель отозвать ничего не может.
2. В этой схеме денег на счете получателя нет, они мгновенно выводятся.
Nicks_TechSupport
20.12.2017 09:17Любопытны, конечно, технические детали и методы взлома. Автор, когда инфа появится, сделаете апдэйт?
nmk2002 Автор
20.12.2017 09:19Да, я слежу за этой темой. Сделаю обновление, если будет что-то интересное. Обычно общественности становится известно что-то вроде скупого «злоумышленники завладели учетной записью администратора».
BlackDiver
20.12.2017 11:48А что удивляться то? Если 98% процентов банков имеют критические уязвимости… Загляните под капот любой банковской инфраструктуры и вы встретите дыры в стиле MS08-067, которые не патчатся десятилетиями.
mihmig
20.12.2017 14:50С удовольствием почитал бы про двухфакторную аутентификацию RDP.
Или все по-старинке под паролем ходят?nmk2002 Автор
20.12.2017 15:52Тут есть варианты.
1. После аутентификации всеми необходимыми факторами для вас становится доступен определенный порт определенного хоста.
Делается по разному, опишу опять же из своего опыта. Например, можно сделать отдельный веб-интерфейс для аутентификации. После удачного прохождения у пользователя появляется SSL-VPN до сервера доступа, который транслирует трафик на RDP хост. + при подключении автостартует mstsc с параметрами подключения. Бонусом можно настроить SSO, чтобы аутентификацию в RDP пользователь уже не производил.
2. RDP в браузере. Есть такой софт, который позволяет завернуть RDP в HTTP. Для этого обычно требуется только браузер, поддерживающий HTML5. Дальше, наверное, объяснять не нужно, так как задача сводится к тому, чтобы сделать 2FA для веб ресурса. SSO тут тоже возможно.
3. Насколько мне известно, Remote Gateway поддерживает протокол RADIUS, а, значит, позволяет использовать сервера аутентификации, которые тоже поддерживают RADIUS.
4. Слышал что-то про варианты, когда на RDP-хост устанавливаются какие-то проприетарные плагины от серверов аутентификации, но сам не использовал.
5. Если говорить про просто задачу двухфакторной аутентификации RDP, то можно использовать PKI-Аутентификацию.
oldbie
Из статьи неясно насколько удачной была атака. Или это тоже неизвестно?
nmk2002 Автор
В начале написал:
То есть судя по всему, деньги-то вывели, но сколько именно неизвестно.
g0rd1as
Или деньги вывели, но банку пока стыдно признаться сколько. :-D
nmk2002 Автор
Жертва — банк Глобэкс. Ущерб — десятки миллионов рублей.
Добавил апдейт в статью.