Егор Филатов, младший аналитик отдела анализа защищенности Angara Security, подготовил разбор двух недопустимых событий в банковской сфере, которые могли бы нанести серьезный урон бизнесу. Но на практике, это моделирование кибератаки через мобильное приложение условного "банка", которое получили все участники майского StandОff 11.

Итак, подготовка к учениям:

До начала соревнований командам, которые успели связаться с организаторами, были высланы две смарт-карты: по легенде одна из этих карт ваша, вторая - украденная. В справочной информации по данному заданию организаторы написали: “Это практически те же карты, как Visa или MasterCard, с такими же уязвимостями”. Забегая вперед, для реализации первых двух недопустимых событий эксплуатировать “уязвимости карты” не потребовалось. Кратко покажу, что же было записано на картах на примере одной из них:

{
  "applications": [
	{
  	"aid": [-96, 0, 0, 0, 3, 16, 16],
  	"amount": -1.0,
  	"applicationLabel": "Paymentvillage.com Challenge Card",
  	"leftPinTry": 20,
  	"listTransactions": [],
  	"priority": 1,
  	"readingStep": "READ",
  	"transactionCounter": 6
	}
  ],
  "at": "",
  "atrDescription": [],
  "state": "ACTIVE",
  "track2": {
	"cardNumber": "1234563175481004",
	"expireDate": "Jan 1, 2024 12:00:00 AM",
	"raw": [18, 52, 86, 49, 117, 72, 16, 4, -46, 64, 18, 1, -111, 79],
	"service": {
  	"serviceCode1": "INTERNATIONNAL_ICC",
  	"serviceCode2": "NORMAL",
  	"serviceCode3": "NO_RESTRICTION"
	}
  },
  "type": "VISA"
}

Из интересного и того, что сразу же бросается в глаза:

amount - количество денег на карте, которое мы не можем точно узнать;
leftPinTry - количество некорректных попыток, которые можно сделать до блокировки карты; transactionCounter - количество транзакций, совершенных с помощью данной карты; cardNumber и expireDate - данные карты, которые помогут нам далее в реализации одного из недопустимых событий.

Уже на соревнованиях (в 10:33 первого дня) участникам выслали ссылку на Android-приложение, которое представляло собой SoftPOS, то есть фактически являлось мобильным POS-терминалом.

На главном экране приложения есть два поля для ввода данных: сумма перевода и id приобретаемого товара.

Если ввести сумму больше 100 и нажать на верхнюю кнопку, приложение выдает ошибку: “Price cannot be more than $10 as we do not accept PIN (yet)”.

При попытке перевести сумму в 100 центов или меньше, приложение начнет ругаться, что оно запущено на устройстве с рутом.

Здесь нам требуется обойти проверку на рут и отключить SSL Pinning. Это можно сделать, воспользовавшись базовым функционалом objection (тулкит для динамического анализа мобильных приложений, использующий frida), а именно, двумя командами.

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

Недопустимое событие №1: вывод денег с украденных банковских карт

В данном НС требовалось списать деньги с украденной смарт-карты в размере $100000 и перевести их на свой счет. Нужно было обойти ввод пин-кода, так как при попытке просто перевести данную сумму сервер возвращал следующую ошибку:

Для этого посмотрим, какой запрос POS-терминал отправляет на сервер.

GET
/auth_host.php? amount=100&trans_type=EMV&9f15=5000&9f34=1f0302&9f36=00B5&9f26=EBD9D9BB0A99BBF1&82=0040&5a=1234563175481012&9f37=5C5543CA&5f2a=0840&9a=230602&9f02=000000000100&merchant_id=1&type=purchase HTTP/1.1
User-Agent: Dalvik/2.1.0 (Linux; U; Android 12; Pixel 6 Build/SQ3A.220705.004)
Host: www.paymentvillageprocessing.com
Connection: close
Accept-Encoding: gzip, deflate

По тегу trans_type можно понять, что тип транзакции - EMV (Europay + MasterCard + VISA).

Отсюда вопрос: какие еще типы транзакций бывают.
Ответ: CNP.

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

Краткий обзор тегов, передающихся на сервер:

Из всех этих тегов интерес для нас представляет тег под номером 9f34, который отвечает за проверку принадлежности карты и того, кто делает транзакцию. Если проще: в этом теге посылается информация о том, была ли транзакция подтверждена и каким способом.

Когда осуществляется оплата больше легитимной суммы, POS-терминалы требуют ввод пин-кода, и в этом случае у них есть две возможности. Либо подтверждать транзакцию самому и ждать ответ от сервера, либо запросить у владельца карты пин-код и проверить его в оффлайн-режиме. Соответственно все, что требуется, − это поменять значение 9f34 на значение, которое означало бы, что пин-код проверен в оффлайн-режиме и был введен корректно.

Для этого нам потребуется декодер данного тега.

Если ввести в него стандартное значение, отправленное нашим приложением, получаем следующую расшифровку:

Далее берем в руки побитовый декод данного тега и пытаемся понять, что нам требуется послать. Рассмотрим генерацию первого байта:

Можем заметить, что есть возможность передать значение “Enciphered PIN verification performed by ICC”. Это нам и нужно, так как данное значение можно перевести как: “Зашифрованная проверка пин-кода выполнена картой”.

Далее скажу честно: был легкий брутфорс b7 значения с помощью рук и редактирования запроса. В итоге получаем нужное нам значение тега 9f34 - 440002, что декодируется как:

То есть пин-код был введен и проверен картой в оффлайн режиме.

Отправляем запрос, при котором сервер должен у нас требовать ввод пин-кода (то есть сумму больше $10), но с измененным значением тега 9f34:

Основное сделано, мы перевели $100000 без ввода пин-кода, осталось закинуть их на свою карту. Напоминаю, что сейчас мы “купили” товар с id 1208 и нам нужно вернуть за него деньги. Если посмотреть внимательно, то можно заметить тег type, который равен purchase. При попытке подставить в данный тег что-то не особо осмысленное получим следующую ошибку:

Соответственно, есть type refund, который вернет нам деньги за покупку. Здесь все оказалось просто: делаем запрос на сервер с просьбой вернуть нам деньги, но вместо возврата на карту, с которой был выполнен платеж, вписываем свою:

На этом этапе первое недопустимое событие было успешно реализовано и можно переходить ко второму.

Недопустимое событие №2: мошенничество с карточным процессингом

У нас была задача совершить мошенническую операцию с картой, которой у команды не было физически. Тут небольшая ремарка, если НС1 был засчитан, то НС2 нет: почему он был отклонен, объясню позже.

Помните про тег trans_type, который равнялся EMV? Тогда заглянем в приложение (все же таск на мобилки, да?) и посмотрим на генерацию запроса на сервер.

Из интересного стоит обратить внимание на следующие строчки:

Из этих строк можно понять, что существует два типа транзакций: CNP и EMV. EMV мы уже проэксплуатировали, попробуем послать CNP-запрос:

Ошибка: сервер хочет получить от нас cvc, exp_year, exp_month. Так как у нас есть своя карта, попробуем указать ее данные и послать запрос:

Транзакция выполнена успешно, теперь нам доступен новый формат общения с сервером. Так как у нас было две карты, мы можем понять, что у StandOff карт exp_year и exp_month одинаковы и равны 24 и 01 соответственно. Следовательно, остается забрутить cvc-код одной из карт и перевести с нее деньги. Для этого переходим в Burp Intruder и пытаемся набрутать любую карту.

Но тут есть одна оговорка, брутать cvc-код мы можем только с минимальной задержкой 8 секунд. Долго? Да, но больше на тот момент ничего не оставалось.

Запускаем, ждем и надеемся:

Супер, нам удалось успешно найти правильные cvc и теперь мы можем списывать деньги с карты, которой нет в физическом доступе.

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

Надеюсь тем, кто участвовал в StandОff 11 было интересно прочитать про реализацию двух недопустимых событий и сравнить со своей тактикой. А тем, кто не принимал участие, - узнать, какие уязвимости были заложены и как их можно было обойти.