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

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

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

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

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

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

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

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

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

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

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

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

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