Az autonóm beléptetőrendszerek problémái – Ahol nem számítottak rájuk

Jó napot mindenkinek. Kezdem azzal a háttérrel, hogy mi késztetett erre a kutatásra, de először figyelmeztetlek: minden gyakorlati intézkedést az irányító struktúrák beleegyezésével hajtottak végre. Bűncselekménynek minősül minden olyan kísérlet, amely ennek az anyagnak a felhasználására korlátozott területre való belépés joga nélkül történik.

Az egész úgy kezdődött, hogy az asztal takarítása közben véletlenül ráhelyeztem az RFID bejárati kulcsot az ACR122 NFC olvasóra – képzeljétek el meglepetésemet, amikor a Windows lejátszotta egy új eszköz észlelésének hangját, és a LED zöldre vált. Eddig a pillanatig azt hittem, hogy ezek a billentyűk kizárólag a Proximity szabványban működnek.
Az autonóm beléptetőrendszerek problémái – Ahol nem számítottak rájuk
De mivel az olvasó látta, ez azt jelenti, hogy a kulcs megfelel az ISO 14443 szabványon felüli protokollok egyikének (más néven Near Field Communication, 13,56 MHz). A takarítás azonnal feledésbe merült, mivel lehetőséget láttam arra, hogy teljesen megszabaduljak a kulcskészlettől, és a bejárati kulcsot a telefonomban tartsam (a lakás már régóta elektronikus zárral van felszerelve). A tanulás megkezdése után rájöttem, hogy a műanyag alatt egy Mifare 1k NFC címke van elrejtve - ugyanaz, mint a vállalati jelvényekben, szállítási kártyákban stb. A szektorok tartalmába való behatolási kísérletek eleinte nem hoztak sikert, majd amikor végre feltörték a kulcsot, kiderült, hogy csak a 3. szektort használták, és abban is duplikált magának a chipnek az UID-jét. Túl egyszerűnek tűnt, és az is lett, és nem lenne cikk, ha minden a tervek szerint alakulna. Így megkaptam a kulcs részeit, és nincs probléma, ha át kell másolni a kulcsot egy másik, ugyanilyen típusúra. De a feladat az volt, hogy átvigyem a kulcsot egy mobileszközre, amit meg is tettem. Itt kezdődött a móka - van egy telefonunk - iPhone SE telepítve iOS 13.4.5 béta build 17F5044d és néhány egyedi komponens az NFC szabad működéséhez - erre bizonyos objektív okok miatt nem térek ki részletesen. Kívánt esetben az alábbiakban leírtak az Android rendszerre is vonatkoznak, de néhány egyszerűsítéssel.

A megoldandó feladatok listája:

  • Hozzáférés a kulcs tartalmához.
  • Valósítsa meg a kulcs emulálásának képességét az eszközön.

Ha az elsőnél minden viszonylag egyszerű volt, akkor a másodiknál ​​problémák voltak. Az emulátor első verziója nem működött. A problémát elég gyorsan felfedezték – a mobileszközökön (iOS vagy Android) emulációs módban az UID dinamikus, és függetlenül attól, hogy mi van bekötve a képbe, lebeg. A második verzió (szuperfelhasználói jogokkal fut) mereven rögzítette a sorozatszámot a kiválasztotton - az ajtó kinyílt. Azonban mindent tökéletesen akartam csinálni, és végül összeállítottam az emulátor teljes verzióját, amely képes megnyitni a Mifare dumpokat és emulálni azokat. Egy hirtelen lendületnek engedve a szektorbillentyűket tetszőlegesre cseréltem, és megpróbáltam kinyitni az ajtót. És ő… NYITOTT! Egy idő után rájöttem, hogy nyitnak bármilyen ajtókat ezzel a zárral, még azokat is, amelyekhez az eredeti kulcs nem illett. Ezzel kapcsolatban új listát készítettem az elvégzendő feladatokról:

  • Tudja meg, milyen vezérlő felelős a kulcsokkal való munkavégzésért
  • Értse meg, hogy van-e hálózati kapcsolat és közös bázis
  • Tudja meg, miért válik egy gyakorlatilag olvashatatlan kulcs univerzálissá

Miután beszéltem egy mérnökkel az alapkezelő társaságnál, megtudtam, hogy az egyszerű Iron Logic z5r vezérlők külső hálózathoz való csatlakozás nélkül használhatók.

CP-Z2 MF olvasó és IronLogic z5r vezérlő
Kaptam egy felszerelést a kísérletekhez:

Az autonóm beléptetőrendszerek problémái – Ahol nem számítottak rájuk

Amint az innen látható, a rendszer teljesen autonóm és rendkívül primitív. Először azt hittem, hogy a vezérlő tanulási módban van - ez azt jelenti, hogy beolvassa a kulcsot, eltárolja a memóriában és kinyitja az ajtót - ezt a módot akkor használják, ha az összes kulcsot rögzíteni kell, például a lakat egy bérházban. De ezt az elméletet nem erősítették meg - ez az üzemmód szoftverben ki van kapcsolva, a jumper munkahelyzetben van -, mégis, amikor felhozzuk a készüléket, a következőket látjuk:

Képernyőkép az emulációs folyamatról az eszközön
Az autonóm beléptetőrendszerek problémái – Ahol nem számítottak rájuk
... és a vezérlő jelzi, hogy a hozzáférést megadták.

Ez azt jelenti, hogy a probléma a vezérlő vagy az olvasó szoftverében van. Vizsgáljuk meg az olvasót - iButton módban működik, ezért csatlakoztassuk a Bolid biztonsági kártyát - az olvasó kimeneti adatait tudjuk majd megtekinteni.

A kártya később RS232-n keresztül lesz csatlakoztatva
Az autonóm beléptetőrendszerek problémái – Ahol nem számítottak rájuk

A többszörös tesztelés módszerével megállapítjuk, hogy az olvasó ugyanazt a kódot sugározza, ha az engedélyezési hiba esetén: 1219191919

A helyzet kezd világosabbá válni, de jelenleg nem világos számomra, hogy a vezérlő miért reagál pozitívan erre a kódra. Feltételezhető, hogy az adatbázis feltöltésekor - véletlenül vagy szándékosan más szektorkulcsokat tartalmazó kártya bemutatása után - az olvasó ezt a kódot küldte, a vezérlő pedig elmentette. Sajnos nincs szabadalmaztatott IronLogic programozóm, aki belenézhetne a vezérlő kulcsadatbázisába, de remélem sikerült felhívnom a figyelmet a probléma fennállására. Elérhető egy bemutató videó a biztonsági rés kezeléséről по ссылке.

PS A véletlenszerű összeadás elmélete ellen szól az a tény, hogy Krasznojarszkban az egyik üzleti központban is sikerült kinyitnom az ajtót ugyanezzel a módszerrel.

Forrás: will.com

Hozzászólás