Radiowe etykiety zyskują popularność. Rośnie liczba ich zastosowań. Przed wdrożeniem warto jednak pamiętać o potencjalnych zagrożeniach, którym często można zapobiec, konfigurując odpowiednio system i aplikacje.

Rosnąca popularność technologii RFID wywołuje dyskusje o potencjalnych zagrożeniach bezpieczeństwa, które niesie jej implementacja. Najlepiej znane i najczęściej wymieniane są możliwości naruszenia prywatności i związanych z tym nadużyć. Ale warto zauważyć, że zagrożeń jest więcej, np. dane pobierane z etykiet RFID przez większość aplikacji są uznawane za informacje zaufane i niepodlegające sprawdzaniu. Powoduje to, że systemy RFID mogą się stać bardzo dobrym środowiskiem do rozprzestrzeniania wirusów lub innego złośliwego kodu. Taki jest przynajmniej wniosek z badań przeprowadzonych na uniwersytecie Vrije w Amsterdamie, które udowadniają ponad wszelką wątpliwość, że jest to zagrożenie realne i możliwe do wykorzystania w praktyce.

Dziurawa aplikacja

Wiele wersji etykiet radiowych jest wyposażonych w pokaźne zasoby pamięci, które z powodzeniem wystarczają do przechowania i roznoszenia złośliwego kodu. Oczywiście sam mikroprocesor RFID zintegrowany z etykietą nie tworzy środowiska, w którym wirusy mogłyby działać, ale może posłużyć jako nośnik złośliwego kodu. Etykieta radiowa ma dość prostą konstrukcję i stosunkowo łatwo można zapewnić jej bezpieczeństwo, ale nie można tego powiedzieć o infrastrukturze służącej do odczytu i zapisu informacji. Są to bardzo skomplikowane elementy zawierające czytnik, serwer aplikacyjny, bazę danych oraz interfejsy. Oprogramowanie do obsługi etykiet jest nie tylko dość skomplikowane, ale również rzadko aktualizowane. Jeśli statystycznie w tysiącu linii kodu obecnych jest do kilkunastu błędów, prawdopodobieństwo eksploitowania jednej z luk w skomplikowanej infrastrukturze, odpowiedzialnej za komunikację z etykietami RFID, jest dość wysokie. Systemy RFID najczęściej składają się z elementów jednego producenta, wykorzystują jedną wersję firmware i przy zastosowaniu jego interfejsów komunikują się z różnymi bazami danych i aplikacjami. W przypadku najpopularniejszych na rynku rozwiązań, nawet jeśli przeprowadzono dokładny audyt ich kodu i znaleziono błędy, prawdopodobieństwo ich usunięcia przez aktualizację wszystkich urządzeń jest niewielkie. Mniej popularne rozwiązania mają z kolei inną wadę - nie zawsze są dostatecznie przetestowane.

Przy budowie infrastruktury RFID z reguły wykorzystywane są standardy internetowe. Dzięki temu system może być skalowalny, ekonomiczny i łatwy do integracji. W praktyce oznacza to, że stosowane są gotowe rozwiązania - aplikacje, biblioteki programistyczne itd. Ale ubocznym tego skutkiem jest włączenie do aplikacji także bagażu znanych błędów. Jeśli biblioteki odpowiedzialne za szyfrowanie lub obsługę DNS zawierają błędy, także aplikacja je zawierająca będzie podatna na ich eksploitowanie. O ile producenci i administratorzy serwerów webowych znają ten problem i aktualizują oprogramowanie dość często, o tyle producenci i administratorzy urządzeń RFID najczęściej nie mają takiej świadomości. Powoduje to podatność oprogramowania middleware na powszechnie znane błędy, związane np. z DNS czy SSL. Choć łatwiejsze i tańsze jest korzystanie z gotowych rozwiązań niż tworzenie nowego kodu od podstaw, ale wówczas należy pamiętać o jego aktualizacji usuwającej powszechnie znane błędy.

Jest luka, znajdzie się eksploit

Ważnym składnikiem infrastruktury RFID jest baza danych oraz aplikacja zapisująca do niej informacje. Ponieważ technologia RFID zakłada masową komunikację, wszystkie urządzenia są przystosowane do automatycznego odczytu etykiet i zapisu informacji do bazy danych. Dane te najczęściej zapisywane są w takiej samej postaci, jak zostały odczytane. Choć tak jest po prostu szybciej i prościej, ale może się okazać, że system będzie podatny na błędy, np. przepełnienia bufora. Typowe etykiety mają pamięć nieprzekra-czającą pojemności 1 KB, lub nawet mniej, i do takiego rozmiaru pakietu przesyłanej informacji dostosowane są aplikacje obsługujące odczyt. Przygotowanie etykiety o większej ilości pamięci, albo wykorzystanie odpowiednio zaprojektowanego urządzenia do modyfikacji sygnałów radiowych wysyłanych przez czytnik umożliwia łatwe przepełnienie bufora aplikacji odpowiedzialnej za odczyt informacji.

Możliwe są także inne ataki, takie jak wstrzyknięcie kodu przez umieszczenie znaków specjalnych ("< >" czy ";"). Już to umożliwia duże nadużycia, bowiem do dyspozycji jest zestaw komend języka skryptowego wewnątrz interpretera pracującego z uprawnieniami normalnej aplikacji. Ponieważ aplikacja korzysta z bazy danych, napastnik może także zastosować techniki SQL Injection, aby umieścić kod SQL w taki sposób, by został on wykonany. Cel ataku może być różny - enumeracja struktury bazy, nieautoryzowane pobranie porcji danych, ich modyfikacja, dodanie lub usunięcie. Na tym nie kończy się wrogi arsenał, bo wiele baz umożliwia wykonywanie komend systemu operacyjnego w środowisku, w którym baza pracuje. Przykładem narzędzia, które można wykorzystać w bazie SQL Server, jest procedura xp_cmdshell, dająca duże możliwości napastnikowi.

Atak za pomocą SQL Injection może dotyczyć nie tylko przepełnienia bufora lub wstrzyknięcia kodu w języku skryptowym - umożliwia przeprowadzenie groźniejszych operacji za pomocą małej ilości kodu. Między innymi polecenie shutdown, umieszczone wewnątrz danych, może spowodować zatrzymanie bazy, DROP TABLE nazwa usunie tabelę o właściwej nazwie, zaś DROP USER midw CASCADE wyeliminuje użytkownika midw z bazy Oracle wraz ze wszystkimi jego obiektami, w tym także tabelami z danymi. Co więcej, możliwa jest kompromitacja systemu operacyjnego, wewnątrz którego pracuje baza, jeśli aplikacja bazy funkcjonuje z uprawnieniami systemowymi. Chociaż jest to trudne, możliwa jest też kompromitacja całej sieci - wystarczy, by SQL Server pracował przy uprawnieniach administratora domeny Active Directory. Wszystko to można wykonać za pomocą jednej specjalnie spreparowanej etykiety RFID, jeśli producent narzędzi do jej odczytu pozostawi w ich kodzie jakiś poważny błąd, a administratorzy systemu w odpowiedni sposób nie ograniczą uprawnień aplikacji.

Wirus w etykiecie

Do wykonania wirusa RFID nie potrzeba specjalnych kwalifikacji. Przygotowanie odpowiedniego kodu ułatwiają popularne podręczniki crackerskie. Po zainfekowaniu systemu wirus taki może się reprodukować do kolejnych etykiet w jego zasięgu. To wszystko można wykonać, wykorzystując tylko SQL Injection, dzięki aktualizacji tabel i zastosowaniu zapytań wyświetlających aktualnie wykonywane zapytania. Tak spreparowany kod wykonuje zmiany w bazie i reprodukuje się sam. Do tego niezbędna jest znajomość bazy danych, która pracuje jako back-end danego rozwiązania. Dla wprawnego crackera nie jest to problem, bo producenci stosują standardowe bazy MS SQL Server, Oracle, MySQL, PostgreSQL lub Sybase, które zawierają obiekt pozwalający odczytać wykonywane zapytanie SQL. Możliwa jest też realizacja wirusa polimorficznego, który zmienia się z każdą replikacją. Oczywiście taki wirus zostawia ślady w bazie danych. Większość zaawansowanych hakerów postarałaby się zapewne, by wirus nie był tak łatwy do wykrycia i zamiast modyfikować tabele umieściłaby kod w procedurze. Administratorzy często sprawdzają tabele i spójność danych, natomiast znacznie rzadziej kontrolują integralność procedur. Warto też zauważyć, że zmiany mogą przejść niezauważone, gdyż bazy infrastruktury RFID są często eksploatowane w sposób całkowicie nienadzorowany. Ponadto, nawet jeśli administrator zauważy fakt zarażenia systemu wirusem, który przenosi się na kolejne etykiety, nie może zdziałać zbyt wiele, dopóki nie usunie luki w bezpieczeństwie. Bo jeśli przywróci bazę do stanu sprzed ataku, każda etykieta zawierająca wirusa spowoduje ponowne naruszenie jej integralności. Właśnie z tego powodu wirus wcale nie musi się maskować - przy masowej obsłudze etykiet, zarażenie pewnej ich liczby powoduje wyjątkowo trudne do eliminacji zagrożenie systemu.

Etykiety RFID, które nie posiadają możliwości zapisywania do nich żadnej informacji przez system (wersja etykiet tylko do odczytu), nie mogą zostać zarażone przez skompromitowany system. Nie oznacza to, że system obsługujący wyłącznie takie etykiety będzie zawsze bezpieczny. Wystarczy, by napastnik zapisał złośliwy kod we własnej, odpowiednio spreparowanej etykiecie i już może zaatakować system RFID, choć nie ma możliwości wykorzystania mechanizmów automatycznego przenoszenia wirusa na inne etykiety.