Mindenkinek jó napot kívánok. Azt fogom elmesélni, hogy mi ösztönzött arra, hogy ezt a kutatást végezzem, de előre figyelmeztetem: minden gyakorlati lépést az irányító struktúrák beleegyezésével hajtottam végre. Bármilyen kísérlet eanyag felhasználására zárt területekre való jogosulatlan behatolás céljából bűncselekmény.
Az egész azzal kezdődött, hogy takarítás közben véletlenül a bejárat RFID kulcsát egy ACR122 NFC olvasóra helyeztem — milyen meglepetésemre Windows az új eszköz felfedezésének hangját játszotta le, és a LED zölden kezdett világítani. Eddig azt hittem, hogy ezek a kulcsok kizárólag Proximity szabvány szerint működnek.
De mivel az olvasó érzékelte, azt jelenti, hogy a kulcs az ISO 14443 szabvány (más néven Near Field Communication, 13,56 MHz) feletti protokollok egyikének megfelel. Az takarításról azonnal elfelejtkeztem, mert láttam, hogy van lehetőség arra, hogy teljesen megszabaduljak a kulcscsomótól, és a bejárati kulcsot a telefonomon tároljam (a lakás már régóta elektronikus zárral van felszerelve). A tanulmányozás után kiderült, hogy a műanyag alatt egy Mifare 1k NFC címke rejtőzik — ez ugyanaz a modell, mint a céges belépő kártyákon, közlekedési kártyákon stb. Az első próbálkozások a szektorok tartalmának megismerésére nem hoztak sikert, de amikor végre sikerült feltörni a kulcsot — kiderült, hogy csak a 3. szektor használatos, és abban duplikálva van a chip UID-ja. Túl egyszerűnek tűnt, és így is volt, és nem lett volna cikk, ha minden úgy történt volna, ahogy terveztük. Most megkaptam a kulcs bélését, és nincsenek problémák, ha másik ugyanilyen kulcsra van szükségem. De a feladat az volt, hogy a kulcsot egy mobil eszközre áttranszferáljam, amivel el is kezdtem foglalkozni. Itt kezdődött a mulatság — van egy telefonunk — iPhone SE előtelepített iOS 13.4.5 Beta build 17F5044d és néhány egyedi komponens a szabad NFC működéshez — erről nem fogok részletezni néhány objektív ok miatt. Igény szerint az itt következő minden állítás alkalmazható az Android rendszerre is, de néhány egyszerűsítéssel.
Feladatlista a megoldáshoz:
- Hozzáférni a kulcs tartalmához.
- Lehetővé tenni a kulcs emulálását az eszközzel.
Az első eset viszonylag egyszerű volt, de a másodiknál problémák merültek fel. Az emulátor első verziója nem működött. A probléma viszonylag gyorsan felfedezésre került - a mobil eszközökön (mind iOS, mind Android) az emulációs módban - a UID dinamikus és függetlenül attól, hogy mi van beírva a képfájlba - ingadozik. A második verzió (amelyet rendszergazdai jogokkal indítottunk) szigorúan rögzítette a sorozatszámot a kiválasztott elemnél - az ajtó kinyílt. Azonban mindent tökéletesre akartam csinálni, és végül egy befejezett emulátor verziót állítottam össze, amely képes volt Mifare dumpokat megnyitni és azokat emulálni. Egy váratlan impulzus hatására a szektorok kulcsait véletlenszerűre változtattam, és megpróbáltam kinyitni az ajtót. És az... KINYÍLT! Néhány idő múlva rájöttem, hogy kinyílnak bármely ajtó ezzel a zárral, még azok is, amelyekhez az eredeti kulcs nem megfelelt. Ebből kifolyólag új feladatlistát állítottam össze:
- Kideríteni, hogy melyik vezérlő felel a kulcsok kezeléséért
- Megérteni, hogy van-e kapcsolat a hálózattal és közös adatbázis
- Kideríteni, hogy miért válik a gyakorlatilag olvashatatlan kulcs univerzálissá
Beszélgetve a kezelőmérnökkel megtudtam, hogy egyszerű Iron Logic z5r vezérlőket használnak, külső hálózatra csatlakozás nélkül.
CP-Z2 MF olvasó és IronLogic z5r vezérlő
Kaptam egy felszerelést a kísérletezéshez:
Ahogyan az itt látható - a rendszer teljesen önálló és rendkívül primitív. Először azt hittem, hogy a vezérlő tanulási módban van - a lényeg az, hogy beolvassa a kulcsot, rögzíti azt a memóriájába, és kinyitja az ajtót - ezt a módot használják, amikor az összes kulcsot rögzíteni kell, például egy zár cseréjekor egy társasházban. De ez a teória nem bizonyult helytállónak - programozásilag ez a mód ki van kapcsolva, a jumper a működő állapotban van - és mégis, amikor az eszközt közelítjük, a következőket látjuk:
A folyamat emulációs képernyője az eszközön
… és a vezérlő jelzi, hogy a hozzáférés engedélyezett.
Ezért a probléma a szoftverben rejlik, vagy a vezérlőn, vagy az olvasón. Nézzük meg az olvasót - iButton módban működik, tehát csatlakoztassuk a Bolid biztonsági lapot - lehetőségünk lesz megnézni az olvasó kimeneti adatait.
A lap a későbbiekben RS232-n keresztül lesz csatlakoztatva
Több próbálkozás módszerével megállapítjuk, hogy az olvasó ugyanazt a kódot továbbítja, ha a hitelesítés nem sikerül: 1219191919
A helyzet kezd tisztázódni, de jelenleg számomra nem világos, hogy miért reagál pozitívan a vezérlő erre a kódra. Felvetődött a gyanú, hogy amikor feltöltötték az adatbázist – véletlenül vagy szándékosan – a szektor más kulcsaival ellátott kártyát közelítették, és az olvasó ezt a kódot küldte el, amit a vezérlő megőrzött. Sajnos nincs az IronLogic gyártótól származó programozóm, hogy belenézzek a vezérlő kulcsainak adatbázisába, de remélem, hogy sikerült felhívnom a figyelmet arra, hogy a probléma létezik. A sérülékenységgel kapcsolatos videódemonstráció elérhető. .
P.S. Az elmélettel ellentétben, miszerint véletlenszerűen adták hozzá, azt a tény támasztja alá, hogy egy Krasznojarszk-i üzleti központban nekem is sikerült kinyitni az ajtót ugyanezen módszerrel.
Forrás: habr.com
