Карта Тройка представляет из себя универсальный пополняемый электронный кошелек, широко используемый в системах оплаты общественного транспорта Москвы с 2013 года.

Цель данного исследования — выяснить защищенность системы электронного кошелька от подделки баланса, оценить безопасность инфраструктуры, работающей с картой. Вся работа была выполнена без использования специальных технических средств. Использовался дешевый смартфон на платформе Android и персональный компьютер. Общее время, затраченное на исследование, составило 15 дней.

В ходе работы был успешно проведен реверс­-инжиниринг мобильного приложения «Мой проездной», что позволило получить доступ к памяти карты и изучить структуру хранения данных. Были найдены уязвимости, позволяющие выполнить подделку баланса, записанного на электронном кошельке карты Тройка. В результате чего стало возможным использование систем, поддерживающих карту, без оплаты.

Итогом исследования стала разработка приложения TroikaDumper, позволяющего эксплуатировать уязвимости системы электронного кошелька.

Внимание! Данные материалы представлены исключительно в ознакомительных целях. Подделка проездных билетов является уголовным преступлением и преследуется по закону.

Введение

Бесконтактные платежи становятся все более популярны. На текущий момент общественный транспорт в Москве полностью переведен на бесконтактную систему оплаты. Самым популярным платежным средством становится универсальная карта Тройка, которая активно интегрируется в различные системы помимо общественного транспорта. Картой уже можно оплатить билет в московский зоопарк, планетарий, каток, арендовать велосипед и прочее. Недавно Тройка была интегрирована в SIM-карты всех мобильных операторов города — услуга Мобильный билет. Очевидно, что распространение карты будет только увеличиваться. Транспортная сеть города обслуживает территорию с населением свыше 20 млн человек и обеспечивает перевозку более 350 млн пассажиров в месяц. В свете этого становится важным вопрос защищенности карты.

Целью данного исследования было выяснить насколько защищена карта от подделки баланса электронного кошелька, изучить принцип работы карты. Проверить защищенность инфраструктуры работающей с картой Тройка.

Карта Тройка введена в эксплуатацию в 2013 году. Представляет из себя универсальный пополняемый электронный кошелек. Согласно сайту troika.mos.ru, продано более 7 миллионов карт.

Поставщиком чипов для карты Тройка является (являлась?) компания NXP. Согласно пресс-релизу компании NXP, чипы выполнены по технологии MIFARE Plus. На данный момент сайт компании NXP более не доступен на русском языке и оригинал пресс-релиза удален.

• Чип Mifare Plus в режиме совместимости с Mifare Classic (SL1)
  
  
• Залоговая стоимость карты 50 рублей (может быть возвращена при возврате карты)
  
  
• Срок действия карты вместе с записанными средствами — 5 лет
  
  
• Максимальная сумма пополнения — 2500 рублей
  
  
• Помимо электронного кошелька может хранить билеты и абонементы
  
  

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

Система	Описание
Московское метро	Стоимость проезда 32 рубля, можно записать билеты
Наземный транспорт	Троллейбус, Автобус, Трамвай. Стоимость проезда 31 рубль.
Пригородные поезда	Стоимость зависит от дальности поездки. Можно записать абонементы.
Аэроэкспресс	450 рублей
Прокат велосипедов	Стоимость не уточнялась
Московский зоопарк	500 рублей
Планетарий	450 рублей
Каток в парке горького	Стоимость не уточнялась

Возможные цели атаки

Был проведен обзор инфраструктуры, работающей с картой Тройка, для установления наиболее привлекательных целей для атаки. Рассмотрены системы, позволяющие производить запись и считывание баланса электронного кошелька. Из основных критериев оценки была доступность для изучения без риска быть задержанным, простота и низкая стоимость.
Требовалось найти наиболее простую цель для проведения атаки, не требующую использования специальных технических средств и дорогостоящего оборудования.

Турникеты в метро

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

Потенциальный вектор атаки: проникновение в сеть, MitM.
_
_
_
_
_
_

Валидаторы в наземном транспорте

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

Потенциальный вектор атаки: физическое извлечение прошивки и данных из памяти устройства.
_
_
_
_
_
_

Валидаторы в метро

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

Потенциальный вектор атаки: проникновение во внутреннюю сеть, эксплуатация уязвимостей операционной системы.
_
_
_
_
_

Автоматы продажи билетов метро

Служат для продажи проездных билетов и пополнения электронного кошелька карты Тройка. Возможна оплата наличными и кредитными картами с помощью систем PayPass/PayWave.
Работают на базе x86 компьютера под управлением операционной системы Windows. В момент сбоя управляющей программы можно видеть интерфейс операционной системы и служебные программы.
Подключены к сети по технологии Ethernet, замечен UTP кабель, идущий к автомату.

Потенциальный вектор атаки: проникновение во внутреннюю сеть, эксплуатация уязвимостей операционной системы.
_

Приложения для смартфонов

В Google Play Market было найдено несколько приложений, позволяющих работать с электронным кошельком карты Тройка. Наиболее популярным по числу установок является приложение «Мой проездной», позволяющее напрямую пополнять карту с помощью смартфона с функцией NFC. Это означает, что приложение содержит данные, позволяющие производить запись в память карты.

Потенциальный вектор атаки: реверс-инжиниринг приложения.
_
_
_
_

Приложение «Мой проездной»

Из всех рассмотренных целей было решено остановиться на реверс-инжиниринге приложения «Мой проездной», как на более простом и безопасном варианте. Для этого достаточно было приобрести смартфон на платформе Android с поддержкой функции NFC. Выбор данной цели обусловлен еще и тем, что для исследования не требовалось иметь доступ к объектам общественного транспорта, и все операции по поиску уязвимостей можно было произвести не выходя из дома.

Приложение «Мой проездной» предназначено для самостоятельного пополнения карты Тройка. Работает на смартфонах с операционной системой Android и функцией NFC. Приложение бесплатное и доступно для загрузки через Google Play Market (каталог приложений Android). Так как приложение позволяет производить непосредственную запись баланса на карту, очевидно, что оно содержит ключи для чтения и записи. Далее будут описаны шаги реверс-инжиниринга приложения для получения требуемых данных.

Загрузка APK-архива

Для изучения кода необходимо получить приложение в виде установочного архива APK (Android application package). Проще всего это сделать, используя один из многочисленных онлайн-сервисов для загрузки APK, например apkpure.com. С помощью данного сервиса можно загрузить любые приложения из Google Play Market на компьютер.

Декомпиляция приложения

APK-файл приложения Android является архивом, внутри которого находятся файлы ресурсов, конфигурации, графика и другие мультимедиа данные, а также файл classes.dex, который является скомпилированным кодом приложения.
С помощью утилиты ibotpeaches.github.io/Apktool/ APK-файл может быть распакован. Вместе с этим файл classes.dex будет разложен на множество файлов формата *.smali.

Smali — это формат исходных текстов для Dalvik, виртуальной машины Android. Это низкоуровневый язык, язык ассемблера Dalvik. Файлы будут иметь порядковые имена вроде a.smali, b.smali, и т.д., внутри них объявления классов, методов, и инструкции виртуальной машины. Структура папок будет развернута в соответствии с названием пакетов классов.



Таким образом было получено развернутое по составляющим и готовое для анализа и модификации приложение. Однако анализировать smali-код довольно сложно. Во-первых, код содержит большое количество вспомогательных инструкций и не удобен для чтения человеком. Во-вторых, не существует доступных инструментов для работы с кодом (подсветка синтаксиса, рефакторинг, навигация по классам и методам).

Намного удобнее было бы использовать для анализа высокоуровневый исходный код на языке Java, далее будет рассмотрен процесс его получения из того же APK-файла.

Конвертация Dalvik Executable (dex) в Java Archive (jar)

Для анализа кода приложения необходимо сконвертировать .dex файлы, полученные из APK архива, в .jar файлы, которые далее могут быть декомпилированы в исходные тексты на языке Java. Это можно сделать с помощью программы dex2jar github.com/pxb1988/dex2jar. Как очевидно из названия, она конвертирует .dex файлы в формат .jar. Поскольку конвертируется только код, без ресурсов, конфигурационных и медиафайлов, .jar-файл на выходе обычно будет меньше по размеру, чем исходный APK.

Декомпиляция jar в исходные тексты Java

Полученные jar файлы теперь можно декомпилировать в исходные тексты языка Java.
Для этого можно использовать любой из доступных Java декомпиляторов, например JD-GUI

Анализ исходного кода

Полученные с помощью Java Decompiler исходные тексты могут быть загружены в любую IDE (Integrated Development Environment) для более удобного изучения. Например, Android Studio.

Декомпилятор не всегда идеально обрабатывает проект — иногда он не справляется и оставляет части smali-кода. Но это не критично, так как главной задачей на данном этапе является анализ кода. Основной целью поиска в исходных текстах программы были ключи для доступа к секторам карты Тройка, описание формата хранения данных в областях памяти карты, содержащих баланс электронного кошелька и механизм пополнения баланса карты.



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

классы в коде приложения «Мой проездной»

Отключение проверки TLS-сертификата

Во время работы приложение «Мой проездной» устанавливает соединение с сервером bmmobile.bm.ru. Для защиты от прослушивания и модификации данных все передаваемые данные между приложением и сервером зашифрованы с помощью протокола TLS. Для проверки подлинности ключа сервера используются TLS сертификаты.

В приложение «Мой проездной» встроена проверка отпечатка сертификата для предотвращения подмены сертификата и прослушивания передаваемых данных на сетевом уровне. Так называемый Certificate Pinning.

функция проверки отпечатка TLS сертификата


В данной проверке явно задан SHA1 отпечаток сертификата, поэтому в случае подмены сертификата проверка не будет пройдена и соединение с сервером установлено не будет. Даже в случае выпуска сертификата от другого сертификационного центра.

цепочка сертификатов и отпечаток сертификата bmmobile.bm.ru


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

цикл проверки отпечатка TLS сертификатов


Для обхода данной проверки достаточно модифицировать условный оператор сравнения отпечатка в smali-файле, заменив if-eqz на if-neq, что означает обратное условие «не равно».
В результате проверка проходит успешно для любого сертификата, как поддельного, так и оригинального, достаточно чтобы в цепочке сертификатов присутствовал хотя бы один сертификат с отличным от заданного отпечатком.
Примечательно, что это единственная модификация кода, которая потребовалась для отключения защиты от подделки сертификата.

изменение условного оператора в цикле проверки отпечатка сертификата

Сборка модифицированного приложения

Чтобы применить внесенные в исходный код изменения, необходимо скомпилировать APK.
С помощью утилиты apktool можно собрать распакованный APK архив обратно.

сборка APK из исходных текстов

Подписание APK

APK-файлы имеют подпись, которая позволяет убедиться, что файл был корректно загружен и выпущен конкретным разработчиком. Без подписи APK-файл установить не получится, но можно использовать самоподписанный сертификат (в этом случае нужно включить опцию “установка из недоверенных источников” в настройках телефона). В результате подписи будет получен APK-файл, готовый для установки на смартфон.

создание сертификата для подписи


подписание APK-файла

Перехват трафика приложения

Перехват защищенного трафика выполняется методом проксирования SSL-подключений с подменой сертификата сервера. Для этого существуют инструменты, вроде Mitmproxy или Fiddler, позволяющие выполнять подмену сертификата и запись расшифрованных данных автоматически. В данном случае, mitmproxy запущен на сервере, к которому по WiFi подключен смартфон с установленным приложением «Мой проездной». В приложении выполнена аутентификация по PIN-коду и произведена проверка баланса на карте Тройка. Все передаваемые в этот момент данные между сервером и приложением были записаны и проанализированы.

Аутентификация

В теле запроса передается номер телефона, PIN-код и информация об устройстве.

▼ Request Headers
	Request URL:	https://bmmobile.bm.ru/bm/3.3/troyka/authenticate.do
	Method:	POST
	Accept-Encoding:  gzip, deflate
	Content-Type:     application/x-www-form-urlencoded
	Content-Length:   192
	Host:		bmmobile.bm.ru
	Connection:	Keep-Alive
	User-Agent:	Apache-HttpClient/UNAVAILABLE (java 1.4)

▼ Request Body
	username=9853828069
	password=12345
	imei=null
	uniqueDeviceId=81f4d23b3a1973da
	deviceModel=samsung+SM-G900
	timeZone=%2B3
	osType=Android
	osVersion=20
	appVersion=2.0.4
	isMobile=true
	passwordType=PIN

В ответе сервера содержится ID пользователя и сессионный ключ.

{
   "userId":"F52D771F3048AFA411AF2A42198D43C2",
   "sessionId":"3A2F134FA60F26180AF6A7ABD35A20F4",
   "errorCode":0
}

Получение ключей от карты Тройка

В запросе на чтение карты Тройка передается сессионный ключ, полученный в момент аутентификации, и серийный номер карты в формате base64.

▼ Request Headers
	Request URL:	https://bmmobile.bm.ru/bm/3.3/troyka/providers.do
	Method:	POST
	Accept-Encoding: gzip, deflate
	Content-Type:	  Content-Type: application/x-www-form-urlencoded
	Host:		bmmobile.bm.ru
	User-Agent:	Apache-HttpClient/UNAVAILABLE (java 1.4)

▼ Request Body
	sessionId=3A2F134FA60F26180AF6A7ABD35A20F4
	serial=MTIzNA==
	isMobile=true

В ответе содержатся ключи A и B от секторов 2,4,7,8 в формате base64.
Примечательно, что здесь так же присутствуют ключи B, которые используются для записи данных на карту, хотя для запроса баланса достаточно было бы ключей А, разрешающих только чтение секторов памяти.

{ "linkId":"F52D771F3048AFA411AF2A42198D43C2",
   "rpcSectors":[  
      { "number":4,
         "keys":[  
            {  "keyId":1,
               "type":"B",
               "value":"K38yU/rF"},
            {  "keyId":2,
               "type":"A",
               "value":"cwaPEYwT"}]},
      {  "number":7,
         "keys":[  
            {  "keyId":1,
               "type":"B",
               "value":"DxxjAT26"}]},
      {  "number":8,
         "keys":[  
            {  
               "keyId":1,
               "type":"B",
               "value":"41FzSUqB"}]}],
   "rpcIsDown":false,
   "cppkSectors":[  
      { "number":2,
         "keys":[  
            {  "type":"A",
               "value":"KqBe0YVv"},
            {  "type":"A",
               "value":"KrqVGfV0"}]}],
   "cppkIsDown":false,
   "errorCode":0}

Запрос баланса

После получения ключей с сервера, происходит считывание необходимых секторов памяти с карты и отправка содержимого памяти на сервер. В данном примере видны сектора 0,4,7,8.

{"sector":[  
    {"blocks":[  
        { "number":0,
          "data":"3q26usD/7hD6ytp6EEgJEQ==\n"},
        { "number":1,
          "data":"AAAAAAAAAAAAAAAAAAAAAA==\n"},
        { "number":2,
          "data":"AAAAAAAAAAAAAAAAAAAAAA==\n"}],
      "number":4,
      "keyId":1},
    { "blocks":[  
        { "number":0,
          "data":"wP7auspfgjOvA0QiPV0tzw==\n"},
        { "number":1,
          "data":"AAAAAAAAAAAAAAAAAAAAAA==\n"},
        { "number":2,
          "data":"AAAAAAAAAAAAAAAAAAAAAA==\n"}],
      "number":7,
      "keyId":1},
    { "blocks":[  
        { "number":0,
          "data":"3q26usD/7hD6ytp6EEgJEQ==\n"},
        { "number":1,
          "data":"wP7auspfgjOvA0QiPV0tzw==\n"},
        { "number":2,
          "data":"wP7auspfgjOvA0QiPV0tzw==\n"}],
      "number":8,
      "keyId":1}]}

В ответе содержится информация о билетах, записанных на карте и баланс электронного кошелька.

 { "providerCode":"1",
        "ticketCode":"3",
        "ticketName":"Электронный кошелек",
        "ticketNo":"8553535",
        "statusCode":"0",
        "currentServices":[  
          {"name":"КОШЕЛЕК",
            "param":[  
              {"name":"Остаток",
                "value":"150.00"}],
            "type":"TRK_EK",
            "topUpType":"CASH"}],
        "availableServices":[  
          { "rpcServiceId":"2231",
            "name":"КОШЕЛЕК",
            "priceMin":"1.00",
            "priceMax":"2854.00",
            "type":"TRK_EK",
            "topUpType":"CASH"}

Итог анализа API

Из перехваченных сообщений видно, что ключи для чтения карты Тройка загружаются с сервера каждый раз во время чтения карты. Были получены ключи от секторов 2,3,4,6,7,8,15. Найдены сектора памяти, содержащие данные электронного кошелька и информацию о билетах, записанных на карте. Все эти данные получены за одну операцию считывания баланса. Платежные реквизиты в приложение добавлены не были, никаких платежных операций не производилось. Примечательно, что для операции чтения баланса с сервера загружаются одновременно A и B ключи, хотя ключи B используются для записи данных в память карты. В результате, атакующий может получить возможность записи данных на карту, выполняя только операции чтения.

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

Анализ памяти карты Тройка

Перехваченные из приложения «Мой проездной» ключи доступа к секторам карты Тройка используем для локального чтения памяти карты с помощью Android приложения MCT — Mifare Classic Tool. Приложение позволяет найти все сектора, к которым подходят перехваченные ключи, так называемый перебор по словарю.

данные в памяти карты в шестнадцатеричном формате

Формат данных в секторе электронного кошелька

Чтобы понять структуру хранения данных в памяти карты, была использована чистая карта, купленная в кассе, по которой не было выполнено ни одной поездки. Далее карта была пополнена 10 раз на 1 рубль через автомат. После каждого пополнения состояние памяти сохранялось. В конце все сохраненные данные были сравнены и установлено, что изменения происходят только в двух блоках 8 сектора.

дампы памяти восьмого сектора после пополнений на 1 рубль


Видно, что данные изменяются в первом блоке (нумерация от нуля) с 9 по 15 байт. Очевидно, что в данном месте содержится баланс электронного кошелька. Путем подбора возможных форматов хранения данных было выяснено, что значение баланса электронного кошелька хранится в области памяти от младших 4 бит 8 байта до старших 3 бит 10 байта и рассчитывается по формуле



Где 137B8 значение в памяти карты в шестнадцатеричном формате, а 399 сумма в рублях.
Таким образом можно рассчитать значения из предыдущей таблицы.

расчет баланса в секторе электронного кошелька

Номер турникета, дата и время прохода

Аналогичная методика была применена для изучения формата остальных данных в секторе. Было выполнено несколько проходов через турникеты метро и сохранено состояние памяти после каждого прохода. Проходы были выполнены с интервалом времени в 1 минуту попеременно на двух различных турникетах.



Путем подбора значений было установлено, что нулевой и первый байт в первом секторе хранит идентификатор последнего турникета, через который осуществлялся проход. Далее второй и третий байты содержат дату последнего прохода в виде количества дней от 1.1.1992.
Соответственно, 0x2260 = 8800, где 8800 число дней от 1.1.1992, что с учетом високосных лет приходится на дату 5 февраля 2016 и соответствует действительной дате прохода.

Время прохода записано в четвертом байте и старших четырех битах пятого байта, и кратно 30 секундам, начиная с 00:00 часов. Следовательно, расчет времени можно выполнить в два действия:

для расчета часов

и для расчета минут

Таким образом получим время 15:30, что соответствует действительному времени прохода.

На основе полученных сведений можно расшифровать данные представленные в предыдущей таблице



Каждая карта Тройка имеет уникальный серийный номер, отличный от UID. Этот номер нанесен на самой карте и используется для удаленного пополнения карты. Он хранится в нулевом блоке восьмого сектора с третьего байта по младшие четыре бита седьмого байта.

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

Запись данных на карту Тройка

Права доступа к секторам карт типа Mifare определяются битами доступа в третьем блоке каждого сектора. Биты доступа, установленные в восьмом секторе, разрешают чтение сектора ключом А и запись ключом B. Полученные из приложения «Мой проездной» ключи, позволяют выполнить запись любых данные в сектор электронного кошелька.

Атака повторного воспроизведения

В результате экспериментов было установлено, что сектор памяти, хранящий информацию о балансе электронного кошелька, содержит криптографическую подпись для подтверждения подлинности данных, так называемую имитовставку. Данный механизм служит для защиты данных от подделки. Подпись обновляется каждый раз в момент изменения баланса электронного кошелька. Это может быть операция списания при проходе через турникет, либо операция пополнения кошелька через терминал или приложение «Мой проездной».
Все устройства, работающие с балансом электронного кошелька (турникеты, терминал), проверяют достоверность подписи, и, в случае несоответствия подписи, возвращают ошибку “карта неисправна”.
Установлено, что подпись формируется на основе уникального идентификационного номера карты (UID), поэтому клонирование сектора памяти электронного кошелька из одной карты на другую с отличным UID, всегда дает недействительную подпись.

Несмотря на то, что области памяти электронного кошелька защищены с помощью имитовставки, система оказалась уязвима для атаки повторного воспроизведения.
Было сохранено состояние памяти сектора электронного кошелька до прохода через турникет, после чего выполнен проход и операция списания 31 рубля с баланса карты. После чего состояние памяти карты было возвращено к исходному состоянию. В результате, на карте была восстановлена сумма баланса до прохода через турникет. Данную операцию удалось повторить несколько раз. Из этого следует вывод, что система не защищена от подобного вида атак.

шаги атаки повторного воспроизведения


Для установления возможности реальной эксплуатации уязвимости было выполнено продолжительное тестирование атаки повторного воспроизведения на инфраструктуре общественного транспорта Москвы.
Первым был протестирован наземный транспорт: троллейбусы, автобусы, трамваи. Электронный кошелек был пополнен единожды на сумму 50 рублей и все проходы через турникеты были выполнены с помощью атаки повторного воспроизведения.
В течение пяти дней было совершено 57 поездок в наземном транспорте на общую сумму 1767 рублей. После чего карта была возвращена в кассу метрополитена и был получен возврат залоговой суммы в 50 рублей.

Для тестирования систем метрополитена была куплена новая карта и пополнена на 50 рублей. Все проходы через турникеты были выполнены с помощью атаки повторного воспроизведения. Было выполнено 12 поездок в течение 2 дней на общую сумму 384 рубля. На третий день карта была заблокирована на всех турникетах метро и наземного транспорта. После полного восстановления состояния памяти карты до состояния на момент приобретения, карта продолжила работать в наземном транспорте, но блокировалась при проходе в метро.
Из этого следует, что турникеты в метро имеют защиту от данного вида атак, однако срабатывает она с задержкой в несколько дней.

Обход блокировки карты

Экспериментально были найдены способы избегать блокировки карты при использовании атаки повторного воспроизведения. Основные факторы срабатывания блокировки:

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

В результате удалось обойти механизм обнаружения мошеннических операций и выполнить более десяти поездок в метро в течение недели.

Приложение TroikaDumper

В рамках данного исследования, для удобства эксплуатации атаки повторного воспроизведения было создано приложение TroikaDumper. Оно позволяет локально (без подключения к интернету) просматривать записанные в памяти карты данные, такие как: баланс электронного кошелька, время последнего прохода через турникет, идентификатор последнего турникета, имитовставку, серийный номер карты Тройка, идентификационный номер карты (UID).
Приложение позволяет сохранять состояние памяти и записывать его на карту.
Приложение доступно в исходных текстах github.com/gshevtsov/TroikaDumper и в скомпилированном виде TroikaDumper.apk. Для работы нужен смартфон на платформе Android с NFC модулем производства NXP.
_
_

интерфейс приложения TroikaDumper

Заключение

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

Относительно легко был осуществлен реверс-инжиниринг приложения «Мой проездной», что позволило обойтись без взлома физических систем транспортной инфраструктуры.

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

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

Для исправления найденных уязвимостей необходимо усовершенствование формата хранения данных в памяти карты и обновление программного обеспечения всех систем, работающих с картой.

// Read Sector 8 data blocks (0 to 2)
for (int i = 0; i < 3; i++)
  System.arraycopy(mfc.readDataBlock(sect8StartBlock + i), 0, mfsect, i * 16, 16);

// Read and show money value from ticket
int money = BitOps.copyBitsToInt(mfsect, 196, 19, false, false) / 100;

public static int copyBitsToInt(byte[] from, int fromStart, int length, boolean revBits, boolean revBytes) {
  byte[] intBytes = new byte[]{0, 0, 0, 0};
  copyBits(from, intBytes, fromStart, 32 - length, length, revBits, revBytes);
  return (intBytes[3] & 0xFF) | ((intBytes[2] & 0xFF) << 8) | ((intBytes[1] & 0xFF) << 16) | ((intBytes[0] & 0xFF) << 24);
}

public static void copyBits(byte[] from, byte[] to, int fromStart, int toStart, int length, boolean revBits, boolean revBytes) {
    int j = 0;
    int y = 0;
    for (int i = 0; i < length; i++) {
      j = (revBits) ? length - 1 - i : i; // Reverse bits counter ("from" side)
      y = (revBytes) ? ((((length - 1) / 8) - (i / 8)) * 8) + (i % 8) : i; // Reverse bytes counter ("to" side)
      if (((from[(fromStart + j) / 8]) & (1 << (7 - ((fromStart + j) % 8)))) > 0) // If bit is set, then
        to[(toStart + y) / 8] |= 1 << (7 - ((toStart + y) % 8)); // Set bit
      else
        to[(toStart + y) / 8] &= ~(1 << (7 - ((toStart + y) % 8))); // Unset bit
    }
  }