God dag till alla. Jag börjar med bakgrunden om vad som fick mig att genomföra denna forskning, men först ska jag varna dig: alla praktiska åtgärder utfördes med de styrande strukturernas samtycke. Varje försök att använda detta material för att komma in i ett begränsat område utan rätt att vara där är ett brott.
Allt började när jag, medan jag städade bordet, av misstag placerade RFID-nyckeln på ACR122 NFC-läsaren - föreställ dig min förvåning när Windows spelade upp ljudet av att detektera en ny enhet och lysdioden blev grön. Fram till detta ögonblick trodde jag att dessa nycklar uteslutande fungerar i Proximity-standarden.
Men eftersom läsaren såg det betyder det att nyckeln uppfyller ett av protokollen ovanpå ISO 14443-standarden (alias Near Field Communication, 13,56 MHz). Städningen glömdes omedelbart bort, eftersom jag såg en möjlighet att helt bli av med nycklar och behålla nyckeln till entrén i min telefon (lägenheten har länge varit utrustad med ett elektroniskt lås). Efter att ha börjat studera fick jag reda på att gömd under plasten finns en Mifare 1k NFC-tagg - samma modell som i företagsmärken, transportkort, etc. Försök att komma in i innehållet i sektorerna gav inte framgång till en början, och när nyckeln äntligen knäcktes visade det sig att endast den tredje sektorn användes, och själva chippets UID duplicerades i den. Det såg för enkelt ut, och det visade sig vara så, och det skulle inte bli någon artikel om allt gick precis som planerat. Så jag fick nyckelns ingående, och det är inga problem om du behöver kopiera nyckeln till en annan av samma sort. Men uppgiften var att överföra nyckeln till en mobil enhet, vilket jag gjorde. Det var här det roliga började - vi har en telefon - iPhone SE med installerad iOS 13.4.5 Beta build 17F5044d och några anpassade komponenter för fri drift av NFC - jag kommer inte att uppehålla mig vid detta i detalj på grund av några objektiva skäl. Om så önskas gäller allt som sägs nedan även för Android-systemet, men med vissa förenklingar.
Lista över uppgifter att lösa:
- Få tillgång till nyckelns innehåll.
- Implementera möjligheten att emulera en nyckel av enheten.
Om allt var relativt enkelt med den första, så fanns det problem med den andra. Den första versionen av emulatorn fungerade inte. Problemet upptäcktes ganska snabbt - på mobila enheter (antingen iOS eller Android) i emuleringsläge är UID dynamiskt och, oavsett vad som är inkopplat i bilden, flyter det. Den andra versionen (kör med superanvändarrättigheter) fixerade serienumret på den valda - dörren öppnades. Jag ville dock göra allt perfekt och det slutade med att jag satte ihop en komplett version av emulatorn som kunde öppna Mifare-dumpar och emulera dem. Jag gav efter för en plötslig impuls ändrade jag sektornycklarna till godtyckliga och försökte öppna dörren. Och hon… ÖPPNAD! Efter ett tag insåg jag att de öppnade någon dörrar med detta lås, även de som originalnyckeln inte passade till. I detta avseende skapade jag en ny lista med uppgifter att slutföra:
- Ta reda på vilken typ av kontroller som ansvarar för att arbeta med nycklar
- Förstå om det finns en nätverksanslutning och en gemensam bas
- Ta reda på varför en praktiskt taget oläsbar nyckel blir universell
Efter att ha pratat med en ingenjör på managementbolaget fick jag veta att enkla Iron Logic z5r-kontroller används utan att ansluta till ett externt nätverk.
CP-Z2 MF-läsare och IronLogic z5r-kontroller
Jag fick en uppsättning utrustning för experimenten:
Som framgår härifrån är systemet helt autonomt och extremt primitivt. Först trodde jag att styrenheten var i inlärningsläge - meningen är att den läser nyckeln, lagrar den i minnet och öppnar dörren - detta läge används när det är nödvändigt att spela in alla nycklar, till exempel när du byter ut låsa in ett hyreshus. Men denna teori bekräftades inte - det här läget är avstängt i programvaran, bygeln är i arbetsläge - och ändå, när vi tar upp enheten, ser vi följande:
Skärmdump av emuleringsprocessen på enheten
... och styrenheten signalerar att åtkomst har beviljats.
Detta innebär att problemet ligger i programvaran för antingen styrenheten eller läsaren. Låt oss kontrollera läsaren - den fungerar i iButton-läge, så låt oss ansluta Bolid-säkerhetskortet - vi kommer att kunna se utdata från läsaren.
Kortet kommer senare att anslutas via RS232
Genom att använda metoden för flera tester får vi reda på att läsaren sänder samma kod med i händelse av auktoriseringsfel: 1219191919
Situationen börjar bli tydligare, men för tillfället är det inte klart för mig varför regulatorn reagerar positivt på denna kod. Det finns ett antagande att när databasen fylldes - av misstag eller avsiktligt presenterades ett kort med andra sektornycklar - läsaren skickade denna kod och styrenheten sparade den. Tyvärr har jag ingen proprietär programmerare från IronLogic för att titta in i controller-nyckeldatabasen, men jag hoppas att jag kunde uppmärksamma det faktum att problemet finns. En videodemonstration av hur man arbetar med denna sårbarhet är tillgänglig .
PS Teorin om slumpmässig addition motarbetas av det faktum att jag i ett affärscenter i Krasnoyarsk också lyckades öppna dörren med samma metod.
Källa: will.com