Goedendag iedereen. Ik begin met de achtergrond over wat mij heeft aangezet tot dit onderzoek, maar eerst waarschuw ik: alle praktische handelingen zijn uitgevoerd met toestemming van de beheersstructuren. Elke poging om dit materiaal te gebruiken voor toegang tot een afgesloten terrein zonder recht om daar te zijn, is een strafbaar feit.
Het begon allemaal met het schoonmaken van mijn bureau, toen ik per ongeluk de RFID-sleutel van de ingang op de NFC-lezer ACR122 plaatste — mijn verbazing was groot toen Windows het geluid van een nieuw apparaat liet horen en de LED groen oplichtte. Tot dat moment dacht ik dat deze sleutels uitsluitend in de Proximity-standaard functioneerden.
Maar nu de lezer het had gezien — betekent dat de sleutel voldoet aan een van de protocollen bovenop de ISO 14443 standaard (ook bekend als Near Field Communication, 13,56 MHz). Ik vergat onmiddellijk de schoonmaak, want ik zag de mogelijkheid om helemaal van de sleutelring af te komen en de ingangssleutel op mijn telefoon op te slaan (het appartement is al lang uitgerust met een elektronisch slot). Toen ik me ging verdiepen, ontdekte ik dat er onder de plastic behuizing een NFC-tag Mifare 1k verborgen zat — hetzelfde model als dat in toegangspassen, bedrijfsbadges, vervoerskaarten, enz. De eerste pogingen om toegang te krijgen tot de inhoud van de sectoren waren niet succesvol, en toen ik de sleutel eindelijk kon kraken — bleek dat alleen sector 3 werd gebruikt, en daarin was de UID van de chip zelf gedupliceerd. Het leek te eenvoudig, en zo bleek het ook, en er zou geen artikel zijn als alles zo was gegaan als gepland. Hier had ik de binnenkant van de sleutel, en er zijn geen problemen als ik de sleutel op een andere identieke sleutel wil dupliceren. Maar de taak was — de sleutel naar een mobiel apparaat over te brengen, wat ik ook deed. En hier begon het plezier — we hebben een telefoon — iPhone SE met geïnstalleerd iOS 13.4.5 Beta build 17F5044d en enkele aangepaste componenten voor een vrije werking van NFC — hier zal ik niet verder op ingaan omwille van enkele objectieve redenen. Als je wilt, is alles wat hierna gezegd wordt ook van toepassing op het Android-systeem, maar dan met enkele vereenvoudigingen.
Takenlijst om op te lossen:
- Toegang krijgen tot de inhoud van de sleutel.
- Mogelijkheid implementeren om de sleutel na te bootsen met het apparaat.
Als het bij de eerste relatief eenvoudig was, deden zich bij de tweede problemen voor. De eerste versie van de emulator werkte niet. Het probleem werd vrij snel ontdekt — op mobiele apparaten (zowel iOS als Android) in emulatiemodus — is de UID dynamisch en ongeacht wat in de afbeelding is ingebed — varieert hij. De tweede versie (uitgevoerd met superuser-rechten) fixeerde het serienummer stevig op de gekozen — de deur ging open. Maar ik wilde alles perfect doen, en uiteindelijk verzamelde ik een afgeronde versie van de emulator die Mifare-dumps kon openen en deze kon emuleren. Gedreven door een plotselinge impuls, wijzigde ik de sleutels van de sectoren naar willekeurige en probeerde de deur te openen. En hij... GING OPEN! Na een tijdje realiseerde ik me dat er geopend werden alle deuren met dit slot, zelfs die waarbij de originele sleutel niet paste. Daarop besloot ik een nieuwe takenlijst op te stellen:
- Uitzoeken welke controller verantwoordelijk is voor de werking met de sleutels
- Begrijpen of er verbinding met het netwerk is en een centrale database
- Uitzoeken waarom een feitelijk onleesbare sleutel universeel wordt
Na een gesprek met de ingenieur van het beheerbedrijf, ontdekte ik dat er eenvoudige controllers Iron Logic z5r worden gebruikt zonder verbinding met een extern netwerk.
Lezer CP-Z2 MF en controller IronLogic z5r
Ik kreeg een set apparatuur voor experimenten:
Zoals je hieruit begrijpt, is het systeem volledig autonoom en uiterst primitief. Eerst dacht ik dat de controller in leerstand stond — het idee hierachter is dat hij de sleutel leest, deze in het geheugen opslaat en de deur opent — deze modus wordt gebruikt wanneer alle sleutels moeten worden vastgelegd, bijvoorbeeld bij het vervangen van een slot in een appartementencomplex. Maar deze theorie bleek niet waar te zijn — softwarematig is deze modus uitgeschakeld, de jumper staat in de 'werkende' stand — en toch zien we bij het aanbieden van het apparaat het volgende:
Screenshot van het emulatieproces op het apparaat
… en de controller geeft aan dat de toegang is verleend.
Dus het probleem zit in de software van ofwel de controller of de lezer. Laten we de lezer controleren — hij werkt in iButton-modus, dus sluiten we de beveiligingskaart Bolid aan — we hebben de mogelijkheid om de uitvoergegevens van de lezer te bekijken.
De kaart zal later via RS232 worden aangesloten
Met de methode van meerdere tests ontdekken we dat de lezer dezelfde code transcribeert in geval van mislukte autorisatie: 1219191919
De situatie begint op te klaren, maar op dit moment begrijp ik niet waarom de controller positief reageert op deze code. Er is een vermoeden dat tijdens het invullen van de database per ongeluk of opzettelijk een kaart met andere sleutelgegevens bij de lezer is gebracht, waardoor deze code werd verzonden en de controller deze heeft opgeslagen. Helaas heb ik geen originele programmeur van IronLogic om in de sleuteldatabase van de controller te kijken, maar ik hoop dat ik de aandacht heb weten te vestigen op het feit dat het probleem bestaat. Een videodemonstratie van het werken met deze kwetsbaarheid is beschikbaar. .
P.S. Tegen de theorie van willekeurig toevoegen spreekt het feit dat ik in hetzelfde kantoorgebouw in Krasnojarsk ook succes had met het openen van de deur met dezelfde methode.
Bron: habr.com
