Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 54
Спасибо, прекрасное доведение до публики некоторых частных проблем. На мой взгляд, немного смазаны решения задач, а именно не очень четко показаны решения этих проблем.
То что эти примеры взяты из реальной практики это печально. Особенно тем что это почти эталонные атаки которые уже много лет как описаны везде от учебников ИБ до глянцевых журналов на околокомпьютерную тематику.
Можно ли сделать следующие выводы: Что уже начиная с этапа проектирования безопасности уделяется минимум внимания? Что соответствие международным стандартам ИБ не представляет интереса для российской банковской сферы? Угрозы реальны, но размеры убытков от них не оправдывают затрат на защиту?
Жаль что в статью не вошла эта часть.
Можно ли сделать следующие выводы: Что уже начиная с этапа проектирования безопасности уделяется минимум внимания? Что соответствие международным стандартам ИБ не представляет интереса для российской банковской сферы? Угрозы реальны, но размеры убытков от них не оправдывают затрат на защиту?
и показывая, как бы он (стандарт) мог «сломать» эти вектора, если бы банки его применяли.
Жаль что в статью не вошла эта часть.
То, что мы встречаем в ТЗ банковских систем — или вообще нет пунктов про безопасность, или если есть, то минимальны и не достаточны (пример первый с SSL. SSL есть, но не работает). Новый стандарт как раз и направлен на исправление данных угроз, так что действия предпринимаются. И про размер убытков — вектор атак явно смещается с клиентов (частные случаи и долгие суды) на сами банки и АБС — а это уже не просто частный случай, это вообще весь банк.
Ох, этот клиент вообще притча во языцех. Мало того, что работает с помощью мамонтов и только на мастдае (IE 7 (на новых версиях — принудительная эмуляция) + куча ActiveX и подгрузок DLL), так еще и дебильно организован (с этими бумажными запросами сертификатов и т.д.).
Пока самый удобный видел у альфа-банка, там только веб-клиент + подтверждение по SMS, уровень безопасности такой же, как и у 3D Secure.
Пока самый удобный видел у альфа-банка, там только веб-клиент + подтверждение по SMS, уровень безопасности такой же, как и у 3D Secure.
С каких пор для обозначения канала связи используется символ СС?
Я думал, что канал связи изображается как-то так:
itmages.ru/image/view/1531024/93ac4d59
Это невежество или демонстрация убеждений?
Я думал, что канал связи изображается как-то так:
itmages.ru/image/view/1531024/93ac4d59
Это невежество или демонстрация убеждений?
Я думаю, что так автор просто показал разрыв канала. Да и у символа СС наклон не такой.
Откуда вы знаете символ СС? Это как-то связано с вашими убеждениями?
Я вот не знаю, как символ СС выглядит — и запросто мог нарисовать такой же, чтобы показать разрыв канала.
Я вот не знаю, как символ СС выглядит — и запросто мог нарисовать такой же, чтобы показать разрыв канала.
offtop: А как по мне, просто две молнии символически нарисованы. Видеть всюду нацистскую символику — не к добру это.
А за статью спасибо, сам общаюсь с программистом, он правда не в банке, а в федеральном казначействе работает, так что мне это тема близка.
А за статью спасибо, сам общаюсь с программистом, он правда не в банке, а в федеральном казначействе работает, так что мне это тема близка.
Обратил внимание на некую схожесть только после вашего комментария. Что вам сказать… «У кого о чем болит». Не думаю, что подобные высказывания и обвинения здесь уместны.
Всякие веб и мобильные банкинги всегда очень интересны. Жаль что сделать это легально практически невозможно. 5 лет назад мне довелось поковыряться в клиенте своего банка под старушку WinCE 6. Через 10 минут мне позвонили и поинтересовались странной активностью с моего аккаунта. Пронесло. А у Вас такое исследование. Интересно.
Больше бы матчасти. MITM это конечно хорошо, но на текущий момент, по сетям гуляет огромное количество различных форм-грабберов и инжекторов. Более интересно было-бы почитать про то, как подобное зверье работает на зараженной машине. Как инжектится в процессы и тд и тп.
4 — использование флага Secure на куках если уж есть https
Мне, и не только мне, одна украинская «контора» предлагала взламывать банки (банковские сервисы) под видом работы. Так что такие подходы встречаются и даже оплачиваются по рыночным окладам.
Кстати, про SSL и банки. Где-то как-то слышал (©), что страница ввода данных карты должна быть с SSL EV-сертификатом. Последнее время всюду вижу обычный сертификат на таких страницах. Это я путаю, или же раньше такое условие все же было?
Кроме того, убивал всегда тот факт, что у того же Тинькоффа (карта яндекс.денег) страница 3DSecure подтягивает какую-нибудь незначительную картинку по http и как следствие браузер ругается… И такое не только в ТКС, встречал и в киберплате подобное, и еще где-то, уж не вспомню…
Кроме того, убивал всегда тот факт, что у того же Тинькоффа (карта яндекс.денег) страница 3DSecure подтягивает какую-нибудь незначительную картинку по http и как следствие браузер ругается… И такое не только в ТКС, встречал и в киберплате подобное, и еще где-то, уж не вспомню…
после первой картинки исправьте пожалуйста опечатку
Все мы знаем про этотцЗеленый цвет в начале навигационного бара. Кому я рассказываю?
Все мы знаем про этот
Давайте еще раз. Клиент отправляет оператору документ. «Документ» является совокупностью данных и запросов по внесению этих данных в банковскую БД. Я правильно понял?
Судя по всему document.scr это исполняемый файл в формате Windows PE.
Так как пентестеры знали архитектуру атакуемой системы, скорее всего этот файл содержит механизм получения доступов и соединения с sql базой данных от имени оператора и с машины оператора, с последующим выполнением нужных sql запросов.
Так как пентестеры знали архитектуру атакуемой системы, скорее всего этот файл содержит механизм получения доступов и соединения с sql базой данных от имени оператора и с машины оператора, с последующим выполнением нужных sql запросов.
Именно так.
Стоит отметить, что вышеописанное характерно и сработает в том случае, если связка между системой ДБО и автоматизированной банковской системой (АБС) используется стандартная и вы знаете какая именно это связка(у БСС в их продукте этих связок много). И нужно отличать что БД ДБО это не БД АБС, в которой как правило есть разграничения по доступам и разграничение контроля, как правило изменение баланса счета без наличия первичных документов обнаружат в кратчайшие сроки и инициируют внутреннюю проверку с блокировкой подозрительного счета.
А еще может быть связка не стандартной, мне, например, в свое время от предыдущего сотрудника досталась связка между АБС diasoft5nt (40я вроде в нотации БСС) и ДБО, так в этой связке кроме «гвоздей» была реализована антифрод система и все подозрительные документы просто сливались в специальную пачку и им присваивался статус фиктивных. Тем самым в любом случае операционист был вынужден обращать на документы внимание. И не зная реализации этой доработанной связки становится очень сложно реализовать подобное описанному в статье.
А еще может быть связка не стандартной, мне, например, в свое время от предыдущего сотрудника досталась связка между АБС diasoft5nt (40я вроде в нотации БСС) и ДБО, так в этой связке кроме «гвоздей» была реализована антифрод система и все подозрительные документы просто сливались в специальную пачку и им присваивался статус фиктивных. Тем самым в любом случае операционист был вынужден обращать на документы внимание. И не зная реализации этой доработанной связки становится очень сложно реализовать подобное описанному в статье.
Абсолютно верно подмечено про различные базы ДБО и АБС, об этом я написал в комментарии ниже (кстати, классно, что умышленно опущенные моменты в статье всё-таки всплыли :) ). Смысл в том, что АБС забирает платежки из базы, где атакующий создает их уже с таким статусом, где ЭЦП не проверяется, как итог — генерация платежок хоть от кого и хоть кому.
>>Смысл в том, что АБС забирает платежки из базы, где атакующий создает их уже с таким статусом, где ЭЦП не проверяется
Не спорю по поводу того, что проверки ЭЦП по-умолчанию(!) на стороне связки с БД ДБО и БД АБС нет. По крайней мере, когда я был сотрудником банка, то такой проверки со стороны связки по-умолчанию(!) в этих продуктах я не видел, АБС была Diasoft5NT.
Но прошу отметить, что БСС и Diasoft предоставляют очень гибкие и очень мощные в плане кастомизации системы.
Как я отметил в комментарии выше, у нас связка была немного переписана, были забиты специфичные для нас «гвозди» и проверки, не зная о которых сгенерить платежный документ в абс становится практически не возможным, т.к. связка не вываливала статусы наружу и из себя представляла черный ящик. Плюс в АБС у нас было разграничение по ролям и один человек, не мог переводить документы из статуса в статус, ко всем действиям привязывалась ЭЦП из АБС и был последконтроль.
Но такая ситуация, когда и организационными и техническими мерами были внедрены системы тотального контроля, возникла после неприятного инцидента:).
Насколько понимаю, в описанном примере, возникла ситуация, когда получилось в БД ДБО внести данные об остатках на счете и затем они попали в БД АБС? Или программный код из «Документ.scr» выполнялся уже в БД АБС?
Не спорю по поводу того, что проверки ЭЦП по-умолчанию(!) на стороне связки с БД ДБО и БД АБС нет. По крайней мере, когда я был сотрудником банка, то такой проверки со стороны связки по-умолчанию(!) в этих продуктах я не видел, АБС была Diasoft5NT.
Но прошу отметить, что БСС и Diasoft предоставляют очень гибкие и очень мощные в плане кастомизации системы.
Как я отметил в комментарии выше, у нас связка была немного переписана, были забиты специфичные для нас «гвозди» и проверки, не зная о которых сгенерить платежный документ в абс становится практически не возможным, т.к. связка не вываливала статусы наружу и из себя представляла черный ящик. Плюс в АБС у нас было разграничение по ролям и один человек, не мог переводить документы из статуса в статус, ко всем действиям привязывалась ЭЦП из АБС и был последконтроль.
Но такая ситуация, когда и организационными и техническими мерами были внедрены системы тотального контроля, возникла после неприятного инцидента:).
Насколько понимаю, в описанном примере, возникла ситуация, когда получилось в БД ДБО внести данные об остатках на счете и затем они попали в БД АБС? Или программный код из «Документ.scr» выполнялся уже в БД АБС?
В самом простом случае автопроцедура BSS выгружает документы которые находятся, например, в статусе «К выгрузке» (т.е. уже прошедшие автоконтроль и проверку ЭЦП). В данной атаке, как я понял, предполагается, что операционист может добавить документ напрямую в базу ДБО BSS сразу в нужном статусе «К выгрузке».
>>> В данной атаке, как я понял, предполагается, что операционист может добавить документ напрямую в базу ДБО BSS сразу в нужном статусе «К выгрузке».
Нет тут немного другой сценарий в статье.
В статье описан пример с отправкой «произвольного документа в банк». Произвольный документ приходит в банк, и возможно операционист из своей кастрированной версии bsclient открывает это сообщение (например нам так посылали списки на зачисление зп), но опять же в диктмане можно 65 ветку настроить так, чтоб ничего кроме тхт приложить не смогли:
>>>У оператора специальное десктопное ПО для обработки подобных заявок
>>>Он его открывает, и после этого на нашем счету 13 млрд рублей:
Остается немного не понятным открывает автопроцедура на cbank'e «документ.scr» или все-таки операционист его ручками запускает?
Нет тут немного другой сценарий в статье.
В статье описан пример с отправкой «произвольного документа в банк». Произвольный документ приходит в банк, и возможно операционист из своей кастрированной версии bsclient открывает это сообщение (например нам так посылали списки на зачисление зп), но опять же в диктмане можно 65 ветку настроить так, чтоб ничего кроме тхт приложить не смогли:
>>>У оператора специальное десктопное ПО для обработки подобных заявок
>>>Он его открывает, и после этого на нашем счету 13 млрд рублей:
Остается немного не понятным открывает автопроцедура на cbank'e «документ.scr» или все-таки операционист его ручками запускает?
Программный код выполняется на машине оператора, соответственно «злобный бинарь» идет в БД ДБО.
Если есть проверка платежки перед импортом ее в АБС — данный вектор ломается (но остаются некоторые другие вектора).
Если есть проверка платежки перед импортом ее в АБС — данный вектор ломается (но остаются некоторые другие вектора).
На самом деле, то что здесь описано в 95% случаев не работает и не будет работать применительно к банку. И вот почему…
1. Про вариант атаки с SSL и открытыми паролями.
Сейчас почти все банки вводят 2-х факторную авторизацию. То есть помимо логина и пароля для совершения платежа в интернет-банк нужно еще кое что:
а) Одноразовый код, присылаемый на сотовый клиента, без этого кода ни одну операцию выполнить нельзя.
б) Использование крипто-калькуляторов для создания одноразового кода подтверждения, без этого кода ни одну операцию выполнить нельзя.
в) Использование всевозможных ключей eToken для подписания операции ЭЦП.
Поэтому даже если MITM осуществима и пароль на вход украли, от него мало пользы без одноразового кода или eToken'a. Хотя и одноразовые пароли и eToken не дает 100% гарантию защиты, всетаки голова на плечах должна быть в любом случае.
2. Про История #2 — хардкорная, тут идет в чистом виде социальная инженерия, в нормальных банках есть соответствующие положения касательно политики информациооонй безопасности, в которых описано что такое соц. инженерия и как на неё не поддаться, сотрудники уведомляются под личную подпись. Конечно человеческий фактор никто не отменял, но и банки тоже стараются это учесть в своей политике.
3. История #3 – тру-банковская — да, тут проблемма есть, но она решается своевременным обновлением прикладного софта, того же Adobe Acrobat и Flash или использованием других программ.
1. Про вариант атаки с SSL и открытыми паролями.
Сейчас почти все банки вводят 2-х факторную авторизацию. То есть помимо логина и пароля для совершения платежа в интернет-банк нужно еще кое что:
а) Одноразовый код, присылаемый на сотовый клиента, без этого кода ни одну операцию выполнить нельзя.
б) Использование крипто-калькуляторов для создания одноразового кода подтверждения, без этого кода ни одну операцию выполнить нельзя.
в) Использование всевозможных ключей eToken для подписания операции ЭЦП.
Поэтому даже если MITM осуществима и пароль на вход украли, от него мало пользы без одноразового кода или eToken'a. Хотя и одноразовые пароли и eToken не дает 100% гарантию защиты, всетаки голова на плечах должна быть в любом случае.
2. Про История #2 — хардкорная, тут идет в чистом виде социальная инженерия, в нормальных банках есть соответствующие положения касательно политики информациооонй безопасности, в которых описано что такое соц. инженерия и как на неё не поддаться, сотрудники уведомляются под личную подпись. Конечно человеческий фактор никто не отменял, но и банки тоже стараются это учесть в своей политике.
3. История #3 – тру-банковская — да, тут проблемма есть, но она решается своевременным обновлением прикладного софта, того же Adobe Acrobat и Flash или использованием других программ.
1. Что мешает злоумышленнику показать пользователю нужную ему страницу с подтверждением, а потом самостоятельно отправить в банк совсем другие данные? Да, в SMS иногда будут приходить не те данные (а в некоторых случаях приходят не полные данные), но кто их сверяет?
1. Вообще-то воровать пароль не обязательно — достаточно украсть саму сессию. А все дополнительные проверки пройдет за нас сам пользователь. В этом и вся суть MITM-атаки.
2. Вообще-то, суть этой истории — не про социальную инженерию, а про DNS-туннель. Скажите, а если бы лично вам поставили задачу настроить сеть так, чтобы исключить утечку информации — вы бы про DNS вспомнили?
3. При чем тут Adobe Acrobat и Flash, если проблема — в собственном клиенте банка, человеческом факторе — и недостаточно параноидальной настройке ОС? Где вообще в этой истории встретились акробат с флэшем?
2. Вообще-то, суть этой истории — не про социальную инженерию, а про DNS-туннель. Скажите, а если бы лично вам поставили задачу настроить сеть так, чтобы исключить утечку информации — вы бы про DNS вспомнили?
3. При чем тут Adobe Acrobat и Flash, если проблема — в собственном клиенте банка, человеческом факторе — и недостаточно параноидальной настройке ОС? Где вообще в этой истории встретились акробат с флэшем?
В первом случае вам не нужен пароль. Необходимо дождаться, когда клиент полностью войдет в систему и инициирует, например, перевод. Остается просто подменить номер счета, куда идут денежки.
2. Вообще-то, суть этой истории — не про социальную инженерию, а про DNS-туннель. Скажите, а если бы лично вам поставили задачу настроить сеть так, чтобы исключить утечку информации — вы бы про DNS вспомнили?
Я в курсе про такую лазейку, еще 4 года назад делел тунель поверх DNS с помощь IODINE.
3. При чем тут Adobe Acrobat и Flash, если проблема — в собственном клиенте банка, человеческом факторе — и недостаточно параноидальной настройке ОС? Где вообще в этой истории встретились акробат с флэшем?
Вы видать плохо прочитали статью, в ней написано про Adobe Acrobat Reader — ASLR/DEP Bypass Exploit with SANDBOX BYPASS, и вектор атаки через PDF-файл, ибо EXE файлы прикреплять в Клиент-банк от BSS запрещено.
История №3 не очень реалистична.
1. Кто из клиентов может отправить файл "*.scr", заверенный ЭЦП?
2. А если документ поддельный, то почему документы, не прошедшие контроль ЭЦП отображаются у оператора?
3. Тот грустный факт что в BSS используют разграничение прав на уровне приложения, но не используют на уровне СУБД, пожалуй я могу подтвердить, тем не менее ничто не мешает самостоятельно сделать нужные настройки на PAYDOCRU и т.п. документы
1. Кто из клиентов может отправить файл "*.scr", заверенный ЭЦП?
2. А если документ поддельный, то почему документы, не прошедшие контроль ЭЦП отображаются у оператора?
3. Тот грустный факт что в BSS используют разграничение прав на уровне приложения, но не используют на уровне СУБД, пожалуй я могу подтвердить, тем не менее ничто не мешает самостоятельно сделать нужные настройки на PAYDOCRU и т.п. документы
Да точно, совсем забыл в cbank'e БССа реализованы все возможные внутренние механизмы, правда мало кто ими пользуется.
В этом комментарии habrahabr.ru/company/dsec/blog/214351/#comment_7375847 я отписался, что есть еще эшелон обороны, а именно связка между ДБО и АБС.
В этом комментарии habrahabr.ru/company/dsec/blog/214351/#comment_7375847 я отписался, что есть еще эшелон обороны, а именно связка между ДБО и АБС.
Отвечу одним комментом сразу на несколько, так как вопросы схожие. Еще раз отмечу, что условия не идеализированные, а были взяты из реальной практики.
По первой истории с митмом мобильного приложения. Если внимательно читать статью, то сказано про изменение именно транзакции «на лету». В случае отсутствия двухфакторной авторизации — транзакция просто пролетит. Реальный же случай был именно с 2х факт. авторизацией — и пусть приходит смска, мы же митмаем на лету! ЭЦП, например при пополнении счета телефона (через моб. приложение) не требуется.
Вторая история. Да, демо в основном показательно слабой настройкой самой сети, о чем также явно сказано в самой статье (снова делаю выводы, что статью читали «наискосок»).
И третий случай. В BSS в ДБО для юр. лиц отлично крепятся .scr файлы, они же обычные исполняемые файлы под Windows. После атаки на оператора, извлечение конфига для подключения к БД .scr файл (кто вообще сказал, что это .pdf эксплойт? Это из второй истории) коннектится напрямую к БД. Да, это не основная БД банка (АБС), но из нее АБС забирает платежки. Трюк далее в том, что создаются платежки с таким статусом, где уже ЭЦП (самой АБС) не проверяется. В итоге платежки улетают куда надо (без оригинальной подписи).
По первой истории с митмом мобильного приложения. Если внимательно читать статью, то сказано про изменение именно транзакции «на лету». В случае отсутствия двухфакторной авторизации — транзакция просто пролетит. Реальный же случай был именно с 2х факт. авторизацией — и пусть приходит смска, мы же митмаем на лету! ЭЦП, например при пополнении счета телефона (через моб. приложение) не требуется.
Вторая история. Да, демо в основном показательно слабой настройкой самой сети, о чем также явно сказано в самой статье (снова делаю выводы, что статью читали «наискосок»).
И третий случай. В BSS в ДБО для юр. лиц отлично крепятся .scr файлы, они же обычные исполняемые файлы под Windows. После атаки на оператора, извлечение конфига для подключения к БД .scr файл (кто вообще сказал, что это .pdf эксплойт? Это из второй истории) коннектится напрямую к БД. Да, это не основная БД банка (АБС), но из нее АБС забирает платежки. Трюк далее в том, что создаются платежки с таким статусом, где уже ЭЦП (самой АБС) не проверяется. В итоге платежки улетают куда надо (без оригинальной подписи).
Здесь принципиальная ошибка — у оператора есть разрешение на создание документов. Оператор может без внешнего проникновения совершать мошеннические действия.
О чем явно сказано в статье — что у оператора, по факту, sql доступ к бд. Расматривается модель внешнего нарушителя, а не внутреннего.
Оффтоп: Странная ситуация приключилась с первой иллюстрацией (комменты + писали в личку). Честно, взял картинку с очень популярного и признанного многими ресурса по безопасности — OWASP: www.owasp.org/index.php/Man-in-the-middle_attack и в мыслях не было ничего про СС и подобные вещи. Решил заменить на черно-белую, совершенно нейтральную картинку.
Судя по оценке того комментария и ответов к нему хабрасообществом, проблема была надуманная. Ну или на хабре одни нацисты.
Пусть теперь в новой найдут что-нибудь :) а всё это конечно напоминает vk.com/wall-23308460_370179
Спасибо за интересную статью! :)
Хотел немного уточнить:
В этом случае необходимо выбирать минимальный TTL для своих ресурсных записей, иначе команды могуть «застрять» в DNS-кэше локального резолвера.
Хотел немного уточнить:
DNS сервер их расшифровывает и отдает обратные команды. Задача решена — доступ в внутреннюю сеть получен :)
В этом случае необходимо выбирать минимальный TTL для своих ресурсных записей, иначе команды могуть «застрять» в DNS-кэше локального резолвера.
Надо просто запрашивать уникальные записи…
Тоже вариант, но в таком случае прийдется придумать оооочень сложную систему кодирования.
А так достаточно просто 26 (+26) записей с буквами латинского алфавита и 10 для цифр. Либо же просто
000-255.example.org для передачи ASCII кодов. Так целую телеграмму передать можно ;-) Конечно, можно подойти более изящно и зашифровать как-то эти символи, сменив порядок.
А так достаточно просто 26 (+26) записей с буквами латинского алфавита и 10 для цифр. Либо же просто
000-255.example.org для передачи ASCII кодов. Так целую телеграмму передать можно ;-) Конечно, можно подойти более изящно и зашифровать как-то эти символи, сменив порядок.
Вот это — действительно сложно. А закодировать команду — довольно просто. На самом деле, закодировать длинное сообщение — гораздо проще, чем реализовывать операцию «склейки» сообщения из однобуквенных фрагментов.
А про антиф-фрод системы нет ли у вас материала для статьи? Помню в прошлом было несколько простых критериев — лимит по сумме (например, свыше 1 000 000 рублей), или дополнительный ручной контроль подлинности документов при платежах новым контрагентам.
Было бы интересно, до чего дошла научно-инженерная мысль.
Было бы интересно, до чего дошла научно-инженерная мысль.
Могу предложить следующие презентации
ib6.ib-bank.ru/files/files/d1/11%20pobortsev.pdf
ib6.ib-bank.ru/files/files/d3/06%20ermakov.pdf
ib6.ib-bank.ru/files/files/d1/11%20pobortsev.pdf
ib6.ib-bank.ru/files/files/d3/06%20ermakov.pdf
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Атаки на банковские системы