Ha en fin dag alle sammen. Jeg starter med bakgrunnen om hva som fikk meg til å gjennomføre denne forskningen, men først vil jeg advare deg: alle praktiske handlinger ble utført med samtykke fra de styrende strukturene. Ethvert forsøk på å bruke dette materialet til å gå inn i et begrenset område uten rett til å være der, er straffbart.
Det hele startet da jeg, mens jeg vasket bordet, ved et uhell plasserte RFID-inngangsnøkkelen på ACR122 NFC-leseren - forestill deg overraskelsen min da Windows spilte lyden av å oppdage en ny enhet og LED-en ble grønn. Inntil dette øyeblikket trodde jeg at disse nøklene utelukkende fungerer i Proximity-standarden.
Men siden leseren så det, betyr det at nøkkelen oppfyller en av protokollene på toppen av ISO 14443-standarden (aka Near Field Communication, 13,56 MHz). Rengjøring ble umiddelbart glemt, da jeg så en mulighet til å kvitte seg helt med settet med nøkler og beholde nøkkelen til inngangen i telefonen min (leiligheten har lenge vært utstyrt med en elektronisk lås). Etter å ha begynt å studere, fant jeg ut at skjult under plasten er en Mifare 1k NFC-tag - samme modell som i bedriftsmerker, transportkort osv. Forsøk på å komme inn på innholdet i sektorene ga ikke suksess med det første, og da nøkkelen til slutt ble sprakk, viste det seg at bare den tredje sektoren ble brukt, og UID-en til selve brikken ble duplisert i den. Det så for enkelt ut, og det viste seg å være slik, og det ville ikke bli noen artikkel om alt gikk akkurat som planlagt. Så jeg mottok innmaten til nøkkelen, og det er ingen problemer hvis du trenger å kopiere nøkkelen til en annen av samme type. Men oppgaven var å overføre nøkkelen til en mobil enhet, det var det jeg gjorde. Det var her moroa begynte - vi har en telefon - iPhone SE med etablerte iOS 13.4.5 Beta build 17F5044d og noen tilpassede komponenter for fri drift av NFC - jeg vil ikke dvele ved dette i detalj på grunn av noen objektive årsaker. Om ønskelig gjelder alt som er nevnt nedenfor også for Android-systemet, men med noen forenklinger.
Liste over oppgaver som skal løses:
- Få tilgang til innholdet i nøkkelen.
- Implementer muligheten til å emulere en nøkkel ved enheten.
Hvis alt var relativt enkelt med den første, så var det problemer med den andre. Den første versjonen av emulatoren fungerte ikke. Problemet ble oppdaget ganske raskt - på mobile enheter (enten iOS eller Android) i emuleringsmodus er UID dynamisk og, uavhengig av hva som er koblet inn i bildet, flyter det. Den andre versjonen (kjørt med superbrukerrettigheter) festet serienummeret på den valgte - døren åpnet. Jeg ønsket imidlertid å gjøre alt perfekt, og endte opp med å sette sammen en komplett versjon av emulatoren som kunne åpne Mifare-dumper og etterligne dem. Jeg ga etter for en plutselig impuls, endret sektornøklene til vilkårlige og prøvde å åpne døren. Og hun… ÅPNET! Etter en stund skjønte jeg at de åpnet noen dører med denne låsen, også de som originalnøkkelen ikke passet til. I denne forbindelse opprettet jeg en ny liste over oppgaver som skal fullføres:
- Finn ut hva slags kontroller som er ansvarlig for å jobbe med nøkler
- Forstå om det er en nettverkstilkobling og en felles base
- Finn ut hvorfor en praktisk talt uleselig nøkkel blir universell
Etter å ha snakket med en ingeniør i administrasjonsselskapet, lærte jeg at enkle Iron Logic z5r-kontrollere brukes uten å koble til et eksternt nettverk.
CP-Z2 MF-leser og IronLogic z5r-kontroller
Jeg fikk et sett med utstyr for eksperimentene:
Som det fremgår herfra, er systemet fullstendig autonomt og ekstremt primitivt. Først trodde jeg at kontrolleren var i læringsmodus - meningen er at den leser nøkkelen, lagrer den i minnet og åpner døren - denne modusen brukes når det er nødvendig å registrere alle nøklene, for eksempel når du bytter ut låse inn en bygård. Men denne teorien ble ikke bekreftet - denne modusen er slått av i programvaren, jumperen er i arbeidsposisjon - og likevel, når vi tar opp enheten, ser vi følgende:
Skjermbilde av emuleringsprosessen på enheten
... og kontrolleren signaliserer at tilgang er gitt.
Dette betyr at problemet ligger i programvaren til enten kontrolleren eller leseren. La oss sjekke leseren - den fungerer i iButton-modus, så la oss koble til Bolid-sikkerhetskortet - vi vil kunne se utdataene fra leseren.
Brettet vil senere kobles til via RS232
Ved å bruke metoden for flere tester finner vi ut at leseren sender den samme koden med i tilfelle autorisasjonsfeil: 1219191919
Situasjonen begynner å bli klarere, men for øyeblikket er det ikke klart for meg hvorfor kontrolleren reagerer positivt på denne koden. Det er en antagelse at når databasen ble fylt - ved et uhell eller med vilje ble det presentert et kort med andre sektornøkler - sendte leseren denne koden og kontrolleren lagret den. Dessverre har jeg ikke en proprietær programmerer fra IronLogic til å se inn i kontrollernøkkeldatabasen, men jeg håper jeg klarte å gjøre oppmerksom på at problemet eksisterer. En videodemonstrasjon av hvordan du arbeider med denne sårbarheten er tilgjengelig .
PS Den tilfeldige addisjonsteorien motarbeides av det faktum at jeg i et forretningssenter i Krasnoyarsk også klarte å åpne døren ved hjelp av samme metode.
Kilde: www.habr.com