Atak na łańcuch dostaw 3CX: wyciągnięte wnioski

Złośliwcy najpierw naruszyli pakiet oprogramowania X_TRADER firmy o nazwie Technologie handlowe z siedzibą w Chicago, IL. Oprogramowanie zawierało złośliwe oprogramowanie ( SYGNAŁ Z KAMUFLAŻEM Wstrzyknięto backdoor. Instalator został podpisany cyfrowo ważnym certyfikatem podpisywania kodu. Możliwe, że hakerzy włamali się do kompilacji. pipeline Do 2021 roku zmodyfikowano oprogramowanie przed jego spakowaniem i podpisaniem. Był to pierwszy etap ataku na łańcuch dostaw. Do marca 2022 roku… zgłaszane w kontekście operacji DreamJob, znany również jako BLINDINGCAN oraz Jabłko Jezus, skierowany do organizacji z siedzibą w USA działających w branży mediów informacyjnych, IT, kryptowalut i technologii finansowych.

To oprogramowanie zostało wycofane w 2020 roku (!), ale było dostępne do pobrania od 2022 roku. Pracownik 3CX zainstalował je na komputerze osobistym. Złodzieje ukradli firmowe dane uwierzytelniające pracownika z zainfekowanego komputera. Co ciekawe, SYGNAŁ Z KAMUFLAŻEM wykorzystał adres URL witryny Trading Technologies w celu kontroli i dowodzenia (często stosowana taktyka w celu uniknięcia wykrycia).

Dwa dni później, po początkowym ataku, cyberprzestępcy wykorzystali korporacyjną sieć VPN do uzyskania dostępu do wewnętrznych systemów 3CX. Wykorzystali odwrotny serwer proxy FRP, publiczne narzędzie, które mogło być wykorzystywane zarówno w dobrych, jak i złych celach, do poruszania się w sposób horyzontalny. Wiedzieli, co zrobić z uzyskanym przyczółkiem: włamali się do systemów kompilacji Windows i macOS. Każde środowisko działało przy użyciu innych narzędzi. Na przykład, użyli narzędzia SigFlip, aby wstrzyknąć kod powłoki zaszyfrowany RC4 do dodatku podpisu. Plik d3dcompiler_47.dll.

Aktualizacje oprogramowania dla aplikacji 3CX Desktop dla systemów Windows i macOS zostały zainfekowane. Był to drugi etap tego (pierwszego?) wieloetapowego ataku na łańcuch dostaw. Aktualizacja oprogramowania dla systemu Windows, również prawidłowo podpisana certyfikatem podpisywania kodu 3CX, zawiera dwa złośliwe pliki: ffmpeg.dll oraz d3dcompiler_47.dll (z odpowiednikiem .dylib biblioteki dla systemu macOS), które zostały załadowane i wykonane przez łagodny Aplikacja 3CXDesktop wykonywalny (za pomocą techniki ładowania bocznego biblioteki DLL). Kod powłoki zaszyfrowany w drugiej bibliotece DLL ładuje inną bibliotekę DLL, która jest pobierana z IconStorages Repozytorium GitHub - plik .ico zawierający zaszyfrowany serwer Command and Control (C2).

Przewidziano ponad 20 domen, co pokazuje, jak starannie zaplanowano atak na łańcuch dostaw oprogramowania.

Połączenia z komputerów ofiar do domen C2 rozpoczęły się 06 marca 2023 r. i zakończyły 29 marca.

Należy pamiętać, że (1) żaden kod źródłowy w repozytorium kodu nie został zmodyfikowany, lecz zamiast tego podczas kompilacji wstrzyknięto ładunek złośliwego oprogramowania, (2) legalny ffmpeg DDL zastąpiono złośliwym i załadowano poprzez boczne ładowanie bibliotek DLL, a (3) popularną aplikację VoIP przekształcono w broń z wieloetapowym złośliwym oprogramowaniem.

Jak potraktowano incydent

Wygląda na to, że 29 marca firma 3CX otrzymała zgłoszenia od stron trzecich o złośliwym oprogramowaniu „wykorzystującym lukę w zabezpieczeniach ich produktu”. Platformy antywirusowe spełniły (częściowo) swoje zadanie.

30 marca 2023 r. 3CX CISO, Pierre Jourdan, opublikował Alarm bezpieczeństwa Informujemy klientów i partnerów, że ich aplikacja Electron (klient komputerowy) została wysłana po aktualizacji zawierającej złośliwe oprogramowanie. W poście wymieniono wersje (dla systemów Windows i Mac), krótkie oświadczenie o podjętych początkowo środkach zapobiegawczych oraz krótką rekomendację, aby kontynuować pracę z klientem webowym zamiast zainfekowanego klienta komputerowego.

Moim zdaniem, początkowa komunikacja, choć nieco lakoniczna, była konkretna. Żadnemu dostawcy nie jest łatwo rozpoznać, że istnieje poważny problem z bezpieczeństwem, który może dotknąć wielu klientów. Firma dostrzegła problem i natychmiast wskazała potencjalnego winowajcę:

„Warto wspomnieć, że najwyraźniej był to ukierunkowany atak ze strony zaawansowanego, trwałego zagrożenia, być może nawet sponsorowanego przez państwo, który przeprowadził złożony atak na łańcuch dostaw i wskazał, kto będzie pobierał kolejne etapy złośliwego oprogramowania”.

Firma zaproponowała alternatywne rozwiązanie, które pozwoli utrzymać produkt w działaniu: Progresywna aplikacja internetowa lub PWA, zamiast aplikacji na komputer, w oparciu o Elektron Ramy.

Zdecydowanie zalecamy korzystanie z naszej aplikacji PWA. Aplikacja PWA jest w całości oparta na przeglądarce i wykonuje 95% funkcji aplikacji Electron. Jej zaletą jest to, że nie wymaga instalacji ani aktualizacji, a zabezpieczenia przeglądarki Chrome są stosowane automatycznie.

Powodem, dla którego mamy dwie aplikacje, jest to, że kiedy uruchamialiśmy Electron App, technologia PWA nie była jeszcze dostępna. Teraz jest dojrzała i działa naprawdę dobrze.

Cóż, aplikacja internetowa również mogła zostać zainfekowana, a PWA z definicji może uruchamiać kod w Service Workers (kod JavaScript) z (ograniczonym) dostępem do zasobów lokalnych. W poście twierdzono, że PWA nie była wówczas zainfekowana. Rozumiemy, dlaczego w wielu z ponad 277 komentarzy do posta pojawiały się pytania, czy wspomniana alternatywa PWA lub samo oprogramowanie serwera PBX zostało zainfekowane.

Tego samego dnia, 3CX wyznaczył Mandianta do przeprowadzenia dochodzenia, z dodatkowymi instrukcjami. Zasadniczo instaluje aktualizację dla

Zainstaluj aplikację desktopową na komputerach Windows/Mac w lokalnej instalacji, odinstaluj aplikację Electron w wersjach, których dotyczy problem, i przejdź do alternatywnej aplikacji PWA. To jednak nie wystarczy, ponieważ złośliwe oprogramowanie może uzyskać dostęp do zainfekowanych systemów, zachować je, a nawet rozprzestrzenić się. Pełne usunięcie złośliwego oprogramowania nie jest takie proste. Rozumiemy, że biorąc pod uwagę pilną sytuację, nie zawsze można znaleźć najlepszy sposób radzenia sobie z incydentem… chyba że wcześniej przewidziano scenariusz i zidentyfikowano odpowiednie środki zaradcze.

 następujący post, Prezes firmy, który teraz stara się uspokoić klientów, ogłaszając aktualizację bezpieczeństwa aplikacji DesktopApp. Wdrożono podstawowe techniki ochrony, takie jak haszowanie haseł („Lepiej niż nigdy, to za późno; nigdy nie odnieść sukcesu byłoby zbyt długim okresem”, Chaucer). Dixit (w 1386 r.) Konkretne, wdrożone zabezpieczenia są lepsze niż dobre intencje i zaplanowane plany… Ale jak przechowywano hasła wcześniej?

W każdym razie Google unieważniło istniejący certyfikat podpisywania kodu 3CX, a dostawcy oprogramowania antywirusowego zablokowali również wszelkie oprogramowanie podpisane tym certyfikatem. Instalatory MSI aktualizacji DesktopApp wymagały ponownego wygenerowania z nowym certyfikatem podpisywania kodu, co zajęło kilka godzin. Można się było tego spodziewać!

Firma 3CX prewencyjnie wdrożyła nowy serwer kompilacji. To uzasadnione: bez analizy nie było wiadomo, w jaki sposób złośliwe oprogramowanie zostało wstrzyknięte.

Tego samego dnia, 1 kwietnia, dyrektor generalny opublikował Aktualizacja incydentów bezpieczeństwaW poście opisano działania firmy (przeprowadzono pełne dochodzenie i zweryfikowano cały kod źródłowy oprogramowania po stronie klienta). Bezpieczeństwo nie może czekać nawet w soboty.

Po przeanalizowaniu incydentu i ustaleniu infrastruktury atakującego, repozytorium GitHub oraz domeny serwerów C2 używanych przez APT zostały usunięte, co skutecznie unieszkodliwiło złośliwe oprogramowanie.

W kwietniu 11th, the CISO opublikował wstępne wyniki analizy incydentów. Pierwszym wymienionym przypadkiem była powiązana z Koreą Północną ofensywa UNC4736.

W piątek 20 kwietnia Mandiant opublikował wstępna analiza incydentuOpublikowano reguły wykrywania YARA i Snort.

Tego samego dnia dyrektor generalny 3CX opublikował nowy post o sugestywnej nazwie „Czyny, nie słowa – Nasz 7-etapowy plan działań na rzecz bezpieczeństwa!”. Podtytuł jest dość interesujący: „Zabezpieczenie przyszłości 3CX po pierwszym w swoim rodzaju kaskadowym atak na łańcuch dostaw oprogramowania w oprogramowaniu.” Etapy projektu karty bezpieczeństwa są następujące:

• Wzmocnienie wielu warstw zabezpieczeń sieci.

• Modernizacja zwiększa bezpieczeństwo.

• Ciągły przegląd bezpieczeństwa produktu.

• Ulepszanie funkcji bezpieczeństwa produktu.

• Przeprowadzanie bieżących testów penetracyjnych.

• Udoskonalenie planu zarządzania kryzysowego i obsługi alertów.

• Utworzenie nowego działu ds. operacji sieciowych i bezpieczeństwa.

Analitycy z pewnością będą mieli oko na ten godny pochwały program…

Następstwa: Jak zareagowała branża

Minęło zaledwie kilka tygodni od publikacji tego incydentu. Ale branża reaguje.

CVE-2023-29059 Został przypisany. Na dzień dzisiejszy ma on 7.8 (WYSOKI) wynik ryzyka CVSSv3. Produkty 3CX mają tylko 16 wymienionych luk CVE, co wygląda dobrze w porównaniu z dostawcami o podobnym poziomie wdrożenia. Ale ten incydent nie jest zwykła podatność rzeczywiście. Jest to aktywny atak ukierunkowany przez Aktywne Trwałe Zagrożenie (APT), ponieważ CISNajbardziej rozpoznawalny O.

 CWE-506 Określenie tego incydentu mianem „wbudowanego złośliwego kodu” niewiele nam pomaga w zrozumieniu, jak zapobiegać tego typu atakom na łańcuch dostaw oprogramowania. Niestety, cyberprzestępcy mają wiele sposobów na dostarczanie złośliwego oprogramowania, a ataki na łańcuch dostaw to nowy klejnot w ich arsenale. CWE-506 należy udoskonalić, aby odzwierciedlał obecne scenariusze, w tym te oparte na naruszeniu systemu kompilacji.

Grupa APT, nazwana przez Mandiant UNC4736, stosuje taktykę i techniki podobne do szeroko znanej grupy Lazarus (APT38), stworzonej przez państwo północnokoreańskie, oraz sprawców kampanii ransomware WannaCry z 2017 roku. Takie powiązania między złoczyńcami w państwach stalinowskich, którzy pracują w regularnych godzinach, są trudne do ustalenia, ale badacze z… CrowdStrike oraz ESET Stwierdzono, że stosowane taktyki, techniki i procedury (TTP) przypominają te powszechnie stosowane przez Lazarus APT38. Zrozumienie ich działania jest kluczowe dla wykrywania, zapobiegania i eliminacji.

Jeszcze trudniej jest poznać ich cele, owiane tajemnicą.

Ten atak jest na tyle ważny, że CISAmerykańska Agencja Bezpieczeństwa Cybernetycznego wyemitowała doradczy z postami dostawców i linkami do licznych analiz dotyczących ataków na łańcuch dostaw. Ich lektura jest istotna dla specjalistów ds. cyberbezpieczeństwa.

Incydent ten przypomina atak SolarWinds. Z uwagi na jego ogromne skutki, wielu dostawców natychmiast przystąpiło do analizy zainfekowanych instalatorów produktów VoIP dla komputerów stacjonarnych. To jednak ostatni krok. Potrzebne są dalsze szczegóły, aby zrozumieć, co zawiodło w zabezpieczeniach systemów kompilacji obu dotkniętych organizacji oraz jakie kroki podjęli atakujący, aby wpłynąć na te systemy i wgrać złośliwe oprogramowanie podczas kompilacji. W przeciwnym razie ten incydent będzie się powtarzał w kółko.

A teraz wyciągnęliśmy wnioski!

Granie w sporcie zespołowym i słuchanie, jak ktoś z twojej drużyny tłumaczy każdą minutę twojego błędu, niszczy nawet najbardziej zahartowanego ducha. Ale tutaj, w Hiszpanii, każdy jest trenerem reprezentacji piłkarskiej! Pozwólcie mi więc zagrać Pepa Guardiolę, José Mourinho, Alexa Fergusona i Arrigo Sacchiego razem wziętych.

Postępuj tak, jakby Twój system budowy był pod ciężkim ostrzałem artyleryjskimByć może nie możesz zapobiec instalacji nieautoryzowanego oprogramowania przez pracownika na komputerach służbowych. Zespoły inżynierskie prawdopodobnie będą wymagać bardziej rygorystycznych zasad. Zachowaj jednak czujność podczas kompilacji i wdrażania. pipelineJeśli dostarczasz klientom oprogramowanie, bezpieczeństwo sposobu jego tworzenia powinno być tak samo ważne, jak bezpieczeństwo samego produktu programistycznego.

Gotowość na incydentyTrudno, a może wręcz jałowo, przewidzieć najbardziej prawdopodobne scenariusze incydentów bezpieczeństwa. Czy powinienem nauczyć się obsługi defibrylatora? Nie, chyba że żyję z tendencją do łamania kart.iac Aresztować. Ale na litość boską! Przygotuj się na „odbudowę swojego systemu” od podstaw, z unieważnianiem i odnawianiem kluczy, tokenów dostępu, par kluczy publicznych i certyfikatów.

Systemy kompilacji muszą mieć określone cechy:Obecny trend budowania w środowiskach efemerycznych, izolowanych, bezparametrowych, hermetycznych, a nawet powtarzalnych, może stanowić podstawę zapobiec ataki takie jak ten na atak na łańcuch dostaw 3CX, uzupełnione dodatkowymi wymaganiami dotyczącymi innych systemów w procesie kompilacji i wdrażania pipeline. Zobaczyć Wymagania kompilacji Google SLSA na przykład.

Właściwa komunikacja jest kluczowaPrzejrzystość jest obowiązkowa. Minimalizowanie problemu lub ukrywanie go pod dywanem to najgorsze, co może zrobić organizacja. Incydenty bezpieczeństwa często uderzają mocniej w reputację niż w inne aktywa, a zła komunikacja po naruszeniu może mieć katastrofalne skutki.

Zmień problemy w szanseDobry incydent może wywołać ulepszenia w zabezpieczeniach, które nigdy nie znalazły odzwierciedlenia w ścisłym planie produktu. Nawet niezbędne elementy, takie jak poprawne hashowanie haseł i dokumentacja konfiguracji/wzmocnienia zabezpieczeń, można zaplanować na krótki okres. Jednak w przypadku ataków na łańcuch dostaw, wzmocnienie systemów kompilacji oraz dodanie atestów i kontroli integralności na każdym etapie kompilacji i wdrożenia. pipelinesą niezbędne. Atakującemu nie powinno być łatwo wprowadzić takie zmiany do systemu kompilacji.

Bądź przygotowany. W przeciwnym razie Twoja organizacja może stanąć w obliczu zagrożenia egzystencjalnego, takiego jak atak na łańcuch dostaw oprogramowania 3CX.