Автор: Артем Захаров

Наверняка многие из тех, кто наслышан об уязвимостях карт с RFID-чипами, держа в руках билеты московского метрополитена, задумывались, а нельзя ли провернуть с ними что-нибудь эдакое. ЖЖ-юзер Александр (dark-simpson), который дал нам интервью, не ограничился только мыслями - венцом его работы стали самостоятельно сгенерированные билеты.

Что подтолкнуло к этим исследованиям?

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

Потом увидел людей, которые продают билеты нового образца (то есть основанные на Mifare Ultralight) на одну-две поездки. Они обычно держатся в тени: стоят где-нибудь в вестибюле метро и скромно предлагают свои услуги. Да что рассказывать, каждый, кто спускается в подземку в час-пик, наверняка замечал этих "благодетелей".

Год назад я купил на Павелецком вокзале такой билет: это просто старый Mifare Ultralight, у которого перерезана антенна, а сзади налеплена наклейка с чипом (вроде тех, что используются для маркировки грузов), которая собственно и программируется. Мне стало интересно. Когда появился ридер, решил сам попробовать: сперва изучал формат, разбирался, где какая информация записана (номер по внутренней базе метро, тип билета, количество поездок и т. д.). Застопорился на "хэше" - данных, генерируемых для защиты от подделки, - до того момента, пока мне в руки не попали программы "Смартека", подрядчика, создававшего систему для московского метрополитена. Случилось это довольно странным образом: грубо говоря, человек написал в аську и предложил, мол, "ты этой темой вроде бы интересуешься; я поковырялся, ничего не получилось - может, ты окажешься удачливее". Своих источников он раскрывать не стал, просто передал мне архив. Как выяснилось позже, это ПО - одно из самых уязвимых мест системы.

До сих пор клонирование Mifare Ultralight сводилось к созданию устройств, эмулирующих билет, вы пошли по этому же пути?

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

Взломать Ultralight с помощью информации, полученной из билетов, невозможно - защита на очень приличном уровне. Как выяснилось из моих исследований, "хэш" - это не что иное, как имитовставка, вырабатывающаяся по алгоритму ГОСТ, метод 16-3. Ключи, необходимые для генерации "хэша", без которого не удастся сделать работающий билет, распространяются в специальном файле-хранилище зашифрованными. Причем, судя по формату файла, он един для компьютеров обслуживающего персонала, турникетов и терминалов проверки. Ключи, а также новые версии программы распространяются по внутренней сети подземки.

Расскажите, как устроена инфраструктура метрополитена?

- На станциях сеть построена примерно следующим образом: есть несколько компьютеров у кассиров, у старшего кассира и компьютер ревизора. Предположительно, где-то находится и аппаратный пункт, "приземляющий" локалку на сеть RS-485, которой объединены турникеты и терминалы проверки билетов. Хотя есть также информация, что локальная сеть Ethernet и сеть устройств RS-485 не объединены (или же объединены, но не на всех станциях), а обновлением ПО и ключевой информации в турникетах и терминалах проверки занимается специальный обслуживающий персонал.

По сути, билет - это самодостаточный организм: в нем записана вся информация, необходимая для прохода, включая унифицированный идентификатор, определяющий географическую зону или предприятие; тип билета (например, на одну поездку, социальный и т. д.); количество оставшихся/совершенных поездок и все даты (дату выдачи, сроки действия), поэтому турникету дополнительно никуда обращаться не надо (за исключением случаев предотвращения повторного прохода по социальному билету "ультралайт" - так как время прохода в билете не указано, турникет обращается за этой информацией к своим "соседям", и, если этот билет уже был недавно использован, отказывает в повторном проходе до истечения определенного времени).

Однако при использовании билетов информация о них заносится в память турникетов (это нужно хотя бы для того, чтобы вести статистику) и в определенное время (возможно, по расписанию) сливается в центральную базу данных и уже там обрабатывается. Каждый раз при покупке билета его данные заносятся в локальную БД, а оттуда отправляются в ЦОД. Это подтверждают метрополитеновские программы: они могут функционировать как в режиме накопления данных, так и в онлайн-режиме, сразу отправляя информацию в центральную базу. Если несколько раз засвечивается номер, который не зафиксирован в БД, это быстро выявляется и билет попадает в стоп-лист, который закачивается в турникеты при следующем обновлении (их память, конечно, не резиновая, но даже за вычетом объема памяти, используемой микропрограммой турникета в служебных целях, ее должно хватить, чтобы занести достаточное количество записей). Так что все сгенерированные мною Mifare Ultralight в течение нескольких дней попадали в стоп-лист.

А можно ли многократно перезаписывать карточку?

- В билете есть перезаписываемая область данных (48 байт), зона однократной записи (4 байта) и зона записи блокировок. С помощью установки управляющих битов можно заблокировать запись в определенные страницы или даже запретить блокирование записи. Смысл в том, что перезаписать можно все данные, кроме зоны однократной записи (one-time programmable, OTP) и битов блокировок: в подземке зона OTP используется для постепенного "выжигания" битов в зависимости от количества использованных поездок (в процентном соотношении). И эта зона, естественно, проверяется при валидации билета турникетом. Когда количество поездок полностью исчерпано, на запись блокируются все страницы памяти и билет остается только выкинуть. Так что "вечный" Ultralight сделать не получится. С клонированным Mifare Classic (отсутствие их жесткой привязки к аппаратному серийному номеру позволяет изготовить "клон") в этом смысле проще: теоретически им можно пользоваться, пока не истечет срок действия карточки, которая была взята в качестве "донора", а потом можно просто пойти и выудить свежий дамп. На практике, правда, многие клонированные "классики" тоже попадают в стоп-лист. На данный момент я как раз пытаюсь понять, по какому принципу идет отсев "левых" карт и какую роль в этом играет аппаратный серийный номер, который собственно для защиты данных не используется.

То есть, выходит, "классики" более уязвимы, чем простые билеты?

- Да, как ни странно, вся защита карт на основе Mifare Classic (а это проездные, студенческие и пенсионные карты и т. д.) основывается на использовании двух ключей: A и B. Причем они лежали в той же метрополитеновской программе, о которой речь шла в начале, в виде констант, и их без труда удалось посмотреть с помощью дизассемблера. Забавно, что там же были ключи не только для секторов, используемых турникетами метро, но и для зон, проверяемых валидаторами наземного транспорта. Применив найденные ключи, я легко сделал копию собственного студенческого проездного на один из старых просроченных, который мне в свое время подарили для экспериментов (чистых карточек Mifare 1К у меня на тот момент не было).