Zdobył ~50 000 PLN za zgłoszenie niewinnej podatności SSRF w Grafanie

08 sierpnia 2020, 13:40 | Aktualności | komentarze 4
: oglądaj sekurakowe live-streamy o bezpieczeństwie IT.

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

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

 

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. PrezydentAmdrzej

    12000 $ dokladnie tyle ile macie ksiazek sprzedanych 🤔
    Przypadek?🤨 Chyba nieee 😏

    Odpowiedz
    • Książek rzeczywiście w okolicach 12 000 sprzedanych :)

      Odpowiedz
  2. asdsad

    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.

    Odpowiedz
  3. Najs. Grafana to takie rozwiązanie gdzie bug na bugu, bugiem pogania. Plus dla twórców za takie nagrody.

    Odpowiedz

Odpowiedz