Według analizy Google Threat Intelligence Group / Mandiant opublikowanej 1 września BREEZE COMET atakował brazylijskie finanse, handel i e-commerce i manipulował systemami płatniczymi. Badacze wskazują na poszukiwanie certyfikatów administracyjnych i danych mTLS do uwierzytelniania wobec systemów bankowych. Dla polskiego fintechu i handlu proponujemy przegląd technicznych tożsamości, dostępu z sieci sklepów oraz przechowywania sekretów w środowiskach programistycznych.

Czy na pytanie o dostęp do płatności wystarczy odpowiedzieć listą pracowników upoważnionych do zatwierdzania transakcji? W przeglądzie inspirowanym przypadkiem BREEZE COMET dopiszmy do tej listy pytania o certyfikaty i dane mTLS. Poprośmy o wskazanie, jaką tożsamość potwierdzają, gdzie są przechowywane i jakie operacje są z nią związane. Następnie sprawdźmy, czy przegląd obejmuje dostęp z placówek handlowych i środowisk programistycznych. To proponowany zakres kontroli własnej organizacji, a nie opis polskiego incydentu. Ustalenia dotyczą Brazylii i nie dają podstaw do przypisywania tej kampanii polskich ofiar. Dla zarządu punktem wyjścia powinno być konkretne pytanie: kto potrafi przedstawić zakres maszynowego dostępu do firmowych płatności?

BREEZE COMET szukał danych do uwierzytelnienia w bankowości

Według Google Threat Intelligence Group / Mandiant napastnicy wyszukiwali certyfikaty administracyjne oraz dane mTLS potrzebne do uwierzytelniania wobec systemów bankowych. Z tego ustalenia wyprowadzamy zalecenie: przy kontroli płatności sprawdzajmy uprawnienia związane z techniczną tożsamością. Sam spis certyfikatów potraktujmy jako początek pracy; dołączmy do niego opis ich zastosowania.

W przeglądzie certyfikatów rozdzielmy pytanie o uwierzytelnienie od pytania o uprawnienia do transakcji. Nie zakładajmy, że dowolny certyfikat wystarczy do wykonania płatności. Dla każdej sprawdzanej tożsamości ustalmy, jakie operacje są dozwolone oraz jakie warunki trzeba spełnić, aby je wykonać. Jeśli zespół potrafi potwierdzić jedynie możliwość uwierzytelnienia, zapiszmy pozostały zakres jako nieustalony.

Przy danych mTLS poprośmy także o wskazanie miejsc przechowywania i osób odpowiedzialnych za dostęp. W wyniku kontroli umieśćmy identyfikator poświadczenia oraz jego rolę, bez przepisywania sekretu. Taki zakres proponujemy jako odpowiedź na opisane przez badaczy poszukiwania; nie przesądza on, jakie uprawnienia mają certyfikaty w konkretnej polskiej firmie.

Przegląd certyfikatu używanego przy płatnościach powinien kończyć się ustaleniem jego uprawnień do operacji finansowych.

Sieć sklepu i CI/CD wymagają sprawdzenia w praktyce

Przypadek BREEZE COMET potraktujmy jako punkt wyjścia do porównania zasad dostępu z konfiguracją własnej organizacji. W sieci sklepu wybierzmy port sieciowy i sprawdźmy, jakie ograniczenia przewiduje dla niego dokumentacja oraz co potwierdzają dostępne ustawienia. Przy segmentacji placówki poprośmy o wskazanie dozwolonych połączeń w kierunku środowiska płatności. Rozbieżności zapiszmy jako konkretne zadania do wyjaśnienia.

W środowisku CI/CD, czyli ciągłej integracji i dostarczania oprogramowania, wybierzmy proces związany z obsługą płatności. Porównajmy deklarowany sposób przechowywania sekretów z miejscami wskazanymi w jego konfiguracji. Ustalmy, kto może uzyskać dostęp do poświadczeń oraz czy znany jest zakres związanych z nimi uprawnień. Jeżeli brakuje dostępu do konfiguracji, odnotujmy ten brak zamiast potwierdzać zgodność z procedurą.

Te kontrole sieci i CI/CD są zaleceniami dla czytelnika. Przywołane ustalenia o poszukiwaniu poświadczeń nie pozwalają odtworzyć procedur zaatakowanych organizacji ani ocenić decyzji ich pracowników. Nie przypisujmy im zaniedbań. We własnym przeglądzie żądajmy natomiast potwierdzenia ustawień dla wybranej placówki i procesu programistycznego, zanim uznamy odpowiednie zasady dostępu za sprawdzone.

Zarząd powinien powiązać certyfikaty z odpowiedzialnością za płatności

Po analizie BREEZE COMET proponujemy wspólne omówienie wyników przez osoby odpowiedzialne za płatności, sieć placówek i środowiska programistyczne. Dla każdej sprawdzanej tożsamości technicznej wskażmy właściciela biznesowego oraz osobę utrzymującą dostęp. Poprośmy ich o uzgodnienie, czy opisane uprawnienia odpowiadają potrzebom danej usługi. Nie zamykajmy przeglądu certyfikatu na informacji, że ma wyznaczonego administratora.

Zarządowi przedstawmy ustalony zakres operacji, niewyjaśnione uprawnienia i proponowaną kolejność dalszych kontroli. Własnego ryzyka związanego z metodami BREEZE COMET nie wyceniajmy przez analogię do zagranicznych ofiar. Zlećmy oszacowanie skutków dla konkretnych płatności dopiero po ustaleniu, co dana tożsamość pozwala zrobić. W ocenie kosztów uwzględnijmy zakres uprawnień do transakcji potwierdzony w naszej organizacji. Nierozstrzygnięte pytania o ten zakres przekażmy osobie odpowiedzialnej za dalszą ocenę.

Odpowiedzialność za tożsamość techniczną w płatnościach powinna obejmować decyzję o potrzebnym zakresie jej uprawnień.

Polski fintech powinien sprawdzić własne warunki dostępu

Opis BREEZE COMET dotyczy brazylijskiego rynku płatności. Nie przenośmy jego mechanizmów na polskie systemy ani nie przedstawiajmy badania jako dowodu ataków w Polsce. Dla polskiego odbiorcy proponujemy zastosowanie pytań o dostęp maszynowy, segmentację placówek i sekrety do własnej architektury. Każdą odpowiedź oprzyjmy na ustaleniach dotyczących sprawdzanej usługi.

W polskim fintechu zacznijmy od wybranej integracji płatniczej, a w handlu od wybranej placówki i jej połączeń. Ustalmy, czy w tym zakresie występują certyfikaty lub sekrety wymagające dalszego przeglądu. Jeśli dany element nie występuje, zapiszmy to wraz z zakresem sprawdzenia. Nie dopasowujmy firmowego systemu do brazylijskiego opisu na siłę. Wynik kontroli powinien mówić, czego dowiedzieliśmy się o własnym dostępie do płatności i których pytań jeszcze nie rozstrzygnęliśmy.

Co z tym zrobić w poniedziałek

  1. Sprawdź wybrany port w sieci sklepu. W 30 minut porównaj dostępną dokumentację z konfiguracją ograniczeń dostępu i segmentacji dla jednej placówki. Zapisz potwierdzone ustawienia oraz brakujące informacje o połączeniach w kierunku płatności. Wyznacz osobę do wyjaśnienia luk.
  2. Przejrzyj sekrety wybranego procesu CI/CD. Przez 30 minut ustal z konfiguracji, gdzie proces związany z płatnościami przechowuje poświadczenia i kto ma do nich dostęp. Zapisz identyfikatory, przeznaczenie oraz właścicieli, bez kopiowania wartości sekretów. Niewyjaśnione pozycje przekaż do dalszej kontroli.
  3. Opisz uprawnienia wybranego certyfikatu. W 30 minut zbierz dostępne informacje o tożsamości używanej wobec systemu płatności. Oddziel możliwość uwierzytelnienia od dozwolonych operacji finansowych. Przy nieustalonych uprawnieniach wskaż osobę i termin ich weryfikacji; nie traktuj tego wstępnego opisu jako zakończonego audytu.

Ochrona płatności powinna obejmować techniczne tożsamości oraz dostęp z sieci sklepu i środowisk programistycznych. Po lekturze analizy BREEZE COMET wymagajmy, by decyzja o utrzymaniu uprawnień certyfikatu opierała się na rozpoznanym zastosowaniu i potrzebach usługi. Niewiadome dotyczące tego dostępu powinny otrzymać właściciela i termin wyjaśnienia.

Źródła

Redakcja cyberinsight.pl.