Проблеми на автономните системи за контрол на достъп - Там, където не са били очаквани

Добър ден на всички. Ще започна с предисторията на това, което ме подтикна да проведа това изследване, но първо ще ви предупредя: всички практически действия бяха извършени със съгласието на управляващите структури. Всеки опит за използване на този материал за влизане в зона с ограничен достъп без право да бъде там е криминално престъпление.

Всичко започна, когато докато почиствах масата, случайно поставих RFID входния ключ върху NFC четеца ACR122 - представете си изненадата ми, когато Windows пусна звук за откриване на ново устройство и светодиодът светна зелено. До този момент вярвах, че тези ключове работят изключително в стандарта Proximity.
Проблеми на автономните системи за контрол на достъп - Там, където не са били очаквани
Но тъй като читателят го видя, това означава, че ключът отговаря на един от протоколите в допълнение към стандарта ISO 14443 (известен още като комуникация в близко поле, 13,56 MHz). Почистването веднага беше забравено, тъй като видях възможност напълно да се отърва от комплекта ключове и да запазя ключа от входа в телефона си (апартаментът отдавна е оборудван с електронна брава). След като започнах да изучавам, разбрах, че под пластмасата е скрит етикет Mifare 1k NFC - същият модел като в корпоративните значки, транспортни карти и т.н. Опитите за проникване в съдържанието на секторите първоначално не донесоха успех и когато ключът най-накрая беше кракнат, се оказа, че е използван само 3-ти сектор, а UID на самия чип е дублиран в него. Изглеждаше твърде просто и се оказа така и нямаше да има статия, ако всичко вървеше точно по план. Така че получих вътрешностите на ключа и няма проблеми, ако трябва да копирате ключа на друг от същия вид. Но задачата беше да прехвърля ключа на мобилно устройство, което направих. Тук започна забавлението - имаме телефон - iPhone SE с инсталиран iOS 13.4.5 бета компилация 17F5044d и някои персонализирани компоненти за безплатна работа на NFC - няма да се спирам подробно на това поради обективни причини. Ако желаете, всичко казано по-долу важи и за системата Android, но с някои опростения.

Списък със задачи за решаване:

  • Достъп до съдържанието на ключа.
  • Внедрете възможност за емулиране на ключ от устройството.

Ако с първото всичко беше сравнително просто, тогава с второто имаше проблеми. Първата версия на емулатора не работи. Проблемът беше открит доста бързо - на мобилни устройства (или iOS, или Android) в режим на емулация, UID е динамичен и независимо от това, което е свързано в изображението, той плава. Втората версия (изпълнена с права на суперпотребител) твърдо фиксира серийния номер на избрания - вратата се отвори. Исках обаче да направя всичко перфектно и в крайна сметка съставих пълна версия на емулатора, който можеше да отваря дъмпове на Mifare и да ги емулира. Поддавайки се на внезапен импулс, смених секторните ключове на произволни и се опитах да отворя вратата. И тя… ОТВОРЕНО! След малко разбрах, че се отварят който и да е врати с тази брава, дори и такива, на които оригиналният ключ не пасваше. В тази връзка създадох нов списък със задачи за изпълнение:

  • Разберете какъв контролер е отговорен за работата с ключове
  • Разберете дали има мрежова връзка и обща база
  • Разберете защо един практически нечетлив ключ става универсален

След като разговарях с инженер в управляващата компания, научих, че се използват прости контролери Iron Logic z5r без свързване към външна мрежа.

Четец CP-Z2 MF и контролер IronLogic z5r
Дадоха ми комплект оборудване за експериментите:

Проблеми на автономните системи за контрол на достъп - Там, където не са били очаквани

Както става ясно оттук, системата е напълно автономна и изключително примитивна. Първо си помислих, че контролера е в режим на обучение - смисъла е, че чете ключа, съхранява го в паметта и отваря вратата - този режим се използва, когато е необходимо да се запишат всички ключове, например при смяна на заключване в жилищен блок. Но тази теория не беше потвърдена - този режим е изключен софтуерно, джъмперът е в работно положение - и въпреки това, когато изведем устройството, виждаме следното:

Екранна снимка на процеса на емулация на устройството
Проблеми на автономните системи за контрол на достъп - Там, където не са били очаквани
... и контролерът сигнализира, че достъпът е разрешен.

Това означава, че проблемът е в софтуера или на контролера, или на четеца. Нека проверим четеца - работи в режим iButton, така че нека свържем защитната платка Bolid - ще можем да видим изходните данни от четеца.

По-късно платката ще бъде свързана чрез RS232
Проблеми на автономните системи за контрол на достъп - Там, където не са били очаквани

Използвайки метода на множество тестове, откриваме, че четецът излъчва един и същ код в случай на неуспешна авторизация: 1219191919

Ситуацията започва да се изяснява, но в момента не ми е ясно защо контролера реагира положително на този код. Има предположение, че когато базата данни е била попълнена - случайно или нарочно е била представена карта с други секторни ключове - четецът е изпратил този код и контролерът го е запазил. За съжаление нямам патентован програмист от IronLogic, за да разгледам базата данни с ключове на контролера, но се надявам, че успях да обърна внимание на факта, че проблемът съществува. Налична е видео демонстрация на работа с тази уязвимост по ссылке.

PS Теорията за случайното добавяне се противопоставя на факта, че в един бизнес център в Красноярск също успях да отворя вратата по същия метод.

Източник: www.habr.com

Добавяне на нов коментар