Wielka grecka afera podsłuchowa – część trzecia

Oprogramowanie, umieszczone w centralach przez przestępców oraz użyte do podsłuchiwania rozmów,  było zdaniem wielu ekspertów majstersztykiem. Jak zostało stworzone? W jaki sposób działało? A przede wszystkim, jak mogło zostać zainstalowane?

Czytasz trzecią część artykułu. Jeśli jeszcze nie znasz części pierwszej oraz drugiej, polecamy lekturę.

Piszesz w PLEXie?

Wróćmy na chwilę do centrali AXE. Co wiemy o nieautoryzowanym oprogramowaniu, które się w niej znalazło? Zacznijmy od tego, że pisanie oprogramowania na centrale Ericssona nie należy do zadań trywialnych. Wymaga ono nie tylko dostępu do identycznej centrali wraz z całym środowiskiem testowym, którego koszty są ogromne, ale także znajomości języka PLEX. Ja możecie się domyśleć, liczba programistów PLEXa jest dość ograniczona – język ten używany jest jedynie do programowania central tego producenta.

Łatanie programu w locie

Program, który realizował podsłuchy, musiał spełniać wiele funkcji. Po pierwsze, musiał działać cały czas, umożliwiając zarówno przekierowywanie rozmów jak i modyfikację swoich parametrów na wypadek takiej konieczności. Po drugie musiał ukrywać wykonywane operacje, w szczególności zapobiegać rejestrowaniu ich w logach systemowych. Po trzecie, musiał perfekcyjnie ukrywać się przed administratorami zarówno Vodafone’a jak i Ericssona. Po czwarte jego instalacja nie mogła przerwać pracy centrali. Jak osiągnięto te cele? Przede wszystkim złośliwy program perfekcyjnie wykorzystał mechanizmy stworzone przez Ericssona dla zapewnienia ciągłości pracy centrali.

Centrale AXE zostały skonstruowane w taki sposób, by umożliwić modyfikację oprogramowania bez konieczności restartu urządzenia. Ich kod podzielony został na niezależne bloki, przechowywane w pamięci centralnego procesora. Wersja oprogramowania z roku 2004 korzystała z ok. 1760 takich bloków. Każdy blok posiada specjalny obszar, przeznaczony na poprawki w kodzie. Działanie kodu modyfikowane jest poprzez załadowanie nowego kodu do tego specjalnego obszaru oraz zmianę odpowiedniego odwołania, by wykonywany był nowy kod. Autorzy nielegalnego oprogramowania zmodyfikowali w ten sposób 29 bloków oryginalnego oprogramowania. Dodatkowo zarezerwowali część pamięci centrali, ukrywając ją przed pozostałymi procesami i przechowywali tam listy numerów, objętych podsłuchem.

Nie ma to jak dobry rootkit

Aby ukryć wprowadzone modyfikacje, oprogramowanie działało jak tradycyjny rootkit. Zmodyfikowało między innymi polecenie wyświetlające listę aktywnych procesów centrali tak, by ukryć swoje wątki. Mogło także zostać wykryte w trakcie aktualizacji oprogramowania – standardową procedurą jest w takich przypadkach weryfikacja sum kontrolnych poszczególnych bloków. Prawdopodobnie również ta funkcja została zmodyfikowana, by ukryć obecność nieautoryzowanego kodu. Oczywiście oprogramowanie zawierało również sprytną tylną furtkę, umożliwiającą jego autorom łatwy późniejszy dostęp do systemu. Wystarczyło wpisać dowolne polecenie systemowe i zakończyć je sześcioma spacjami, by rootkit dezaktywował logi systemowe i związane z tym alarmy oraz udostępniał możliwość zarządzania nielegalnymi podsłuchami. Prawdopodobnie był to pierwszy w historii rootkit, dedykowany dla konkretnego urządzenia.

Kiedy 24. stycznia 2005 nieudana aktualizacja oprogramowania szpiegującego spowodowała problemy z doręczaniem wiadomości SMS na jednej z zainfekowanych central, specjaliści Ericssona poprosili o wykonywane okresowo zrzuty pamięci urządzenia. Dopiero analizując je poza urządzeniem natrafili najpierw na listę podsłuchiwanych numerów, a później na skompilowany kod, którego przeznaczenia wtedy jeszcze nie znali. Pracochłonna rekonstrukcja programu, stworzonego w języku PLEX, wskazała, że miał on ok. 6500 linii kodu i był bez wątpienia owocem pracy wysokiej klasy fachowców. Analiza historycznych zrzutów pamięci centrali pozwoliła na ustalenie przebiegu zdarzeń oraz pełnej listy podsłuchiwanych numerów.

Kto to napisał i zainstalował?

Kto mógł stworzyć tak złożony program w tak egzotycznym języku? Tak się ciekawie składa, że w Grecji od kilkunastu lat tworzona była spora część oprogramowania Ericssona. Zajmowała się tym spółka Intracom Telecom. Program mógł być stworzony przez jej obecnych lub byłych pracowników.

W jaki sposób mogło dojść do włamania? Odpowiedzi na to pierwsze pytanie niestety nie znamy – mamy za to dwie podstawowe teorie. Jedna z nich zakłada udział personelu Ericssona w instalacji nieautoryzowanego oprogramowania – rzekomo tylko trzech pracowników tej firmy znało hasła dostępu niezbędne, by zainstalować poprawki do modułu podsłuchowego. Druga sugeruje, że w centralach Ericssona istniały (lub nadal istnieją) tylne furtki, umieszczane w kodzie w celach serwisowych. W sieci można znaleźć informacje mówiące, że furtka istniała w kodzie demona telnetd i wystarczyło nadać jednej ze zmiennych systemowych odpowiednią wartość, by przy próbie połączenia z centralą otrzymać uprawnienia roota. Bez wątpienia instalacji oprogramowania musiał dokonać ktoś, kto posiadał fizyczny dostęp do wszystkich czterech zainfekowanych central.

Dlaczego śledztwo w tej sprawie prowadzono nieudolnie? Gdzie zniknęły dowody? Kim mogli być sprawcy? Odpowiedzi na te pytania znajdziecie w ostatnim odcinku historii już jutro o 20:00.