Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
Из статьи неясно насколько удачной была атака. Или это тоже неизвестно?
Но большей проблемой является то, что сервера SWIFT обычно (и это тоже рекомендация) изолированы от локальной сети и просто не имеют доступа к NTP-серверам — источникам точного времени, так нужным для корректной работы TOTP.
Это не проблема. Атомный источник времени с NTP в закрытый контур и проблемы нет (либо gps-ntp). Цена копеечная. У гугла или фейсбука (не помню) такой в каждой стойке стоит.
Gps-ntp подвержен атакам извне, все слышали, как у кремля навигатор показывает, что он находится во Внуково? Что же до атомного источника времени, это из пушки по воробьям, вроде это довольно дорогое удовольствие, но это не точно. Помимо прочего, использование такого локального NTP не решает других проблем, озвученных в статье. Как я понимаю, там отсутствует нормальная дистрибуция секрета, как минимум, а безопасность — это сугубо комплексная штука.
В дополнение, я считаю, что использование времени в качестве части вектора инициализации само по себе ослабляет метод.
В дополнение, я считаю, что использование времени в качестве части вектора инициализации само по себе ослабляет метод.
В дополнение, я считаю, что использование времени в качестве части вектора инициализации само по себе ослабляет метод.
Только если сравнивать вариант где одни и те же биты берутся из времени или из случайного разделяемого секрета. Но в алгоритме TOTP время не заменяет биты разделяемого секрета, а подмешиваются к ним через криптографическую хеш-функцию. Такая операция никак не может ослабить метод, только усилить.
Не так. У нас есть по сути 2 варианта:
1) счетчик, который зависит только от количества событий генерации OTP.
2) счетчик, значение которого соответствует текущему времени, разделенному на фиксированный какой-то период (обычно 30 сек)
Оба варианта замешиваются, но если счетчик доподлинно не известен злоумышленнику, то время он знает. Таким образом TOTP выходит слабее, так как неизвестных стало меньше.
1) счетчик, который зависит только от количества событий генерации OTP.
2) счетчик, значение которого соответствует текущему времени, разделенному на фиксированный какой-то период (обычно 30 сек)
Оба варианта замешиваются, но если счетчик доподлинно не известен злоумышленнику, то время он знает. Таким образом TOTP выходит слабее, так как неизвестных стало меньше.
Счетчик очень легко становится неизвестным не только злоумышленнику, но и пользователю. Фактически, его можно инкрементировать только после успешной аутентификации — из-за чего сгенерированный пароль в сценариях двухфакторной аутентификации перестает быть одноразовым.
Простите, но я совершенно не понял вашу мысль. Пользователь счетчик не знает, его знает токен и его знает сервер. Кейз с рассинхронизацией — если кто-то понажимал кнопку токена много раз, решается процедурой синхронизации, когда сервер получает 2 новых OTP сгенерированных подряд и находит, насколько далеко ушел счетчик.
Злоумышленник же ничего сделать не может, так как чтобы на сервере счетчик пошел вперед, необходимо успешно аутентифицироваться с использованием OTP.
Тоесть счетчик на самом токене всегда на шаг или много шагов опережает счетчик на сервере. Это нормально. А вот дважды использовать один и тот же OTP нельзя по определению, так что одноразовым никто не перестанет быть.
Это означает еще одну важную вещь, что в идеале токенов может быть только 1шт, в противном случае будут возникать события, когда счетчик на клоне токена ушел как бы назад, что по сути повод признать его скомпрометированным.
С TOTP клонов может быть сколько угодно и все они одновременно будут действующими. Небольшие флуктуации списываются на неточность часов и не говорят о компрометации.
Злоумышленник же ничего сделать не может, так как чтобы на сервере счетчик пошел вперед, необходимо успешно аутентифицироваться с использованием OTP.
Тоесть счетчик на самом токене всегда на шаг или много шагов опережает счетчик на сервере. Это нормально. А вот дважды использовать один и тот же OTP нельзя по определению, так что одноразовым никто не перестанет быть.
Это означает еще одну важную вещь, что в идеале токенов может быть только 1шт, в противном случае будут возникать события, когда счетчик на клоне токена ушел как бы назад, что по сути повод признать его скомпрометированным.
С TOTP клонов может быть сколько угодно и все они одновременно будут действующими. Небольшие флуктуации списываются на неточность часов и не говорят о компрометации.
когда сервер получает 2 новых OTP сгенерированных подряд и находит, насколько далеко ушел счетчик.
Таким способом легко устроить DoS.
От такого DoS относительно легко защититься. Можно ограничить глубину поиска вменяемым диапазоном, ограничить количество ресинхронизаций в минуту, заставить пройти предварительную аутентификацию по статическому паролю, отправив email со спец URL для подтверждения… способов много разных.
Да и операция не самая тяжелая сама по себе.
Да и операция не самая тяжелая сама по себе.
Что же до атомного источника времени, это из пушки по воробьям, вроде это довольно дорогое удовольствие, но это не точно.
Недорогое, столько же как и gps (что там 1-3к вечнозеленых президентов для банка). В тот же чип вместо кварца вкатан например рубидий. gps можно заюзать только для первой синхронизации времени (все равно ее откуда-то нужно будет взять, а точнее спутников сейчас особо нечего), а затем отключить и жить только на атомных часах.
Например железки symmetricom.
В дополнение, я считаю, что использование времени в качестве части вектора инициализации само по себе ослабляет метод.
Квантового шифрования для передачи ключей еще в нашей повседневности нету. Сотовая связь дырявая.
TOTP хотя бы позволяет иметь оффлайновый генератор и встает вопрос только в первичной инициации, которую можно перезапускать раз в месяц например чтобы не подобрали ключ на основе прежде введенных данных (если нечасто коды используются). В принципе QR код тоже можно по почте получать курьером, хотя это менее надежно крипто-туннеля. Т.е. тут все упирается в первую пересылку которую можно осуществить хоть на вертолете с вооруженной охраной и чемоданчиком с самоуничтожением (тут заиграла музыка из Миссия Невыполнима).
Оффлайновые коды имеют минус в их количестве. Т.е. возможно придеться часто их передавать, а это возможность утечки.
Например железки symmetricom.
Спасибо, буду знать.
Но опять таки, точное время это далеко не все, что стоило бы поправить.
В принципе QR код тоже можно по почте получать курьером, хотя это менее надежно крипто-туннеля.
Вся беда в том, что если QR с секретом показать на скомпрометированной машине — то пиши пропало. Это решено в основной массе промышленных серверах аутентификации, хотя и требует установки «родных моб. приложений», зато секрет передается в приложение напрямую.
Оффлайновые коды имеют минус в их количестве. Т.е. возможно придеться часто их передавать, а это возможность утечки.
Передача OTPшек вряд ли поможет вскрыть секрет.
Что же до сравнения HOTP/TOTP, то по моему мнению HOTP сильнее, так как текущий счетчик неизвестен злоумышленнику.
Но опять таки, точное время это далеко не все, что стоило бы поправить.
Видя как порой делается безопасность в околовоенных сферах и коммерческих крупных, понимаешь что частенько безопасность там делают не знающие люди, а удобные. А уж банковский сектор так вобще консервативен и жаден до ужаса и там как обычно «пока гром не грянет, а если и грянет то вдруг пронесет»
Что же до сравнения HOTP/TOTP, то по моему мнению HOTP сильнее, так как текущий счетчик неизвестен злоумышленнику.
TOTP — это эволюция HOTP.
А как синхрить счетчик? Вот в банке глюканул компьютер и он потерял запомненный счетчик. Если ему прилетит номер счетчика от SWIFT, тогда это уже ничем не будет отличаться от TOTP (алгоритм то тот-же самый). А если не прилетит и придется заказывать его по другим каналам — то это уже простой в работе.
TOTP — это эволюция HOTP.
А как синхрить счетчик? Вот в банке глюканул компьютер и он потерял запомненный счетчик. Если ему прилетит номер счетчика от SWIFT, тогда это уже ничем не будет отличаться от TOTP (алгоритм то тот-же самый). А если не прилетит и придется заказывать его по другим каналам — то это уже простой в работе.
TOTP и HOTP это вариации одного по сути алгоритма, разница в основном в источнике счетчика. Если счетчик слетел, то его синхронизируют вводом двух последовательных OTP.
Если все совсем сломалось, то надо просто заново персонализировать мобильный токен (по сути создать новый), благо это делается при наличии правильного софта — за считанные минуты. Ниоткуда ничего прилететь не может, это не так работает.
gps можно заюзать только для первой синхронизации времени (все равно ее откуда-то нужно будет взять, а точнее спутников сейчас особо нечего), а затем отключить и жить только на атомных часах.
Если это настолько точное устройство то отчего же просто на заводе при изготовлении не вшивать время сразу
И жить пока батарейка не сядет? Атомные часы всего навсего дают импульс в единицу времени, который точно известен и не меняется в некотором диапазоне внешних факторов (которые тоже нужно обеспечить). Т.е. примерно как секундомер который сказал «прошла ровно 1 секунда». Все остальное — это уже софт который обрабатывает эту информацию и которому как раз нужна точка отсчета.
Батарейка для нужд часов может жить годами.
Поставить качественную батарейку в дорогущие атомные часы не проблема. Обеспечить два или три альтернативных питания также копейки.
Поставить качественную батарейку в дорогущие атомные часы не проблема. Обеспечить два или три альтернативных питания также копейки.
Мне кажется, что вы путаете потребление кварцевых часов и атомных часов. Навскидку для кварцевых потребляемая мощность исчисляется в десятках микронов ватт, в то время как только сам чип атомных часов судя по сайту производителя имеет мощность в пределах 0,12 ватт. Разница в несколько (5!) порядков.
Если не ошибаюсь SWIFT долгое время был изолирован от Инета? Если так, то м.б. стоило продолжать изоляцию?
Дело в том, что оператор работает в SWIFT со своего рабочего компьютера, который обычно находится в локальной сети. Кстати, в качестве одного из уровня защиты SWIFT предлагает использовать еще так называемый jump server — промежуточный сервер, через который происходит доступ. Тогда оператор не обращается к защищаемым серверам напрямую, а взаимодействует с jump server'ом.
Я не про локальную сеть. Понятно, что всякому банку она нужна. Но, нпр., прихожу в один банк, как клиент, и говорю, на вашем сайте такая инфа. Мне отвечают: а мы не знаем. Я им: посмотрите. А они: нам Интернет закрыт по соображениям безопасности. М.б. и SWIFT нужно отключить от Интернета по соображениям безопасности?
Кидать собственные кабели между странами? Делать собственную копию интернета на текущих магистралях? Боюсь все просто пошлют SWIFT и мгновенно появится более дешевый конкурент.
Я выше спросил:
Если не ошибаюсь SWIFT долгое время был изолирован от Инета?Были системы связи только-SWIFT.
По модему если только были. Но это все равно общие каналы связи. Сейчас связать все банки в мире через физически отдельную сеть нереально, бессмысленно, дорого и небезопасно. Да и и смысла нету т.к. все равно не сможешь расстыковаться с интернетом — пользователь на сайте банка сказал сделать перевод, оно ушло в процессинг, затем в SWIFT и далее… Стык никуда не денется.
Но это все равно общие каналы связиПочему общие? Есть, нпр., услуги: выделенный канал связи, виртуальный канал связи, криптозащита. Есть стандарты, нпр., ISO/IEC 15408.
А почему вы думаете, что связь со свифтом идет просто так через интернет? Есть же аппаратные VPN. Интернет — это просто среда для передачи данных, но свифтовые сообщения всегда передаются по специально организованным каналам, я уверен. И операторы для этого не нужны.
А почему вы думаете, что связь со свифтом идет просто так через интернет?Я пытаюсь понять: может какой-то хакер из дома со свифтом связаться или это физически невозможно?
Вряд ли из дома это возможно. Но если он уже взломал инфраструктуру банка, то может делать в сети что хочет. Единственное, что ему нужно, чтобы сделать перевод — получить статический пароль оператора SWIFT.
Извините не понял. Из дома можно взломать инфраструктуру банка и работать, как оператор SWIFT? (Как получен/угадан/подобран пароль — это другой вопрос. Предположим, что все пароли злоумышленник знает).
Вероятно, я не понимаю ваш вопрос, потому что он мне кажется наивным.
Если вопросы такие:
Можно ли взломать инфраструктуру банка из дома?
Можно ли подключиться к SWIFT, если у вас есть логин/пароль и доступ к сети банка?
То это зависит от квалификации злоумышленника.
Если вы спрашиваете, можно ли имея пароль подключиться к SWIFT из дома, то конечно нет. Для этого вам все еще нужен доступ к сети SWIFT.
Если вопросы такие:
Можно ли взломать инфраструктуру банка из дома?
Можно ли подключиться к SWIFT, если у вас есть логин/пароль и доступ к сети банка?
То это зависит от квалификации злоумышленника.
Если вы спрашиваете, можно ли имея пароль подключиться к SWIFT из дома, то конечно нет. Для этого вам все еще нужен доступ к сети SWIFT.
Вероятно, я не понимаю ваш вопрос, потому что он мне кажется наивным.Разве наивный вопрос трудно понять? Перечитайте ветку: когда такое разнообразие ответов — приходится упрощать вопрос до наивного в надежде получить полный, внятный и однозначный ответ. Но могу и не получать — мне было просто любопытно, но если здесь какая-то банковская/технологическая тайна, то не смею настаивать.
А где деньги? Я вот не понимаю. Все счета же привязаны к физическому или юридическому лицу. В конце концов банк всегда может отозвать транзакцию или swift такого не умеет?
Всегда можно загнать деньги в казино в какой-нибудь диковинной стране. Вам, конечно, помогут власти с расследованием инцидента, но дней через 30 после запроса. Сами понимаете, деньги успеют из казино уйти, оставив заведению определенный процент. Казино выступает в роли миксера.
1. Если деньги уже на счете получателя, отправитель отозвать ничего не может.
2. В этой схеме денег на счете получателя нет, они мгновенно выводятся.
2. В этой схеме денег на счете получателя нет, они мгновенно выводятся.
Любопытны, конечно, технические детали и методы взлома. Автор, когда инфа появится, сделаете апдэйт?
А что удивляться то? Если 98% процентов банков имеют критические уязвимости… Загляните под капот любой банковской инфраструктуры и вы встретите дыры в стиле MS08-067, которые не патчатся десятилетиями.
С удовольствием почитал бы про двухфакторную аутентификацию RDP.
Или все по-старинке под паролем ходят?
Или все по-старинке под паролем ходят?
Тут есть варианты.
1. После аутентификации всеми необходимыми факторами для вас становится доступен определенный порт определенного хоста.
Делается по разному, опишу опять же из своего опыта. Например, можно сделать отдельный веб-интерфейс для аутентификации. После удачного прохождения у пользователя появляется SSL-VPN до сервера доступа, который транслирует трафик на RDP хост. + при подключении автостартует mstsc с параметрами подключения. Бонусом можно настроить SSO, чтобы аутентификацию в RDP пользователь уже не производил.
2. RDP в браузере. Есть такой софт, который позволяет завернуть RDP в HTTP. Для этого обычно требуется только браузер, поддерживающий HTML5. Дальше, наверное, объяснять не нужно, так как задача сводится к тому, чтобы сделать 2FA для веб ресурса. SSO тут тоже возможно.
3. Насколько мне известно, Remote Gateway поддерживает протокол RADIUS, а, значит, позволяет использовать сервера аутентификации, которые тоже поддерживают RADIUS.
4. Слышал что-то про варианты, когда на RDP-хост устанавливаются какие-то проприетарные плагины от серверов аутентификации, но сам не использовал.
5. Если говорить про просто задачу двухфакторной аутентификации RDP, то можно использовать PKI-Аутентификацию.
1. После аутентификации всеми необходимыми факторами для вас становится доступен определенный порт определенного хоста.
Делается по разному, опишу опять же из своего опыта. Например, можно сделать отдельный веб-интерфейс для аутентификации. После удачного прохождения у пользователя появляется SSL-VPN до сервера доступа, который транслирует трафик на RDP хост. + при подключении автостартует mstsc с параметрами подключения. Бонусом можно настроить SSO, чтобы аутентификацию в RDP пользователь уже не производил.
2. RDP в браузере. Есть такой софт, который позволяет завернуть RDP в HTTP. Для этого обычно требуется только браузер, поддерживающий HTML5. Дальше, наверное, объяснять не нужно, так как задача сводится к тому, чтобы сделать 2FA для веб ресурса. SSO тут тоже возможно.
3. Насколько мне известно, Remote Gateway поддерживает протокол RADIUS, а, значит, позволяет использовать сервера аутентификации, которые тоже поддерживают RADIUS.
4. Слышал что-то про варианты, когда на RDP-хост устанавливаются какие-то проприетарные плагины от серверов аутентификации, но сам не использовал.
5. Если говорить про просто задачу двухфакторной аутентификации RDP, то можно использовать PKI-Аутентификацию.
Добавил уточненную информацию по сумме ущерба — 339,5 млн.р. Она стала известна из обзора FinCERT Банка России.
Насколько я помню из прочитанного по этой истории, местом атаки был канал между АБС и терминалом SWIFT. Вроде тех нескольких случаев с УФЭБС.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Еще одна кража через SWIFT. Теперь в России