Dorks, dorking – co to takiego?
Nazwa została odziedziczona po znanej technice wyszukiwania informacji w Google zwanej „Google dorks” lub „Google dorking”. W skrócie, technika ta oznacza wykorzystanie wyszukiwarki Google w celach ofensywnych lub badawczych. Zanim przejdziemy do opisu techniki GitHub dorks, opiszemy także pokrótce jej przodka, czyli technikę Google dorking.
Ten artykuł dostępny jest także w wersji video na Youtube.
Na początku było „Google dorking”
Nie wszyscy zdają sobie sprawę, że wyszukiwarka Google może pomóc nam filtrować wyniki wyszukiwania przy pomocy określonej składni. Istnieje wiele stron, na których można znaleźć dokumentację składni wyszukiwania – np. możecie zajrzeć tu. I tak przykładowo, jeżeli chcielibyśmy znaleźć wszystkie strony www zaindeksowane przez Google, które mają włączony listing katalogów, to możemy wpisać w wyszukiwarkę
intitle:”index of”
Zaznaczamy w tym miejscu, że w przypadku testu penetracyjnego, listowanie katalogów zazwyczaj może już pojawić się w raporcie jako luka bezpieczeństwa o niskim poziomie ryzyka – zależnie od tego, jakie pliki zostają wylistowane. Ale tę z pozoru niegroźną technikę można wykorzystać do znalezienia znacznie poważniejszych podatności wśród stron zaindeksowanych przez Google.
Projekt Google Hacking Database zawiera kilka tysięcy „dorków”, czyli fraz, które pozwalają na wyszukiwanie zaindeksowanych w Google serwisów po cechach charakterystycznych dla oprogramowania podatnego na konkretne błędy bezpieczeństwa. Np. jeżeli wiemy, że określone oprogramowanie w wersji 14.1 jest podatne na jakiś atak, a tytuł strony, która go używa, to domyślnie „Witaj w Mojeoprogramowanie 14.1„, to wyszukiwanie właśnie takiego tytułu (intitle) w Google może pozwolić nam na znalezienie wielu podatnych instancji tego produktu. Poniżej zamieszczamy fragment Google Hacking Database z przykładowymi „dorkami„, celującymi w znalezienie podatnych wersji znanego oprogramowania.
A co z tym GitHubem?
W jaki sposób można wykorzystać „dorking” na platformie GitHub? Otóż wyszukiwarka GitHub również posiada pewnego rodzaju charakterystyczną składnię i właściwości, co może czynić ją wartościowym źródłem informacji.
Kolejną interesującą informacją jest fakt, że w kodach źródłowych składowanych na tej platformie bardzo często znajdują się takie informacje jak:
- Klucze API
- Hasła i loginy
- Subdomeny i wewnętrzne adresy IP
- Certyfikaty służące do logowania
- Pliki konfiguracyjne
Skąd się tam biorą? Ciężko o jednoznaczną odpowiedź. Być może część osób nie zdaje sobie sprawy, że ktokolwiek mógłby tam w ogóle szukać i nie zastanawia się nad tym, co „commituje”. Być może też autorzy nie do końca wiedzą, co znajduje się w wypychanym kodzie (zwłaszcza, jeżeli np. jedna osoba zaczyna pisać fragment kodu, a dopiero druga poprawia i commituje), albo dochodzi do pomylenia repozytoriów prywatnych z publicznymi. Niezależnie od przyczyny, tego typu przypadki często się zdarzają. Jednocześnie jest to świetna okazja dla początkujących Bug Hunterów – ponieważ wyszukiwanie tego typu podatności charakteryzuje się niskim progiem wejścia (potrzebujesz tylko trochę czasu i samozaparcia, nie musisz za to znać złożonych technikaliów). Istnieje także prawdopodobieństwo, że przestępcy mogą przyjmować podobne strategie, dlatego też jeżeli korzystasz z GitHub’a jako developer czy programista – koniecznie upewnij się, co zawiera Twój kod.
Jak i czego szukać?
Jeżeli w wyszukiwarkę GitHub’a wpiszemy słowo kluczowe, to w wynikach wyszukiwania pojawi się możliwość zawężenia wyników po miejscach ich pochodzenia:
Jeżeli wybierzemy np. „users”, to wyszukiwarka pokaże nam tylko użytkowników o nazwie zawierającej wyraz „tesla”. Jeżeli w wyszukiwarce wpiszemy np. „org:teslamotors”, to wyniki będą pochodziły tylko od organizacji teslamotors, czyli popularnej firmy technologicznej (organizacja to rodzaj konta, z którym mogą być skojarzone konta użytkowników – np. programistów danej firmy)
Wybierając dalej „users” przejdziemy na stronę organizacji „Tesla, Inc”. Naszym oczom ukaże się strona organizacji w ramach GitHub, a w prawej części ekranu możemy zobaczyć wszystkich skojarzonych z nią użytkowników indywidualnych:
Oczywiście, nie jest wykluczone że Tesla zatrudnia więcej niż 10 programistów. Po prostu tylko osoby wyświetlone w profilu organizacji są oficjalnie „podpięte” do firmy. Dalej GitHub umożliwia także przeglądanie profilu określonego użytkownika pod kątem jego aktywności .
A jakie słowa kluczowe mogą być interesujące? Jest ich bardzo wiele, niektóre z nich to np.:
- 27017 mongo
- api_key
- secret_key
- BEGIN RSA PRIVATE KEY
- Itp.
Przykłady można by mnożyć w nieskończoność. W następnym akapicie opiszemy, jak nieco ułatwić sobie zadanie. Przy poszukiwaniu manualnym należy jeszcze zwrócić uwagę na jedną istotną kwestię – aby sortować wyniki od najnowszego. Istnieje wtedy szansa, że faktycznie wykryjemy wyciek danych – natomiast dane pochodzące np. sprzed roku prawdopodobnie są już nieaktualne.
Automatyzacja Github Dorks
Szukanie „sekretów” na GitHubie zawsze będzie pewnego rodzaju manualnym zadaniem – finalnie, będziemy musieli i tak zweryfikować, czy to, co znajdziemy to np. faktycznie jakieś poufne dane techniczne czy tylko np. dane przykładowe (tzw. placeholdery). Narzędzia, które znacznie mogą ułatwić nam to zadanie to np.:
– gitdorker (https://github.com/obheda12/GitDorker)
– githound (https://github.com/tillson/git-hound)
Te dwa narzędzia działają podobnie: dajemy im token API do GitHuba (jeżeli się boisz, to stwórz nowe konto i na nim wygeneruj token API), a one wykonują wyszukiwania. GitDorker jest dużo prostszy w obsłudze i zwraca plik .CSV podobny do poniższego – zawiera on URL’e do konkretnych wyników wyszukiwania:
W praktyce warto zacząć od tych, gdzie znaleziono najmniej dopasowań, a wyniki posortować od najnowszych. Często może zdarzyć się, że jakieś słowo kluczowe daje kilkaset dopasowań – wtedy musimy spróbować zawęzić jakoś kryteria manualnie (np. przeglądać tylko pliki w określonych formatach z wysokim prawdopodobieństwem bycia plikami konfiguracyjnymi jak .yaml czy .conf)
– trufflehog (https://github.com/dxa4481/truffleHog)
To narzędzie działa nieco inaczej – przyjmuje ono ścieżkę do repozytorium i przeszukuje je pod kątem sekretów – zarówno słów kluczowych, ale także wyszukuje ciągów znaków o wysokiej entropii (różnorodności). W ten sposób może być możliwe znalezienie nietypowo nazwanych zmiennych przechowujących sekrety… lub sum kontrolnych bibliotek .js i innych tego typu false positive’ów.
– keyhacks (https://github.com/streaak/keyhacks)
Na sam koniec, kiedy już mamy pełne dyski tajnych kluczy i nie do końca wiemy, co z nimi zrobić, powinniśmy udać się pod adres tego repozytorium, aby znaleźć zastosowanie naszych skarbów. Zawiera ono przykłady użycia konkretnych API tokenów – czyli jeżeli nasz token zadziała z żądaniem HTTP do niego pasującym, to prawdopodobnie znaleźliśmy tzw. sekret i możemy teraz poinformować posiadacza aplikacji lub odpowiedni program Bug Bounty. W tym drugim przypadku powinniśmy upewnić się, że dany program na pewno życzy sobie „sprawdzania czy token działa”, ponieważ czasami jest to niedozwolone.
Podsumowanie
GitHub Dorking jest efektywną i dość prostą metodą rozpoczęcia swojej przygody z Bug Bounty, ale może być również świetnym uzupełnieniem ćwiczeń Red Teamowych lub testów penetracyjnych na otwartym scope’ie.
Z kolei jeżeli jesteś developerem, programistą czy też z innych powodów korzystasz z publicznych repozytoriów GitHub’a, pamiętaj, żeby oczyścić swój kod z „sekretów”.
Na dokładkę zamieszczamy też linki do ciekawych raportów i opisów podatności:
https://hackerone.com/reports/397527
https://hackerone.com/reports/360811
https://medium.com/@cosmobugbounty/bounty-of-the-week-15-000-snapchat-leak-af38f882d3ac
https://tillsongalloway.com/finding-sensitive-information-on-github/index.html
