Witam wszystkich serdecznie. Zacznę od historii, która skłoniła mnie do przeprowadzenia tego badania, ale najpierw ostrzegam: wszystkie praktyczne działania zostały wykonane za zgodą władz. Jakiekolwiek próby wykorzystania tego materiału w celu dostania się na zamknięty teren bez uprawnienia są przestępstwem.
Wszystko zaczęło się od tego, że sprzątając na biurku, przypadkowo położyłem klucz RFID od wejścia na czytnik NFC ACR122 – jakże byłem zaskoczony, gdy Windows wydał dźwięk wykrycia nowego urządzenia, a dioda LED zaświeciła się na zielono. Do tej pory sądziłem, że te klucze działają wyłącznie w standardzie Proximity.
Skoro czytnik go wykrył, to znaczy, że klucz odpowiada jednemu z protokołów na standardzie ISO 14443 (znanym również jako Near Field Communication, 13,56 MHz). O sprzątaniu natychmiast zapomniałem, bo zauważyłem możliwość pozbycia się zestawu kluczy i przechowania klucza od wejścia w telefonie (mieszkanie od dawna jest wyposażone w elektroniczny zamek). Po zagłębieniu się w badania, odkryłem, że pod plastikiem kryje się znacznik NFC Mifare 1k – ten sam model, który znajduje się w identyfikatorach w firmach, kartach transportowych itp. Próby dostania się do zawartości sektorów na początku nie przyniosły sukcesu, a kiedy udało mi się złamać klucz – okazało się, że używany jest tylko 3. sektor, w którym powielony jest UID samego chipu. Wyglądało to zbyt prosto, więc tak też było i nie byłoby artykułu, gdyby wszystko przebiegło zgodnie z planem. Oto miałem wyciąg z klucza i nie było problemów, jeśli trzeba było skopiować klucz na inny taki sam. Ale zadaniem było przeniesienie klucza na urządzenie mobilne, czym się zająłem. I tu zaczęła się zabawa – mamy telefon – iPhone SE z zainstalowanym iOS 13.4.5 Beta build 17F5044d i kilkoma niestandardowymi komponentami do swobodnej pracy NFC – na tym nie będę szczegółowo się zatrzymywał z powodów obiektywnych. Przy odrobinie chęci wszystko, co powiedziano dalej, ma zastosowanie również w systemie Android, ale z pewnymi uproszczeniami.
Lista zadań do rozwiązania:
- Uzyskać dostęp do zawartości klucza.
- Zrealizować możliwość emulacji klucza przez urządzenie.
Jeśli w przypadku pierwszego wszystko było stosunkowo proste, to w przypadku drugiego wystąpiły problemy. Pierwsza wersja emulatora nie zadziałała. Problem został dość szybko zidentyfikowany — w przypadku urządzeń mobilnych (zarówno iOS, jak i Android) w trybie emulacji — UID jest dynamiczny i niezależnie od tego, co jest zaimplementowane w obrazie — zmienia się. Druga wersja (uruchamiana z uprawnieniami superużytkownika) sztywno fiksowała numer seryjny na wybranym — drzwi się otwierały. Jednak chciałem zrobić wszystko idealnie i w końcu stworzyłem ukończoną wersję emulatora, która mogła otwierać zrzuty Mifare i je emulować. Poddałem się nagłemu impulsowi, zmieniłem klucze sektorów na dowolne i próbowałem otworzyć drzwi. I one... OTWORZYŁY SIĘ! Po chwili zrozumiałem, że otwierają się jakiekolwiek drzwi z tym zamkiem, nawet te, do których oryginalny klucz nie pasował. W związku z tym stworzyłem nową listę zadań do wykonania:
- Dowiedzieć się, który kontroler odpowiada za współpracę z kluczami
- Zrozumieć, czy istnieje połączenie z siecią i wspólna baza
- Dowiedzieć się, dlaczego faktycznie nieczytelny klucz staje się uniwersalny
Rozmawiając z inżynierem zarządzającym firmą, dowiedziałem się, że używa się prostych kontrolerów Iron Logic z5r bez podłączenia do zewnętrznej sieci.
Czytnik CP-Z2 MF i kontroler IronLogic z5r
Otrzymałem zestaw sprzętu do eksperymentów:
Jak tutaj widać — system jest całkowicie autonomiczny i ekstremalnie prymitywny. Na początku pomyślałem, że kontroler znajduje się w trybie uczenia się — sens polega na tym, że odczytuje klucz, zapisuje go w pamięci i otwiera drzwi — ten tryb wykorzystuje się, gdy trzeba zapisać wszystkie klucze, na przykład podczas wymiany zamka w budynku wielorodzinnym. Ale ta teoria nie potwierdziła się — programowo ten tryb jest wyłączony, zworka znajduje się w pozycji roboczej — i mimo to, kiedy zbliżamy urządzenie, widzimy następujące:
Zrzut ekranu procesu emulacji na urządzeniu
… a kontroler sygnalizuje, że dostęp został przyznany.
Oznacza to, że problem tkwi w oprogramowaniu albo kontrolera, albo czytnika. Sprawdźmy czytnik — działa w trybie iButton, więc podłączymy płytę bezpieczeństwa Bolid — będziemy mieć możliwość zobaczenia danych wyjściowych z czytnika.
Płytka, później będzie podłączona przez RS232
Metodą wielokrotnych prób ustalamy, że czytnik przesyła ten sam kod w przypadku nieudanej autoryzacji: 1219191919
Sytuacja zaczyna się wyjaśniać, jednak w obecnej chwili nie rozumiem, dlaczego ten kod pozytywnie reaguje kontroler. Jest przypuszczenie, że podczas napełniania bazy przypadkowo lub celowo zbliżono kartę z innymi kluczami sektora — czytnik wysłał ten kod, a kontroler go zapisał. Niestety nie posiadam firmowego programatora od IronLogic, aby zajrzeć do bazy kluczy kontrolera, ale mam nadzieję, że udało mi się zwrócić uwagę na to, że problem istnieje. Wideo demonstrujące działanie tej luki jest dostępne .
P.S. Przeciwko teorii przypadkowego dodania przemawia fakt, że w jednym z biurowców w Krasnojarsku również udało mi się otworzyć drzwi tą samą metodą.
Źródło: habr.com
