W kierunku zrozumienia stosowalności obrony ruchomego celu w czasie wykonywania dla Internetu rzeczy i systemów cyber‑fizycznych

Dlaczego maleńkie komputery potrzebują dużych zabezpieczeń

Od inteligentnych termostatów po roboty przemysłowe — codzienne życie coraz bardziej opiera się na małych połączonych urządzeniach, które dyskretnie mierzą, kontrolują i automatyzują nasz świat. Te same urządzenia mogą jednak zostać przejęte przez atakujących wykorzystujących od dawna znane błędy oprogramowania, by uzyskać kontrolę. Artykuł bada, czy potężny trik bezpieczeństwa zwany obroną ruchomego celu rzeczywiście działa na skromnym sprzęcie, który napędza większość urządzeń Internetu Rzeczy (IoT) i systemów cyber‑fizycznych (CPS) — oraz co to oznacza dla ochrony coraz bardziej zautomatyzowanego świata.

Ruchoma tarcza dla hakerów

Tradycyjne narzędzia bezpieczeństwa, takie jak zapory ogniowe czy antywirusy, w większości reagują dopiero po rozpoczęciu ataku. Obrona ruchomego celu stosuje inną taktykę: nieustannie zmienia kluczowe części systemu, aby atakujący nigdy nie byli pewni, gdzie trafić. Konkretną techniką badana tutaj jest Address Space Layout Randomization (ASLR), która za każdym uruchomieniem przetasowuje, gdzie programy i biblioteki znajdują się w pamięci. Dzięki temu nawet jeśli atakujący zna słaby punkt, nie może łatwo odnaleźć jego dokładnego adresu. ASLR jest dziś standardem w głównych systemach operacyjnych, ale jego zachowanie na małych urządzeniach o ograniczonych zasobach — takich jak typowe urządzenia IoT i CPS — nie było dobrze poznane.

Test trzech systemów

Autorzy porównują skuteczność ASLR na trzech systemach opartych na Linuksie: 64‑bitowym Kali Linux na typowym procesorze Intela oraz dwóch 32‑bitowych systemach ARM uruchamiających Raspberry Pi OS i OpenWRT, które są bliższe temu, co można znaleźć w urządzeniach brzegowych, routerach i bramach. Zamiast próbować włamać się na ślepo, przyjmują naukowe podejście: wielokrotnie rejestrują, gdzie dana powszechna biblioteka systemowa (libc) ląduje w pamięci, budując duże zbiory danych rzeczywistych adresów. Następnie analizują, jak szeroko te adresy się rozkładają, jak poszczególne bajty każdego adresu zmieniają się z uruchomienia na uruchomienie oraz jak nieprzewidywalny jest ogólny wzór za pomocą miary zwanej entropią. Pozwala to oszacować, jak trudno byłoby atakującemu odgadnąć właściwą lokalizację.

Jak „losowe” jest wystarczająco losowe?

Wyniki pokazują wyraźny kontrast między dużym systemem 64‑bitowym a urządzeniami 32‑bitowymi. W 64‑bitowym Kali Linux adresy są rozproszone niemal równomiernie na szerokim zakresie: większość bajtów w adresie zmienia się znacznie, bardzo niewiele lokalizacji się powtarza, a test statystyczny potwierdza, że wybory wyglądają blisko prawdziwej losowości. Dla atakującego oznacza to ogromną przestrzeń poszukiwań i niewielką szansę na szybkie odgadnięcie właściwego miejsca. W systemach 32‑bitowych, przeciwnie, w praktyce pojawia się tylko niewielki zestaw 256 odrębnych adresów, nawet po zebraniu 100 000 próbek. Kilka bajtów prawie w ogóle się nie zmienia, głównie z powodu ograniczeń architektonicznych i wymogów wyrównania stron pamięci. W praktyce oznacza to, że atakujący może potrzebować zaledwie kilkuset prób — nie milionów czy miliardów — aby trafić w odpowiedni adres.

Atak w praktyce i niewielkie koszty

Aby sprawdzić, czy te różnice mają znaczenie w praktyce, badacze zaimplementowali typ techniki przejęcia sterowania znany jako return‑oriented programming (ROP) na wszystkich trzech systemach. Gdy kluczowa opcja utwardzania o nazwie Position Independent Executable (PIE) jest wyłączona, atak się powodzi: normalny przebieg programu zostaje przekierowany do ukrytych funkcji wybranych przez atakującego. Ale gdy PIE jest włączone, w połączeniu z ASLR, które czyni nawet lokalizację głównego programu ruchomą, atak niezawodnie prowadzi do awarii zamiast przejęcia kontroli — zarówno na wydajnej maszynie 64‑bitowej, jak i na skromnych urządzeniach ARM 32‑bit. Pomiary wykazują również, że włączenie ASLR, ochrony stosu i pamięci nieegzekucyjnej powoduje tylko niewielki narzut w użyciu pamięci i czasie wykonania, rzędu około jednego procenta.

Co to oznacza dla codziennych urządzeń

Badanie konkluduje, że chociaż ASLR na systemach ARM 32‑bit jest matematycznie słabszy i mniej losowy niż na 64‑bitowych komputerach stacjonarnych i serwerach, nadal oferuje ochronę porównywalną do starszych 32‑bitowych pecetów i może skutecznie blokować proste ataki, gdy jest połączony z innymi wbudowanymi zabezpieczeniami. Dla najmniejszych czujników IoT ASLR często jest niemożliwy, ponieważ sprzęt nie posiada niezbędnych cech pamięciowych; tam lepiej sprawdzają się inne techniki, takie jak bezpieczne uruchamianie (secure boot) i lekkie szyfrowanie. Jednak dla urządzeń brzegowych, takich jak routery i płytki klasy Raspberry Pi, włączenie ASLR, PIE i pokrewnych zabezpieczeń jest zarówno praktyczne, jak i warte wysiłku. Przejście tych platform na architektury 64‑bitowe oraz łączenie ASLR z innymi technikami ruchomego celu na poziomie sieci i oprogramowania może znacząco podnieść poprzeczkę dla atakujących próbujących zamienić codzienne przedmioty w broń.

Cytowanie: Gurung, D., Pradhan, M.P. & Gurung, S. Towards understanding the applicability of runtime moving target defense for the internet of things and cyber physical systems. Sci Rep 16, 5907 (2026). https://doi.org/10.1038/s41598-026-36797-4

Słowa kluczowe: obrona ruchomego celu, ASLR, bezpieczeństwo Internetu Rzeczy, systemy cyber‑fizyczne, ataki przepełnienia bufora