Rickroll w repo i bomba w (niezbyt) głębokim ukryciu

Podatności aplikacji webowych miewają różną genezę. Mogą być niezawinione – błędom typu 0-day nie da się skutecznie zapobiec. Mogą być w pełni zawinione – gdy w trzeciej dekadzie XXI wieku programista pisze kod podatny na SQL injection. Mogą być też wynikiem roztargnienia lub nieuwagi – np. wtedy, gdy na świat wystawione zostanie repozytorium kodu, w którym przechowywana jest owa aplikacja. Nieuprawniony dostęp do takiego repozytorium może oznaczać przejęcie kontroli nad całą webaplikacją – gdy w kodzie źródłowym albo plikach konfiguracyjnych znajdziemy hasło do bazy danych, klucze prywatne do usług chmurowych albo plik tekstowy z hasłem administratora. Podobnie stanie się, gdy operator zapisze kopię bezpieczeństwa do pliku backup.zip zlokalizowanego w głównym katalogu witryny.

Ja postanowiłem zażartować sobie z osób, które szukają takich podatności.

Trojański backup.zip, który wybucha

Z kopią bezpieczeństwa było łatwo – plik https://informatykzakladowy.pl/backup.zip to tak zwana ZIP-bomba. Jest to archiwum plików spreparowane w taki sposób, aby zawartość po rozpakowaniu zajmowała możliwie najwięcej miejsca. Skorzystałem z wariantu opisanego na stronie bamsoftware.com – choć sam plik ZIP ma niespełna 10 megabajtów, to do zapisania zdekompresowanej zawartości potrzeba 281 terabajtów. Dla porównania – typowy dysk twardy w domowym komputerze ma nie więcej niż dwa terabajty.

W dzisiejszych czasach ZIP-bomby są raczej niegroźne – antywirusy nie próbują rozpakować archiwów przed skanowaniem, zaś sygnatury znanych egzemplarzy pozwalają na ich ignorowanie. Zawsze można mieć jednak nadzieję, że plik znajdzie świeżak, zajrzy do środka i… czegoś się przy tej okazji nauczy.

Nieco inne treści czekały na osoby poszukujące repozytoriów kodu git, których obecność w danej witrynie można zweryfikować sięgając do pliku .git/config albo .git/HEAD (np. informatykzakladowy.pl/.git/HEAD). Można robić to ręcznie, można automatycznie, można też użyć rozszerzenia DotGit by sprawdzać każdą witrynę, jaką zdarzy nam się odwiedzić.

Miałem nadzieję, że osoby przeprowadzające rekonesans nie powstrzymają ciekawości i ściągną zawartość mojego repozytorium na dysk. Czekała na nie zawartość mająca przypominać kopię bezpieczeństwa – z plikami backup.zip oraz pass.txt. Wiele systemów operacyjnych ukrywa rozszerzenia znanych typów plików, liczyłem więc, że końcówka pełnej nazwy backup.zip.mp4 zostanie przez ciekawskich przeoczona.

zawartość repozytorium z serwisu informatykzakladowy.pl

Co takiego mógł zobaczyć znalazca repozytorium, gdy podekscytowany otworzył domniemane archiwum? Oczywiście złotą kolekcję klasyki, czyli Rickroll. Z kolei w pliku pass.txt znajdował się mój e-mail i pytanie, czy żarcik się udał.

Kto złapał się na dowcip?

Jak widzicie na obrazku, eksperyment został odpalony w czerwcu 2023. Przez następne osiem miesięcy dostałem łącznie 11 e-maili informujących mnie o wystawionym na świat repozytorium. Zgłaszających można podzielić na kilka grup.

• Grupa pierwsza to piątka ludzi, którzy pobrali repozytorium, zajrzeli do środka i napisali mi, że żarcik się udał.
• Grupa druga to trójka osób, które dały jedynie znać o tym, że repo jest widoczne i nie weszły w dalsze interakcje.

Rozbawiła mnie grupa trzecia czyli dwie osoby wyraźnie przejęte znaleziskiem lub przestraszone swoją śmiałością. Dialog szedł jakoś tak:

– całkowicie przypadkiem znalazłem .git/HEAD, być może powinieneś ukryć to repozytorium
– czy zaglądałeś do środka?!
– nie, oczywiście, że nie
– na pewno??!
– stary, nigdy bym się nie ośmielił, jak bum cyk cyk, rączki na kołderce

Tym osobom to ja musiałem powiedzieć, o co chodziło w dowcipie.

Na końcu był jeden automatyczny e-mail z serwisu Repo Lookout, którego celem jest odnajdywanie takich właśnie ujawnionych przypadkowo repozytoriów i ostrzeganie właścicieli witryn. Potem zapadła cisza, od lutego 2024 nie dostałem już żadnej nowej wiadomości – czas więc opublikować niniejszy raport.

Czy git wystawiony na świat to popularna podatność?

jedno z repozytoriów odnalezionych za pomocą DotGit

W roku 2025 – raczej nie. Najbardziej spektakularnym przypadkiem tego typu był chyba wyciek kodu japońskiego eBaya w roku 2018. W tym samym roku niezależny badacz bezpieczeństwa przeskanował 230 milionów witryn i odkrył aż 390 tysięcy repozytoriów – ciężko jednak określić, ile z nich znalazło się tam celowo (za informację podziękował co setny adresat). Pośród raportów serwisu HackerOne takich znalezisk jest raptem kilka. Moje przeglądarkowe rozszerzenie DotGit przez półtora roku wykryło 18 repozytoriów, z których jedynie dwa były kompletne i zawierały rzeczywistą historię zmian zawartości witryn.

Automatyczny skan typowych problematycznych URL-i powinien być jednak częścią każdego testu penetracyjnego. Nieuprawniony dostęp do repozytorium kodu może narazić firmę na utratę reputacji, odpowiedzialność prawną oraz wielki rachunek za usługi chmurowe skonsumowane przez przestępców – i trudno z góry określić, który z tych scenariuszy będzie najgorszy.

Autorem artykułu jest Tomasz Zieliński, autor szkolenia z automatyzacji pobierania danych z internetu (scrapowanie.pl), w wolnych chwilach prowadzący bloga Informatyk Zakładowy (informatykzakladowy.pl). Za publikację nie otrzymaliśmy wynagrodzenia, ale otrzymamy inne benefity. A Tomek pięknie potrafi przekazać wiedzę, więc jak potrzebujecie kompetencji ze scrapingu, to polecamy kliknąć w link wyżej. Nie zawiedziecie się.”