Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



26.08.2021

Firma Fortinet rozszerzyła...

Firma Fortinet rozszerzyła ofertę o usługę FortiTrust, która dołączyła do innych usług...
26.08.2021

Aplikacje biznesowe

Ready_™ AppStore
26.08.2021

Automatyzacja chmur...

Integracja z Red Hat Ansible
26.08.2021

Backup kodu źródłowego

GitProtect.io dostępny na Github
26.08.2021

Wsparcie pracy hybrydowej

Zdalny SD WAN
26.08.2021

Nowy monitor Philips 498P9Z

Nowy monitor Philips 498P9Z to model wyposażony w 49-calowy, zakrzywiony panel VA o...
26.08.2021

Wytrzymały punkt dostępowy

D-Link DIS-2650AP
26.08.2021

Ekonomiczne dyski

SSD bez DRAM
26.08.2021

Petabajty pojemności

Serwery QNAP

Zatruty wodopój – rocket science w atakach APT

Data publikacji: 04-02-2021 Autor: Ireneusz Tarnowski

Rok 2020 zmienił rozumienie cyberbezpieczeństwa na całym świecie. Przyspieszona adaptacja do warunków pracy zdalnej, nowych usług czy wręcz zjawisk internetowych to w zakresie ochrony cyberbezpieczeństwa prawdziwe wyzwanie. Zwieńczeniem minionego roku okazał się jednak niezwykle groźny i bardzo ważny dla przyszłości bezpieczeństwa IT atak Advanced Persistent Threat.

 

Jedni radzili sobie z nowymi realiami dyktowanym przez pandemię lepiej, inni gorzej. Wiele tegorocznych najbardziej znanych ataków, takich jak rekordowa fala oprogramowania ransomware, wykorzystywało chęć użytkowników do klikania w linki w wiadomościach phishingowych lub skradzione dane uwierzytelniające do włamywania się do systemów. W końcówce roku ujawniono jednak szczegóły ogromnego ataku APT, w którym zastosowano metodę wodopoju (zatrutego źródła). Atak ten w aspekcie zmiany myślenia o cyberbezpieczeństwie można porównywać do kampanii WannaCry czy NotPetya z 2017 roku.


Powierzchnia ataku sięgnęła 18 tys. podmiotów (firm, instytucji, agencji rządowych) – tyle odnotowano pobrań zatrutej wersji oprogramowania. Trzeba podkreślić, że zainfekowane oprogramowanie było licencjonowane i dostępne tylko dla firm posiadających duże sieci wewnętrzne. Wśród ofiar znalazły się takie organizacje jak amerykańskie agencje rządowe: Departament Obrony, Energii, Bezpieczeństwa, Stanu, Skarbu oraz Zdrowia, a wśród firm m.in. Microsoft, Intel, Cisco, Nvidia, VMware, Belkin, SAP, NCR, czy nawet potentat z obszaru cybersecurity, firma FireEye, która jako pierwsza podała informację o zdarzeniu.

 

> NA POCZĄTKU TRZĘSIENIE CYBERPRZESTRZENI


13 grudnia firma FireEye ogłosiła, że odkryła globalną kampanię włamań do systemów informatycznych największych firm na świecie. Odpowiedzialną za ten atak ogłoszono grupę UNC2452. Początkowo FireEye odkryło szczegóły ataku na własną infrastrukturę i idące za tym konsekwencje w postaci wycieku narzędzi ofensywnych. Będąc jedną z największych firm analitycznych w obszarze cyberbezpieczeństwa, spotkała się z wieloma głosami krytyki, a sam atak miał bardzo negatywny wpływ na jej wizerunek. Jednak w miarę odsłaniania kolejnych szczegółów problemy FireEye schodziły na coraz dalszy plan.


Wykryto bowiem atak na łańcuch dostaw polegający na trojanizowaniu (dodaniu do legalnego oprogramowania funkcji konia trojańskiego) aktualizacji oprogramowania biznesowego SolarWinds Orion w celu dystrybucji złośliwego oprogramowania. Odkryty koń trojański otrzymał nazwę SUNBURST. Szybko stało się jasne, że atak jest niezwykle wyrafinowany, a sam atakujący wykorzystał wiele technik, by uniknąć wykrycia i ukryć swoją aktywność. Sama kampania była szeroko rozpowszechniona, dotykając większość użytkowników oprogramowania Orion. Było to dzieło wysoce wykwalifikowanej grupy hakerskiej, a operacja została przeprowadzona przy dużej staranności i zachowaniu bezpieczeństwa operacyjnego, tak aby uniknąć wykrycia, zaatakować zdefiniowane cele i zapewnić możliwie długie jej trwanie.


Początkowym wektorem ataku w łańcuchu dostaw było przejęcie oprogramowania Orion w wersjach:

 

  • Orion Platform 2019.4 HF5, version 2019.4.5200.9083;
  • Orion Platform 2020.2 RC1, version 2020.2.100.12219;
  • Orion Platform 2020.2 RC2, version 2020.2.5200.12394;
  • Orion Platform 2020.2, 2020.2 HF1, version 2020.2.5300.12432.


SolarWinds Orion to pakiet oprogramowania do zarządzania siecią w organizacji, który obejmuje monitorowanie wydajności oraz samych aplikacji, jak również zarządzanie konfiguracją sieci. Ma on wbudowanych wiele różnych typów narzędzi analitycznych. Służy do monitorowania i zarządzania infrastrukturą lokalną oraz zewnętrzną (hostowaną czy chmurową). Aby zapewnić oprogramowaniu SolarWinds Orion niezbędny dostęp do infrastruktury i zróżnicowanej technologii, administratorzy sieci często konfigurują je z wysokimi uprawnieniami. Między innymi to spowodowało, że jest on cennym celem dla działań przeciwnika.
Adwersarz (twórca i operator ataku) dodał złośliwą wersję binarnego pliku solarwinds.orion.core.businesslayer.dll do cyklu wytwarzania oprogramowania SolarWinds. Biblioteka ta została następnie podpisana (w kolejnych wersjach oprogramownia) przez legalny certyfikat podpisujący kod SolarWinds. „Dodatek” ten zawiera wkompilowany backdoor, który komunikuje się przez HTTP z serwerami zewnętrznymi. Po początkowym okresie uśpienia trwającym do dwóch tygodni SUNBURST może pobierać i wykonywać polecenia, które nakazują złośliwemu kodowi transfer plików, wykonywanie programów, profilowanie systemu, wyłączanie usług oraz ponowne uruchamianie systemu. Ruch sieciowy szkodliwego oprogramowania próbuje wtopić się w legalną aktywność SolarWinds poprzez naśladowanie protokołu Orion Improvement Program (OIP), a trwałe dane stanu są przechowywane w legalnych plikach konfiguracyjnych wtyczek. Backdoor używa wielu zaciemnionych list blokowanych do identyfikacji procesów, usług i sterowników powiązanych z narzędziami wykrywającymi ataki APT, wirusy i malware. I tak, po uruchomieniu aplikacji następuje:

 

  1. Weryfikacja, czy uruchomiona (przejęta) biblioteka DLL jest wywołana przez proces właściwej aplikacji.
  2. Okres uśpienia od 288 godzin (12 dni) do 336 godzin (14 dni).
  3. Sprawdzenie, czy komputer jest dopięty do domeny (praca w organizacji domenowej, a nie prywatny lokalny komputer) oraz czy domena nie jest na liście wykluczeń. Lista wykluczeń to zakodowane skróty MD5 takich nazw jak dev.local, lab.local, lab.na, lab.rio, cork.lab, apac.lab, lab.brno, pci.local, dmz.local, swdev.local, saas.swi, swdev.dmz, emea.sales.
  4. Weryfikacja narzędzi bezpieczeństwa – sprawdzenie listy procesów, listy serwisów oraz sterowników.
  5. Próba wyłączenia wykrytych narzędzi bezpieczeństwa, np. poprzez zmianę wartości w rejestrze, i restart systemu.
  6. Sprawdzenie konfiguracji sieciowej poprzez rozwinięcie nazwy DNS api.solarwinds.com. Działanie aplikacji Orion niewzbudzające podejrzeń dla aplikacji Orion.
  7. Zebranie podstawowych informacji o systemie, tak by wygenerować zgodną z zaprogramowanym algorytmem nazwę domenową DGA.
  8. Sprawdzenie, czy zapytanie DNS o utworzoną domenę DGA rozwija się do adresu IP.
  9. Wykorzystując pozyskany adres IP (z rekordu A), proces uruchamia właściwy backdoor, który łączy się przez HTTPS do serwerów zarządzających (Command and Control, C2). Tu następuje właściwe użycie konia trojańskiego do infiltracji środowiska (infekcja – faza 2).
  10. Adres serwera zarządzającego C2 pobierany jest z DNS, pola CNAME domeny.
  11. Komunikacja adwersarza z przejętym serwerem jest ustanowiona i następują dalsze kroki ataku, które są uzależnione od organizacji, w której znajduje się serwer.

 

Poszczególne elementy pierwszej fazy ataku przedstawiono na rys. 1.

W trakcie pierwszej fazy infekcji malware wykorzystuje algorytm DGA do utworzenia ukrytego kanału komunikacji. Dla zainfekowanego systemu tworzona jest domena w jednej z czterech nazw domenowych FQDN:

 

  • .appsync-api.eu-west-1[.]avsvmcloud[.]com,
  • .appsync-api.us-west-2[.]avsvmcloud[.]com,
  • .appsync-api.us-east-1[.]avsvmcloud[.]com,
  • .appsync-api.us-east-2[.]avsvmcloud[.]com.

 

Jedna z metod zatrutej biblioteki jest odpowiedzialna za inicjalizację funkcji kryptograficznych do generowania losowo wyglądających subdomen C2. Generowane są one poprzez konkatenację (połączenie) zakodowanego identyfikatora użytkownika z zakodowaną nazwą domeny systemu. Operator C2 może odtworzyć nazwę domeny ofiary z zakodowanych danych i prawdopodobnie wykorzystuje tę informację do przekierowania komunikacji malware SUNBURST do właściwego (ostatecznego) serwera C2. Identyfikator użytkownika jest generowany na podstawie trzech wartości:

 

  • adres MAC pierwszego dostępnego interfejsu sieciowego;
  • nazwa domenowa środowiska;
  • klucz rejestru HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyMachineGuid.

 

Malware SUNBURST liczy skrót MD5 od tych wartości i koduje je funkcją XOR, używając własnego schematu. Uważa się, że wartość ta służy grupie UNC2452 do identyfikacji, śledzenia i zarządzania swoimi ofiarami. Analitycy napisali program do dekodowania subdomen DGA dla tego ataku. W przypadku pojawienia się w sieci lokalnej zapytania DNS o subdomenę DGA z ataku można podjąć próbę odkodowania nazwy domeny środowiskowej i porównać, czy jest ona związana z organizacją. Dla przykładu subdomena 18l3m0mkua37kahcs2ejri0t6eorver.appsync-api.eu-west-1.avsvmcloud[.]com dekoduje się do nazwy środowiska: rocket.science.

 

Zapytanie DNS może pojawić się w różnych okolicznościach, jednak jeżeli w organizacji domeną windowsową jest rocket.science, można być pewnym, że atak APT właśnie się zaczyna lub trwa w najlepsze.

 

[...]

 

Ekspert w zakresie analizy i reagowania na cyberzagrożenia. Analizując zagrożenia w cyberprzestrzeni oraz techniki, taktyki i procedury w atakach, ocenia potencjalny wpływ na organizację i opracowuje plany reakcji na pojawiające się ataki i zagrożenia. Miłośnik defensywnego podejścia do cyberbezpieczeństwa.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"