20. maja 2013 w Sztokholmie zaczął się proces Gottfrida Svartholma, znanego jako anakata, współzałożyciela TPB. Nie jest on jednak oskarżony o naruszanie prawa autorskiego, a o poważne włamania. Co zarzucają mu śledczy oraz jak policja natrafiła na jego trop?
Obciążony procesor symptomem problemów
3. marca 2012 administratorzy szwedzkiego oddziału firmy Logica, międzynarodowego dostawcy usług informatycznych, zauważyli zwiększone obciążenie procesora maszyny klasy mainframe, zarządzanej przez ich firmę. Obciążenie było większe, niż zwykłe, ale nie alarmujące. Bez zbytniego pośpiechu przystąpili do analizy zjawiska. Już 6. marca zauważyli, że obciążenie procesora powoduje konto pracownika jednego z klientów Logica. Wykonywało ono ok. 1600 transakcji na godzinę – ilość niemożliwą do wygenerowania przez zwykłego użytkownika. Kiedy przyjrzeli się bliżej temu zbyt aktywnemu kontu, odkryli również, że wykonywało podejrzane operacje wyszukiwania. Sam posiadacz konta nie miał pojęcia o zauważonej aktywności. Odkryto także liczne transakcje FTP, bardzo rzadko używane przez tego klienta oraz tajemnicze połączenia z użyciem protokołu telnet, zazwyczaj nie wykorzystywanego przez tę maszynę.
Baza, w której jest wszystko
Konto, od którego zaczęło się śledztwo, należało do sprzedawcy firmy Applicate, świadczącej dla odmiany usługi serwisowi InfoTorg, największej bazie informacji o szwedzkich obywatelach. Można w niej znaleźć dane osób fizycznych, ich informacje podatkowe, dane o ich dochodzie, stanie cywilnym, zaległości płatnicze a także zapisy dotyczące własności nieruchomości czy pojazdów mechanicznych czy też np. prawa jazdy. System przechowuje również wszystkie informacje dotyczące szwedzkich podmiotów gospodarczych. Takie połączenie baz PESEL, REGON, CEPIK, KRS, BIG/BIK, NIP oraz ksiąg wieczystych – jak widać, jest to możliwe. Applicate świadczy także usługi i obsługuje bazy danych urzędu skarbowego oraz urzędu komorniczego.
Jak namierzyć użytkownika cudzego WiFi
Po dwóch tygodniach wewnętrznego dochodzenia, prowadzonego przy wsparciu producenta mainframe’a, IBMa, Logica poinformowała o włamaniu policję. Organa ścigania podeszły do sprawy poważnie, powołując 40-sobową grupę śledczą. Posiadając liczne logi dostępowe, śledczy rozpoczęli próby zlokalizowania włamywaczy. Adresy IP, z których nawiązywano połączenia z serwerem, rozsiane były po całym świecie. Pięć z nich było jednak zlokalizowanych w jednej dzielnicy małego, szwedzkiego miasteczka Ludvika, w promieniu 100m.
Namierzenie użytkownika, który włamywał się do sieci sąsiadów, okazało się dość proste. Włamywacze, mając dostęp do bazy danych wszystkich Szwedów, nie oparli się pokusie zapytania o samych siebie. W okolicy przedstawionej na powyższej mapce mieszkała tylko jedna osoba, która znała się na komputerach i jednocześnie była obiektem zainteresowania włamywaczy.
Skarby znalezione w chmurach
Podejrzany, znany pod inicjałami MG, został zatrzymany, a wszystkie jego nośniki elektroniczne poddane wnikliwej analizie. Na jego telefonie komórkowym znaleziono aplikację portalu InfoTorg, niedostępną dla klientów indywidualnych, z zapamiętanym loginem konta, które nie należało do niego. Ciekawym znaleziskiem okazała się także karta SD, na której w ścieżce /u1/Ubuntu One/Linux/Hacking/ znaleziono narzędzia do łamania zabezpieczeń sieci WiFi oraz dane sieci, które zostały wykorzystane do włamania do serwera Logica. W historii przeglądarki znaleziono także dane konta na serwerze FTP oraz usługi backupu w chmurze, Ubuntu One – w obu lokalizacjach znajdowało się sporo plików interesujących z punktu widzenia organów ścigania. Na podstawie odzyskanych informacji ustalono, że MG posługuje się w sieci nickiem diROX oraz adresem email [email protected]. Na serwerze Ubuntu One odnaleziono także zrzut ekranu, na którym widać, jak będąc zalogowanym do konta na Gmailu, diROX jednocześnie przegląda dane z bazy InfoTorg.
To wszystko były jednak poszlaki – w przeciwieństwie do dużej ilości danych, skradzionych z serwerów Logica, a odnalezionych na komputerze diROXa oraz śladów wskazujących na to, że dostęp do serwerów Logica posiadał już w roku 2010. Znaleziono także, bardzo ważne w późniejszym śledztwie, logi z kanału irc #hack.se (EFNet), na którym diROX rozmawiał z użytkownikiem, ukrywającym się pod pseudonimem tLt.
Wielokrotne przesłuchania skutkują
W połowie kwietnia zaczęły się przesłuchania diROXa. Ich streszczenia pokazują, że początkowo nie przyznawał się nawet do posiadania dużej wiedzy na temat komputerów. Po kilku dniach potwierdził, że w ciągu ostatniego tygodnia logował się do serwisu InfoTorg, do którego loginy i hasła znalazł gdzieś w sieci. Miesiąc później przyznał się, że dostęp do serwerów firmy miał od 2 lat, natomiast ciągle zaprzeczał, jakoby posiadał kiedykolwiek kartę SD lub konto backupu w chmurze. Nie pamiętał także nicka, którego używał na ircu. Śledczy wykorzystują wtedy swojego jokera – zeznania innego podejrzanego, który potwierdził, że MG to diROX oraz że diROX przekazał mu dane, pochodzące z włamania. Już w czerwcu diROX przypomniał sobie swój nick i przyznał się do włamywania się do sieci WiFi. Dopiero podczas październikowego przesłuchania śledczy ujawnili, że odnaleźli w plikach diROXa logi z kanału irc, gdzie rozmawia z użytkownikiem tLt o włamaniu do serwera Logica. diROX potwierdził, że tLt to nikt inny, jak Gottfrid Svartholm, anakata, założyciel The Pirate Bay.
Przebieg włamania
Wiemy już, że włamywacze uzyskali dostęp do serwera mainframe, na którym przetwarzane były ogromne ilości danych obywateli Szwecji. Jak jednak doszło do włamania? Do czego służyło narzędzie o bardzo swojsko brzmiącej nazwie?
Mimo, iż spędziliśmy już wiele godzin nad raportami z analizy powłamaniowej tego incydentu, ciągle sporo wydarzeń jest dla nas nie do końca jasnych. Niestety duża część dokumentacji jest dostępna wyłącznie po szwedzku, raport angielskojęzyczny jest bardzo chaotyczny, a do tego w ogóle nie znamy się na mainframe’ach i systemie z/OS. Postaramy się jednak opisać to, co udało nam się zrozumieć. Oprócz dokumentów procesowych opublikowanych przez Wikileaks (najciekawsze to raport z włamania po angielsku i szczegóły analizy nośników oskarżonych, niestety ponad 700 stron po szwedzku), bardzo cenne dla zrozumienia sytuacji są również artykuły z serwisu gnrq, prowadzonego przez przyjaciela anakaty.
Od czego wszystko się zaczęło
Początki włamania do serwera mainframe firmy Logica toną w mrokach dziejów. Z danych, przejętych przez policję na nośnikach należących do diROXa, wynika, że posiadał on dostęp do niektórych systemów firmy już w roku 2010. 29 stycznia 2010 zanotowano na skutek błędnej konfiguracji (domyślne konta) nieautoryzowany dostęp do serwera mainframe przy użyciu protokołu FTP. Nieznany użytkownik pobrał z serwera duże ilości danych, w tym udało mu się również uzyskać dostęp do częściowej listy kont w systemie. Konfiguracja serwera została poprawiona. Niestety brak dalszych szczegółów z tamtego okresu, a wszystkie dostępne raporty opisują dopiero włamanie, które miało miejsce w lutym 2012.
Szwedzki parlament również ofiarą włamywaczy?
Pierwsze zidentyfikowane nieautoryzowane logowanie FTP do systemów Logica w w 2012 roku miało miejsce 25. lutego, przy użyciu loginu i hasła konta AVIY356, wykorzystywanego przez szwedzki parlament. Do tej pory nie wyjaśniono, skąd atakujący miał dostęp do danych konta, wykorzystywanego do automatycznych transferów plików. W sieci krążą informacje, że włamywacze posiadali od kilku lat dostęp do systemów najważniejszych organów szwedzkiego państwa, jednak brak na to jakichkolwiek dowodów.
Jak postawić mainframe’a w domu
Niestety nie potrafiliśmy znaleźć szczegółowych informacji, jakie kroki wykonali włamywacze, by uzyskać wyższe uprawnienia w systemie. Na pewno wykorzystali jednak jeden lub więcej błędów typu 0day. Prawdopodobnie w celu ich odnalezienia i przetestowania wykorzystali Herculesa, emulator systemów klasy mainframe, na którym uruchomili system z/OS. Aby odtworzyć atakowane środowisko, wykonali kopie i pobrali z serwerów wiele plików systemowych i konfiguracyjnych.
Według różnych źródeł włamywaczom udało się odnaleźć (i wykorzystać) co najmniej 2 nieznane wcześniej błędy pozwalające na podniesienie uprawnień w systemie. Jeden z nich to błąd w serwerze HTTP IBMa, a drugi to błąd w pliku CNMEUNIX, który w domyślnej konfiguracji posiada uprawnienia SUID 0 (co oznacza, że wykorzystując zawarte w nim błędy można wykonywać polecenia z uprawnieniami administratora systemu). W tym drugim przypadku co prawda dokumentacja producenta mówi wprost, że nie ma żadnego powodu, dla którego plik ten potrzebowałby takich uprawnień, ale mimo to posiada je w domyślnej konfiguracji. Jak wyglądało samo łączenie się do zdalnego serwera i uzyskiwanie uprawnień roota? Anakata (występujący pod nickiem tLt) pochwalił się tym koledze na ircu.
<tlt> port 443: listening. <tLt> waiting for the APTback<TM>... <tLt> alert!!! advancing port 443 threat! <tLt> accepted persistent tcp connection from 93.186.170.54:26773 <tLt> $APTM1337 ENTERING ADVANCED PRINTER/TYPEWRITER MODE <tLt> pwd <tLt> uname -a ; id <tLt> 0S/390 SYS19 22.00 03 2817 <tLt> uid=2147483647(BPXDFLTU) gid=548400(E484) <tLt> chmod 755 /tmp/duku <tLt> l3tz g3t us s0m3 0f d4t r00t!@# <tLt> eu: 0 u: 0 g: 0 <tLt> g0t r00t ? <tLt> id <tLt> uid=0(SUPERUSR) gid=0(STCGROUP) groups=548400(E484)
Skoro już mamy uprawnienia…
Z raportów śledczych wynika, że jednym z najcenniejszych zasobów systemowych, do których dostali się włamywacze, był program RACF (Resource Access Control Facility), używany w systemie z/OS do uwierzytelnienia i zarządzania uprawnieniami użytkowników. Baza ta zawiera między innymi nazwy użytkowników oraz ich zahaszowane hasła. W bazie znajdowało się ok. 120 tysięcy kont użytkowników.
Złamanie haseł użytkowników na pewno nie było trudnym zadaniem. Po pierwsze, w bazie RACF przechowywane są dane kont TSO (shella na z/OS), a TSO dopuszcza nazwy użytkownika o długości maksymalnej 7 znaków, a maksymalna długość hasła to 8 znaków. Do tego większość implementacji dopuszcza w treści hasła jedynie litery, cyfry i 3 znaki specjalne: #, @, $.
Algorytm tworzenia hasza hasła wygląda następująco: po podaniu hasła jest ono uzupełnianie (w razie takiej konieczności) spacjami do długości 8 znaków. Następnie każdy znak jest XORowany przez wartość ox55 a następnie przesunięty o 1 bit w lewo. Następnie identyfikator użytkownika (pełniący tu rolę soli) jest szyfrowany z użyciem algorytmu DES, gdzie kluczem jest zmodyfikowane hasło.
Ustalenie algorytmu oraz stworzenie odpowiedniego modułu zajęło programistom popularnego narzędzia John the Ripper kilkanaście dni – obecnie program ten świetnie radzi sobie z hashami z bazy RACF. Powstało także narzędzie racf2john.c, które przekształca plik wyeksportowanej bazy w dane wejściowe, czytelne dla JtR. Modyfikacja ta została użyta przez włamywaczy do uzyskania dostępu do ogromnej liczby kont w systemie. Co ciekawe, na liście dyskusyjnej PaulDotCom pytanie o hashe RACF pojawiło się 28go lutego 2012, a na liście Johna The Rippera 3go marca 2012 – co za zbieg okoliczności…
W trakcie śledztwa przeprowadzono test stopnia złożoności haseł użytkowników. W ciągu kilku dni, na zwykłym komputerze klasy PC, złamano hasła 30,000 ze 120,000 użytkowników. W późniejszej fazie ataku, oprócz wykorzystywania kont, do których hasła udało się włamywaczom złamać, manipulowali oni również uprawnieniami użytkowników w bazie RACF, nadając szerokie uprawnienia kontom, z których korzystali w celu dalszej penetracji systemu.
Na wszelki wypadek dodajmy kilka backdoorów
W teorii, by zapewnić sobie dostęp do cudzego systemu, wystarczy jeden dobrze ukryty backdoor. Każdy kolejny zwiększa ryzyko wykrycia nieautoryzowanych działań, jednak zwiększa także szansę, że po usunięciu jednej furtki, druga nadal będzie działać. W systemie Logica odkryto kilka różnych backdoorów, w tym także dość trywialnych.
Najbardziej zaawansowany był program, nazwany najpierw a.env a następnie, by lepiej ukryć go w środowisku z/OS, CSQXDISP, który nawiązywał sesję z predefiniowanym komputerem poza siecią firmy (na porcie 443, by wyglądać jeszcze bardziej niewinnie) i oczekiwał tam na połączenie przychodzące z dedykowanego klienta (o znamiennej nazwie aptcli). Dzięki połączeniu przez dodatkowy serwer ukrywał on również adres IP prawdziwego użytkownika.
Drugi i trzeci backdoor opisany w raporcie były dużo prostsze. Poniższe rzuty ekranu mówią same za siebie.
Jeden z najstarszych backdoorów świata, czyli dodatkowy wpis w pliku inetd.conf, zapewniający uruchomienie powłoki po połączeniu na port 443.
Dopisanie własnego klucza do listy kluczy akceptowanych w ramach połączenia SSH, umożliwiające zdalne logowanie bez podawania hasła, jedynie w oparciu o klucz.
Co na dysku robi „kurwa”?
W trakcie analizy zaatakowanego serwera odnaleziono wiele narzędzi, pozostawionych przez włamywaczy. Zdumiewa różnorodność języków programowania, w których były one stworzone. Na dyskach znalazły się nieznane wcześniej programy napisane w C, HLASM (assembler na platformę m.in. z/OS), REXX (zbliżony do Perla) oraz JCL. Oznacza to, że albo włamywacz był geniuszem, dla którego programowanie w kilku językach na mało popularnej platformie nie stanowi dużego wyzwania, albo administratorem z/OS, albo we włamaniu wzięło udział więcej osób. Jeśli chcecie spojrzeć na kod źródłowy narzędzi włamywaczy, to jeden z internautów zebrał wszystkie ujawnione fragmenty kodu na GitHubie.
Jednym z najciekawszych naszych odkryć w czasie lektury raportu był jeden z programów w REXXie. Spójrzcie na fragment raportu.
Tak, program nazywa się po prostu „kurwa”. Choć podobnie brzmiące słowo istnieje w kilku językach, to pisownia nie pozostawia wiele wątpliwości. Pozostałe nazwy używanych narzędzi wyglądają na losowe lub opisujące ich funkcje (np. go, enum, kuku, duqu, qwe, bes). „Kurwa” jest jedyną nazwą na pierwszy rzut oka pochodzącą z innego języka niż angielski. Sam program służył zapewne do podniesienia uprawnień użytkownika przy założeniu, że można go było uruchomić z bitem SUID i uprawnieniami administratora. Czy narzędzie stworzył jakiś Polak? Czy jeden z włamywaczy znał język polski albo przynajmniej jego podstawy (nawet zredukowane do jednego słowa)? Na te pytania pewnie nie poznamy odpowiedzi.
Błędy anakaty
Jak policja dowiedziała się, że za włamaniem do mainframe’a dużej szwedzkiej firmy stoi jeden z założycieli The Pirate Bay? Jakie błędy popełnił włamywacz i jakie pozostawił po sobie ślady? Na jakiej podstawie skonstruowano akt oskarżenia?
Wpadka kolegi na dobry początek
Wszystko zaczęło się od wpadki diROXa, opisywanej w pierwszym odcinku historii. Korzystał on z sieci WiFi blisko swojego miejsca zamieszkania, a wrażliwe dane przechowywał w chmurze, do której login i hasło zapamiętał w przeglądarce. Policja wśród jego plików znalazła logi z kanału #hack.se, na którym rozmawiał o technicznych szczegółach włamania z użytkownikiem, kryjącym się pod pseudonimem tLt. diROX w trakcie przesłuchań sam przyznał, że był to anakata, a wśród jego plików policja znalazła nawet skan kambodżańskiego prawa jazdy anakaty.
„Porwanie” z Kambodży
Anakata był na celowniku organów ścigania już od wielu lat. W 2009 roku został skazany na rok więzienia oraz pokaźną grzywnę w związku z działalnością serwisu The Pirate Bay. Nie czekając na wyrok, wyjechał do Kambodży, która nie posiada umowy o ekstradycji ze Szwecją. 30. sierpnia 2012 został niespodziewanie aresztowany przez lokalne organa ścigania a po kilku dniach deportowany do Szwecji. Jego zatrzymanie oraz deportacja były przedmiotem wielu kontrowersji. Choć jego kambodżańska wiza wygasła kilkanaście dni wcześniej i władze Kambodży miały podstawy, by go deportować, to odmówiono mu zarówno dostępu do pomocy prawnej jak i prawa wyboru kraju, do którego zostanie deportowany. Według niektórych teorii wiąże się to z 50 mln USD pomocy finansowej „na rozwój kambodżańskiej demokracji”, przekazanymi przez Szwecję w pierwszych dniach września (podobne darowizny Szwecja przekazywała Kambodży w poprzednich latach, jednak w wysokości bliższej 30 mln USD).
Zatrzymanie i deportacja anakaty od początku nie miały oficjalnie nic wspólnego z jego działalnością w The Pirate Bay. Dokumentacja, przedstawiona przez szwedzkie władze, wskazywała na poważne zarzuty dotyczące włamania do serwerów w Szwecji. Wraz z anakatą Szwedom przekazano również jego komputery, dyski, telefony i nośniki USB. Materiały te okazały się być prawdziwą skrzynią skarbów z punktu widzenia śledczych – ale o tym za chwilę.
Cała kolekcja poszlak
Zanim w ręce szwedzkich śledczych wpadły dyski anakaty, dysponowali oni już całkiem pokaźnym zbiorem poszlak wskazujących, że może on być sprawcą włamań, które analizowali. Pierwszym tropem były liczne połączenia do serwera firmy Logica, do którego nastąpiło włamanie, z adresów IP należących do kambodżańskiego operatora telekomunikacyjnego Cogetel Online, działającego w Phnom Penh, gdzie mieszkał anakata. Jak wykazało późniejsze śledztwo, choć trudno w to uwierzyć, anakata czasem logował się do zhakowanego serwera, korzystając ze swojego prywatnego łącza internetowego.
Drugą wskazówką dla śledczych było konto Monique Wadstedt, do którego uzyskali nieautoryzowany dostęp i za jego pomocą sprawcy włamania przeprowadzali większość interesujących wyszukiwań w systemie InfoTorg, . Osoba ta okazała się być prawniczką znaną z tego, że w trakcie procesu The Pirate Bay reprezentowała amerykański przemysł rozrywkowy.
Trzecią wskazówką był fakt, że w systemie InfoTorg wyszukiwano między innymi informacje dotyczące samego anakaty. Oczywiście mógł to być zbieg okoliczności, jednak wraz z pozostałymi przesłankami tworzył logiczną całość.
Oprócz tych poszlak, policja miała oczywiście jeden z najważniejszych dowodów, czyli logi kanału #hack.se, na którym anakata pokazywał, że posiada dostęp do serwera mainframe oraz zeznania dwóch innych bywalców kanału potwierdzające, że od anakaty właśnie otrzymali loginy i hasła dostępu do systemu InfoTorg. Wszystkie te dowody były jednak niczym wobec informacji, które znaleziono w Kambodży.
Z TrueCrypta trzeba umieć korzystać
W dokumentach śledztwa najważniejsze są materiały, znalezione na MacBooku należącym do anakaty. MacBook miał zainstalowane dwa systemy operacyjne – OS X oraz Windows 7. O ile pierwszy nie zawierał żadnych interesujących z punktu widzenia śledczych danych, o tyle na drugim znaleziono plik \Users\a\tc\t001a, który okazał się być wolumenem TrueCrypta o pojemności 16GB, pełnym dowodów, które mogą wysłać jego właściciela na kilka lat za kratki.
Na pewno od razu zadacie pytanie – jak śledczy dostali się do wolumentu TrueCrypta? Niestety w materiałach śledztwa nie natrafiliśmy na odpowiedź wprost na to pytanie, zatem możemy jedynie przedstawić Wam prawdopodobny scenariusz wydarzeń. Anakata w trakcie przesłuchań do tej pory na większość pytań śledczych odmawiał odpowiedzi, więc nie sądzimy, że podał im hasło do dysku. Mało prawdopodobne także wydaje się nam, by korzystał ze słabego hasła lub zapisał je na żółtej karteczce przyklejonej w szufladzie biurka. Pewną wskazówką jest fragment przesłuchania, gdzie anakata najpierw informuje, że nic wie o pliku t001a o rozmiarze 16GB, a śledczy pytają, czemu w takim razie w trakcie uruchamiania systemu automatycznie podłączany jest właśnie ten wolumen. Nie sądzimy, że anakata stworzył wolumen bez hasła, ale bardzo możliwe jest, że w trakcie zatrzymania komputer był włączony lub w stanie hibernacji, dzięki czemu śledczym udało się odzyskać klucze szyfrujące z pamięci RAM lub pliku hibernacji. Czemu anakata mógł nie wyłączać komputera? Zapewne nie spodziewał się, że śledczy, potrafiący zabezpieczać sprzęt komputerowy, pojawią się w Phnom Penh (prawdopodobnie wśród osób go zatrzymujących mogli być szwedzcy funkcjonariusze – szedzka policja prosila o to swoich kambodżańskich odpowiedników). Pewną wskazówką jest także fragment pisma (str. 168), wysłanego przez szwedzkie władze z prośbą o zatrzymanie anakaty:
Jest bardzo ważne, aby przejmowane komputery, telefony oraz inne urządzenia techniczne nie były wyłączane. Ich wyłączenie może znacząco ograniczyć możliwość odnalezienia ważnych informacji.
Skąd wiadomo, że tLt z irca to anakata?
Oprócz zeznań diROXa, który zidentyfikował tLt jako anakatę, śledczy natrafili na inny dowód potwierdzający tożsamość włamywacza.
tLt sam przyznaje na prywatnym czacie ze znajomy, że w jego komputerze wypadły klawisze „O” oraz strzałka w dół – co policja szybko łączy z MacBookiem oskarżonego, w którym brakuje między innymi tych własnie dwóch klawiszy.
Co zeznaje anakata
Powyższy fragment czatu stoi w sprzeczności z zeznaniami anakaty. Oprócz odrzucania wszystkich oskarżeń twierdzi on, że MacBooka w ogóle nie używał osobiście, ponieważ pełnił on funkcję serwera i miał uszkodzoną klawiaturę. Tymczasem z czatu wynika, że z tym drugim problemem radził sobie, podłączając zewnętrzną klawiaturę…
Anakata broni się przed zarzutami informując śledczych, że z jego komputera mogło korzystać wiele osób, które łączyły się z nim zdalnie. Tymczasem analiza śledcza rejestrów systemowych i logów aplikacji pokazała, że w ciągu okresu, który interesuje organa ścigania, nikt nie logował się zdalnie na jego komputer i anakata był jego jedynym użytkownikiem.
Anakata wydaje się niewiele pamiętać lub w ogóle odmawia odpowiedzi na pytania śledczych. Nie słyszał o systemie z/OS, nie potrafi wytłumaczyć, skąd na jego komputerze wzięła się duża liczba plików, skradzionych z mainframe’a firmy Logica, co robił tam emulator systemu z/OS skonfigurowany jak zhakowany serwer ani co oznaczają jego liczne wypowiedzi w przejętych logach irca, w których opisuje ze szczegółami operacje wykonywane na zhakowanym serwerze. Takich samych wyjaśnień udziela także pytany o odnalezione na jego dysku szczegółowe logi z operacji wykonywanych na mainframie od dnia włamania oraz o kolekcję wszystkich narzędzi, które do włamania posłużyły. Wygląda zatem na to, że jeżeli nie wydarzy się jakiś cud, to trudno będzie mu wybronić się ze stawianych w śledztwie zarzutów. A oskarżenie o włamanie do mainframe’a firmy Logica to i tak jego najmniejszy problem.
Włamań było więcej
Większość informacji na temat zarzutów postawionych założycielowi The Pirate Bay koncentruje się wokół wycieku danych podatkowych obywateli Szwecji. Nie wszyscy jednak wiedzą, że anakata włamał się również do innego mainframe’a. Głównego sewera Nordei.
Do czego może się przydać całkiem dobry 0day
Włamywacze, którzy uzyskali kontrolę nad serwerem mainframe firmy Logica, znaleźli w tym celu co najmniej dwa błędy typu 0day. Kiedy już administratorzy Logica w połowie marca 2012 odcięli im dostęp, zaczęli szukać innych celów. Nie wiemy, ile serwerów typu mainframe odwiedzili, wiemy jednak, że jednym z nich okazał się serwerem banku Nordea. Mainframe Nordei działał pod kontrolą tego samego systemu operacyjnego z/OS, co w firmie Logica, dzięki czemu prawdopodobnie zadziałał tam ten sam exploit, odkryty przez włamywaczy.
Krótka chronologia włamania
Najstarsze odkryte ślady nieautoryzowanego dostępu do systemu pochodzą z 25 kwietnia 2012, a więc ok. miesiąca po odcięciu włamywaczy od serwera Logica. Najwyraźniej rozejrzenie się po systemie, poznanie zasad jego funkcjonowania i zlokalizowanie najciekawszej funkcjonalności zajęło włamywaczom trochę czasu, ponieważ pierwsze nieautoryzowane transakcje zaczęli wykonywać dopiero 22. lipca. Pod koniec lipca bank zorientował się, że liczba osób o dostępie administracyjnym nie zgadza się z liczbą osób w tym celu zatrudnionych a przelewy na łączną kwotę ok. 3 milionów złotych nie wyglądają na autoryzowane i przelewy anulował a ślady po włamaniu posprzątał.
O włamaniach do banków lepiej nie opowiadać
Pewnie pomyślicie, że w kolejnym kroku bank powiadomił organa ścigania, że ktoś włamał się do jego systemów i próbował okraść na poważną kwotę. Otóż nie. Bank najwyraźniej uznał, że straty nie są wielkie, więc lepiej nie robić niepotrzebnego zamieszania i raport z włamania schował do szuflady. Tym większe było zaskoczenie biegłych, kiedy w wolumenie TrueCrypta, na dysku anakaty, podejrzanego o włamanie do serwera Logica, znaleźli pełną bazę danych klientów Nordei oraz informacje o wykonywanych, nieautoryzowanych przelewach. Kiedy zwrócili się w tej sprawie do Nordei, ta przypomniała sobie o własnym raporcie i udostępniła go, by dołączyć do akt śledztwa. Wikileaks raport zeskanowało, a my przebrnęliśmy przez 160 stron po szwedzku, by opowiedzieć Wam tę historię.
Co można przeskrobać w banku
Niestety raport nie precyzuje, jakich błędów użył anakata w ataku na bank. Wiadomo za to, że udało mu się pobrać pełną bazę użytkowników wraz z ich hasłami. Nie wiemy niestety, czy chodzi o użytkowników systemowych, czy tez o klientów banku.
Wiemy na pewno, że uzyskane informacje pozwoliły mu na poziom dostępu wystarczający do wysyłania przelewów z cudzych rachunków, czego nie omieszkał uczynić. Według dokumentów śledztwa pobrał także na swój komputer pliki kompletnego systemu bankowego Nordei – prawdopodobnie w celu dalszej analizy. Skąd jednak wiadomo, że to na pewno była jego sprawka?
Proxy fajna rzecz, ale do czasu
W trakcie czterech miesięcy, podczas których włamywacz miał dostęp do serwerów banku, korzystał z 13 różnych adresów IP. Śledczy wszystkie 13 przypisali anakacie – choć nie wszystkie bezpośrednio. Większość adresów należała do kambodżańskiego operatora telekomunikacyjnego Cogetel Online, z usług którego korzystał anakata. Mało tego, na dysku jego komputera znaleziono wszystkie adresy, z których łączył się do serwera banku. Spora część znajdowała się w ciasteczkach, które różne strony www zamieszczały w jego przeglądarce, a część odnalazła się w historii zaufanych kluczy SSH Putty. Najciekawsza jest jednak historia pewnej szkoły w Sztokholmie, z serwera której dokonano nieautoryzowanych przelewów. Okazuje się, że ktoś uzyskał nieautoryzowany dostęp do jej strony www (posługując się w tym celu kambodżańskim adresem IP…) i umieścił na jej serwerze skrypt o nazwie 72_i7kqafilt7.php, a w nim webshella (narzędzie do zdalnego uruchamiania poleceń przez www). Przez przypadek skrypt o identycznej nazwie oraz plik z pełną ścieżką do skryptu na szkolnym serwerze znaleziono na komputerze anakaty. Poniżej zawartość pliku t001a\a\x\cpr\malmostuds.txt:
www.malmoborgarskola.se/photo/utbildning/72_i7kqafi1t7.php?1=passthru('uname -a');
Dodatkowo anakata posłużył się narzędziem datapipe do zestawienia połączenia do serwera banku. Jak widać, nie pomogło.
Jak wyprowadzić pieniądze
Skoro już miał narzędzie do bezpiecznej łączności, anakata przystąpił do kolejnej części planu, jaką było wykorzystanie posiadanych uprawnień w systemie Nordei do wykonania nieautoryzowanych przelewów. W tym celu wybierał konta dużych firm, o wysokich saldach. Nie wiemy, czy musiał omijać dodatkowe systemy uwierzytelnienia – według udostępnionych materiałów przelewy wykonywał bezpośrednio z terminala, nie korzystając z interfejsu www banku, więc możliwe, że dzięki temu nie musiał np. podawać kodów sms.
Pierwszy przelew na skromna kwotę ok. 13 tyś. PLN wysłał 23 lipca 2012. Odbiorcą był niejaki Ahmed Mohamed Haji Elmi, współoskarżony w tym samym procesie. Ahmed, pytany przez policję, od kogo otrzymał pieniądze, odpowiedział, że znajomy znajomego poprosił go o przysługę przyjęcia przelewu, za którą miał otrzymać drobne wynagrodzenie. Otrzymaną kwotę szybko wypłacił z bankomatu a los pieniędzy pozostaje nieznany.
Zapewne zadowolony z sukcesu kolejne przelewy anakata wysłał kilka godzin później tego samego dnia do tego samego odbiorcy – tym razem kwoty były odrobinę wyższe. Nordea jednak zorientowała się już, że dzieje się coś podejrzanego i zablokowała te płatności. Anakata pewnie jeszcze o tym nie wiedział, ponieważ w kolejnych dniach podejmował kolejne próby. 24. lipca wysłał 3900 EUR do banku Barclays w Wielkiej Brytanii, ale na prośbę Nordei przelew został zwrócony.
Tym razem anakata postanowił iść na całość i kolejny przelew, wysłany 1. sierpnia, opiewał na sumę 420,000 EUR i był skierowany do szwajcarskiej filii banku UBS a następny na 230,000 EUR, do banku na Cyprze.
Nordea wnikliwie monitorowała jednak przelewy międzynarodowe (zapewne ciągle szukając błędu w systemie…) i obie transakcje zablokowała. Anakata spróbował jeszcze wysłać kwoty rzędu kilkudziesięciu tysięcy PLN dwóm osobom w Szwecji – odbiorcami przelewów byli Abdul-rahim Bashe Said oraz Seifaddin Sedira. Nordea zablokowała jednak również i te transakcje. Więc prób – przynajmniej według raportu Nordei – już nie podejmował…
Dowody włamania
Jak pewnie się już zorientowaliście, zamiast szukać dowodów, policja musi raczej zastanowić się, które wybrać z bogatego zbioru. Narzędzia, używane przez anakatę, logowały każdy ekran terminala. W materiałach śledztwa widać po kolei każdy zlecany przelew. Na jego komputerze znaleziono także dowody na to, że wszystkie adresy IP użyte w czasie włamania należały do niego lub miał do nich dostęp. Dodatkowo na jego komputerze odnaleziono ponad 400 plików i katalogów, które pochodziły z serwera Nordei. Co prawda linia obrony anakaty opiera się na twierdzeniu, że do jego komputera logowało się wiele osób, jednak rejestry systemowe oraz logi aplikacyjne nie potwierdzają tej teorii. Wygląda zatem na to, że niefrasobliwość, polegająca na używaniu domowego adresu IP do włamań oraz zostawianie podpiętego wolumentu TrueCrypta, wyśle anakatę na co najmniej kilka lat za kratki. Pewnie zastanawiacie się, jak tak utalentowany specjalista mógł popełnić tak proste błędy – odpowiedź może czaić się w logach z irca – w jednej z rozmów anakata wspomina, że pracuje na amfetaminie…
Podsumowanie
Rzadko mamy do czynienia z tak bogatą dokumentacją na temat przestępstw komputerowych. Gdyby całość była po angielsku, a nie szwedzku, wpis byłby jeszcze dłuższy i ciekawszy. Jeśli spodobał się Wam ten artykuł i chcecie podzielić się nimi ze znajomymi, to możecie udostępnić im poniższy link:
https://zaufanatrzeciastrona.pl/historia-pewnego-włamania
Będziemy wdzięczni za wrzucenie go na Wasze profile, strony, blogi i fora – na pewno zachęci nas to do pisania podobnych artykułów w przyszłości :)
Jeśli kogoś wpis ten natchnął do studiowania bezpieczeństwa mainframe’ów, to polecamy na dobry początek blog Soldier of Fortran.