На всички желая добър ден. Ще започна с предистория, какво ме накара да проведа това изследване, но преди всичко предупреждавам: всички практически действия бяха извършени със съгласието на управляващите структури. Всяка опит за използване на този материал с цел проникване в затворена територия без право да се намирате там — е криминално нарушение.
Всичко започна с това, че докато чистех на масата, случайно поставих RFID ключа от входа на NFC четец ACR122 — какво беше удивлението ми, когато Windows издаде звук за откриване на ново устройство, а светодиодът светна в зелено. Дотогава бях убеден, че тези ключове работят единствено по стандарта Proximity.
Но след като четецът го видя — значи ключът отговаря на един от протоколите над стандарта ISO 14443 (т.е. Near Field Communication, 13.56 MHz). Застанахме зад правенето на почистване, тъй като видях възможност напълно да се сбогувам с разликата от ключове и да запазя ключа от входа на телефона (апартаментът отдавна е оборудван с електронна брава). След като се задълбочих в изучаването, разбрах, че под пластмасата се крие NFC етикет Mifare 1k — същият модел, използван в пропуски, табелки на предприятия, транспортни карти и др. Опитите ми да получа достъп до съдържанието на секторите в началото не успяваха, а когато все пак успях да хакна ключа — се оказа, че се използва само 3-ят сектор, в който е дублиран UID на самия чип. Изглеждаше много просто и така и беше, и нямаше да има статия, ако всичко беше преминало точно по план. Ето, получих вътрешността на ключа и няма проблеми, ако трябва да копирам ключ на друг идентичен. Но задачата беше — да пренеса ключа на мобилно устройство, с което започнах да се занимавам. Тук започна забавлението — имаме телефон — iPhone SE с инсталиран iOS 13.4.5 Beta build 17F5044d и някои персонализирани компоненти за свободна работа с NFC — няма да засягам това подробно поради някои обективни причини. Ако желаете, всичко, което ще бъде казано по-нататък, е приложимо и за системата Android, но с някои опростявания.
Списък с задачи за решаване:
- Да получим достъп до съдържанието на ключа.
- Да реализираме възможност за емирация на ключа с устройството.
Ако с първия всичко беше относително просто, то с втория възникнаха проблеми. Първата версия на емулатора не сработи. Проблемът беше открит доста бързо — на мобилните устройства (както iOS, така и Android) в режим на емулация — UID е динамичен и независимо от това какво е записано в образа — плава. Втората версия (стартирана с права на суперпотребител) фиксираше серийния номер на избрания — вратата се отваряше. Въпреки това исках да направя всичко перфектно и в крайна сметка събрах завършена версия на емулатора, която можеше да отваря дампи Mifare и да ги емулатира. Поддавайки се на внезапен порив, промених ключовете на секторите на произволни и опитах да отворя вратата. И тя… СЕ ОТВОРИ! След известно време разбрах, че се отварят всякакви врати с този заключващ механизъм, дори и тези, за които оригиналният ключ не подхождаше. В тази връзка съставих нов списък със задачи за изпълнение:
- Да разбера кой контролер отговаря за работата с ключовете
- Да проуча дали има свързаност с мрежата и обща база
- Да разбера защо фактически нечетимият ключ става универсален
Когато разговарях с инженера от управляващата компания, научих, че се използват прости контролери Iron Logic z5r без свързване към външна мрежа.
Четец CP-Z2 MF и контролер IronLogic z5r
Получих комплект оборудване за експерименти:
Както е видно — системата е напълно автономна и изключително примитивна. Първоначално помислих, че контролерът работи в режим на обучение — смисълът е, че той счете ключа, запомня го и отваря вратата — този режим се използва, когато е необходимо да се запишат всичките ключове, например при смяна на ключалка в многофамилна сграда. Но тази теория не се потвърди — програмно този режим е изключен, Jumper-ът е в работно положение — и все пак, когато приближим устройството, виждаме следното:
Скрийншот на процеса на емулация на устройството
… и контролерът сигнализира, че достъпът е предоставен.
Значи проблемът се крие в софтуера на или контролера, или четеца. Нека проверим четеца — той работи в режим iButton, значи ще свържем платка за сигурност Bolid — ще имаме възможност да видим изходните данни от четеца.
Платката по-късно ще бъде свързана през RS232
С метода на множество опити разбираме, че четецът предава един и същ код в случай на неуспешна автентикация: 1219191919
Ситуацията започва да се изяснява, но в момента не е ясно защо контролерът реагира положително на този код. Има предположение, че когато е попълвана базата, случайно или умишлено е била приближена карта с други ключове на сектора и четецът е изпратил този код, който контролерът е запазил. За съжаление, нямам фирмен програматор от IronLogic, за да погледна в базата с ключове на контролера, но се надявам да успях да обърна внимание на съществуването на проблема. Видеодемонстрация на работа с тази уязвимост е налична .
P.S. Против теоретичното случайно добавяне свидетелства фактът, че в един бизнес център в Красноярск също успях да отворя вратата с този метод.
Източник: habr.com
