Goddag til alle. Jeg vil begynde med baggrunden for, hvad der fik mig til at udføre denne undersøgelse, men jeg vil først advare: alle praktiske handlinger blev udført med samtykke fra de styrende organer. Enhver forsøg på at bruge dette materiale til at trænge ind på et lukket område uden ret til at være der, er en strafbar handling.
Det hele startede med, at jeg mens jeg ryddede op på mit skrivebord, ved et uheld satte RFID-nøglen til opgangen på NFC-læseren ACR122 – hvor stor var min overraskelse, da Windows gav lyden af en ny enhed, og lysdiode lyste grønt. Indtil dette tidspunkt havde jeg troet, at disse nøgler kun fungerede i Proximity-standarden.
Men da læseren kunne se den, betyder det, at nøglen overholder en af protokollerne over ISO 14443-standarden (også kendt som Near Field Communication, 13,56 MHz). Jeg glemte straks om oprydningen, da jeg så muligheden for helt at slippe for nøglebundtet og gemme nøglen til opgangen på min telefon (lejligheden har længe været udstyret med en elektronisk lås). Jeg satte mig for at undersøge sagen og fandt ud af, at der under plastikken gemte sig en NFC-tag Mifare 1k – samme model, der bruges i adgangskort, transportkort osv. Forsøg på at tilgå indholdet af sektorerne gav i starten ikke resultater, men da jeg endelig lykkedes med at hacke nøglen, viste det sig, at kun den 3. sektor blev brugt, og i den var UID for selve chippen duplikeret. Det så alt for enkelt ud, og det viste sig, at der ikke ville være nogen artikel, hvis alt var gået helt som planlagt. Så jeg havde fået nøglens indhold, og der var ingen problemer, hvis det var nødvendigt at kopiere nøglen til en anden ensartet. Men opgaven var at overføre nøglen til en mobil enhed, hvilket jeg satte mig for. Her begyndte det sjove — vi har en telefon — iPhone SE med installeret iOS 13.4.5 Beta build 17F5044d og nogle tilpassede komponenter for fri NFC-funktionalitet – jeg vil ikke gå i dybden med dette af nogle objektive årsager. Hvis ønskes, kan alt det, der bliver sagt herunder, også anvendes til Android-systemet, men med nogle forenklinger.
Liste over opgaver at løse:
- Få adgang til nøglens indhold.
- Implementere muligheden for at emulere nøglen med enheden.
Hvis det var relativt nemt med det første, så opstod der problemer med det andet. Den første version af emulatoren virkede ikke. Problemet blev hurtigt identificeret — for mobile enheder (både iOS og Android) i emulationsmodus er UID dynamisk, og uanset hvad der er indkodet i billedet, ændrer det sig. Den anden version (udført med superbrugerrettigheder) fastlåste seri nummeret på det valgte — døren blev åbnet. Men jeg ønskede at gøre det perfekt, og i sidste ende samlede jeg en færdig version af emulatoren, der kunne åbne Mifare dumps og emulere dem. Efter et pludseligt anfald ændrede jeg sektor nøglerne til vilkårlige og forsøgte at åbne døren. Og den… ÅBNEDES! Efter et stykke tid indså jeg, at der åbnes enhver dør med denne lås, selv dem som den originale nøgle ikke passede til. I den forbindelse dannede jeg en ny opgaveliste til at udføre:
- Find ud af, hvilken controller der er ansvarlig for arbejdet med nøglerne
- Forstå om der er forbindelse til netværket og en fælles database
- Find ud af, hvorfor en reelt ulæselig nøgle bliver universel
Efter at have talt med ingeniøren fra administrationen fik jeg at vide, at der anvendes simple controllere, Iron Logic z5r, uden forbindelse til et eksternt netværk.
Læsere CP-Z2 MF og controller IronLogic z5r
Jeg fik udleveret et sæt udstyr til forsøg:
Som det fremgår herfra — systemet er fuldstændig autonomt og ekstremt primitivt. Først troede jeg, at controlleren var i læringsmode — meningen er, at den indlæser nøglen, gemmer den i hukommelsen og åbner døren — denne tilstand bruges, når man skal registrere alle nøgler, f.eks. ved udskiftning af låsen i et lejlighedskompleks. Men denne teori blev ikke bekræftet — programmet er deaktiveret i denne tilstand, jumperen er i arbejdsposition — og alligevel når vi holder enheden op til det, ser vi følgende:
Screenshot af emuleringsprocessen på enheden
… og controlleren signalerer, at adgangen er givet.
Så problemet ligger i softwaren enten i controllere eller læseren. Lad os tjekke læseren — den fungerer i iButton-tilstand, så lad os tilslutte sikkerhedsboardet Bolid — vi vil få mulighed for at se uddata fra læseren.
Boardet, vil senere blive tilsluttet via RS232
Ved hjælp af multiple tests finder vi, at kortlæseren transmitterer den samme kode ved fejlslagen autorisation: 1219191919
Situationen begynder at blive klarere, men på nuværende tidspunkt forstår jeg ikke, hvorfor denne kode positivt reageres af controlleren. Der er en formodning — at da databasen blev udfyldt — tilfældigt eller med vilje blev et kort med andre sektor-nøgler præsenteret — kortlæseren sendte denne kode, og controlleren gemte den. Desværre har jeg ikke den originale programmerer fra IronLogic til at kigge i controllerens nøgledatabase, men jeg håber, jeg har formået at få opmærksomhed på, at problemet eksisterer. En video-demo af arbejdet med denne sårbarhed er tilgængelig .
P.S. Mod teorien om tilfældig tilføjelse taler det faktum, at jeg i et forretningscenter i Krasnoyarsk også kunne åbne døren med denne metode.
Kilde: habr.com
