Firma Truffle Security opublikowała scenariusze ataków na kilka typowych metod pracy z repozytoriami na GitHubie, które pozwalają na pozyskiwanie danych z zdalnych repozytoriów posiadających publiczne forki lub stworzonych jako forki.
Możliwość dostępu do commitów po hashu we wszystkich powiązanych forkach repozytoriów wynika z tego, że GitHub w celu optymalizacji i eliminacji duplikatów przechowuje wszystkie obiekty z głównego repozytorium i forków razem, logicznie dzieląc przynależność commitów. Takie przechowywanie pozwala na przeglądanie w głównym repozytorium dowolnego commita z każdego forka, wyraźnie określając jego hash w URL. Na przykład, użytkownik może stworzyć fork repozytorium '/torvalds/linux' i dodać do niego dowolny kod, po czym kod ten stanie się dostępny pod bezpośrednim linkiem hashu w repozytorium '/torvalds/linux'. W przypadku usunięcia repozytorium, jeżeli istnieje choćby jeden publiczny fork, dane z usuniętego repozytorium pozostają dostępne po hashu commita.
Zaproponowano trzy scenariusze, które stanowią zagrożenie dla bezpieczeństwa:
- Pierwszy scenariusz dotyczy sytuacji, w których deweloperzy tworzą forki publicznych repozytoriów, wprowadzają w nich zmiany, eksperymentują, a następnie je usuwają. Oprócz wycieku kodu, który nie jest przeznaczony do publikacji, niebezpieczeństwo stanowi sytuacja, w której w eksperymentach w kodzie plików z przykładami są dodawane aktywne klucze dostępu do API. W takim przypadku atakujący może uzyskać dostęp do zmiany po hashu commita, kierując się po usunięciu forka przez główne repozytorium. Na przykład, w sposób zaproponowany przez badaczy udało im się zidentyfikować 30 aktywnych kluczy dostępu do API, analizując trzy powiązane z machine learning repozytoria z dużą liczbą forków.
- Drugi scenariusz dotyczy możliwości uzyskania dostępu do danych po usunięciu pierwotnego repozytorium, jeśli dla tego repozytorium utworzono fork. Jako przykład podano przypadek, w którym w publicznym repozytorium jednej firmy przypadkowo opublikowano klucze prywatne jednego z pracowników, które zapewniają pełny dostęp do wszystkich repozytoriów tej firmy na GitHubie. Firma usunęła repozytorium, z którego doszło do wycieku, ale klucze pozostały nadal dostępne do wydobycia poprzez zapytania po hashu commitów w repozytoriach z forkami.
- Trzeci scenariusz związany jest z modelem rozwoju projektów, które rozwijają podstawową otwartą wersję w publicznym repozytorium oraz rozszerzoną wersję prywatną w repozytorium prywatnym. Jeśli firma początkowo rozwijała projekt w prywatnym repozytorium, a następnie po otwarciu kodu projektu przeniosła go do kategorii publicznych, ale kontynuowała rozwój zamkniętej wewnętrznej lub rozszerzonej wersji w prywatnym forku, istnieje możliwość dostępu do zmian dodanych do prywatnego forka po hashach commitów poprzez publiczne repozytorium. Przy tym dostęp możliwy jest tylko do zmian dodanych do prywatnego forka przed przeniesieniem głównego repozytorium do kategorii publicznych (repozytoria prywatne i publiczne są oddzielone, ale gdy dwa repozytoria były prywatne, commity były przechowywane wspólnie, dlatego pozostały w repozytorium po jego przeniesieniu do kategorii publicznych).
Sztuczka umożliwiająca dostęp do commitów w forkach repozytorium poprzez link do głównego repozytorium jest znana od wielu lat i okresowo używana do różnych żartów oraz wprowadzania w błąd programistów (na przykład żartownisie okresowo w ten sposób tworzą wrażenie podstawiania backdoorów w repozytorium jądra Linux na GitHubie). Jako środek przeciwdziałający takim żartom, GitHub dodał ostrzeżenie, że żądany commit nie należy do gałęzi w bieżącym repozytorium i może należeć do forka. Przy tym sama możliwość dostępu do commitów po hashu w jakichkolwiek powiązanych forkach repozytoriów traktowana była jako nieszkodliwa, ponieważ dla uzyskania danych w zdalnych i prywatnych forkach potrzebna była znajomość hasha commita.
Znalezienie hasha commita, generowanego na podstawie algorytmu SHA-1 i zawierającego 32 znaki, jest niemożliwe, ale okazało się, że nie jest to również wymagane. GitHub obsługuje skróconą formę odniesienia do commitów, pozwalającą adresować zmiany przy użyciu kilku pierwszych znaków hasha, jeśli nie ma nakładania się z innymi commitami. Minimalna liczba znaków do skrótu hasha wynosi 4, co odpowiada 65 tysiącom kombinacji (16^4). Przy tym, możliwe jest, że analiza nie będzie konieczna, ponieważ API GitHub umożliwia podłączanie handlerów do przechwytywania zdarzeń, które są używane przez zewnętrzne projekty prowadzące archiwum z pełnym logiem wszystkich operacji, w którym informacje o hashach commitów pozostają nawet po usunięciu repozytoriów.
Źródło: opennet.ru
