A keresőmotorokat tartalom indexelésére tervezték. A támadók azonban a hibáid indexelésére használják őket. A lekérdezés allintext:login fájltípus:napló ártalmatlannak tűnhet. A valóságban ez az egyik legegyszerűbb módja a hitelesítési folyamatokat, hitelesítő adatokat, tokeneket és belső infrastrukturális adatokat tartalmazó nyilvánosságra hozott naplófájlok felderítésének.
Ha a Google láthatja ezeket a naplókat, akkor a támadók is. Az indexelés után a leleplezés elkerülhetetlen. Sőt, amikor a hitelesítő adatok megjelennek egy nyilvánosan hozzáférhető fájlban, a behatolás már folyamatban van.
1. Miért minden szövegben:login A filetype:log veszélyesebb, mint amilyennek látszik
A Google dork egy olyan keresési lekérdezés, amely fejlett operátorokat használ a keresőmotorok által indexelt érzékeny vagy rosszul konfigurált tartalmak megkeresésére. Nem a Google-t használja ki, hanem a felhasználó láthatóságát.
Ez a lekérdezés két operátort kombinál:
- allintext: olyan oldalakat ad vissza, ahol az összes kifejezés szerepel a szöveg törzsében
- fájltípus:napló korlátozza az eredményeket
.logfájlok
Ebből adódóan:
Jelentése: „Mutasd azokat a naplófájlokat, amelyek tartalmazzák a szót login. "
Első pillantásra ez triviálisnak tűnik. A gyakorlatban azonban gyakran a következő eredményt kapjuk:
- Nyilvánosan közzétett webszerver naplók
- CI/CD naplók feltöltése műtermékként
- Naplók véletlen hibakeresése committed a tárházakba
- Alkalmazásnaplók egyszerű szöveges hitelesítő adatokkal
Ez nem egy keresőmotor-hiba. Inkább egy adatkiszivárgási sebezhetőség a helytelen konfiguráció okozta. A Google egyszerűen csak azt indexelte, ami nyilvánosan elérhető volt.
2. Mit találnak a támadók a kiszivárgott naplófájlokban?
Amikor a támadók elfutnak allintext:login fájltípus:napló, nem véletlenszerűen böngészik. Hitelesítési nyomokat keresnek.
2.1 Sima szöveges hitelesítő adatok
A naplók gyakran tartalmaznak olyan bejegyzéseket, mint például:
or
Vagy akár SMTP hitelesítő adatok:
A hitelesítési adatok naplózása az egyik leggyorsabb módja a hitelesítő adatok kiszivárogtatásának éles környezetben. Következésképpen egyetlen kiszivárgott naplófájl érvénytelenítheti a teljes hozzáférés-vezérlési modellt.
2.2 Munkamenet-tokenek és JWT-k
Még ha a jelszavakat nem is naplózzák, a tokeneket gyakran igen.
Például:
Egy érvényes JWT vagy munkamenet-süti egy .log a fájl engedélyezheti:
- Munkamenet eltérítése
- Privilege eszkaláció
- Oldalirányú mozgás a belső rendszereken keresztül
Más szóval, a naplókban található tokenek a hibakeresési kimenetet hitelesítést megkerülő vektorrá alakítják.
2.3 CI/CD Mesterséges
Az építési naplók különösen veszélyesek. Valójában CI/CD A rendszerek gyakran környezeti változókat nyomtatnak ki a build lépései során.
A támadók gyakran felfedezik:
Olyan sorokat tartalmaz, mint:
If CI/CD A tárgyak nyilvánosak, majd a titkok nyilvánosak. A Google idiótája egyszerűen felgyorsítja a felfedezést.
2.4 Felhő- és infrastruktúra-adatok
A kiszivárgott naplók gyakran a következőket mutatják ki:
- AWS hozzáférési kulcsok
- Azure Storage-kapcsolati karakterláncok
- Belső szolgáltatás URL-címei
- Adatbázis hitelesítő adatok
- Redis végpontok
Még ha a hitelesítő adatokat később módosítják is, a támadó akkor is rendelkezik a következőkkel:
- Infrastruktúra-térképezés
- Elnevezési konvenciók
- Célfelderítés a jövőbeli támadásokhoz
Ezért a kitett naplók hozzáférést és felderítést is biztosítanak.
3. Hogyan válnak ezek a naplók nyilvánossá
A naplók nem varázsütésre jelennek meg a Google-ben. Azért indexelődnek, mert nyilvánosan elérhetőek voltak.
3.1 Rosszul konfigurált webszerverek
Gyakori minták a következők:
/logs/hitelesítés nélkül elérhető könyvtárak- Címtárlista engedélyezve
- Nginx vagy Apache nyersen felszolgálva
.logfájlok
Ha egy napló elérhető HTTP-n keresztül, akkor indexelhető.
3.2 CI/CD Műtárgy expozíció
Tipikus hibák:
- Nyilvános műtárgyak engedélyezve itt: GitHub-műveletek
- Naplók feltöltve az S3 tárolók megnyitásához
- Pipeline hitelesítés nélkül is elérhető nyomkövetések
A pipeline amely a naplókat egy nyilvános tárolóban tárolja, hatékonyan közzéteszi a titkait.
3.3 Hibakeresési mód éles környezetben
A keretrendszer alapértelmezett beállításai veszélyesek lehetnek:
Ezenkívül a túlzott kérésnaplózás a következőket nyomtathatja ki:
- Fejlécek
- tokenek
- Teljes kéréstörzsek
A hibakeresési naplózás éles környezetben hitelesítőadat-exportálóvá alakítja az alkalmazást.
3.4 Docker és konténer naplók
A konténeres környezetek új expozíciós útvonalakat vezetnek be:
- Megosztott kötetekre csatolt naplók
- Naplók exportálása nem biztonságos végpontokra a mellékkocsik segítségével
- Bejelentkezés dashboardnyilvános hozzáféréssel
Ha a konténernaplók HTTP-n vagy nyílt tárolón keresztül érhetők el, akkor kereshetők. Végül indexelésre kerülnek.
4. Realisztikus támadási folyamat: A hülyétől a behatolásig
Egy tipikus támadási lánc így néz ki:
A támadó fut:
- Leletek feltárása
.logfilé - Kivonatok:
- JWT token
- Alapszintű hitelesítési fejléc
- Adatbázis-kapcsolati karakterlánc
Hitelesítési kísérletek a következő ellen:
- API-végpontok
- Adminisztrációs panelek
- Belső szolgáltatások
Sikeres hitelesítés esetén a támadó a következőket teheti:
- Jogosultságok eszkalálása
- Oldalirányú mozgás
- Nélkül CI/CD
- Az ellátási lánc veszélyeztetése
Ami keresési lekérdezésként indult, az lesz:
- Munkamenet eltérítése
- Belső hitelesítő adatok feltöltése
- Pipeline átvenni
- Műtárgymérgezés
Mindez egy nyilvánosan indexelt naplófájlból.
5. Miért jelent alkalmazásbiztonsági problémát a „túl sok” naplózás
A fakitermelés nem semleges. Ehelyett egy másodlagos adattár.
Ha bizalmas adatokat naplózol, gyakorlatilag egy második másolatot hozol létre a titkaidról.
A naplókat azonban gyakran kihagyják a fenyegetésmodellezésből. A STRIDE alatt ez egyértelműen a következőkre utal:
Információ közzététele
Ezért a Biztonságos SDLC a gyakorlatoknak a naplókat a következőképpen kell kezelniük:
- Biztonsággal kapcsolatos összetevők
- Érzékeny eszközök
- Védelmet igénylő infrastruktúra-összetevők
Ha a fenyegetési modelled figyelmen kívül hagyja a naplókat, akkor hiányos.
6. Hogyan akadályozható meg a hitelesítő adatok kiszivárgása a naplófájlokban
6.1 A titkok naplózásának leállítása
Soha ne naplózza:
- jelszavak
- tokenek
- API kulcsok
- Munkamenet-azonosítók
- Engedélyezési fejlécek
Még hibakeresési módban is.
Amikor csak lehetséges, alkalmazzon automatikus szerkesztést.
6.2 Strukturált és biztonságos naplózás
Használjon strukturált naplózást maszkolással és szűréssel.
Példa (Node.js):
Példa (Python):
A fő elv egyszerű: a titkok soha nem juthatnak el a rönknyeletőbe.
6.3 Naplótárolás lezárása
A biztonsági ellenőrzéseknek a következőket kell tartalmazniuk:
- Címtárlista letiltása
- Védje
/logs/hitelesítéssel ellátott útvonalak - Vödörhozzáférés korlátozása
- Megőrzési szabályzatok alkalmazása
- Inaktív naplók titkosítása
A naplók soha nem lehetnek nyilvánosan elérhetők HTTP-n keresztül.
6.4 CI/CD Guardrails
A manuális felülvizsgálatok nem elegendőek. Ehelyett automatizált ellenőrzéseket kell bevezetni:
- Naplók titkos szkennelése a tárgyak közzététele előtt
- Hiba a buildekben, ha tokeneket észlelnek
- Hitelesítő adatokat tartalmazó elemek feltöltésének megakadályozása
- Hash-érvényesítés műtermékekhez
CI/CD az indexelés megkezdése előtt blokkolnia kell a kitettséget.
7. Hogyan akadályozza meg az Xygeni az allintext-et:login fájltípus:napló incidensek
A probléma nem a Google hülyesége, hanem a leleplezettség. Ezért a megelőzésnek az indexelés előtt kell történnie.
7.1 Titkos elemek észlelése naplókban és tárgyakban
Xygeni szkennelések:
- Alkalmazásnaplók
- CI/CD munkakövetések
- Építs tárgyakat
- Docker rétegek
- Sorosított kimenetek
Ha hitelesítő adatok, tokenek vagy bizalmas értékek jelennek meg a .log fájlokat, a Xygeni azonnal megjelöli azokat.
7.2 CI/CD Guardrails Ez blokkolja az expozíciót
Ahelyett, hogy manuális ellenőrzésekre hagyatkoznánk, A Xygeni érvényesíti a biztonságot a következő helyen: pipeline szint:
Ez:
- A buildek sikertelenek, ha titkos adatok jelennek meg a naplókban
- Blokk műtárgy publikáció
- Megakadályozza a véletlen nyilvános expozíciót
- Megállítja a nem biztonságos egyesüléseket a főút elérése előtt
Ha egy CI-feladat tokent nyomtat, a pipeline sikertelen.
Nincs indexelés.
Nincs kitettség.
Nincs incidens.
7.3 Shift-Balra billentyűkombináció használata elleni védelem, mielőtt a Google látná
Az időzítés számít.
Ahelyett, hogy erre reagálnál:
A Xygeni megoldja a problémát:
- At commit idő
- Alatt pull request érvényesítés
- Alatt pipeline végrehajtás
- A műtárgy közzététele előtt
Ha a napló soha nem válik nyilvánossá, a Google soha nem indexeli azt.
Végső következtetés: Ha a Google képes indexelni, a támadók már megtették
A naplófájlok nem ártalmatlanok. Valójában ritkán átmenetiek. Alapértelmezés szerint nem privátak. Ezért minden naplófájlt biztonsággal kapcsolatos eszközként kell kezelni, nem csak hibakeresési kimenetként.
Ha az érzékeny adatok elérik a .log fájlba, és nyilvánosan hozzáférhetővé válik, azonnal támadási felületté alakul. Ráadásul, miután egy keresőmotor indexelte az oldalt, a láthatóság az irányításodon túl is növekszik.
A megoldás nem a naplózás leállítása. Inkább a felelősségteljes naplózás és a tárolás és terjesztés szigorú ellenőrzésének érvényesítése. Más szóval, a biztonságnak túl kell terjednie magán az alkalmazáson, a megfigyelhetőségi rétegre is.
Helyette:
- Titkok naplózásának leállítása
- Zárolt naplótárolás
- kényszerítése pipeline guardrails
- Automatizált észlelés és szabályzat-érvényesítés
Végül, A megelőzés az időzítésről szól. Mert ha egyszer allintext:login fájltípus:napló visszaadja a domainjét, az incidens már elkezdődött.
