Kilka tygodni temu przestępcy próbowali ukraść miliard dolarów z kont banku centralnego w Bangladeszu. Prawie im się to udało, a dzięki analizie użytego złośliwego oprogramowania możemy zajrzeć za kulisy spektakularnego włamania.
W lutym miało miejsce jedno z najbardziej spektakularnych przestępstw komputerowych w dotychczasowej historii. Tajemniczy sprawcy próbowali ukraść prawie miliard dolarów z kont banku centralnego w Bangladeszu. Tylko przypadkowi można zawdzięczać fakt, że ukradli zaledwie 80 milionów.
Złośliwe oprogramowanie stworzone specjalnie na potrzeby tego ataku
Analiza takiego włamania to marzenie większości firm działających w branży bezpieczeństwa. Skąd jednak wziąć próbki, skoro to FireEye został zaangażowany do obsługi incydentu? Z pomocą przychodzą repozytoria złośliwego oprogramowania – domyślamy się, że jak w większości przypadków mogło chodzić o serwis VirusTotal. Eksperci firmy BAE Systems odnaleźli tam ciekawe próbki, wgrane krótko po ataku własnie z Bangladeszu. Co więcej, w ich kodzie zaszyte są informacje wskazujące, że miały działać własnie w sieci banku centralnego w Bangladeszu. Wszystko zatem wskazuje na to, że mamy do czynienia z oprogramowaniem użytym w ataku.
Program o nazwie evtdiag.exe musiał zostać zainstalowany na serwerze obsługującym transakcje systemu międzybankowego SWIFT. Jego konfiguracja przechowywana jest w zaszyfrowanym pliku i zawiera wskazówki co do sposobu jego działania i listy słów kluczowych, na które reagował. Znaleziono w niej także adres serwera C&C: 196.202.103.174. Program po uruchomieniu skanuje wszystkie procesy w systemie i szuka tego, który załadował bibliotekę liboradb.dll, należącego do oprogramowania obsługującego system SWIFT opartego o Oracle Database. Gdy znajdzie już odpowiedni proces, łata w pamięci dwa bajty biblioteki. Powoduje to, że przestają działać wewnętrzne testy bezpieczeństwa (zamiast przerwać wykonywanie programu jest ono kontynuowane mimo błędów) i program może swobodnie manipulować danymi.
Kilka drobnych manipulacji
Złośliwy program monitoruje wiadomości systemu SWIFT, zawierające m. in. informacje o zleconych i wykonanych przelewach. Przeszukuje je pod kątem zdefiniowanej listy słów kluczowych i gdy trafi na wiadomość spełniającą określony warunek, odczytuje jej parametry i usuwa z bazy danych odpowiedni wpis, ukrywając nieautoryzowaną transakcję. Przygotowuje w tym celu i wykonuje odpowiedni skrypt SQL.
Program monitoruje także logowania do systemu za pomocą poniższego kodu, wykonywanego co 5 sekund:
SELECT * FROM (SELECT JRNL_DISPLAY_TEXT, JRNL_DATE_TIME FROM SAAOWNER.JRNL_%s WHERE JRNL_DISPLAY_TEXT LIKE '%%LT BBHOBDDHA: Log%%' ORDER BY JRNL_DATE_TIME DESC) A WHERE ROWNUM = 1;
Warto zwrócić uwagę na ciąg BBHOBDDHA – to identyfikator banku centralnego w Bangladeszu. Informacje o logowaniach przekazywane są do serwera C&C.
Program potrafi także modyfikować w locie salda rachunków w systemie by ukryć fakt dokonywania nieautoryzowanych transakcji. Jako że potwierdzenia transakcji są również automatycznie drukowane, program identyfikuje określone wiadomości, modyfikuje je w locie, konwertuje na pliki PRT, wysyła do drukarki a następnie usuwa ze swojej pamięci nadpisując zerami.
Czego nie wiemy
Autorzy analizy wskazują, że twórca programu dysponował solidnymi umiejętnościami programistycznymi oraz głęboką wiedzą na temat funkcjonowania systemu SWIFT oraz procedur operacyjnych obowiązujących w banku. Analiza fragmentu użytego złośliwego oprogramowania pokazuje w jaki sposób przestępcy zacierali ślady, jednak nie pokazuje, w jaki sposób dostali się do sieci (rzekomo bank używał switchy z odzysku za 10 dolarów sztuka), jak zdobyli uprawnienia oraz w jaki sposób wysłali nieautoryzowane przelewy.
Przedstawiciele organizacji SWIFT podkreślają, że bezpieczeństwo sieci oraz serwerów nie zostało naruszone, jednocześnie zapowiadając aktualizację oprogramowania klienckiego. Mamy nadzieję, że nie jest to ostatnia odsłona tej historii i wkrótce poznamy kolejne szczegóły.
Komentarze
Dopóki oprogramowanie klasy enterprise będzie zezwalało serverowi aplikacji (a i czesto klientowi!) na bezprśrednie wykonywanie zapytań DML, dopóty jakiekolwiek wdarcie się do aplikacji bedzie konczyło się bazodanowym sajgonem. Gdzie widoki, stored procedures? Jaki nieodpowiedzialny gość zezwala serwerowi aplikacji na jakikolwiek dostęp do journala? Chore…
Ale przecież „teraz tak się pisze” – taka jest szybciej, efektywniej, taniej. Nikt już sobie nie zawraca głowy, aby logikę biznesową implementować na poziomie bazy danych, teraz zajmuje się tym obiektowo-zorientowany framework, z którego korzystają interfejsy. Łatwiej to utrzymywać (no bo jednak do aktualizacji żywej bazy danych to trzeba kogoś, kto cokolwiek umie, małpa nie wystarczy), ale znajdziesz SQL injection i po zabawie. A taki framework nie dość, że z pewnością jest dziurawy, to jeszcze gada z bazą danych za pomocą jednego użytkownika; ja jeszcze robię osobne zestawy użytkowników z dostępem r/o, prawami dobranymi na konkretne tabele/kolumny, aplikacja NIGDY nie ma dostępu do modyfikacji samej bazy ani tabel z danymi audytowymi (rejestracja wszystkich zmian w bazie) – więc nie obawiam się jakoś szczególnie o żadne drop database, drop table czy delete from table. Ale to jest już archaizm – w dzisiejszych czasach jedyną gwarancją bezpieczeństwa enterprise jest to, że mało osób ma dostęp do aplikacji przez nich używanych, więc ciężko jest szukać błędów. W tym przypadku ktoś najwyraźniej dysponował taką końcówką, żeby ją sobie pooglądać. Czyli zawiodło obscurity, a poza nim nic dot. security nie było.
A ta DLL-ka od Oracle niczym niezabezpieczona, nawet niepodpisana cyfrowo… Czy to możliwe, że oprogramowanie SWIFT powstało na freelancerze i robiła to jakaś studentka z polski?
A który system operacyjny weryfikuje podpisy w locie po załadowaniu biblioteki do pamięci? Może powinien to jeszcze robić dla pewności przed wywołaniem każdego API?
Windows 10 nawet na natywne biblioteki i chyba bylo to wprowadzone juz w Viscie.
Dodatkowo, caly .NET od wersji 1.0.
Aha, no i to sie dzieje przed zaladowaniem biblioteki do pamieci a nie po.