Аннотация
В последнее время, в интернете развелось слишком много мошенников, которые пользуются неграмотностью людей (недостатком знаний), и разводят их на деньги, иногда не малые. Если разбирать платежи в системе SWIFT то особенно часто можно увидеть предложения про мануал доводку платежей (manual download), которую ставят хакеры (так вам будут объяснять ребята свою работу), в итоге максимум вы получите pdf файл, с непонятным набором символов, который выглядит логично, но ничего общего с SWIFT не имеющий. В данной статье будет описаны процедуры, благодаря которым вы действительно сможете составить платежное сообщение которое сможет пройти комплаенс на суммах до 500 тысяч евро, благодаря доверительным отношениям внутри системы СВИФТ. Также вы поймете общий принцип работы системы СВИФТ, и сможете проводить первичную проверку сообщений и выявлять подделки.
Пролог
Все что описано в данной статье, представлено для ознакомления. Все данные связанные с фирмами, действующими лицами в статье обобщены, отредактированы или изменены. Статья не призывает к незаконным действиям. Представлена для ознакомления в обучающих целях.
Перейдем к сути:
Типичные атаки хакеров, имеющие отношения к системе СВИФТ, которые мы можем наблюдать в отчетах полиции или средствах массовой информации – следующие:
1. Компрометация сети учреждения;
2. Использование критичных багов платежной системы;
3. Компрометация учетных данных оператора платежей СВИФТ;
4. Доступ к СВИФТ-интерфейсу обмена сообщений учреждения;
5. Авторизация платежных сообщения с использованием скомпрометированных учетных записей платежного оператора и интерфейса обмена сообщениями;
Чтобы выполнить данный вектор атаки вам потребуется компрометация нескольких пользователей, нескольких систем, понимания того, как работает целевое приложение, обход двухфакторной авторизации, затем вы обязаны скрыть журналы доступа во избежание предупреждения от легитимных операторов, настроить вредоносное ПО и .т.д. – что даже в кратком описании выглядит ОЧЕНЬ сложно.
Поэтому мы пойдем от простого к сложному, и опишем устройство системы в целом, которое поможет вам разобраться как работает система SWIFT, и разберем стандартное платежное поручение, а затем уже более внимательно изучим каждый вектор атаки по отдельности.
Общие параметры
Для начала вам нужно полностью понять и разобраться с конкретным «разделом» платежной системы (СВИФТ) в целевом учреждения. Мы будем называть её просто СВИФТ.
СВИФТ принимает данные в произвольном формате и выводит начальные платежные инструкции в формате ISO 15022 / RJE / SWIFT MT.
Мы сосредоточимся на компрометации платежного поручения МТ103, а именно:
- MT - «тип сообщения»
- 1 - категория 1 (платежи и чеки клиентов)
- 0 - группа 0 (перевод финансовых учреждений)
- 3 - Тип 3 (уведомление)
Помимо типа сообщения, нам нужно понять, как обрабатывается данный платеж. Он достаточно типичен, для таких видов перевода и выглядит так:
- Система (Приложение для работы с SWIFT) принимает данные от пользователя в удобном ему формате (например посредством заполнения полей в графическом интерфейсе приложения). Затем Система выводит начальную платежную инструкцию в формате SWIFT MT;
- Система отправляет данное сообщение дальше, в компонент именуемый Промежуточным Программным Обеспечением (ППО), который преобразует (при необходимости) полученное сообщение в современный формат SWIFT, понятный системе. По сути, это брокер сообщений предоставляемый для не институциональных финансовых организаций.
- ППО отсылает сформированное сообщение в Институциональное Финансовое Учреждение (Банк, Кредитная организация или иное, далее Банк для удобства), для обработки.
- Банк проверяет содержимое сообщения, производит ряд проверок (не находится ли компания в черном списке, проходит проверку системой борьбы по отмыванию денег, проверяет легальность операции при высоких объемах, делает запрос в антимонопольное ведомство или в валютный контроль, если такие опции есть в стране где находится Банк)
- Если сообщение сформировано верно, проходит внутрибанковскую проверку, то сообщение отправляется в Swift Alliance Gateway, где оно подписывается и отправляется в организацию/банк получателя через SwiftNet.
Разбираемся в деталях обмена данными
Зададимся вопросом: как эти сообщения передаются между всеми этими системами?
Чаще всего в любой Платежной Системе для передачи сообщений между различными компонентами используются так называемые Очереди Сообщений (ОС).
Существуют различные «адаптеры», которые могут быть использованы между системами обменивающиеся данными напрямую с Swift Alliance Gateway:
- Удаленный хост-адаптер API (HAPI)
- Хост адаптер Очереди Сообщений (MQHA)
- Хост-адаптер веб-служб (WSHA)
Также в требованиях строго прописано, что должно присутствовать минимум два администратора очереди. Один управляет очередями в Зоне работы SWIFT, второй для общения в корпоративной сети и/или прочих системах учреждения (к примеру внутрибанковские операции должны быть ОТДЕЛЕНЫ от операций связанных с системой SWIFT, а также операции в других платежных системах, например VISA, MASTERCARD или SEPA).
Определяем жизнеспособный вектор для внедрения
Пришло время определится с задачей: «Поместить платежное поручение в очередь и успешно его обработать во всех системах (пройти валидацию)»
Задача простая, поэтому зададим правильные вопросы, которые помогут в реализации:
- Как получить доступ на запись в нужную очередь?
- Что защищает сообщения в очередях?
- Что защищает сообщение при транзите?
- В каком формате находятся сообщения?
- Как составить синтаксически верное сообщение для выбранного формата? (цель – 0 ошибок)
- Где находится PKI (Public Key Infrastructure или Инфраструктура открытых ключей)? Как, где и когда подписываются сообщения, производится их проверка?
- Можно ли как-нибудь обойти подпись сообщения?
- Какие значения в сообщениях зависят / контролируются / определяются системой, обрабатывают их вне моего контроля (или другого человека)?
- Какую максимальную сумму я могу перевести с помощью, не предупреждая учреждение / не требуя проверки вручную?
Теперь распишем саму задачу подробнее, по пунктам:
- Грамотно написать платежную инструкцию на 500 тысяч евро;
- Вставить данную платежную инструкцию в очередь;
- Сообщение должно пройти синтаксическую проверку (ACK or NACK);
- Сообщение должно пройти все дополнительные проверки, включая проверку AML;
- Сообщение должно быть успешно подписано;
- Пройти валидацию при проверки правилами SWIFTNet;
С точки зрения хакера оно выглядит так:
- Скомпрометировать сеть учреждения;
- Получить доступ к рабочей станции администратора Менеджера Очередей;
- Получить необходимые реквизиты фирмы;
- Провести требуемую работу.
Следует избегать следующего:
- Атака с участием платежного оператора SWIFT (самой системы);
- Атака с использованием доступа к SWIFT-приложению (прямой доступ к официальному банковскому приложению);
- Необходимость компрометации подписи ключей (подделка цифровых ключей);
- Необходимость компрометации учетных записей или сертификатов оператора SWIFTNet.
Нужно разобраться как сделать простейшую инструкцию по оплате в формате МТ103. Как правило, банковский оператор (или любой иной пользователь/оператор системы СВИФТ) пишет платежные сообщения также как и мы с вами, но с помощью удобного графического интерфейса (например, Alliance Access). В необработанном виде это выглядит примерно так:
Разберем каждое поле выделенное :ТАК: подробнее.
:20: Ссылка на транзакцию
16x — данное поле может быть размером только 16 символов. По этому ссылке, ваш банк может идентифицировать сообщение в своей сети, ровно также, как и банк отправитель.
:23B: Код операции банка
4!c — четыре заглавных буквы, отвечающие за операцию. В нашем случае это CRED — кредитование бенефициара.
:32A: Дата / Валюта / Сумма
6!n3!a15d — поле заполняется в строгой последовательности. Сначала дата (год/месяц/день), затем заглавными буквами валюта (например: EUR, USD, RUB), затем в произвольном порядке цифрами сумма.
Также к примеру, если комиссия в поле 71A — будет указана как BEN, то в таком случае добавляется поле 33B, где будет указана точная сумма к зачислению на счет.
:50K: Клиент
Данное поле содержит реквизиты приказодателя (юридическое лицо, физическое лицо, банк). Поле используется в сообщениях МТ103, МТ103+ с опциями ”A”, “K”, “F”. В зависимости от опции заполнение меняется, от банка к банку.
:59: Бенефициар
В данном поле указываются реквизиты клиента-бенефициара в пользу которого осуществляется платеж:
- номер счета клиента в банке бенефициара (При переводе средств в пользу клиентов банков стран, поддерживающих Директиву ЕС об обязательном указании IBAN, указание номера счета в формате IBAN является обязательным.(указывается без каких-либо разделительных символов)
- наименование клиента;
- адрес (при наличии);
- город, страна.
:70: Информация о денежном переводе
В данном поле размером 4 строки по 35 символов — указывается информация о переводе, включающая в себя: цель перевода (оплата контракта-договора/ обучения/ путевки, материальная помощь и т.д.), номер и дату договора-контракта, товарных документов, наименование выполненных работ/ оказанных услуг, товаров, др.
:71A: Детали комиссии
Указывается, за чей счет совершается оплата комиссий при осуществлении перевода. При этом отмечается один из возможных вариантов:
- OUR - общая сумма взимаемых комиссий Банка-клиента, а также комиссии других банков, участвующих в прохождении платежа, оплачиваются клиентом-плательщиком (поле 50A,K или F).
При этом существует вероятность зачисления средств бенефициару не в полном объеме.
- SHA - общая сумма взимаемых комиссий Банка-клиента оплачивается клиентом-плательщиком (поле 50A,K или F), а комиссии других банков, участвующих в прохождении платежа взимаются из суммы перевода;
- BEN - общая сумма взимаемых комиссий Банка-клиента, а также комиссии других банков, участвующих в прохождении платежа, взимаются из суммы перевода, указанной в поле 33B.
Теперь имея валидное тело сообщения, будь у нас был доступ к оператору SWIFT Alliance Access, мы могли бы вставить это сообщение в интерфейс создания необработанных сообщений и совершить перевод. Останется лишь дело за малым — добавить коды BIC отправителя и получателя, и выбрать подразделения банка откуда и куда.
Но мало изучить само тело сообщения (вы должны помнить что все поля должны заполнятся СТРОГО инструкций в чем грешат большинство мошенников которые рисуют вам платежки, нарушая элементарные правила заполнения документов). Поэтому перейдем к следующей части и разберем сообщение целиком, не только его тело.
Детальный разбор МТ103
Как выше уже говорилось мы разобрали лишь тело сообщения, которое является «Блоком №4» (именуемым «Текстовый блок») в стандарте сообщений СВИФТ МТ. Как следует из названия, вы сможете догадаться, что также имеются блоки 1-3, и будете правы.
Обычно данные блоки генерируются автоматически приложениями обработки платежей (тот же SWIFT Alliance Access), и не обязательно вводятся операторами.
«Полное» сообщение МТ103 состоит из 6 блоков:
- Блок 1 – Базовый заголовок;
- Блок 2 – Заголовок приложения;
- Блок 3 – Пользовательский заголовок;
- Блок 4 – Текстовый блок;
- Блок 5 – Хвост сообщения;
- Блок 6 – Системный блок.
Согласно документации SWIFT, базовый заголовок имеет следующий вид.
Разберем его на составные части
{1:F01EBNKGB20AXXX0000999999}
Это порядковый номер блока (не может быть 2, 3 или любым другим в данном блоке).
{1:F01EBNKGB20AXXX0000999999}
Это тип приложения, в нашем случае это F — т.е. FIN
{1:F01EBNKGB20AXXX0000999999}
Это тип сообщения, в нашем случае это 01. Что эквивалентно FIN, т.е. не является сообщением ответом — по типу ACK или NACK.
{1:F01EBNKGB20AXXX0000999999}
Это БИК отправителя EBNKGB20, где EBNK (Код банка) GB (Код страны) 20 (Код территории).
{1:F01EBNKGB20AXXX0000999999}
Это номер терминала отправителя. Обычно указывается A, но в случае огромного институционального банка могут быть и иные терминалы.
{1:F01EBNKGB20AXXX0000999999}
Это филиал отправителя. В случае если указывать филиал банка указывать не требуется, то заполняется просто XXX.
{1:F01EBNKGB20AXXX0000999999}
Это номер сессии, в нашем случае это 0000
{1:F01EBNKGB20AXXX0000999999}
Это порядковый номер сообщения, в нашем случае 999999
Забегая вперед, стало видно первая проблема с которой столкнётся хакер: это номер сеанса и порядковый номер сообщения, достаточно сложно выгадать точные значения которые будут не выбиваться из общей канвы отправленных сообщений в автоматическом режиме.
БЛОК 2 (ЗАГОЛОВОК ПРИЛОЖЕНИЯ)
Также из документации, вы можете свободно понять что он выглядит таким образом:
Разберем его на составные части:
{2:I103FBNKFR20XXXXN}
Это порядковый номер блока, может быть только 2.
{2:I103FBNKFR20XXXXN}
Это идентификатор сообщения. В нашем случае это I (Input), но есть вариант Output или O. Тут важно не ошибиться, Input — несмотря на то что начинается на IN — исходящее сообщение, а Output — входящее сообщение. Тут часто ошибаются рисовальщики, выдавая со значением O.
{2:I103FBNKFR20XXXXN}
Это тип сообщение, в нашем случае это 103, или кредитный перевод для одного клиента.
{2:I103FBNKFR20XXXXN}
Это идентификатор банка клиента, FBNKFR20, где FBNK (Код банка) FR (Код страны) 20 (Код территории).
{2:I103FBNKFR20XXXXN}
Далее идёт X — или номер терминала банка получателя. Обычно все не специализируемые терминалы маркируются X. И это даёт ещё одну ошибку в SWIFTах, художников. Обычно они пишут всего три X, когда всегда их было 4.
{2:I103FBNKFR20XXXXN}
Это филиал получателя банка. Для обычных переводов, обычно филиал указывать не требуется. В отличии, например от переводов Банковских инструментов.
{2:I103FBNKFR20XXXXN}
Это приоритет сообщения. В нашем случае это N (Normal), то есть не срочный. Может быть также U (Urgent), или срочный. Обычно за такие доплачивают дополнительные комиссии до 100 долларов.
БЛОК 3 (Пользовательский заголовок)
Третий блок используется для определения некоторых «специальных» правил обработки сообщения SWIFT. Используя данный заголовок, можно указать что сообщения должно обрабатываться с использованием так называемых правил «Сквозной обработки» (Straight Through Processing или STP), которые поясняют что сообщение идет end-to-end без вмешательства человека (например вы отправили деньги из онлайн банкинга, и оно обработано автоматически компьютером, без участия банковского офицера). Это можно указать следующим образом.
Однако, в таком виде заголовок не будет действительным, потому что с Ноября 2018 года теперь для данного заголовка требуется ОБЯЗАТЕЛЬНОЕ значение “Unique end-to-end transsation reference” или UETR, которое введено в рамках Swift Global Payments Innovation (GPI), а с Ноября 2020 года абсолютно все SWIFT MT1xx, 2xx — должны обрабатываться согласно директивы GPI во всех банках без исключений. (Это ещё один повод не верить в сказки людей, ищущих специфичные «приемки» GPI. Все SWIFT сейчас работают с этим протоколом.)
UETR код, по своей сути является, глобальный уникальный идентификатор (Globally Unique Identifier или GUID) соответствующий четвертой версии алгоритма генерации, используемого стандартом IETF “RFC4122”. Он состоит из 32 шестнадцатеричных символов, разделенных на 5 частей дефисами следующим образом:
Где:
- Х – любой шестнадцатеричный символ в нижнем регистре (от 0 до f)
- 4 – фиксированное значение;
- Y – либо 8, 9, а, b.
Где:
{3: {119: STP} {121: 8с1с42b5-669f-46ff-b2f2-c21f99788835}}
Это порядковый номер блока, может быть только 3.
{3: {119: STP} {121: 8с1с42b5-669f-46ff-b2f2-c21f99788835}}
Это тип проверки сообщения, в нашем случае 119 — указывает каким способом обработать FIN сообщения.
{3: {119: STP} {121: 8с1с42b5-669f-46ff-b2f2-c21f99788835}}
Это область проверки, в нашем случае — STP. Запрос SWIFT проверить сообщение по принципу Сквозной обработки.
{3: {119: STP} {121: 8с1с42b5-669f-46ff-b2f2-c21f99788835}}
Указывает на поле UETR.
{3: {119: STP} {121: 8с1с42b5-669f-46ff-b2f2-c21f99788835}}
Само значение UETR.
БЛОК 5 и 6 (ХВОСТ и СИСТЕМНЫЙ БЛОК)
Ранее мы уже обсуждали «Тело сообщения» или БЛОК 4, поэтому мы его пропускаем и рассмотрим два последних блока.
Прежде чем мы двигаться дальше, немного расскажу о бессмысленно сложной концепции сообщений в СВИФТ.
- Вводимое сообщение (Input message) – это сообщение, которое ОТПРАВЛЯЕТСЯ из учреждения, так как это сообщение «вводится» оператором и отправляется учреждением в другое учреждение.
- Выводимое сообщение (Output message) – это сообщение, которое «входит» в учреждение. Так что это сообщение выводится SWIFTNet и принимается учреждением.
Для вводимых сообщений эти блоки не проблема, потому что заголовки используются только для указания того, было ли сообщение предназначено для обучения/ тестирования, или это возможный дубликат (копия сообщения):
Где TNG – означает TRAINING (обучение), а SPD означает Possible Duplicate (Возможный дубликат).
Однако, для выводимых сообщений, все немного сложнее, и системный блок может выглядеть так:
{5:{MAC:13461AEF}{CHK:4A3367FD3D76}{TNG:}}{S:{SPD:}{SAC:}{COP} {MDG:5E87F8F390E5FB886E8311E4D7C994371FA9AF3119B2C314DAE4583 8AFF08AC}}
Разбивая эти значения получим следующее.
Хвост ({5:})
MAC – код аутентификации сообщения, рассчитанный на основе всего содержимого сообщения с использованием секретного ключа, который был получен от банка получателя, и секретного алгоритма;
CHK – это контрольная сумма PKI сообщения, используемая для гарантии того, что сообщение не было повреждено при передаче.
TNG – отметка, указывающая, является это сообщение тестовым или обучающим.
Системный блок ({S
SPD – возможный дубликат
SAC – отметка об успешном заверении и авторизации, она присутствует только в случаях если проверка подписи прошла успешно или авторизация и проверка RMA (Application Management) прошла спешно.
COP – указывает что это основная копия сообщения;
MDG – HMAC256 сообщения с использованием ключей LAU
И если вы понимаете логику, то указание того же MAC, или CHK в СВИФТе отправки — не возможно. Так как их вам может выдать и отпечатать только принимающий банк, банк отправитель эти значения знать не может.
Разобравшись с логикой сообщения SWIFT, перейдем непосредственно к отправке сообщений.
Логика подготовки хакера
Так как ранее, мы разбирали это с точки зрения того, что SWIFT типа Manual Download, или иные виды ставят нам хакеры, или банковские офицеры мы должны разобраться в их логике.
Напоминаю, что цель вставить наше сообщение в очередь, чтобы оно прошло все валидаторы и попало в SWIFT NET.
Чтобы поставить наше сообщение в очередь, потребуются две вещи:
1. Доступ к правильному менеджеру очередей (МО);
2. Возможность записи в этом МО.
В зависимости от банка/финансовой организации, доступ к МО добыть можно разными способами, порой очень сложными. Однако, если будем пытаться получить доступ «с нуля», то схема примет примерно такой вид:
- Администратор МО получает доступ к своей выделенной рабочей станции с помощью данных АП;
- Получаем удаленный доступ к выделенному серверу через RDP, так как лишь компьютер администратора находится в белом списке тех, кто имеет доступ до сервера.
- Может потребоваться дополнительный шаг, в случае если очереди используют Channel Authentication Records, разрешая лишь определенным системам, или учетным записям пользователей доступ к определенной очереди сообщения.
- Может потребовать дополнительный шаг, в случае если каналы дополнительно защищены Message Encryption (MQME), которое шифрует сообщения основываясь на том, с какого канала оно поступило. Таким образом, даже если вы Главный Администратор всея Банка, вы можете читать/записывать только в специально выделенные для вас очереди, прописанные в MQME — конфигурационном файле.
- Исходя из вводных, приходим к выводу, что администратор МО может использовать дополнительные инструменты, такие как Jump Server, для чтения/записи в желаемые очереди сообщений.
При обсуждении в данной статье таких сложных атак на инфраструктуру финансового рынка (FMI) более разумно согласиться с тем, что Advanced Persistent Threat (APT) будет рассматриваться как выполнимая задача. Поэтому рассмотрим реальный вектор атаки на Банк.
Жизнеспособный вектор атаки
Взяв на вооружения идею о том, как получить доступ, понимая все технологии и средства контроля безопасности, мы перейдем к детальному разбору векторов атаки.
Важно добавить что между адаптерами Swift Alliance Gateway и Банком (или иным институциональным финансовым учреждением (ИФУ), имеются каналы LAU (локальной аутентификации), ровно также как и между Банком и ППО (промежуточным программным обеспечением, например Alliance Access). Наверное стоит объяснить что такое LAU.
«Локальная аутентификация» или LAU — это контроль, безопасности реализованный SWIFT для аутентификации сообщения с помощью пары общих ключей между двумя системами. Эти ключи объединяются и используются для генерации SHA256 HMAC сообщения и добавления его в блок S (о чем мы говорили ранее). Затем эти ключи могут быть проверены и валидированы системой получателя. Фактически, это проверка подлинности и происхождения сообщения. Таким образом, даже если злоумышленник отправит с фиктивного терминала мошеннический платеж, ему для начала нужно скомпрометировать левы и правый ключ подписания LAU, либо сгенерировать правильный HMAC и добавить его к сообщению, чтобы оно было принято и успешно обработано. (что снова приводит к тому, что врунишки говорящие что они подделывают банковский сервер, не более чем врунишки).
Но оставим пока LAU в стороне, для начало нам нужно определится с тем что будет является нашей целью. Ведь по сути, внутри банка очень много очередей, и каждая из них имеет «входящие» и «исходящие» очереди. Держа в уме этот момент, стоить отметить: входящее сообщение должно быть в формате ожидаемом целевой системы (все зависит от конкретной исходящей системы), а исходящее — в формате которое будет принято и обработано, в соответствии с правилами. Поэтому пойдем с конца.
Цель SWIFT ALLIANCE GATEWAY
На мой взгляд, это наименее осуществимый вектор атаки. Чтобы его сделать, хакеру предстоит разобраться как работают SWIFT-адаптеры (не продаются в свободном доступе), исследовать каждый уголок системы, что мало вероятно.
Внедрение SWIFTом, LAU на сообщениях между адаптерами, отличный способ обезопасить канал связи. Что исключает возможность атаки в этом направлении.
Примечание: В интернете вы наверняка натыкались на manual download, и ledger 2 ledger. Так вот, это и есть то самое тонкое место где можно провести данное сообщение. Сделать такое и тысячи китайских хакеров не могут.
Цель БАНК
Отбросим пока LAU и SWIFT-адаптеры, помните сеансы и номера сообщений в начале статьи? Так вот, они вставляются банком, в самом конце жизненного пути сообщения. Учитывая тот факт, что мы не знаем как генерировать эти значения без получения доступа ко всей инфраструктуре банка, а также к зашифрованным данным на их серверах, на данный момент рассматривать Банк как цель не выглядит возможным.
Цель Программное Обеспечение (ППО)
Чтобы ППО стало ваше целью, надо ввести сообщение в «входящую» очередь Банка, или исходящую очередь ППО. По сути, оно должно соответствовать формату сообщений которые выпускает ППО. После того, как ППО запустит сообщение в очередь банка, в теории у нас добавиться и номер сеанса, и порядковый номер к сообщению, совместно с UETR кодом. Это крайне интересны вектор атаки.
Тем не менее, ППО — чаще всего «партнер» системы SWIFT, а они как правило, предоставляют партнерам облачное решение разработанное с использование Alliance Access Development Kit, что позволяет вендорам разрабатывать программное обеспечение, совместимое с SWIFTNet, и собственно внедрять LAU. Поэтому, подделать сообщение здесь — значит скомпрометировать левый и правый ключ подписи LAU, вручную высчитать и записать HMAC сообщения (без ошибок), а затем разместить его в очередь.
Цель Платежная Система Банка (ПС)
Как мы описывали ранее в этой статье, входящие данные представляют собой платежную инструкцию «специфичную для конкретного приложения» из бэк-офисной системы целевого учреждения, но это не само сообщение SWIFT. И это крайне интересный концепт.
Что насчет исходящих очередей?
Несмотря на то, что ПС получает данные в пользовательского формате, исходящее сообщение смутно напоминает SWIFT MT. Что для хакера будет идеальным вектором для атаки. Кроме того, у ПС нет LAU между ним и ППО, потому что в отличии от ППО, ПС не является партнером SWIFT в сфере отправки сообщений. Она лишь одна из немногих платежных систем внутри Банка.
Кроме того, поскольку ПС по сути лишь небольшая часть гораздо более крупной архитектуры бэк-офиса, она не является частью SWIFT Secure Zone, и поэтому использует Менеджер очередей в более доступном разделе сети (МО1).
Учитывая все выше сказанное, и имея скомпрометированный аккаунт администратора МО, мы могли бы использовать доступ в корпоративной сети для аутентификации МО1. Также, впоследствии хакер может записать платежное поручение в «исходящую очередь» платежной системы.
Сформулируем что мы хотим:
В теории, почему это должно сработать, заключается в том, что ППО — приложение которое неявно доверяет всему, что получает от соответствующих upstream-систем. Это сделано преднамеренно, так как по замыслу модели безопасности, сообщение об отправке средств может быть создано в любой момент времени. Если существует система, целью которой является обеспечить действительность сообщения об оплате в любой точке upstream, то downstream системы не должны иметь проблем с обработкой данных сообщений (за некоторыми исключениями). Без этой конструкции по крайней мере невозможно поддерживать высокопроизводительную платежную систему.
План такой:
- использовать доступ администратора МО;
- злоупотребить «доверительными отношениями» между ПС, ППО и Банком
- ввести платежное сообщение в исходящую очередь ПС;
- платежное поручение МТ103, должно пройти все валидаторы.
Хакер запускает платеж
Немного разобравшись в том, как устроена система, проверяем элементы которые нужны для того чтобы отправить SWIFT.
- Целевая система;
- Формат сообщения;
- Менеджер очередей;
- Требуемая очередь;
- Права на запись, чтение, доступ на уровне администратора;
- Доступ к обмену сообщения SWIFT;
- Поддельное сообщение.
Теперь, хакеру необходимо создать действительное платежное сообщение, используя настоящие реквизиты компании в целевом учреждении. Это кстати было причиной, ранее когда искали компании и их реквизиты в виде CIS — в интернете. Большинству людей нужны доноры для их переводов. В нашей статье, эти данные будут поддельными в угоду статье. Т.Е. это не настоящие реквизиты.
Детали счета отправителя — John Doe, GB12EBNK98765412345678 на EBNKG20;
Детали счета получателя — Alise Smith, GB15EBNK9876587654321 на EBNKG20;
Возможно вы обратили внимание, что отправитель и получатель имеют идентичный BIC. В рамках статьи это сделано потому, что наш хакер хочет увидеть как сообщение обработается посредством SWIFTNet, и смог провести его анализ от начала и до конца. Более того, мы используем код BIC для «test&training».
Примечание: SWIFT сообщение может из одного банка, отправлено в тот же банк, и обработано системой SWIFTNet, а не внутри банка.
Теперь имея доступ к этим «настоящим реквизитам аккаунтов и тем знаниям что у вас есть после прочтения статьи, мы генерируем исходящее сообщение MT103:
Примечание: Поле 33B не является обязательным, однако в стандарте МТ указано что «если код страны отправителя и получателя, принадлежат одной стране, то поле 33B обязательное». Таким образом, если 33B будет отсутствовать, то правила проверки сети будут неудачными, SWIFTNet вернет NAK с кодом ошибки: D49{1:F01EBNKG20AXXX0000000000}
{2:I103EBNKG20XXXXN}
{3:{119:STP}{121:3b02c40e-e060-400a-ac74-47e006dd26e3}}
{4:
:20:SWIFTMT103FAKE
:23B:CRED
:32A:220214EUR500000
:33B:EUR500000
:50K:/GB12EBNK98765412345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREET, LONDON, GB
:59: /GB15EBNK98765487654321
ALICE SMITH
ALICE'S COMPANY
ALICE'S COMPANY
10 ALICE STREET< MACHESTER, GB
:70
:71A:SGA
-}{5:{TNG:}}{S:{SPD:}}
Отложим пока обязательные и необязательные поля в сторону. Нужно подправить наше сообщение, чтобы его могла скушать исходящая очередь Платежной Системы Банка.
Сначала первые три блока, мы разметим на одной строке. Далее, удаляем поле 121 (UETR) из пользовательского заголовка, так как данное поле сгенерирует банк непосредственно перед отправкой в SWIFTNet.
Далее, в поле TRN проверим что имеется ровно 16 символов, чтобы не совершить классическую ошибку.
Не забудем добавить десятичную запятую, в сумме транзакции. Иначе правила проверки синтаксиса будет нарушено, и сообщение не пройдер проверку SWIFTNet.
Убеждаемся в том, что IBAN точные, в противном случае, сообщение не сможет понять какой тип подписи применить в сети SWIFT. В нашей статье IBAN фальшивые и они не бьются, но хакеры в своей работе должны использовать легитимные данные.
Остается нам удалить лишь блок трейлера (5) — так как он также будет добавлен в БАНКе. Системный блок удалеяем по той же причине.
Конечное сообщение у нас приняло следующий вид:
{1:F01EBNKGB20AXXX0000000000}{2:I103EBNKGB20XXXXN}{3:
{119:STP}}{4:
:20:MYSWIFTMT103FAKE
:23B:CRED
:32A:220214EUR500000,00
:33B:EUR5000000,00
:50K:/GB12EBNK98765412345678
JOHN DOE
JOHN'S BUSINESS LTD
21 JOHN STREE, LONDON, GB
:59:/GB15EBNK98765487654321
ALICE SMITH
ALICE'S COMPANY
10 ALICE STREET, MACHESTER, GB
:70
:71A:SHA
-}
Если внимательно изучить конечный результат, то многие проблемы о которых мы думали — отошли на второй план. Чем глубже мы закапывались в дебри SWIFT, тем проще стало составление сообщение.
Теперь у нас есть сырое сообщение в формате МТ103, поэтому сохраняем его в файл — к примеру в 103.txt почему бы и нет, и добавляем в очередь сообщений.
- Через доступ к учетной записи менеджера очередей, подключаемся к его компьютеру;
- Переходим на сервер;
- Открывает наши инструменты для работы с менеджерами, логин в менеджере очередей, на моменте исходящей очереди Платежной Системы;
- Подключаемся к очереди;
- Выбираем наш файл 103.txt;
- Вызываем функцию «записи в очередь»;
- И… операция выполнена.
Теперь вам нужно перейти в Alliance Access. Открыть вкладку истории сообщений, и ждать 15-20 минут его обработки.
ACK. Оно работает. (Примечание: на самом деле, конечно, с первого раза врядли получится. Когда я изучал только SWIFT, все мои разы были NAK, и те самые исправления в тексте сообщения, это лишь результат практики в составлении сообщений, и поиска ошибок в этих сообщениях, чтобы не быть замеченным легитимным оператором)
С таким платежным поручением у нас получится в пределах банка отработать сообщение. Но это не тоже самое, чтобы отправить сообщение в другой банк.
И тут всплывают множество иных моментов, где одного оформления MT103 недостаточно. 103, лишь платежное уведомление, но с ним не обязательно деньги упаду на счет (такое возможно только при прямых корреспондентских отношениях между банками). Тем более, шанс сделать это сколько ни будь легально драматически падают, ведь сообщение будет проверяться банками посредниками. Поэтому копаем дальше.
Разбираемся где потеряли деньги
Итак, мы отправили МТ103 и он даже добрался до целевого учреждения. Но где деньги? Здесь все совсем неоднозначно, ведь чтобы деньги зачислились, они должны откуда то списаться. Но обо всем по порядку.
Для начала разберемся, как вообще происходит процесс списания денег внутри банка. К примеру есть у нас клиент А, и клиент Б в Deutsche Bank (далее DB). Я (Клиент А) хочу отправить 10 евро своему другу (Клиенту Б). Мне стоит лишь сообщить банку о своих намерениях, и банк спишет с моего счета 10 евро, а на счет моего друга зачислит эти деньги. По сути процедура осуществляется в пределах Платежной Системы Банка, внутри самого банка. Деньги не поступают в банк, и не выводятся из него, они просто фиксируются во внутренней бухгалтерии и все уравновешивается.
Но что, если Клиент Б, находится в другом банке, например HSBC. DB не составит труда списать 10 евро с моего счета, но как нашему банку убедится что HSBC зачислили на счет Клиента Б — 10 евро? Зачем HSBC соглашаться на то, чтобы быть должным клиенту Б больше, чем раньше? По сути, они были бы согласны на такую операцию, чтобы быть должным кому то больше, если кому то, они в конечном счете будут должны немного меньше.
Тот самый другой, кому они должны меньше не может быть Клиента А, ведь мы никак не связаны с их банком, и даже не имеем счетов в банке HSBC. В таком случае, могут ли они контактировать банки друг с другом? Например DB откроет свой счет в HSBC, а HSBC откроет свой счет в DB.
Тогда схема будет выглядеть так:
- DB списывает 10 евро со счета Клиента А;
- DB добавляет 10 евро к счету HSBC, открытому в DB;
- DB уведомляет HSBC о том, что на их счет поступили 10 евро, и они хотят передать эти 10 евро Клиенту Б;
- HSBC зная что на их депозите в DB стало на 10 евро больше, могут пополнить этими деньгами счет клиента Б.
Такая модель обработки платежей является деятельностью банков на основе корреспондентских отношений. Мы разобрали лишь простейшую схему, со связью банков непосредственно друг с другом. Но порой бывает чтобы проложить маршрут для платежа, приходится использовать третий, или даже четвертый банк в цепочке, пока платеж не достигнет Бенефициара. Что безусловно увеличивает расходы и степень сложности совершения такого платежа.
Также у банка вызывает беспокойство тот факт, что это очень рискованный вид платежа. Давайте посмотрим как это выглядит со стороны банка. Ведь в результате этого платежа, банк становится уязвимым от DB. В нашем случае это всего 10 евро. Но представим что сумма не 10 евро, а например 100 миллионов. И банк корреспондент не DB, а менее крупный, и надежный оператор. В таком случае у HSBC возникнут большие трудности, если маленький банк разорится. В таком случае, конечно можно попросить не зачислять деньги на счет HSBC в DB, а попросить HSBC списать деньги со счета DB в HSBC. Но в таком случае возникают иные проблемы, присущие перемещениям крупных средств.
Также стоит учесть, что сеть SWIFT стоит денег. Если DB нужно посылать сообщение в сети SWIFT о каждом переводе на счет клиента Б — 10 евро. То в скором времени количество затрат в выписке возрастет кратно. И самое худшее, появляется проблема ликвидности. Представьте сколько нужно было бы DB иметь на счетах банков корреспондентов денег, на случай если любой из клиентов пожелает перевести деньги в HSBC, или Lloyds, или Citi, или любой иной банк. Эти же деньги можно вложить в активы, выдача займа, потратить или запустить в трейдинг, где они принесут банку доход.
Именно поэтому банки делают немного иначе. Большинство банков отслеживает все многочисленные платежи, и фиксируют их разницу в своих расчетах при закрытии банковского дня. При таком подходе, у каждого банка, на счету прочих банков корреспондентов не потребовалось иметь огромные суммы, и эти деньги могут использоваться более эффективно. В частности, сокращает издержки банков и позволяет не держать в заморозке огромное количество денег на кор счетах других банков.
Но и при тако подходе возникают угрозы — потеря завершенности расчета. Вы можете отправить платеж рано утром, однако банк-бенефициар не получит деньги до определенного момента. Ведь в любой момент дня, до завершения расчета, возможно банкротство отправителя во время перевода: зачисление средств принимающей стороной на счет получателя — опрометчивый ход. А значит возникает задержка.
Но можно конечно взять на себя риск, и в случае проблем отменить транзакцию, тогда расчет никогда не будет считаться завершенным, и получатель не может рассчитывать на эти деньги до определенного момента.
И все таки, как же достигается консенсус и нулевой риск для контрагента?
Ведь ни один из подходов описанных ранее, нельзя применить и быть абсолютно уверенным, что платеж осуществиться быстро, его нельзя будет отменить и банк-отправитель в последствии не разорится. Вам нужна гарантия такого рода, но увы, никто не даст вам гарантию на 100 миллионов евро облигациями или акциями, если есть риск что эти 100 миллионов не будут выплачены, или их нельзя вернуть.
Тут нам поможет система Центробанков. Именно для этого и создавались такие системы как CHAPS, FedWire, Target 2, которые занимаются переводами фунтов, долларов и евро соответственно. Данные системы осуществляют движение денежных средств в режиме реального времени между счетами, которые банки имеют в соответствующем Центробанке (т.е. все крупнейшие банки страны, имеют счет в центральном банке, где они могут переводить деньги из одного банка в другой, просто давая указания Центробанку на списание средств с одного счета и зачисления на другой). По сути это система валовых расчетов в режиме реального времени (Примечание: никакого учета задолженностей, то есть мгновенная, завершенная, без возможности возврата средств).
И только теперь, мы поговорим про покрытие Мт202. При отправке SWOFT на малую сумму — банк получатель, проверяет пополнение своего счета на указанную сумму в банке корреспонденте отправителя, в случае отсутствия пополнения счета банка получателя, он списывает данные средства со счета банка отправителя в своем банке, и зачисляет платеж далее по цепочке. Списание со счета, будет отображено в выписке банке отправителя, тем самым показывая что средства ушли в сторону бенефициара. При отсутствии баланса, или недостатке ликвидности на данном счете, счет может закрытья, а в случае Центробанков еще и грозит отзывом лицензии из-за той самой пресловутой ликвидности, что вскроет мошенническую схему и хакера который делал перевод.
Что приводит к простому выводу. Деньги на кор. счетах не лежат в больших количествах. Даже в крупных банках, размеры этих счетов редко превышают 50 миллионов евро. Про миллиарды нет и речи. Потому что деньги лежащие мертвым грузом, банку не нужны. В дополнение к этому, система Центробанков использует SWIFT лишь в уведомительных целях, и все переводы на суммы крупнее 15 миллионов евро, проходят дополнительный клиринг. Что для фантазеров с 50 миллионов за транш, как нож в спину.
Немного о настоящих хакерах
И все таки, взломы систем SWIFT — были. Точнее ломали небольшие банки, и их корпоративные сети. Но взломы были. И попытки отправки SWIFT тоже. Несмотря на то, что хакеру есть много иных методов помогающих вывести огромный капитал за короткий срок времени, при такого уровня доступе.
Но мы разберем, напоследок, какие вещи приходится делать хакерам, чтобы ваш платеж был успешно обработан, и добрался до бенефициара в автоматическом режиме.
Чисто гипотетически, хакер можем владеть аккаунтом где есть финансы, в нужном банке. Тогда платежного поручения МТ103 — достаточно. Легитимный оператор в 100% случаев, увидит и обработает платеж. Спишет деньги с вашего кор. счета, и отправит их по банковским каналам далее. Но в большинстве своем, получая доступ к банковской инфраструктуре вы не получаете доступ до компаний и их деньгам, а значит хакерам придется оперировать с деньгами на кор. счете.
И тут уже придется идти на всякие ухищрения. Подделывать легитимные программы вшивая в них backdoor, очереди печати на принтер, подделывать и перехватывать почту на почтовых серверах банка, и так далее. Это очень долгий, кропотливый и дорогостоящий труд, без права на ошибку. Простым обывателям с интернета, которые бесплатно хотят держать карман шире, чтобы кто-то отсыпал им денюжку, а с этих денег они уже вам отыграют — никому не нужны.
В 99% случаев, все это работает по заранее отлаженным каналам, с известными друг другу людьми и попасть в эти круги извне просто обладая и хлопая красивыми глазами не выйдет.
Послесловие
В сухом остатке. Работа в теме SWIFT — долгая, кропотливая, и очень дорогостоящая. Сопряжена с высокими рисками, и возможностью сесть за решетку. Поэтому крайне рекомендуется избегать такой вид деятельности. В большинстве своём, вы скорее всего попадётесь на развод, а если и не попадётесь, то после работы велик шанс что ваш «технарь», не особый то и профессионал, и не пройдет и пары дней, как к вам совместно с ордером на арест придут граждане в форме. Деньги конечно же отзовут, а снятие их со счета, или дальнейшее движение — это будет отягощающим фактором в вашем будущем деле.
И это не страшилка для запугивания, а реальные жизненные кейсы, которые случаются ежегодно. Успешных операций, по выводу средств — очень немного. И выполняются они в очень узких кругах, известными всем банкирам людьми. Возможно вы их даже знаете, раз читаете эту статью.
В большинстве своем, люди ищут простой, бесплатный, надежный канал для отправки денег на их счета, и чтоб это было завтра. Так никогда не было, и никогда не будет. Только в сказках.
Всем мир. Работайте с профессионалами, делайте деньги, а не гоняйте воздух в интернете.
