Do napisania tego artykułu zainspirowała mnie operacja GhostPulse opisana przez CERT Orange (po polsku) oraz oryginalnie przez Elastic Security Labs (po angielsku). W dużym skrócie – jednym z etapów złośliwej kampanii było wygenerowanie pliku instalacyjnego MSIX. Warunkiem koniecznym do uruchomienia takiego programu na (większości) stacji roboczej jest podpis prawidłowym certyfikatem. Fragment raportu Elastic Security mówi, że „However, MSIX requires access to purchased or stolen code signing certificates making them viable to groups of above-average resources.”.

Zacząłem się zastanawiać czy rzeczywiście zdobycie aktualnego certyfikatu, który służy do podpisu cyfrowego (Key Usage!) jest takie trudne i czy cyberprzestępcy są w stanie znaleźć to w otwartym Internecie.

Ale czego tak na prawdę potrzebuję?

Zacznijmy od tego, czego potrzebujemy do podpisywania naszego pliku instalacyjnego. Potrzebny nam jest certyfikat wraz z kluczem prywatnym oraz z całym drzewkiem certyfikatów zaufanych CA, które podpisały nasz certyfikat. Najczęściej pliki z certyfikatami mają następujące rozszerzenia:

• PFX
• P12
• CER
• CRT
• PEM
• DER

Nie chcę tutaj rozwijać za bardzo różnic pomiędzy tymi formatami, ale skrótowo je opiszę:

PFX to „kontener”, który może zawierać w sobie wiele certyfikatów i kluczy. Jest on kompatybilny z formatem P12, co oznacza, że możemy konwertować je bez utraty funkcjonalności, zmieniając ich rozszerzenia w systemie Windows. Plik PFX jest z reguły zaszyfrowany.

CER oraz CRT to formaty plików, które zawierają tylko certyfikat. Może być on przechowywany zarówno w formacie binarnym (.DER) lub w formacie tekstowym (.PEM). Zawiera on w sobie certyfikaty zgodne ze standardem X.509, tj. zawiera informacje o podmiocie, nazwie, organizacji, ma w sobie również klucz publiczny służący do szyfrowania lub weryfikacji podpisu cyfrowego, w końcu zawiera też podpis cyfrowy CA, które wystawiło certyfikat.

Istnieje też rozszerzenie „.key”. Pliki takie najczęściej zawierają klucz prywatny, który jest częścią pary kluczy. Może być on przechowywany w formacie binarnym .DER jak i .PEM. Kojarzycie napis „——– BEGIN PRIVATE KEY ———-„? To właśnie format tekstowy .PEM.

Powyższy nagłówek można więc podsumować następująco: potrzebujemy albo kontenera PFX – czyli certyfikatu i klucza prywatnego, albo połączenia klucza prywatnego .key oraz certyfikatów .cer.

Aby było jeszcze bardziej skomplikowanie, czasami różne elementy certyfikatów, kluczy, CSR (Certificate Signign Reqeuest) mogą być przechowywane z rozszerzeniem .PEM! Wtedy po prostu oznacza to, że certyfikat jest przechowywany w formie tekstowej, klucz jest przechowywany w formie tekstowej itp. itd.

Jeżeli jest tu jakiś specjalista od kryptologii i są jakieś błędy w powyższych definicjach – chętnie przyjmę krytykę!

Możemy więc podsumować to w taki sposób: jeżeli chcemy zasymulować taki atak, powinniśmy szukać kontenerów PFX lub kombinacji klucza wraz z certyfikatem.

Potęga Google Dorks

W jaki sposób najczęściej Administratorzy serwerów www wystawiają pliki do pobrania? Z wykorzystaniem tzw. „Directory Listing”, czyli funkcjonalności serwerów webowych umożliwiających wyświetlania zawartości katalogów i hostowanie plików. W tytule takiej strony znajduje się wtedy fraza „Index of”.

Wykorzystajmy więc dobrze znany Google Dork: intitle:”Index of” w celu znalezienia interesujących nas plików.

intitle:"Index of" pfx

Po chwili przed naszymi oczami pojawi się duża ilość zasobów zawierających w sobie pliki PFX! Zakładam, że większość tych plików i zasobów znalazła się w otwartym Internecie przez przypadek. Być może jednak niektórzy myślą, że pliki PFX zabezpieczone hasłem to wystarczająca ochrona przed potencjalnymi przestępcami. Nic bardziej mylnego – współczesne zasoby sprzętowe mają na prawdę duże możliwość ataków brute-force na pliki PFX, tym bardziej, że są to ataki offline.

Jeżeli komuś zależy, może łamać takie pliki nawet i miesiącami. Potencjalny zysk jest większy niż poniesione koszty.

Pamiętacie jeszczeo kluczu .key i certyfikacie .cer?

Możemy spróbować użyć operatorów lub, aby przeszukać zawartości serwerów w poszukiwaniu plików key.

intitle:"Index of" (intext:"pfx" | intext:"key")

I w ten sposób trafiamy na kolejny zasób, zawierający CSR, klucz, certyfikat, jak i kontener PFX.

Jak się zabezpieczyć?

Dobre praktyki i procedury mają ogromne znaczenie, ale często moment weryfikacji przychodzi w momencie realnego testu. Dobrą analogią są procedury wykonywania backupów. Ich posiadanie jest bardzo ważne, lecz równie istotne jest rzeczywiste sprawdzenie od czasu do czasu czy uda się odtworzyć system z kopii zapasowej.

To samo tyczy się wrażliwych danych organizacji. DLP, procedury, procesy, to niezwykle istotna sprawa, ale czy kiedykolwiek rzeczywiście testowaliście czy wrażliwe dane waszych pracowników, kontrahentów, systemów nie są na wyciągnięcie ręki dla cyberprzestępców?
To wiele nie kosztuje. Odpalcie Google i zweryfikujcie najpopularniejsze zapytania:

site:twojafirma.com wp-config
site:twojafirma.com access.log
site:twojafirma.com intitle:zaloguj
site:twojafirma.com intitle:panel
site:twojafirma.com intitle:Index of
site:twojafirma.com intitle:Index of intext:mysql_connect()
site:twojafirma.com intitle:Dane filetype:pdf
site:twojafirma.com intitle:Index of inurl:/backup
site:twojafirma.com intitle:Index of inurl:/admin
site:twojafirma.com intitle:Index of inurl:/config
site:twojafirma.com intitle:Brother
site:twojafirma.com intitle:"Kyocera Command Center" inurl:index.htm
site:twojafirma.com intitle:"Camera" inurl:view
site:twojafirma.com filetype:.bash_history
site:twojafirma.com filetype:json
site:twojafirma.com filetype:conf
site:twojafirma.com filetype:php.bak
site:twojafirma.com filetype:id_rsa
site:twojafirma.com filetype:ovpn
site:twojafirma.com WebServers.xml

Powyższe to tylko przykłady dorków, które możemy przetestować. Przygotowując się do takich testów, powinniśmy sprawdzić z jakich technologii korzystamy na co dzień i jakie rozszerzenia mają pliki konfiguracyjne. Scope poszukiwanych materiałów należy przygotować możliwie najszerzej. Być może korzystamy z charakterystycznego software, który wykorzystuje „niestandardowe” rozszerzenia? Czy wykonujemy backupy skrzynek Outlooka? Jeśli tak, nie zapomnijmy o formacie „PST”. Przykłady można mnożyć.

Często backupy tych plików konfiguracyjnych lądują w miejscach, które są dostępne z sieci. Zastanówmy sie też jakie mamy endpointy „wystawione” do Internetu. Być może oprócz URLa „twojafirma.com” powinniśmy przetestować inne (np. deweloperskie) domeny i adresy IP.

Więcej o najpopularniejszych dorkach możecie przeczytać tutaj.

Pamiętajmy również o zasadzie low-hanging fruits. Przestępcy nie będą musieli stosować wyszukanych metod aby dostać się do Waszej infrastruktury, kiedy pliki „ovpn” będą dostępne od ręki.

Jak się zabezpieczyć jeszcze bardziej?

Monitorowanie własnych zasobów to jedno. A co jeśli staniemy się ofiarą Malware, który został podpisany właśnie takim „zleakowanym” certyfikatem? Przypomina mi to analogię do sytuacji na drodze, w której osoba, która zawsze dba o bezpieczeństwo i jeździ zgodnie z przepisami – a i tak uczestniczy w wypadku spowodowanym przez kogoś nierozważnego.

Myślę, że dobrym rozwiązaniem jest masowe wdrożenie AppLockera w organizacjach,, który działa w oparciu o sztywne reguły white-lists. Może być to nieco uciążliwe na etapie wdrożenia, ale uważam, że w ogólnym rozrachunku zapewnia zadowalający poziom bezpieczeństwa.

Czy AppLocker wspiera obsługę plików MSIX? Pewnie, że tak. Więcej o tym możecie przzeczytać tutaj.

Epilog