Witajcie w kolejnej odsłonie Centrum Bezpieczeństwa Xopero. W tym tygodniu bierzemy pod lupę przypadek malware’a Z0Miner – atakujący obrali sobie tym razem za cel niezałatane serwery ElasticSearch i Jenkins. Serwery MS Exchange są także przedmiotem ataku. Pamiętacie o czterech nowych 0-day, które wykryto kilka tygodni temu? Teraz otrzymały wymyślna nazwę – exploity ProxyLogon – oraz wyjątkowo skuteczny ransomware DearCry, który przejmuje podatne urządzenia. Co jeszcze? Przestępcy po raz kolejny sięgnęli po fałszywe Google reCAPTCHA i z ich pomocą wykradają dane uwierzytelniające Microsoft 365. Drobne problemy miał również GitHub – dokładnie, mechanizm logowania do usługi dał… Co dokładnie? O tym przeczytacie poniżej.
Niezałatane serwery ElasticSearch i Jenkins są dziś łatwym łupem dla botneta z0Miner
Odkryty w zeszłym roku botnet z0Miner aktualnie przejmuje podatne serwery Jenkins i ElasticSearch, które następnie przekształca w koparki Monero (XMR). Na ślad jego działań natknął się zespół Tencent Security. Początkowo cyberprzestępcy bazowali na likach bezpieczeństwa w Weblogic.
Teraz atakujący zaktualizowali złośliwe oprogramowanie w taki sposób, by wyszukiwać i przejmować serwery w podatnościami RCE:
błąd CVE-2015-1427 wykryty w ElasticSearch
oraz starsza podatność w serwerach Jenkins.
Po przejęciu serwera złośliwe oprogramowanie najpierw pobiera złośliwy skrypt powłoki, który ma zweryfikować czy na urządzeniu nie działa już jakiś inny złośliwy program, a jeśli go wykryje – uśmiercić wszystkie konkurencyjne procesy.
Następnie program konfiguruje nowy wpis cron, aby okresowo pobierać i uruchamiać złośliwe skrypty z Pastebin. Kolejny etap infekcji obejmuje pobranie minning kit zawierającego skrypt XMRig koparki, plik konfiguracyjny i skrypt startowy. Po tym zagrożenie może już bez przeszkód wydobywać kryptowaluty w tle.
W zeszłym roku przestępcy przejęli ponad 5 tys. urządzeń. Następnie przez kilka miesięcy ich działania prawie zanikły. Teraz aktywność botneta z0Miner bardzo szybko przybiera na sile. Pierwszy pick przypadł na środek stycznia. Specjaliści doradzają użytkownikom serwerów ElasticEearch i Jenkins weryfikację zabezpieczeń i w razie wykrycia problemów z zabezpieczeniach – szybką aktualizację.
Jeśli masz jednak podejrzenia, że urządzenie znajduje się w rękach przestępców, skup się na wyszukiwaniu nieprawidłowych procesów i połączeń sieciowych. Zacznij również prowadzić monitoring – i wdróż skuteczne blokowanie – blokowanie nieistotnych adresów IP i URL.
Przestępcy korzystają z fałszywych Google reCAPTCHA aby wykradać dane logowania do konta Microsoft 365
W tej nowej kampanii maile phishingowe udają automatyczne komunikaty dostarczane przez wykorzystywane przez ofiary narzędzia do komunikacji.
Ofiary otrzymują na firmową skrzynkę wiadomość, że numer “(503) ***-6719 w dniu 20 stycznia pozostawił wiadomość głosową, o długości 35 sekund”. Do wiadomości jest załączany plik “vmail-219.HTM”. Niektóre osoby miały do czynienia jednak z odmiennym komunikatem. W tym drugim wariancie ofiara ma zweryfikować ważny dokument (REVIEW SECURE DOCUMENT) – czyli klasyczny zabieg socjotechniczny.
W momencie gdy użytkownik Microsoft 365 klika załącznik, w przeglądarce ładuje się klasyczny widok z Google reCAPTCHA – tyle, że są one oczywiście fałszywe.
Google reCAPTCHA to popularna usługa, która ma za zadanie zabezpieczać strony internetowe m.in. przez spamerskimi botami. Graficzna łamigłówka polegającą na wskazaniu zdjęć zawierających rower lub hydrant to nic innego jak nowoczesna odmiana testu Turinga.
Po przejściu testu, ofiara zostaje przekierowana na stronę phishingową, gdzie ma wpisać swoje dane dostępowe do konta Microsoft 365. Przestępcy odrobili pracę domową i przygotowali formularze tak by były one zgodne z oryginalnym profilem atakowanych organizacji. Na tym etapie ofiary są proszone o wprowadzenie danych uwierzytelniających do systemu. Kiedy operacja kończy się sukcesem zostają przekierowani do widoku, gdzie mogą osłuchać otrzymaną wcześniej wiadomość głosową. Jest to interesujący zabieg, ponieważ zwykle w ostatnim kroku zaatakowany użytkownik trafia na właściwą stronę logowania do usługi.
Kto jest celem przestępców?
Tym razem atakujący celują w Wicedyrektorów oraz Dyrektorów Zarządzających, którzy mają dostęp do znacznie bardziej atrakcyjnych danych. Według analityków, w ciągu ostatnich trzech miesięcy wysłano co najmniej 2,5 tysiąca takich wiadomości – głównie do pracowników sektora bankowego oraz IT.
Ransomware DearCry atakuje serwery Microsoft Exchange za pomocą exploitów ProxyLogon
Tydzień temu nalegaliśmy na pilne załatanie czterech krytycznych luk zero-days w Microsoft Exchange ostrzegając przed apogeum ataków. Niestety, w zeszłym tygodniu nasze obawy stały się rzeczywistością… Cyberprzestępcy wykorzystują te luki nazwane ProxyLogon, do instalowania nowego ransomware DearCry.
Michael Gillespie, twórca witryny ID-Ransomware identyfikującej oprogramowanie szyfrujące przyznaje, że od 9 marca do jego systemu zaczęły spływać noty okupu i zaszyfrowane pliki przesyłane przez użytkowników.
Exploity ProxyLogon
Microsoft potwierdził, że DearCry jest instalowany podczas ataków na serwery Microsoft Exchange z wykorzystaniem luk w zabezpieczeniach ProxyLogon.
MalwareHunterTeam znalazł trzy próbki tego ransomware w VirusTotal, z których wszystkie są plikami wykonywalnymi skompilowanymi z użyciem MinGW.
Po uruchomieniu ransomware DearCry próbuje zamknąć usługę Windows o nazwie „msupdate”. Nie wiadomo, czym jest ta usługa, ale nie wygląda na legalną. Następnie oprogramowanie zaczyna szyfrować pliki na komputerze dodając rozszerzenie .CRYPT do nazwy pliku.
Gillespie twierdzi, że oprogramowanie to używa algorytmu AES-256 + RSA-2048 do szyfrowania plików i dodaje „DEARCRY!” na początku ciągu znaków każdego zaszyfrowanego pliku.
Po zakończeniu szyfrowania ransomware tworzy prostą notę okupu o nazwie „readme.txt” na pulpicie systemu Windows. Od jednej z ofiar grupa zażądała okupu w wysokości 16 tys. dolarów.
Niestety, to oprogramowanie ransomware nie wydaje się mieć żadnych słabych punktów, które umożliwiłyby ofiarom bezpłatne odzyskanie plików. Póki co, jedyną możliwością jest odzyskanie danych z kopii zapasowej – dlatego tak ważne jest posiadanie sprawdzonego oprogramowania do backupu danych.
Według nowych danych udostępnionych przez Palo Alto Networks dziesiątki tysięcy serwerów Microsoft Exchange zostało załatanych w ciągu ostatnich dni. Eksperci przyznają, że nigdy wcześniej nie widzieli tak wysokich wskaźników poprawek dla żadnego systemu. Niestety, firma twierdzi, że nadal istnieje około 80 000 starszych serwerów, które nie mogą bezpośrednio zastosować najnowszych aktualizacji zabezpieczeń.
Wszystkim organizacjom ponownie zalecamy jak najszybsze zastosowanie poprawek dla podatności ProxyLogon!
GitHub naprawia błąd powodujący logowanie użytkowników do cudzych kont
W nocy z 8 na 9 marca GitHub automatycznie wylogował wielu użytkowników, unieważniając ich sesje w celu ochrony ich kont przed potencjalnie poważną luką w zabezpieczeniach.
Na początku miesiąca GitHub otrzymał zewnętrzny raport o pewnym nietypowym zagrożeniu. Wynikało ono z rzadkiej luki w zabezpieczeniach typu “race condition”, która przekierowywała sesję logowania użytkownika GitHub do innego zalogowanego konta użytkownika, dając temu drugiemu uwierzytelniony plik cookie oraz dostęp do konta tego poprzedniego.
GitHub w ostatnim kroku podjętym w celu załatania błędu wylogował wszystkich użytkowników, którzy byli zalogowani przed 8 marca, 12:03 czasu UTC
Według GitHuba luka mogła zostać wykorzystana w niezwykle rzadkich okolicznościach, gdy “race condition” wystąpiłby podczas procesu obsługi żądań. W takim przypadku sesyjny plik cookie zalogowanego użytkownika GitHub zostałby przesłany do przeglądarki innego użytkownika, dając temu ostatniemu dostęp do konta poprzedniego.
Firma twierdzi, że ten błąd był obecny na GitHub.com przez okres poniżej dwóch tygodni w określonych punktach w czasie między 8.02 a 5.03.2021 r. Nie ma dowodów na to, że inne produkty, takie jak np. GitHub Enterprise Server były narażone na ten błąd.
Według firmy błędne przekierowanie dotyczyło zaledwie 0,001% uwierzytelnionych sesji w witrynie GitHub.com. Właściciele kont, których dotyczył ten problem zostali poinformowani oraz otrzymali dodatkowe informacje i wskazówki.
Liczba 0,001% wydaje się znikoma, ale biorąc pod uwagę, że GitHub ma ponad 32 miliony aktywnych odwiedzających (uwierzytelnionych lub nie) w ciągu miesiąca, błąd mógł dotyczyć dziesiątek tysięcy kont.
Takie luki w uwierzytelnianiu mogą prowadzić do ataków typu side-channel. Chociaż GitHub dał się poznać jako rzetelna platforma do hostowania kodu, problemy są nieuniknione dla wszystkich dostawców usług. Tutaj mają jednak szczególne znaczenie. Kod jako własność intelektualna może być najcenniejszym zasobem w Twojej organizacji – upewnij się, że jest dobrze chroniony i rozważ inwestycję w rzetelne oprogramowanie do backupu GitHub.
Takich jak Xopero ONE for GitHub – zapisz się na Beta Testy.