На всички пожелавам добър ден. Ще започна с предистория, която ме подбуди да проведа това изследване, но преди това предупреждавам: всички практически действия бяха извършени със съгласието на управляващите органи. Всяка опит да се използва този материал с цел проникване на закрита територия без право да се намирате там - е криминално престъпление.
Всичко започна, когато по време на почистване на масата случайно поставих 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 без свързване към външна мрежа.
Четец CP-Z2 MF и контролер IronLogic z5r
Предоставиха ми комплект оборудване за експерименти:
Както става ясно оттук — системата е напълно автономна и изключително примитивна. Първоначално помислих, че контролерът е в режим на обучение — идеята е, че той прочита ключа, записва го в паметта и отваря вратата — този режим се използва, когато трябва да запиша всички ключове, например при смяна на ключалката в многоквартирна сграда. Но тази теория не се потвърди — програмно този режим е изключен, перемичката е в работно положение — и все пак при поднасяне на устройството виждаме следното:
Скриншот на процеса на емулация на устройството
… и контролерът сигнализира, че достъпът е предоставен.
Следователно проблемът е в софтуера на контролера или четеца. Нека проверим четеца — той работи в режим iButton, следователно ще свържем платка за сигурност Bolid — ще имаме възможност да видим изходните данни от четеца.
Платката по-късно ще бъде свързана чрез RS232
Чрез многократни опити установяваме, че четецът предава един и същ код при неуспех на авторизацията: 1219191919
Ситуацията започва да се прояснява, но в момента не разбирам защо контролерът реагира положително на този код. Имам предположение — че при попълване на базата — случайно или умишлено е била поднесена карта с други ключове на сектора — четецът е изпратил този код и контролерът го е запазил. За съжаление нямам фирмен програмист от IronLogic, за да погледна в базата с ключове на контролера, но се надявам, че успях да привлека вниманието към съществуването на проблема. Видеодемонстрация на работата с тази уязвимост е налична .
P.S. Срещу теорията за случайното добавяне говори и фактът, че в един бизнес център в Красноярск успях да отворя вратата по същия метод.
Източник: habr.com
