[Из песочницы] Проблемы автономных СКУД — Там, откуда не ждали
Всем доброго времени суток. Начну с предыстории, о том, что меня побудило провести данное исследование, но прежде предупрежу: все практические действия были выполнены с согласия управляющих структур. Любая попытка использовать данный материал в целях проникновения на закрытую территорию без права там находиться — является уголовным правонарушением.
Началось все с того что убираясь на столе, я случайно поместил RFID ключ от подъезда на NFC-считыватель ACR122 — каково же было мое удивление, когда Windows воспроизвела звук обнаружения нового устройства, а светодиод загорелся зеленым. Я до этого момента полагал что эти ключи работают исключительно в стандарте Proximity.
Но раз считыватель его увидел — значит ключ отвечает одному из протоколов поверх стандарта ISO 14443 (Он же Near Field Communication, 13,56 МГц). Про уборку было тут же забыто, так как я увидел возможность совсем избавиться от связки ключей, и сохранить ключ от подъезда в телефоне (квартира давно оборудована электронным замком). Засев за изучение, выяснил, что под пластиком скрывается NFC-метка Mifare 1k — та же модель что в пропусках-бейджах предприятий, транспортных картах и т.д. Попытки влезть в содержимое секторов поначалу успеха не приносили, а когда ключ таки удалось взломать — выяснилось, что используется лишь 3-й сектор, и в нем продублирован UID самого чипа. Выглядело слишком просто, так и оказалось и не было бы статьи, если бы все прошло совсем так как задумано. Вот я получил потроха ключа, и никаких проблем нет, если нужно скопировать ключ на другой такой же. Но задача была — перенести ключ на мобильное устройство, чем я и занялся. Вот тут то и началось веселье — имеем телефон — iPhone SE с установленной iOS 13.4.5 Beta build 17F5044d и некоторыми кастомными компонентами для свободной работы NFC — на этом подробно останавливаться не буду в силу некоторых объективных причин. При желании все сказанное далее применимо и для системы Android, но с некоторыми упрощениями.
Список задач для решения:
- Получить доступ к содержимому ключа.
- Реализовать возможность эмуляции ключа устройством.
Если с первым все было относительно просто, то со вторым возникли проблемы. Первая версия эмулятора не сработала. Проблема была довольно быстро обнаружена — у мобильных устройств (что iOS, что Android) в режиме эмуляции — UID динамический и независимо от того что, зашито в образе — плавает. Вторая версия (запускаемая с правами суперпользователя) жестко фиксировала серийный номер на выбранном — дверь открывалась. Однако я хотел сделать все идеально, и в итоге собрал законченную версию эмулятора которая могла открывать дампы Mifare и эмулировать их. Поддавшись внезапному порыву, я изменил ключи секторов на произвольные, и попытался открыть дверь. И она… ОТКРЫЛАСЬ! Через некоторое время я понял что открываются любые двери с этим замком, даже те, к которым исходный ключ не подходил. В связи с этим я сформировал новый список задач для выполнения:
- Выяснить что за контроллер отвечает за работу с ключами
- Понять есть ли подключение к сети и общая база
- Выяснить почему фактически нечитаемый ключ становится универсальным
Пообщавшись с инженером управляющей компании я узнал что используются простые контроллеры Iron Logic z5r без подключения к внешней сети.
Как отсюда понятно — система полностью автономна и крайне примитивна. Сначала я подумал что контроллер находится в режиме обучения — смысл такой, что он считывает ключ, заносит его в память и открывает дверь — этот режим используют когда надо записать все ключи, например при замене замка в многоквартирном доме. Но эта теория не подтвердилась — программно этот режим выключен, перемычка стоит в рабочем положении — и тем не менее при поднесении устройства мы видим следующее:
… и контроллер сигнализирует о том что доступ предоставлен.
Значит проблема кроется в ПО либо контроллера, либо считывателя. Давайте проверим считыватель — он работает в режиме iButton, значит подключим плату безопасности Bolid — у нас будет возможность посмотреть выходные данные со считывателя.
Методом множественных проб выясняем, что считыватель транслирует один и тот же код с в случае неудачи авторизации: 1219191919
Ситуация начинает проясняться, однако на текущий момент мне непонятно почему на этот код положительно откликается контроллер. Есть предположение — что когда наполняли базу — случайно или специально поднесли карту с другими ключами сектора — считыватель отправил этот код и контроллер его сохранил. К сожалению я не располагаю фирменным программатором от IronLogic чтобы заглянуть в базу ключей контроллера, но надеюсь мне удалось обратить внимание на то что проблема существует. Видеодемонстрация работы с данной уязвимостью доступна по ссылке: vk.com/video104139075_456239166
P.S. Против теории со случайным добавлением выступает тот факт, что в одном бизнес-центре Красноярска мне так же удалось открыть дверь этим же методом.
