Żądny wiedzy? Wbijaj na Mega Sekurak Hacking Party w maju! -30% z kodem: majearly

GitHub: nieautoryzowany dostęp do kont użytkowników -> przyznano nagrodę ~100 000zł

07 listopada 2019, 19:50 | Aktualności | komentarze 2

Ta podatność w GitHub-ie warta jest wspomnienia ze względu na kilka różnych ciekawostek. Całość dotyczy wydawałoby się bezpiecznego mechanizmu OAuth. Ale od początku, GitHub definiuje taki URL:

https://github.com/login/oauth/authorize

Realizuje on dwie funkcje – jeśli dostaniemy się tam GET-em otrzymujemy ekran logowania, z kolei POST wysyłany jest w momencie kiedy użytkownik kliknie przycisk „daj uprawnienia tej aplikacji”:

Badacz doszedł jednak do wniosku, że można odwołać się do tego URL-a metodą HEAD, którą Ruby przetwarza jako GET (zwracając tylko nagłówki odpowiedzi). Zauważmy jednak, że w poniższym kodzie żądanie HEAD będzie przetwarzane we fragmencie znajdującym się za else (czyli tak jak POST)!

if request.get?
# serve authorization page HTML
else
# grant permissions to app
end

Czyli sytuacja jakbyśmy kliknęli przycisk: „daj uprawnienia tej aplikacji”! Jednak zostaje jeszcze jeden element do przejścia. GitHub ma wdrożoną ochronę przeciwko podatności CSRF. Ale.. stosuje ją tylko dla metod HTTP, które coś zmieniają (np. POST; to swoją drogą częste i najczęściej poprawne zalecenie w kontekście ochrony przed CSRF). Żądania typu GET czy HEAD w zasadzie nie powinny nic zmieniać, więc ochrona ta nie została wdrożona.

Finalnie więc na złośliwej stronie, którą odwiedza ofiara (zalogowana wcześniej do GitHuba), wywołujemy w jej imieniu (np. JavaScriptem) taki URL (metodą HEAD).

https://github.com/login/oauth/authorize?client_id=${CLIENT_ID}&scope=read:user&authorize=1

CLIENT_ID to nasza wcześniej zarejestrowana w GitHubie złośliwa aplikacja, która automatycznie dostaje uprawnienia – np. do odczytywania / zapisywania danych do konta ofiary. Wszystko dzieje się automatycznie. Game Over.

Badacz od GitHuba otrzymał $25 000, a przygotowanie łaty zajęło raptem 3h od zgłoszenia…

PS

Jak widać mamy tu mieszanie metodami HTTP, mamy podatność CSRF i wreszcie mamy OAuth – wszystkie te tematy omawiamy w naszej książce: Bezpieczeństwo aplikacji webowych.

–ms

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



Komentarze

  1. wk

    Ładne.

    Odpowiedz
  2. Sprzedawca Malin

    Githabowa Amatorka. Ja w kodzie zawsze mam:

    if GET:

    else if POST:

    else 'dupa’

    Odpowiedz

Odpowiedz na Sprzedawca Malin