Goededag aan iedereen. Ik zal beginnen met de achtergrond van wat mij ertoe heeft aangezet dit onderzoek uit te voeren, maar eerst waarschuw ik u: alle praktische acties zijn uitgevoerd met toestemming van de bestuursstructuren. Elke poging om dit materiaal te gebruiken om een beperkt gebied te betreden zonder het recht om daar te zijn, is een strafbaar feit.
Het begon allemaal toen ik, terwijl ik de tafel aan het schoonmaken was, per ongeluk de RFID-toegangssleutel op de ACR122 NFC-lezer plaatste. Stel je mijn verbazing voor toen Windows het geluid afspeelde van het detecteren van een nieuw apparaat en de LED groen werd. Tot nu toe geloofde ik dat deze sleutels uitsluitend in de Proximity-standaard werken.
Maar aangezien de lezer het heeft gezien, betekent dit dat de sleutel voldoet aan een van de protocollen bovenop de ISO 14443-standaard (ook bekend als Near Field Communication, 13,56 MHz). Het schoonmaken werd meteen vergeten, omdat ik een kans zag om de set sleutels volledig weg te doen en de sleutel van de ingang in mijn telefoon te bewaren (het appartement is al lang voorzien van een elektronisch slot). Toen ik begon te studeren, ontdekte ik dat onder het plastic een Mifare 1k NFC-tag verborgen zit - hetzelfde model als in bedrijfsbadges, transportkaarten, enz. Pogingen om in de inhoud van de sectoren te komen, leverden aanvankelijk geen succes op, en toen de sleutel uiteindelijk werd gekraakt, bleek dat alleen de derde sector werd gebruikt en dat de UID van de chip zelf daarin werd gedupliceerd. Het leek te simpel, en dat bleek ook zo te zijn, en er zou geen artikel zijn als alles precies volgens plan verliep. Dus ik heb de ingewanden van de sleutel ontvangen, en er zijn geen problemen als je de sleutel naar een andere sleutel van hetzelfde type moet kopiëren. Maar de taak was om de sleutel over te zetten naar een mobiel apparaat, en dat is wat ik deed. Dit is waar het plezier begon - we hebben een telefoon - iPhone SE met geïnstalleerd iOS 13.4.5 Bètabuild 17F5044d en enkele aangepaste componenten voor de gratis werking van NFC - ik zal hier om een aantal objectieve redenen niet in detail op ingaan. Indien gewenst is alles wat hieronder staat ook van toepassing op het Android-systeem, maar met enkele vereenvoudigingen.
Lijst met op te lossen taken:
- Toegang tot de inhoud van de sleutel.
- Implementeer de mogelijkheid om een sleutel door het apparaat te emuleren.
Als bij de eerste alles relatief eenvoudig was, dan waren er bij de tweede problemen. De eerste versie van de emulator werkte niet. Het probleem werd vrij snel ontdekt: op mobiele apparaten (iOS of Android) in de emulatiemodus is de UID dynamisch en, ongeacht wat er in de afbeelding zit, zweeft hij. De tweede versie (uitgevoerd met superuser-rechten) bevestigde het serienummer strikt op de geselecteerde - de deur ging open. Ik wilde echter alles perfect doen en uiteindelijk heb ik een complete versie van de emulator samengesteld die Mifare-dumps kon openen en emuleren. Ik gaf toe aan een plotselinge impuls, veranderde de sectorsleutels in willekeurige sleutels en probeerde de deur te openen. En zij… GEOPEND! Na een tijdje besefte ik dat ze open gingen ieder deuren met dit slot, zelfs deuren waarbij de originele sleutel niet paste. In dit verband heb ik een nieuwe lijst met taken gemaakt die ik moet voltooien:
- Ontdek welk type controller verantwoordelijk is voor het werken met sleutels
- Begrijp of er een netwerkverbinding en een gemeenschappelijke basis is
- Ontdek waarom een vrijwel onleesbare sleutel universeel wordt
Na een gesprek met een ingenieur bij het beheerbedrijf kwam ik erachter dat eenvoudige Iron Logic z5r-controllers worden gebruikt zonder verbinding te maken met een extern netwerk.
CP-Z2 MF-lezer en IronLogic z5r-controller
Ik kreeg een set apparatuur voor de experimenten:
Zoals hieruit duidelijk wordt, is het systeem volledig autonoom en uiterst primitief. In eerste instantie dacht ik dat de controller in de leermodus stond - de betekenis is dat hij de sleutel leest, in het geheugen opslaat en de deur opent - deze modus wordt gebruikt wanneer het nodig is om alle sleutels op te nemen, bijvoorbeeld bij het vervangen van de slot in een appartementencomplex. Maar deze theorie werd niet bevestigd - deze modus is softwarematig uitgeschakeld, de jumper bevindt zich in de werkpositie - en toch zien we het volgende als we het apparaat naar voren brengen:
Schermafbeelding van het emulatieproces op het apparaat
... en de controller meldt dat toegang is verleend.
Dit betekent dat het probleem in de software van de controller of de lezer ligt. Laten we de lezer controleren - deze werkt in iButton-modus, dus laten we de Bolid-beveiligingskaart aansluiten - we kunnen de uitvoergegevens van de lezer bekijken.
Het bord wordt later via RS232 aangesloten
Met behulp van de methode van meerdere tests komen we erachter dat de lezer dezelfde code uitzendt als de autorisatie mislukt: 1219191919
De situatie begint duidelijker te worden, maar op dit moment is het mij niet duidelijk waarom de controller positief reageert op deze code. Er wordt aangenomen dat toen de database werd gevuld - per ongeluk of met opzet een kaart met andere sectorsleutels werd gepresenteerd - de lezer deze code verzond en de controller deze opsloeg. Helaas heb ik geen eigen programmeur van IronLogic die in de sleuteldatabase van de controller kan kijken, maar ik hoop dat ik de aandacht heb kunnen vestigen op het feit dat het probleem bestaat. Er is een videodemonstratie beschikbaar van het werken met dit beveiligingslek .
PS De theorie van willekeurige optelling wordt tegengesproken door het feit dat ik er in een zakencentrum in Krasnojarsk ook in slaagde de deur op dezelfde manier te openen.
Bron: www.habr.com