Tag: ssrf

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…

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…

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)…

Opis wartego $2000 znaleziska można znaleźć tutaj. Przykładowy plik video wygląda np. tak:

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 od Apple (HTTP Live Streaming). Co więcej podatność…

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…

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/

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

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).