Wyszukiwarki zostały stworzone do indeksowania treści. Jednak atakujący używają ich do indeksowania błędów. Zapytanie allintext:login typ pliku:log Może wydawać się nieszkodliwy. W rzeczywistości jest to jeden z najprostszych sposobów na odkrycie ujawnionych plików dziennika zawierających przepływy uwierzytelniania, dane uwierzytelniające, tokeny i dane infrastruktury wewnętrznej.
Jeśli Google może zobaczyć te logi, atakujący również mogą. Po zindeksowaniu, ujawnienie danych staje się nieuniknione. Co więcej, gdy dane uwierzytelniające pojawiają się w publicznie dostępnym pliku, naruszenie bezpieczeństwa jest już w toku.
1. Dlaczego allintext:login filetype:log jest bardziej niebezpieczny niż wygląda
„Google dork” to zapytanie wyszukiwania, które wykorzystuje zaawansowane operatory do lokalizowania poufnych lub błędnie skonfigurowanych treści indeksowanych przez wyszukiwarki. Nie wykorzystuje ono Google. Zamiast tego wykorzystuje Twoje ujawnienie.
To zapytanie łączy dwa operatory:
- allintext: zwraca strony, na których wszystkie terminy pojawiają się w tekście głównym
- typ pliku:log ogranicza wyniki do
.logpliki
W związku z tym:
Oznacza: "Pokaż mi pliki dziennika zawierające słowo login".
Na pierwszy rzut oka wydaje się to błahe. Jednak w praktyce często zwraca:
- Publicznie ujawnione logi serwera WWW
- CI/CD logi przesłane jako artefakty
- Przypadkowe debugowanie logów commitdo repozytoriów
- Dzienniki aplikacji z poświadczeniami w postaci zwykłego tekstu
To nie jest błąd wyszukiwarki. To raczej podatność na ujawnienie danych spowodowane błędną konfiguracją. Google po prostu indeksowało to, co było publicznie dostępne.
2. Co atakujący faktycznie znajdują w ujawnionych plikach dziennika?
Kiedy atakujący uciekają allintext:login typ pliku:log, nie przeglądają sieci losowo. Szukają śladów uwierzytelniania.
2.1 Poświadczenia w postaci zwykłego tekstu
W dziennikach często znajdują się wpisy takie jak:
or
Albo nawet dane uwierzytelniające SMTP:
Rejestrowanie danych uwierzytelniających to jeden z najszybszych sposobów na wyciek danych uwierzytelniających. W rezultacie pojedynczy ujawniony plik dziennika może unieważnić cały model kontroli dostępu.
2.2 Tokeny sesji i JWT
Nawet jeśli hasła nie są rejestrowane, tokeny często są.
Na przykład:
Prawidłowy plik JWT lub plik cookie sesji w .log plik może włączyć:
- Sesja porwania
- Eskalacja uprawnień
- Ruch boczny w obrębie układów wewnętrznych
Innymi słowy, tokeny w logach zamieniają dane wyjściowe debugowania w wektor omijający uwierzytelnianie.
2.3 CI/CD Artefakty
Dzienniki budowy są szczególnie niebezpieczne. W rzeczywistości, CI/CD Systemy często drukują zmienne środowiskowe podczas etapów kompilacji.
Napastnicy często odkrywają:
Zawierające linie takie jak:
If CI/CD Artefakty są publiczne, więc sekrety są publiczne. Google dork po prostu przyspiesza odkrywanie.
2.4 Dane w chmurze i infrastrukturze
Odsłonięte logi często ujawniają:
- Klucze dostępu AWS
- Ciągi połączeń z magazynem Azure
- Wewnętrzne adresy URL usług
- Dane uwierzytelniające bazy danych
- Punkty końcowe Redis
Nawet jeśli dane uwierzytelniające zostaną później wymienione, atakujący będzie teraz posiadał:
- Mapowanie infrastruktury
- Konwencje nazewnictwa
- Wywiad docelowy na potrzeby przyszłych ataków
Dlatego udostępnione dzienniki umożliwiają zarówno dostęp, jak i rozpoznanie.
3. W jaki sposób te dzienniki stają się publiczne?
Logi nie pojawiają się magicznie w Google. Są indeksowane, ponieważ były publicznie dostępne.
3.1 Nieprawidłowo skonfigurowane serwery WWW
Typowe wzorce obejmują:
/logs/katalogi dostępne bez uwierzytelniania- Włączono listę katalogów
- Nginx lub Apache obsługujący surowe dane
.logpliki
Jeśli do dziennika można dotrzeć przez HTTP, jest on indeksowalny.
3.2 CI/CD Narażenie na artefakty
Typowe błędy:
- Artefakty publiczne włączone w Akcje GitHub
- Logi przesłane do otwartych kontenerów S3
- Pipeline ślady dostępne bez uwierzytelniania
A pipeline który przechowuje logi w publicznym kontenerze, skutecznie publikuje swoje sekrety.
3.3 Tryb debugowania w środowisku produkcyjnym
Domyślne ustawienia frameworka mogą być niebezpieczne:
Ponadto nadmierne rejestrowanie żądań może spowodować wydrukowanie:
- Nagłówki
- Żetony
- Pełne treści żądań
Rejestrowanie debugowania w środowisku produkcyjnym przekształca Twoją aplikację w eksporter poświadczeń.
3.4 Dzienniki Dockera i kontenerów
Środowiska kontenerowe wprowadzają nowe ścieżki ekspozycji:
- Dzienniki zamontowane w woluminach współdzielonych
- Sidecary eksportujące logi do niezabezpieczonych punktów końcowych
- Zaloguj dashboardz dostępem publicznym
Jeśli logi kontenerów są udostępniane przez HTTP lub otwartą pamięć masową, można je przeszukiwać. Ostatecznie są indeksowane.
4. Realistyczny przebieg ataku: od głupka do włamania
Typowy łańcuch ataku wygląda następująco:
Atakujący biegnie:
- Znaleziska odsłonięte
.logfilet - wyciągi:
- Token JWT
- Nagłówek uwierzytelniania podstawowego
- Ciąg połączenia z bazą danych
Próba uwierzytelnienia względem:
- Punkty końcowe interfejsu API
- Panele administracyjne
- Usługi wewnętrzne
Jeśli uwierzytelnienie powiedzie się, atakujący może:
- Zwiększ uprawnienia
- Poruszać się bocznie
- Uzyskiwania dostępu CI/CD
- Naruszyć łańcuch dostaw
To, co zaczęło się jako zapytanie wyszukiwania, staje się:
- Sesja porwania
- Wewnętrzne wypełnianie poświadczeń
- Pipeline Przejęcie
- Zatrucie artefaktem
Wszystko z publicznie indeksowanego pliku dziennika.
5. Dlaczego rejestrowanie „zbyt dużej ilości” danych stanowi problem bezpieczeństwa aplikacji
Rejestrowanie nie jest neutralne. Zamiast tego tworzy wtórny magazyn danych.
Jeśli zapisujesz poufne dane, w istocie tworzysz drugą kopię swoich sekretów.
Jednak logi są często wykluczane z modelowania zagrożeń. W STRIDE jest to wyraźnie odwzorowane na:
Ujawnienie informacji
Dlatego zabezpiecz SDLC praktyki powinny traktować dzienniki jako:
- Artefakty istotne z punktu widzenia bezpieczeństwa
- Aktywa wrażliwe
- Elementy infrastruktury wymagające ochrony
Jeśli model zagrożeń ignoruje logi, jest niekompletny.
6. Jak zapobiegać wyciekom danych uwierzytelniających w plikach dziennika
6.1 Zatrzymaj rejestrowanie sekretów
Nigdy nie loguj:
- hasła
- Żetony
- Klucze API
- Identyfikatory sesji
- Nagłówki autoryzacji
Nawet w trybie debugowania.
W miarę możliwości należy wdrożyć funkcję automatycznego redagowania.
6.2 Ustrukturyzowane i bezpieczne rejestrowanie
Użyj strukturalnego rejestrowania z maskowaniem i filtrowaniem.
Przykład (Node.js):
Przykład (Python):
Podstawowa zasada jest prosta: sekrety nigdy nie mogą trafić do ujścia dziennika.
6.3 Blokada przechowywania dziennika
Kontrola bezpieczeństwa powinna obejmować:
- Wyłącz listę katalogów
- Chronić
/logs/ścieżki z uwierzytelnianiem - Ogranicz dostęp do wiadra
- Zastosuj zasady przechowywania
- Szyfruj dzienniki w stanie spoczynku
Dostęp do logów nie może być nigdy publiczny poprzez protokół HTTP.
6.4 CI/CD Guardrails
Ręczne przeglądy są niewystarczające. Zamiast tego wdroż zautomatyzowane kontrole:
- Tajne skanowanie dzienników przed publikacją artefaktu
- Nieudane kompilacje w przypadku wykrycia tokenów
- Zapobiegaj przesyłaniu artefaktów zawierających dane uwierzytelniające
- Walidacja skrótu dla artefaktów
CI/CD należy zablokować ujawnienie przed indeksowaniem.
7. W jaki sposób Xygeni zapobiega allintext:login typ pliku: log Incydenty
Problemem nie jest Google dork. Problemem jest ujawnienie. Dlatego zapobieganie musi nastąpić przed indeksowaniem.
7.1 Wykrywanie sekretów w logach i artefaktach
Skanowanie Xygeni:
- Dzienniki aplikacji
- CI/CD ślady pracy
- Twórz artefakty
- Warstwy Dockera
- Serializowane wyjścia
Jeśli w polu pojawią się dane uwierzytelniające, tokeny lub wartości poufne, .log pliki, Xygeni natychmiast je oznacza.
7.2 CI/CD Guardrails Ta ekspozycja bloku
Zamiast polegać na ręcznych recenzjach, Xygeni zapewnia bezpieczeństwo w pipeline poziom:
To:
- Kompilacje kończą się niepowodzeniem, gdy w logach pojawiają się sekrety
- Publikacja artefaktów bloków
- Zapobiega przypadkowemu narażeniu publicznemu
- Zatrzymuje niebezpieczne połączenia przed dotarciem do głównego
Jeśli zadanie CI drukuje token, pipeline zawiedzie.
Brak indeksowania.
Brak ekspozycji.
Bez incydentów.
7.3 Ochrona przed przesunięciem w lewo, zanim Google ją zobaczy
Czas ma znaczenie.
Zamiast reagować na:
Xygeni zatrzymuje problem:
- At commit czas
- Podczas pull request uprawomocnienie
- Podczas pipeline egzekucja
- Przed publikacją artefaktu
Jeśli dziennik nigdy nie zostanie upubliczniony, Google nigdy go nie zaindeksuje.
Podsumowanie: jeśli Google może to zaindeksować, atakujący już to zrobili
Logi nie są nieszkodliwe. W rzeczywistości rzadko są tymczasowe. Domyślnie nie są prywatne. Dlatego każdy plik logu powinien być traktowany jako zasób istotny dla bezpieczeństwa, a nie tylko jako wynik debugowania.
Jeśli wrażliwe dane dotrą do .log plik i staje się publicznie dostępny, natychmiast staje się powierzchnią ataku. Co więcej, po zindeksowaniu przez wyszukiwarkę, skala ekspozycji wykracza poza Twoją kontrolę.
Rozwiązaniem nie jest zaprzestanie rejestrowania danych. Chodzi raczej o odpowiedzialne rejestrowanie danych i egzekwowanie ścisłych kontroli nad przechowywaniem i dystrybucją. Innymi słowy, bezpieczeństwo musi wykraczać poza samą aplikację i obejmować warstwę obserwacji.
Zamiast:
- Przestań rejestrować sekrety
- Zablokuj przechowywanie dziennika
- egzekwować pipeline guardrails
- Zautomatyzuj wykrywanie i egzekwowanie zasad
Ostatecznie, Zapobieganie to kwestia czasu. Bo kiedy allintext:login typ pliku:log zwraca Twoją domenę, incydent już się rozpoczął.
