bomba logiczna

Bomba logiczna to fragment kodu celowo umieszczony w systemie, który uruchamia szkodliwą funkcję dopiero wtedy, gdy zostaną spełnione określone warunki ^[1]. Do tego czasu program działa normalnie, więc wstawka nie zwraca uwagi. MITRE opisuje ją w katalogu słabości jako CWE-511: kod zaprojektowany do zakłócenia działania produktu albo jego otoczenia po upływie określonego czasu lub po spełnieniu warunku logicznego ^[2]. Bomba logiczna jest rodzajem złośliwego oprogramowania (malware), ale zwykle nie przychodzi z zewnątrz. Najczęściej wstawia ją ktoś, kto ma legalny dostęp do kodu.

Jak działa

Bomba logiczna ma dwie części: wyzwalacz i ładunek. Wyzwalacz to warunek sprawdzany przy każdym uruchomieniu programu. Ładunek (payload) to działanie wykonywane po spełnieniu warunku. MITRE podaje jako typowe wyzwalacze datę i czas systemowy, generator liczb losowych oraz liczniki ^[2].

Po „detonacji” bomba może spowodować odmowę usługi (DoS), na przykład przez awarię systemu, skasowanie ważnych danych albo spowolnienie odpowiedzi ^[2]. MITRE zaznacza też, że bomba może być ukryta w koniu trojańskim, zarówno powielającym się, jak i niepowielającym ^[2].

Cykl życia takiego kodu pokazuje schemat poniżej.

RYS. 1Cykl życia bomby logicznej

Kluczowa cecha to opóźnienie. Między wstawieniem kodu a szkodą mija czas, więc związek przyczynowy trudno odtworzyć. Kod może też wyglądać jak zwykły błąd programu, zwłaszcza gdy ładunek tylko psuje wyniki albo powoduje losowe awarie.

Odmiany

CWE-511 łączy dwa pojęcia: bombę czasową i bombę logiczną ^[2]. Różnią się rodzajem wyzwalacza. Oba należą do szerszej kategorii CWE-506, czyli osadzonego złośliwego kodu, obok konia trojańskiego, zapadni (trapdoor) i oprogramowania szpiegującego ^[3].

Od tylnej furtki (backdoor) bomba różni się celem. Tylna furtka daje dostęp, bomba logiczna ma w określonym momencie wyrządzić szkodę.

Kto ją podkłada

Bomba logiczna to typowe narzędzie osoby z wewnątrz, czyli insidera. CISA definiuje insidera jako każdą osobę, która ma albo miała autoryzowany dostęp do zasobów organizacji lub wiedzę o nich, w tym o sieciach i systemach ^[4]. Zagrożeniem wewnętrznym nazywa możliwość, że taka osoba wykorzysta dostęp albo wiedzę, by zaszkodzić organizacji ^[4].

Wśród form zagrożenia wewnętrznego CISA wymienia sabotaż, a w nim sabotaż cyfrowy: złośliwe działania środkami technicznymi, które mają zakłócić albo zatrzymać normalną działalność organizacji ^[4]. Jako przykład sabotażu podaje między innymi usuwanie kodu, by uniemożliwić normalną pracę ^[4].

Programista, administrator albo wykonawca zewnętrzny ma to, czego brakuje atakującemu z zewnątrz: dostęp do repozytorium, zaufanie i czas. Dlatego bomba logiczna rzadko wymaga wykorzystania podatności. Wystarczy zwykły proces wdrażania kodu.

W WordPressie

Na stronach WordPress ryzyko dotyczy kodu, którego właściciel strony nie pisał i nie przeglądał: wtyczek, motywów i fragmentów dodanych przez wykonawcę. MITRE wskazuje, że przy osadzonym złośliwym kodzie groźny atak może kryć się w jednej lub dwóch zaciemnionych linijkach umieszczonych w dowolnym miejscu aplikacji ^[3]. Zaciemnianie kodu w plikach wtyczki powinno więc budzić ostrożność.

Szczególną uwagę warto zwrócić na:

• piracką wtyczkę (nulled) i fałszywą wtyczkę, których kodu nikt nie weryfikował;
• kod pozostawiony przez byłego wykonawcę, który miał dostęp do serwera;
• atak na łańcuch dostaw (supply chain attack), w którym zmieniona zostaje aktualizacja zaufanej wtyczki.

WordPress ma wbudowany mechanizm zadań zaplanowanych, WP-Cron. Sprawdza on przy każdym wczytaniu strony listę zaplanowanych zadań i uruchamia te, których termin minął ^[7]. To zwykłe narzędzie do kopii zapasowych czy wysyłki wiadomości, ale z tego samego powodu zadanie zaplanowane na konkretną datę może też posłużyć jako wyzwalacz. Dokumentacja zaznacza, że WP-Cron nie działa stale jak systemowy cron, tylko przy wczytaniu strony ^[7]. Zadanie zaplanowane na określoną godzinę wykona się więc przy pierwszym wejściu na stronę po tym czasie.

Jak się bronić

MITRE jako środek zaradczy dla CWE-511 zaleca, by zawsze weryfikować integralność instalowanego produktu ^[2]. Dla osadzonego złośliwego kodu w ogóle zaleca usunięcie go i szczegółowy przegląd całego kodu, by zapobiec kolejnym wstawkom ^[3].

W praktyce przekłada się to na kilka zasad:

• Przegląd kodu przez drugą osobę przed wdrożeniem, także u zaufanych wykonawców.
• Monitorowanie integralności plików, które wykrywa zmiany poza oficjalnym procesem wdrożenia.
• Zasada najmniejszych uprawnień i odbieranie dostępu zaraz po zakończeniu współpracy.
• Wtyczki i motywy tylko z zaufanych źródeł, bez wersji pirackich.
• Kopia zapasowa (backup) przechowywana poza serwerem, bo ładunek często kasuje dane.

Przy podejrzeniu sabotażu przydaje się plan reagowania na incydenty. Trzeba ustalić, kto wprowadził kod i kiedy, zanim zostanie usunięty.

Historia i przykłady

Głośnym przypadkiem była sprawa wykonawcy firmy Siemens, Davida Tinleya. Sekurak w lipcu 2019 roku opisał, że wprowadzał on „bomby logiczne” do arkuszy Excela, z których firma korzystała przy zarządzaniu zamówieniami ^[5]. Po określonej dacie skrypty psuły działanie arkuszy, a Tinley zarabiał na ich naprawianiu ^[5].

Według BleepingComputer działał tak od 2014 roku do 13 maja 2016 roku ^[6]. Kod umieszczony w arkuszach chronionych hasłem miał uruchamiać się po ustalonym czasie i losowo powodować awarie ^[6]. Sprawa wyszła na jaw, gdy Tinley wyjechał i musiał przekazać hasło pracownikom Siemensa, którzy mieli pilny termin ^[6]. W grudniu 2019 roku sąd skazał go na sześć miesięcy więzienia, dwa lata nadzoru i 7500 dolarów grzywny ^[6]. W porozumieniu z prokuraturą stratę ustalono na 42 262,50 dolara ^[6].