God dag til alle. Jeg starter med baggrunden om, hvad der fik mig til at udføre denne forskning, men først vil jeg advare dig: alle praktiske handlinger blev udført med samtykke fra de styrende strukturer. Ethvert forsøg på at bruge dette materiale til at komme ind i et begrænset område uden ret til at være der er en strafbar handling.
Det hele startede, da jeg, mens jeg rensede bordet, ved et uheld placerede RFID-indgangsnøglen på ACR122 NFC-læseren - forestil dig min overraskelse, da Windows afspillede lyden af registrering af en ny enhed, og LED'en blev grøn. Indtil dette øjeblik troede jeg, at disse nøgler udelukkende fungerer i Proximity-standarden.
Men siden læseren så det, betyder det, at nøglen opfylder en af protokollerne oven på ISO 14443-standarden (alias Near Field Communication, 13,56 MHz). Rengøring blev straks glemt, da jeg så en mulighed for helt at slippe af med nøglesættet og beholde nøglen til indgangen i min telefon (lejligheden har længe været udstyret med en elektronisk lås). Da jeg var begyndt at studere, fandt jeg ud af, at gemt under plastikken er et Mifare 1k NFC-tag - samme model som i enterprise badges, transportkort osv. Forsøg på at komme ind på indholdet af sektorerne gav ikke succes i starten, og da nøglen endelig blev knækket, viste det sig, at kun den 3. sektor blev brugt, og selve chippens UID blev duplikeret i den. Det så for simpelt ud, og det viste sig at være det, og der ville ikke være nogen artikel, hvis alt gik helt som planlagt. Så jeg modtog nøglens indmad, og der er ingen problemer, hvis du skal kopiere nøglen til en anden af samme slags. Men opgaven var at overføre nøglen til en mobil enhed, hvilket jeg gjorde. Det var her det sjove begyndte - vi har en telefon - iPhone SE med installeret iOS 13.4.5 Beta build 17F5044d og nogle brugerdefinerede komponenter til fri drift af NFC - jeg vil ikke dvæle ved dette i detaljer på grund af nogle objektive årsager. Hvis det ønskes, gælder alt nævnt nedenfor også for Android-systemet, men med nogle forenklinger.
Liste over opgaver, der skal løses:
- Få adgang til nøglens indhold.
- Implementer evnen til at emulere en nøgle ved enheden.
Hvis alt var relativt enkelt med den første, så var der problemer med den anden. Den første version af emulatoren virkede ikke. Problemet blev opdaget ret hurtigt - på mobile enheder (enten iOS eller Android) i emuleringstilstand er UID'et dynamisk, og uanset hvad der er forbundet til billedet, flyder det. Den anden version (køres med superbrugerrettigheder) fikserede serienummeret på den valgte - døren åbnede. Jeg ville dog gøre alt perfekt, og endte med at sammensætte en komplet version af emulatoren, der kunne åbne Mifare-dumps og efterligne dem. Jeg gav efter for en pludselig impuls, ændrede sektornøglerne til vilkårlige og forsøgte at åbne døren. Og hun… ÅBNET! Efter et stykke tid indså jeg, at de åbnede nogen døre med denne lås, også dem som den originale nøgle ikke passede til. I denne forbindelse oprettede jeg en ny liste over opgaver, der skal udføres:
- Find ud af, hvilken type controller der er ansvarlig for at arbejde med nøgler
- Forstå, om der er en netværksforbindelse og en fælles base
- Find ud af, hvorfor en praktisk talt ulæselig nøgle bliver universel
Efter at have talt med en ingeniør hos administrationsselskabet, lærte jeg, at simple Iron Logic z5r-controllere bruges uden at forbinde til et eksternt netværk.
CP-Z2 MF-læser og IronLogic z5r-controller
Jeg fik et sæt udstyr til eksperimenterne:
Som det fremgår herfra, er systemet fuldstændig autonomt og ekstremt primitivt. Først troede jeg, at controlleren var i indlæringstilstand - meningen er, at den læser nøglen, gemmer den i hukommelsen og åbner døren - denne tilstand bruges, når det er nødvendigt at registrere alle nøglerne, for eksempel ved udskiftning af låse en lejlighedsbygning ind. Men denne teori blev ikke bekræftet - denne tilstand er slået fra i software, jumperen er i arbejdsposition - og alligevel, når vi bringer enheden op, ser vi følgende:
Skærmbillede af emuleringsprocessen på enheden
... og controlleren signalerer, at der er givet adgang.
Dette betyder, at problemet ligger i softwaren til enten controlleren eller læseren. Lad os tjekke læseren - den virker i iButton-tilstand, så lad os tilslutte Bolid-sikkerhedskortet - vi vil være i stand til at se outputdataene fra læseren.
Kortet vil senere blive tilsluttet via RS232
Ved at bruge metoden til flere test finder vi ud af, at læseren udsender den samme kode med i tilfælde af godkendelsesfejl: 1219191919
Situationen begynder at blive klarere, men i øjeblikket er det ikke klart for mig, hvorfor controlleren reagerer positivt på denne kode. Der er en antagelse om, at når databasen blev udfyldt - ved et uheld eller med vilje blev der præsenteret et kort med andre sektornøgler - sendte læseren denne kode, og controlleren gemte den. Desværre har jeg ikke en proprietær programmør fra IronLogic til at kigge i controller-nøgledatabasen, men jeg håber, jeg var i stand til at gøre opmærksom på, at problemet eksisterer. En videodemonstration af arbejdet med denne sårbarhed er tilgængelig .
PS. Teorien om tilfældig tilføjelse modarbejdes af, at det i et forretningscenter i Krasnoyarsk også lykkedes mig at åbne døren ved hjælp af samme metode.
Kilde: www.habr.com