Усім добрага часу сутак. Пачну з перадгісторыі, аб тым, што мяне заахвоціла правесці дадзенае даследаванне, але перш за папярэджу: усе практычныя дзеянні былі выкананы са згоды кіраўнікоў структур. Любая спроба выкарыстоўваць дадзены матэрыял у мэтах пранікнення на закрытую тэрыторыю без права там знаходзіцца - з'яўляецца крымінальным правапарушэннем.
Пачалося ўсё з таго, што прыбіраючыся на стале, я выпадкова змясціў 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 без падлучэння да знешняй сеткі.
Счытвальнік СP-Z2 MF і кантролер IronLogic z5r
Мне выдалі камплект абсталявання для досведаў:
Як адгэтуль зразумела сістэма цалкам аўтаномная і вельмі прымітыўная. Спачатку я падумаў што кантролер знаходзіцца ў рэжыме навучання - сэнс такі, што ён счытвае ключ, заносіць яго ў памяць і адчыняе дзверы - гэты рэжым выкарыстоўваюць калі трэба запісаць усе ключы, напрыклад пры замене замка ў шматкватэрнай хаце. Але гэтая тэорыя не пацвердзілася - праграмна гэты рэжым выключаны, перамычка стаіць у працоўным становішчы - і тым не менш пры паднясенні прылады мы бачым наступнае:
Скрыншот працэсу эмуляцыі на прыладзе
… і кантролер сігналізуе аб тым што доступ прадстаўлены.
Значыць праблема крыецца ў ПЗ або кантролера, або счытвальніка. Давайце праверым счытвальнік - ён працуе ў рэжыме iButton, значыць падключым плату бяспекі Bolid - у нас будзе магчымасць паглядзець выходныя дадзеныя са счытвальніка.
Плата, пазней будзе падключана праз RS232
Метадам шматлікіх спроб высвятляем, што счытвальнік транслюе адзін і той жа код з у выпадку няўдачы аўтарызацыі: 1219191919
Сітуацыя пачынае праясняцца, аднак на дадзены момант мне незразумела чаму на гэты код станоўча адгукаецца кантролер. Ёсць здагадка - што калі напаўнялі базу - выпадкова ці спецыяльна паднеслі карту з іншымі ключамі сектара - счытвальнік адправіў гэты код і кантролер яго захаваў. Нажаль я не размяшчаю фірмовым праграматарам ад IronLogic каб зазірнуць у базу ключоў кантролера, але спадзяюся мне атрымалася звярнуць увагу на тое што праблема існуе. Відэадэманстрацыя працы з дадзенай уразлівасцю даступная .
PS Супраць тэорыі са выпадковым даданнем выступае той факт, што ў адным бізнэс-цэнтры Краснаярска мне гэтак жа атрымалася адчыніць дзверы гэтым жа метадам.
Крыніца: habr.com