Dla przykładu, samoloty F-35 zostały zaprojektowane w taki sposób, by można było regularnie aktualizować systemy pokładowe i dokładać nowe funkcjonalności[1]. Złożoność systemów rodzi pytanie o potencjalne istnienie tylnych furtek (ang. backdoor) w oprogramowaniu samolotów czy innych środków militarnych. Czy dałoby się zdalnie unieruchomić flotę F-35[2] – takie pytanie zadają sobie potencjalni nabywcy tej zaawansowanej technologicznie broni. Marketingowcy i politycy będą zapewniać, że nie, ale gwarancji nikt nie da. Jeśli nawet aktualnie takich furtek nie ma, to mogą pojawić się w przyszłości przy okazji aktualizacji, czy to w wyniku celowego działania twórców czy ataku hakerów.
[1] https://www.defenseone.com/business/2025/03/f-35-get-new-software-summer-theres-no-date-yet-planned-full-upgrade/403536/
[2] https://ottawacitizen.com/news/national/defence-watch/u-s-f-35-fighter-jets-canada
Należy sobie uświadomić, że oprogramowanie może być wykorzystane jako broń (ang. software as a weapon, SaaW[1]), czy też amunicja[2] i to na wiele różnych sposobów, zarówno w scenariuszach defensywnych jak i ofensywnych.
Z jednej strony mamy mechanizmy zdalnej aktualizacji oprogramowania, w szczególności układowego (ang. firmware), mam tu na myśli m.in. mechanizm FOTA albo OTA, z drugiej zaszyte w kodzie warunki graniczne, które zadziałają w określonych okolicznościach, powodując zablokowanie kluczowych funkcjonalności lub wykonanie określonych akcji. Oczywiście wszystkie te mechanizmy mają pozytywne i negatywne zastosowania. Mogą służyć do ochrony przed zagrożeniami, ale także do siania chaosu czy zniszczenia.
Za przykład pozytywnego wykorzystania mechanizmu FOTA w celu zwiększenia poziomu bezpieczeństwa może służyć zdalne zwiększenie zasięgu samochodów elektrycznych, kiedy w 2017 roku nad Florydę nadciągał huragan Irma[3]. Natomiast warunki logiczne w kodzie chronią interesy licencjodawców w modelach subskrypcyjnych czy filtrują dane chroniąc przed wyciekiem informacji.
Afera z naszego krajowego podwórka, dotycząca pociągów „stających w szczerym polu”, potocznie zwana „aferą Impulsową” pokazuje, że warunki w kodzie można wykorzystać do mniej szlachetnych celów. Implementacja warunków powodujących unieruchomienie środków transportu, kiedy trafią one w określoną lokalizację lub osiągną określony przebieg[4], nie stanowi większego problemu. Podobne „zabezpieczenia”, zwłaszcza te oparte na pozycji geograficznej, można by wprowadzić w oprogramowaniu pojazdów militarnych czy innych środków bojowych.
Czasem oprogramowanie pod przykrywką sprawdzania aktualizacji czy telemetrii wysyła nadspodziewanie dużo danych, do których w ogóle nie powinno mieć dostępu. Świetnym przykładem jest tu transfer danych do Chin dokonywany przez oprogramowanie Adups FOTA preinstalowane kilka lat temu (w 2016 roku) na wielu modelach telefonów z niższej półki[1]. Oprogramowanie to wysyłało na zdalne serwery m.in. zawartość SMS-ów (sic!).
Powody do myślenia daje także „wpadka” z wadliwą aktualizacją oprogramowania CrowdStirke Falcon, która spowodowała 19 lipca 2024 roku awarię systemów Windows na wielką skalę, dotykając milionów systemów, w tym wielu systemów zlokalizowanych w portach lotniczych[2]. A co, gdyby taką wadliwą aktualizację „wypuścił” specjalnie, a nie przypadkiem producent popularnego systemu operacyjnego lub inny duży dostawca, np. na zlecenie pewnego rządu? Ile systemów stałoby się czasowo bezużytecznych? Notabene, niecelowe wypuszczanie niedopracowanych aktualizacji zdarza się producentom dość często – w przypadku giganta z Redmond najświeższy taki przypadek to aktualizacje z marca br.[3] Przypadek SolarWinds, jednego z większych dostawców oprogramowania do monitorowania i zarządzania infrastrukturą, pokazuje skuteczność ataków przez infiltracje producentów oprogramowania. Atakującym udało się przeniknąć do sieci organizacji i wstrzyknąć złośliwy fragment kodu (Sunburst) do oprogramowania monitorującego Orion. Oprogramowanie z wstrzykniętym dodatkiem zostało następnie wysłane do klientów razem z innymi aktualizacjami. Efekt, około 18000 klientów (w tym dużych firm) zostało zainfekowanych – uzyskano dostęp do ich infrastruktury[4].
Atak z zastosowaniem socjotechnik próbowano przeprowadzić również na popularną bibliotekę otwartoźródłową XZ. Infiltracja się powiodła, ale sam atak został udaremniony przez dociekliwego testera oprogramowania zaintrygowanego spadkiem wydajności w nowej wersji systemu. Osoby przeprowadzające atak długo pracowały nad tym by zdobyć zaufanie niezbędne do zrealizowania planu, czyli wstrzyknięcia kodu, który modyfikował zachowanie demona SSH (który pośrednio wykorzystuje biblioteki XZ)[5]. Gdyby plan udało się zrealizować, to atakujący za pomocą predefiniowanych poświadczeń uzyskali by zdalny dostęp do milionów serwerów na całym świecie.
Oprogramowanie jako broń sensu stricto, w walce z mniej lub bardzie sprecyzowanym wrogiem wykorzystują agencje rządów różnych krajów, np. eksploit EternalBlue[6] opracowała NSA w USA – ten kod został niestety przechwycony przez hakerów i wykorzystany do stworzenia m.in. WannaCry[7] (szczególnie popularnego w brytyjskich szpitalach). Kolejny głośny przykład Stuxnet (znany z uszkodzenia Irańskich wirówek przemysłowych) to podobno wspólne dzieło USA i Izraela[8]. Natomiast autorstwo stosunkowo świeżego oprogramowania Hatvibe i Cherryspy przypisuje się agencjom rosyjskim[9]. Oprogramowanie to było wykorzystywane m.in. do szpiegowania dyplomatów z Azji Centralnej. Przy okazji szpiegowania warto wspomnieć broń (wg. legislacji Izraela) jaką jest oprogramowanie Pegasus produkowane przez prywatną firmę NSO – jego sprzedaż jest objęta restrykcjami eksportowymi[10].
Współcześnie wykorzystywane oprogramowanie jest pełne błędów i niedociągnięć, które są sukcesywnie odkrywane i łatane. Część z tych odkrywanych błędów może być wynikiem celowego działania agencji wywiadowczych lub grup cyberprzestępczych. W wielu sytuacjach nie da się jednoznacznie określić czy luka w kodzie była celowym zabiegiem czy tylko zwykłym błędem. Zwykle zaczynamy się nad tym zastanawiać dopiero w sytuacji, kiedy odkrywane są ataki z użyciem nieznanych powszechnie podatności.
Przyzwyczailiśmy się już do ciągłych aktualizacji i nie zastanawiamy się czy i dlaczego są one konieczne. Ufamy dostawcom. To zaufanie nie powinno być jednak bezgraniczne, zwłaszcza w przypadku krytycznych systemów. Aktualizacje przed zainstalowaniem w krytycznych systemach produkcyjnych powinny zostać odpowiednio przetestowane i zweryfikowane. Warto też mieć „plan b”, czyli np. możliwość przywrócenia systemu do stanu pierwotnego.
Pamiętajmy, że aktualizacje są bronią defensywną chroniącą przed nowo odkrywanymi zagrożeniami, ale same też mogą być źródłem zagrożenia i mogą zostać wykorzystane jako broń ofensywna w celu zakłócenia działania systemów lub infiltracji organizacji.
Aktualizujmy systemy, ale rozsądnie. Wybierając wdrażane rozwiązania sprawdzajmy dostawców i ich powiązania.
[1] https://zaufanatrzeciastrona.pl/post/popularne-chinskie-telefony-przylapane-na-wysylaniu-smsow-i-kontaktow-do-chin/
[2] https://testerzy.pl/news/flash/nowa-najwieksza-w-historii-globalna-awaria-it
[3] https://www.windowslatest.com/2025/03/13/windows-11-kb5053598-issues-install-fails-rdp-disconnects-bsods-windows-11-24h2/
[4] https://www.fortinet.com/resources/cyberglossary/solarwinds-cyber-attack
[5] https://www.wired.com/story/xz-backdoor-everything-you-need-to-know/
[6] https://pl.wikipedia.org/wiki/EternalBlue
[7] https://cert.pl/posts/2017/05/wannacry-ransomware/
[8] https://foreignpolicy.com/2016/10/17/obamas-general-pleads-guilty-to-leaking-stuxnet-operation/
[9] https://votiro.com/blog/browser-security-understanding-malware-like-hatvibe-and-cherryspy/
[10] https://en.wikipedia.org/wiki/NSO_Group
[1] https://link.springer.com/chapter/10.1007/978-3-662-56672-5_4
[2] https://blog.lukaszolejnik.com/software-as-munitions-including-offensive-tools/
[3] https://www.theverge.com/2017/9/10/16283330/tesla-hurricane-irma-update-florida-extend-range-model-s-x-60-60d
[4] https://cyberdefence24.pl/cyberbezpieczenstwo/za-nami-rok-blokad-w-pociagach-newagu-co-dzis-wiemy
Maciej Miłostan