Dla łowców nagród za błędy repozytoria GitHub mogą ujawnić wiele potencjalnie przydatnych informacji. Mogą wystąpić problemy z celami, które nie zawsze są open source. Czasami informacje, które mogłyby zostać wykorzystane przeciwko firmie docelowej, są omyłkowo ujawniane przez członków organizacji i ich inicjatywy open source. W tym artykule przedstawię krótki przegląd, który powinien pomóc Ci rozpocząć skanowanie repozytoriów GitHub w poszukiwaniu luk w zabezpieczeniach i przeprowadzanie ogólnego rekonesansu.

1-masowe klonowanie

Możesz po prostu przeprowadzić swoje badania na github.com, jednak aby umożliwić lokalne testy, radzę sklonować każde docelowe repozytorium. GitHubCloner autorstwa @mazen160 to fantastyczny produkt. Wszystko, co musisz zrobić, to wykonać skrypt, aby być gotowym do pracy.

$ python githubcloner.py --org organization -o /tmp/output

      
                

                    
                    
                
            

Istotne jest, aby rzeczywiście zrozumieć projekt, do którego dążysz, przed rozpoczęciem analizy statycznej. Korzystaj z podstawowych funkcji podczas uruchamiania projektu. Powodem, dla którego nazywam to „krokiem Joberta”, jest to, że słyszałem, że przed rozpoczęciem każdego polowania, Jobert używa projektu i dobrze rozumie cel, zanim zacznie szukać słabych punktów.

3- Analiza ręczna

W tej sytuacji sprawdza się powiedzenie „naucz się robić, a potem psuj” . Jeśli potrafisz nauczyć się języka programowania, powinieneś być w stanie zrozumieć tajniki środków ostrożności, których należy przestrzegać, a których należy unikać.

Grepowanie można rozpocząć po zapoznaniu się z celem i jego architekturą. Poszukaj słów kluczowych, które Cię interesują, które znasz lub wiesz, że programiści często się mylą.

Oto podstawowa lista niektórych wyszukiwanych haseł, których użyję podczas pierwszej ogólnej oceny:

• API i klucz. (Zdobądź więcej punktów końcowych i znajdź klucze API).
• znak
• sekret
• DO ZROBIENIA
• hasło
• wrażliwy
• http:// i https://

• CSRF
• losowy
• haszysz
• MD5, SHA-1, SHA-2 itd.
• HMAC

Kolejnym krytycznym krokiem jest przejrzenie historii zatwierdzeń. Będziesz zaskoczony, jak wiele informacji możesz uzyskać z zatwierdzeń. Widziałem, jak współpracownicy błędnie wierzyli, że usunęli poświadczenia, podczas gdy pozostają one w historii zatwierdzeń. Dzięki historii git odkryłem starożytne punkty końcowe, które nadal działają. Oprócz bieżących problemów możesz natknąć się na problemy historyczne, których można uniknąć dzięki starym zatwierdzeniom.

4- Narzędzia

Czasami automatyzacja nudnych zadań może pomóc w uzyskaniu podstawowego przeglądu tego, czego szukać. Należy pamiętać, że nigdy nie należy kopiować i wklejać wyników skanowania do raportów. Otrzymasz wiele fałszywych alarmów, więc zawsze powinieneś dokładnie zbadać wszelkie potencjalne problemy, aby upewnić się, że można je wykorzystać.

Głównym narzędziem, którego używam podczas realizacji projektów w Pythonie, jest Bandit .

Bandit zidentyfikuje typowe problemy, ale często zwraca fałszywe alarmy lub nisko wiszące owoce. Więc używaj go ostrożnie. Bez wątpienia nie należy na nim polegać.

$ bandit -r path/to/your/code -ll

Snyk.io to wspaniałe narzędzie do sprawdzania zależności. Platforma obsługuje szeroką gamę języków.

Dla rozpoznania wielu badaczy sugeruje użycie Gitrob . To narzędzie będzie szukać poufnych informacji w publicznych repozytoriach GitHub.

$ gitrob analyze acme,johndoe,janedoe

$ truffleHog https://github.com/dxa4481/truffleHog.git

W przypadku aplikacji Ruby on Rails polecam Brakeman . Brakeman to skaner bezpieczeństwa do analizy statycznej, który może znaleźć mnóstwo różnych problemów związanych z bezpieczeństwem w kodzie.

Użyj LinkFinder autorstwa Gerbena Javado, aby znaleźć punkty końcowe w plikach JS repozytorium.

$ python linkfinder.py -i 'path/to/your/code/*.js' -r ^/api/ -o cli

OK, poważnie, nie socjotechniczni właściciele projektów.

Zgłaszanie wyników

Jak zawsze, jeśli chodzi o polowanie na nagrody za błędy, przeczytaj dokładnie zasady programu. Bardzo rzadko program akceptuje raporty przez GitHub. Skontaktuj się z zespołem ds. bezpieczeństwa lub, jeśli to możliwe, skorzystaj z platformy nagród za błędy, takiej jak HackerOne lub Bugcrowd

Na marginesie, fajną rzeczą w testowaniu białoskrzynkowym jest to, że mając dostęp do kodu, łatwiej jest zasugerować poprawkę lub przesłać łatkę.

DZIĘKI ZA PRZECZYTANIE TEGO!