Dzisiaj pokażę Ci 4 drobne błędy w oprogramowaniu Kallithea1, które umożliwiają dostęp do cudzych danych.
Kallithea to serwer Git napisany w Pythonie. Jest to więc alternatywa dla GitHuba.
Wspiera również mniej znany system kontroli wersji - Mercurial.
Popatrzmy na pierwszy błąd.
Uprawnienia użytkowników w całej aplikacji są weryfikowane przy pomocy dekoratorów.
Za każdym razem gdy chcemy sprawdzić, czy użytkownik posiada uprawnienia do danej funkcjonalności - zamiast wywoływać funkcję HasRepoPermission - możemy użyć dekoratorów.
W Pythonie - odbywa się to przy pomocy @.
Takie rozwiązanie poprawia czytelność kodu.
Od razu wiadomo, która metoda wymaga jakich uprawnień, ale jej używanie niesie pewne ryzyko.
Jeżeli bowiem nie umieścimy żadnego dekoratora aplikacja będzie myślała, że dany użytkownik ma pełne uprawnienia do danej metody.
Poszukując błędów sprawdzamy wszystkie metody na serwerze i upewnieniamy się, że wszędzie dodane są prawidłowe dekoratory.
Po kilku minutach analizy kodu można zauważyć, że programiści zapomnieli o jednym miejscu2.
Pech chciał, że to miejsce jest odpowiedzialne za sprawdzanie uprawnień dostępu do konkretnego repozytorium.
Jeżeli więc znamy nazwę czyjegoś repozytorium, możemy dodać siebie samych jako administratorów.
Dzięki temu automatycznie uzyskujemy nieautoryzowany dostęp do kodu, który nie należy do nas.
Sprawdźmy to. Modyfikuję uprawnienia dostępu do repozytorium którego jestem właścicielem.
Następnie zmieniam nazwę repozytorium na to, które chcę zaatakować i wysyłam żądanie ponownie.
Mogę teraz bez problemu odczytać treść pliku sekret.
Kolejne błędy są możliwe do wykonania jedynie z poziomu API.
Ten serwer bowiem oprócz obsługi poprzez interfejs webowy pozwala na wykonywanie pewnych czynności z poziomu API.
To kolejne miejsce, które powinno zwrócić uwagę pentestera.
Jeżeli aplikacja działa poprawnie poprzez przeglądarkę nie oznacza to, że będzie działała prawidłowo z poziomu API.
Ten serwer pozwala na tworzenie repozytoriów na podstawie innych repozytoriów.
Podczas tworzenia nowego repozytorium możemy podać adres do innego serwera, z którego pobrane zostaną dane.
Dzięki temu możemy w prosty sposób zaimportować pliki z innego serwera.
Standardowe użycie tej funkcjonalności to podanie adresu HTTP serwera - na przykład na GitHubie.
Ale my jesteśmy pentesterami i staramy się wywołać daną funkcjonalność w sposób nieprzewidziany przez programistę.
Może nie wszyscy z was wiedzą, że funkcja git clone (odpowiedzialna za kopiowanie danych z zewnętrznego serwera) oprócz obsługi protokołu HTTP pozwala również na podawanie lokalnych ścieżek.
Jeżeli znamy nazwę repozytorium - możemy odgadnąć ścieżkę w jakiej jest ono przechowywane na serwerze Kallithea.
W standardowej instalacji jest to katalog c:\kalithearepos\nazwa repozytorium.
Wystarczy więc w miejscu do klonowania podać właśnie tą ścieżkę.
Wtedy serwer automatycznie skopiuje pliki do których nie posiadaliśmy dostępu i stworzy na ich podstawie nasze nowe repozytorium.
Musimy to zrobić poprzez wywołanie API - interfejs webowy bowiem sprawdza poprawność adresu do klonowania.
Potrzebujemy zatem klucza API, który można pobrać z panelu użytkownika.
W trzecim błędzie serwer nie sprawdzał czy nazwa repozytorium jest prawidłowa, jeżeli tworzyliśmy je poprzez API.
A jest to ważne, ponieważ na podstawie nazwy serwer tworzy katalog na dysku, w którym przechowywane są wszystkie dane.
Jeżeli w nazwie znajduje się ../ lub ..\ system potraktuje to jako komendę: przejdź katalogu wyżej i stworzy katalog nie tam gdzie powinien - a w innym, kontrolowanym przez użytkownika miejscu.
Tak jak w tym przykładzie, gdzie repozytorium zostało stworzone w katalogu python a nie repos.
Ostatni błąd jest również powiązany z nazwą repozytorium
Oprócz tego, że mogliśmy tam podać kropkę i slash serwer przyjmował dowolny znak ASCII.
Możliwe więc było stworzenie repozytorium, którego nazwa była payloadem XSS.
Następnie taka nazwa jest wyświetlana w kilku miejscach na serwerze, co może doprowadzić do przejęcia czyjegoś konta.
Wystarczy bowiem, że spreparujemy odpowiednia nazwę i poczekamy, aż zostanie ono odwiedzone przez administratora serwera.
Wtedy możemy wykonać jakieś akcje w jego imieniu.
Icon made by Freepik, justicon, Iconnice from www.flaticon.com
