Server-Side Request Forgery – czyli zmuszenie serwera do zainicjowania pewnej komunikacji sieciowej. Przykład? Umieszczam na Facebooku link do zewnętrznego zasobu – Facebook łączy się do zadanego URL-a, pobiera jego zawartość, a następnie przedstawia ją użytkownikowi w zgrabnej formie. Całość wygląda całkiem bezpiecznie. W którym zatem miejscu występuje podatność? W zasadzie…
Czytaj dalej »
Ostra seria podatności tutaj. Na celowniku tym razem był jeden z systemów legal – w domenie thefacebook.com. Dokładnie rzecz biorąc – ten system. Zaczęło się od zlokalizowania ciasteczka o nazwie .ASPXAUTH Jest to ciastko sesyjne, ale jakby tu dostać się na admina? Badacz miał nosa do tego typu przypadku (doświadczenia…
Czytaj dalej »
O temacie pisaliśmy niedawno, a obecnie o aktywnej eksploitacji ostrzega grupa NCC: Opis podatności jest tutaj: iControl REST unauthenticated remote command execution Więcej technikaliów można z kolei znaleźć w tym miejscu. Tak np. wygląda udana próba eksploitacji: Co ciekawe jednym z istotnych kroków (ominięcie uwierzytelnienia) odbywa się z wykorzystaniem podatności…
Czytaj dalej »
Z podatnością Server-Side Request Forgery (SSRF) bywa różnie – czasem właściciele systemu, który ma tę lukę wzruszają ramionami – niby brak impactu. Czasem jednak można otrzymać całkiem sowitą nagrodę i tak też było w tym przypadku. Przypomnijmy – SSRF to zmuszenie serwera (aplikacji) do wykonania żądania HTTP (lub innym protokołem)…
Czytaj dalej »
Opis wartego $2000 znaleziska można znaleźć tutaj. Przykładowy plik video wygląda np. tak: #EXTM3U #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:10.0, concat:http://dx.su/header.m3u8|file:///etc/passwd #EXT-X-ENDLIST a cała magia dzieje się w trakcie konwersji, np.: ffmpeg -i podatny_plik.mp4 -o wynik.avi, która jest wykonywana automatycznie po uploadzie pliku od użytkownika. „Dziwna” zawartość pliku graficznego to użycie pewnej ciekawej funkcji…
Czytaj dalej »
Ciekawy błąd zgłoszony do GitLaba: Unauthenticated blind SSRF in OAuth Jira authorization controller, wypłata $4000. Istota problemu polegała tutaj na odpowiednim użyciu nagłówka HTTP Host: Zauważmy że adres, do którego łączy się curl (https://gitlab.com/) to nie ten sam, co w nagłówku Host (162.243.147.21:81). Ten ostatni to adres napastnika, a jak widać możemy…
Czytaj dalej »
Jako wstęp do cytowanego tekstu można poczytać: RFC 3986 oraz nasz tekst o podatności Server Side Request Forgery. Można też obadać świeże mięso z BlackHata. Dowiecie się m.in. że URL: http://2130706433/ prowadzi de facto do http://127.0.0.1/
Czytaj dalej »
Writeup podatności zgłoszonej do Google. Pierwszym problemem okazał się SSRF w domenie toolbox.googleapps.com. Jeśli ktoś jeszcze nie kojarzy tej podatności – mamy jej opis na sekuraku. Później wystarczyło najpierw zbruteforce-ować adres wewnętrznego serwera DNS (sieć 10.x), a następnie już hulaj dusza. Wszystko korzystając z publicznie dostępnego interfejsu widocznego poniżej: –ms
Czytaj dalej »
Spora część aplikacji webowych umożliwia wgranie własnego pliku na serwer poprzez podanie adresu URL, skąd zostanie on automatycznie pobrany na serwer. W tym artykule omówimy jakie problemy mogą wynikać z takiego rozwiązania – innymi słowy poznamy podatność Server-Side Request Forgery (SSRF).
Czytaj dalej »
