Goeie dag vir almal. Ek begin met die agtergrond oor wat my aangespoor het om hierdie navorsing te doen, maar ek sal jou eers waarsku: alle praktiese aksies is uitgevoer met die toestemming van die beheerstrukture. Enige poging om hierdie materiaal te gebruik om 'n beperkte gebied binne te gaan sonder die reg om daar te wees, is 'n kriminele oortreding.
Dit het alles begin toe ek, terwyl ek die tafel skoongemaak het, per ongeluk die RFID-ingangsleutel op die ACR122 NFC-leser geplaas het - stel my verbasing voor toe Windows die klank van die opsporing van 'n nuwe toestel gespeel het en die LED groen geword het. Tot op hierdie oomblik het ek geglo dat hierdie sleutels uitsluitlik in die Proximity-standaard werk.
Maar aangesien die leser dit gesien het, beteken dit dat die sleutel voldoen aan een van die protokolle bo en behalwe die ISO 14443-standaard (ook bekend as Near Field Communication, 13,56 MHz). Skoonmaak is dadelik vergeet, want ek het kans gesien om heeltemal van die stel sleutels ontslae te raak en die sleutel van die ingang in my foon te hou (die woonstel is lankal toegerus met 'n elektroniese slot). Nadat ek begin studeer het, het ek uitgevind dat 'n Mifare 1k NFC-etiket onder die plastiek weggesteek is - dieselfde model as in ondernemingskentekens, vervoerkaarte, ens. Pogings om by die inhoud van die sektore in te gaan, het aanvanklik nie sukses gebring nie, en toe die sleutel uiteindelik gekraak is, het dit geblyk dat slegs die 3de sektor gebruik is, en die UID van die chip self is daarin gedupliseer. Dit het te eenvoudig gelyk, en dit blyk so te wees, en daar sal geen artikel wees as alles presies verloop soos beplan nie. So ek het die ingewande van die sleutel ontvang, en daar is geen probleme as jy die sleutel na 'n ander een van dieselfde soort moet kopieer nie. Maar die taak was om die sleutel na 'n mobiele toestel oor te dra, wat ek gedoen het. Dit is waar die pret begin het - ons het 'n foon - iPhone SE met gevestigde iOS 13.4.5 Beta bou 17F5044d en 'n paar pasgemaakte komponente vir gratis werking van NFC - ek sal nie in detail hieroor stilstaan nie as gevolg van 'n paar objektiewe redes. As jy wil, is alles wat hieronder gesê word, ook van toepassing op die Android-stelsel, maar met 'n paar vereenvoudigings.
Lys van take om op te los:
- Toegang tot die inhoud van die sleutel.
- Implementeer die vermoë om 'n sleutel deur die toestel na te boots.
As met die eerste alles relatief eenvoudig was, dan was daar probleme met die tweede. Die eerste weergawe van die emulator het nie gewerk nie. Die probleem is redelik vinnig ontdek - op mobiele toestelle (óf iOS of Android) in emulasiemodus is die UID dinamies en, ongeag wat in die beeld vasgemaak is, dryf dit. Die tweede weergawe (loop met supergebruikersregte) het die reeksnommer op die geselekteerde een streng vasgemaak - die deur het oopgegaan. Ek wou egter alles perfek doen, en het uiteindelik 'n volledige weergawe van die emulator saamgestel wat Mifare-stortings kon oopmaak en dit naboots. Toegegee aan 'n skielike impuls, het ek die sektorsleutels na arbitrêre verander en probeer om die deur oop te maak. En sy… OOPgemaak! Na 'n rukkie het ek besef dat hulle oopmaak enige deure met hierdie slot, selfs dié waarop die oorspronklike sleutel nie gepas het nie. In hierdie verband het ek 'n nuwe lys take geskep om te voltooi:
- Vind uit watter soort beheerder verantwoordelik is om met sleutels te werk
- Verstaan of daar 'n netwerkverbinding en 'n gemeenskaplike basis is
- Vind uit hoekom 'n feitlik onleesbare sleutel universeel word
Nadat ek met 'n ingenieur by die bestuursmaatskappy gepraat het, het ek geleer dat eenvoudige Iron Logic z5r-beheerders gebruik word sonder om aan 'n eksterne netwerk te koppel.
CP-Z2 MF-leser en IronLogic z5r-beheerder
Ek het 'n stel toerusting vir die eksperimente gegee:
Soos hieruit duidelik blyk, is die stelsel heeltemal outonoom en uiters primitief. Ek het eers gedink dat die beheerder in leermodus is - die betekenis is dat dit die sleutel lees, dit in die geheue stoor en die deur oopmaak - hierdie modus word gebruik wanneer dit nodig is om al die sleutels op te neem, byvoorbeeld wanneer die toesluit in 'n woonstelgebou. Maar hierdie teorie is nie bevestig nie - hierdie modus is afgeskakel in sagteware, die springer is in die werkposisie - en tog, wanneer ons die toestel opbring, sien ons die volgende:
Skermskoot van die emulasieproses op die toestel
... en die beheerder beduie dat toegang verleen is.
Dit beteken die probleem lê in die sagteware van óf die beheerder óf die leser. Kom ons kyk na die leser - dit werk in iButton-modus, so kom ons koppel die Bolid-sekuriteitsbord - ons sal die uitvoerdata van die leser kan sien.
Die bord sal later via RS232 verbind word
Deur die metode van veelvuldige toetse te gebruik, vind ons uit dat die leser dieselfde kode uitsaai met in geval van magtigingsmislukking: 1219191919
Die situasie begin duideliker word, maar op die oomblik is dit nie vir my duidelik hoekom die kontroleerder positief op hierdie kode reageer nie. Daar is 'n aanname dat wanneer die databasis gevul is - per ongeluk of met opset 'n kaart met ander sektorsleutels aangebied is - die leser hierdie kode gestuur het en die kontroleerder het dit gestoor. Ongelukkig het ek nie 'n eie programmeerder van IronLogic om na die kontroleerdersleuteldatabasis te kyk nie, maar ek hoop ek kon die aandag vestig op die feit dat die probleem bestaan. 'n Videodemonstrasie van die werk met hierdie kwesbaarheid is beskikbaar .
NS Die ewekansige optelteorie word gekant deur die feit dat ek in een sakesentrum in Krasnoyarsk ook daarin geslaag het om die deur met dieselfde metode oop te maak.
Bron: will.com