Hakukoneet on rakennettu sisällön indeksointia varten. Hyökkääjät kuitenkin käyttävät niitä virheidesi indeksointiin. Kysely allintext:login tiedostotyyppi:loki saattaa näyttää harmittomalta. Todellisuudessa se on yksi yksinkertaisimmista tavoista löytää paljastuneet lokitiedostot, jotka sisältävät todennusvirtoja, tunnistetietoja, tokeneita ja sisäisen infrastruktuurin tietoja.
Jos Google voi nähdä lokit, hyökkääjätkin voivat. Indeksoinnin jälkeen altistuminen on väistämätöntä. Lisäksi, kun tunnistetiedot näkyvät julkisesti saatavilla olevassa tiedostossa, tietomurto on jo käynnissä.
1. Miksi allintext:login filetype:log on vaarallisempi kuin miltä se näyttää
Google dork on hakukysely, joka käyttää edistyneitä operaattoreita paikantaakseen hakukoneiden indeksoimaa arkaluontoista tai väärin määritettyä sisältöä. Se ei hyödynnä Googlea, vaan pikemminkin sinun näkyvyyttäsi.
Tämä kysely yhdistää kaksi operaattoria:
- allintext: palauttaa sivut, joilla kaikki termit esiintyvät leipätekstissä
- tiedostotyyppi:loki rajoittaa tuloksia
.logTiedostojen
Siksi:
Tarkoittaa: "Näytä lokitiedostot, jotka sisältävät sanan login"
Ensi silmäyksellä se vaikuttaa triviaaliselta. Käytännössä se kuitenkin usein palauttaa tulokseksi:
- Julkisesti näkyvät verkkopalvelinlokit
- CI/CD lokit ladattuina esineinä
- Lokien virheenkorjaus vahingossa committed arkistoihin
- Sovelluslokit selkotekstisten tunnistetietojen kanssa
Tämä ei ole hakukonevirhe. Sen sijaan se on tietojen paljastumisen haavoittuvuus johtui virheellisestä määrityksestä. Google yksinkertaisesti indeksoi julkisesti saatavilla olevan sisällön.
2. Mitä hyökkääjät todellisuudessa löytävät paljastuneista lokitiedostoista
Kun hyökkääjät juoksevat allintext:login tiedostotyyppi:loki, he eivät selaa sattumanvaraisesti. He etsivät todennusjälkiä.
2.1 Selkotekstiset tunnistetiedot
Lokitiedostot sisältävät usein merkintöjä, kuten:
or
Tai jopa SMTP-tunnistetiedot:
Todennushyötykuormien lokitiedostojen tallentaminen on yksi nopeimmista tavoista vuotaa tuotantoympäristön tunnistetiedot. Tämän seurauksena yksittäinen paljastunut lokitiedosto voi mitätöidä koko käyttöoikeusmallisi.
2.2 Istuntotunnukset ja JWT:t
Vaikka salasanoja ei kirjattaisikaan, tokeneita usein kirjataan.
Esimerkiksi:
Kelvollinen JWT- tai istuntoeväste osoitteen sisällä .log tiedosto voi ottaa käyttöön:
- Kaappausistunto
- Etuoikeuksien lisääntyminen
- Sivuttaisliike sisäisten järjestelmien läpi
Toisin sanoen lokien tunnukset muuttavat virheenkorjaustulosteen todennuksen ohitusvektoriksi.
2.3 CI/CD Esineet
Rakennuslokit ovat erityisen vaarallisia. Itse asiassa CI/CD järjestelmät tulostavat usein ympäristömuuttujia käännösvaiheiden aikana.
Hyökkääjät usein huomaavat:
Sisältää rivejä, kuten:
If CI/CD Jos esineet ovat julkisia, niin sitten salaisuudet ovat julkisia. Googlen idiootti yksinkertaisesti nopeuttaa löytöjä.
2.4 Pilvi- ja infrastruktuuridata
Paljastuneet lokit paljastavat usein:
- AWS-käyttöavaimet
- Azure-tallennustilan yhteysmerkkijonot
- Sisäisten palveluiden URL-osoitteet
- Tietokannan tunnistetiedot
- Redis-päätepisteet
Vaikka tunnistetiedot vaihdettaisiin myöhemmin, hyökkääjällä on nyt:
- Infrastruktuurikartoitus
- Nimeämiskäytännöt
- Kohdetiedustelu tulevia hyökkäyksiä varten
Siksi paljastuneet lokit tarjoavat sekä pääsyn että tiedustelun.
3. Miten näistä lokeista tulee alun perin julkisia
Lokit eivät ilmesty Googleen taianomaisesti. Ne indeksoidaan, koska ne olivat julkisesti saatavilla.
3.1 Väärin konfiguroidut verkkopalvelimet
Yleisiä malleja ovat:
/logs/hakemistot, joihin pääsee käsiksi ilman todennusta- Hakemistolistaus käytössä
- Nginx tai Apache raakana tarjoiltuna
.logTiedostojen
Jos loki on tavoitettavissa HTTP:n kautta, se on indeksoitavissa.
3.2 CI/CD Artefaktialtistus
Tyypillisiä virheitä:
- Julkiset esineet käytössä GitHub-toiminnot
- Lokit ladattu avoimiin S3-säiliöihin
- Pipeline jälkiä, joihin pääsee käsiksi ilman todennusta
A pipeline joka tallentaa lokit julkiseen säilöön, julkaisee tehokkaasti salaisuutensa.
3.3 Virheenkorjaustila tuotannossa
Kehyksen oletusarvot voivat olla vaarallisia:
Lisäksi liiallinen pyyntöjen lokikirjaus voi tulostaa seuraavat tulokset:
- Otsikot
- tokens
- Täydelliset pyyntöjen rungot
Virheenkorjausloki tuotannossa muuttaa sovelluksesi tunnistetietojen viejäksi.
3.4 Docker- ja konttilokit
Konttiympäristöt tuovat mukanaan uusia altistumisreittejä:
- Jaettuihin levyihin liitetyt lokit
- Sivuvaunut vievät lokeja suojaamattomiin päätepisteisiin
- Kirjaudu dashboards julkisella pääsyllä
Jos säilölokit ovat saatavilla HTTP:n tai avoimen tallennustilan kautta, ne ovat haettavissa. Lopulta ne indeksoidaan.
4. Realistinen hyökkäyskulku: Tyhmyydestä murtoon
Tyypillinen hyökkäysketju näyttää tältä:
Hyökkääjä juoksee:
- Löytöjä paljastettu
.logtiedosto - Uutteet:
- JWT-tunnus
- Perustodennusotsikko
- Tietokannan yhteysmerkkijono
Yrittää todennusta osoitteesta:
- API-päätepisteet
- Hallintapaneelit
- Sisäiset palvelut
Jos todennus onnistuu, hyökkääjä voi:
- Eskaloi oikeuksia
- Siirrä sivusuunnassa
- Pääsy CI/CD
- Vaurioittaa toimitusketjua
Se, mikä alkoi hakukyselynä, muuttuu:
- Kaappausistunto
- Sisäinen tunnistetietojen täyttö
- Pipeline vallata
- Artefaktien myrkytys
Kaikki julkisesti indeksoidusta lokitiedostosta.
5. Miksi "liika" lokitietojen kerääminen on sovellusturvaongelma
Hakkuu ei ole neutraalia. Sen sijaan se luo toissijainen tietovarasto.
Jos kirjaat arkaluonteisia tietoja, luot käytännössä toisen kopion salaisuuksistasi.
Lokit kuitenkin usein jätetään pois uhkamallinnuksesta. STRIDE-ympäristössä tämä vastaa selvästi seuraavia seikkoja:
Tiedot julkistamisesta
Siksi, turvallinen SDLC käytäntöjen tulisi käsitellä lokeja seuraavasti:
- Turvallisuuteen liittyvät esineet
- Arkaluontoiset varat
- Suojausta vaativat infrastruktuurikomponentit
Jos uhkamallisi jättää lokit huomiotta, se on epätäydellinen.
6. Kuinka estää tunnistetietojen vuotaminen lokitiedostoissa
6.1 Lopeta salaisuuksien kirjaaminen
Älä koskaan kirjaa:
- salasanat
- tokens
- API-avaimet
- Istuntotunnukset
- Valtuutusotsikot
Jopa debug-tilassa.
Käytä automaattista hävittämistä aina kun mahdollista.
6.2 Rakenteinen ja turvallinen lokikirjaus
Käytä jäsenneltyä lokikirjausta maskauksen ja suodatuksen kanssa.
Esimerkki (Node.js):
Esimerkki (Python):
Keskeinen periaate on yksinkertainen: salaisuudet eivät saa koskaan päästä tukkipesään.
6.3 Lokitiedostojen säilytyksen lukitseminen
Turvallisuustarkastuksiin tulisi sisältyä:
- Poista hakemistolistaus käytöstä
- Suojella
/logs/polkuja, joissa on todennus - Rajoita ämpärien käyttöä
- Käytä säilytyskäytäntöjä
- Salaa lokit levossa
Lokien ei saa koskaan olla julkisesti saatavilla HTTP:n kautta.
6.4 CI/CD Guardrails
Manuaaliset tarkastukset eivät riitä. Ota sen sijaan käyttöön automaattisia kontrolleja:
- Lokien salainen skannaus ennen artefaktien julkaisemista
- Epäonnistuvat koonnit, jos tunnisteita havaitaan
- Estä tunnistetietoja sisältävien artefaktien lataukset
- Artefaktien hajautusvalidointi
CI/CD tulisi estää altistuminen ennen indeksointia.
7. Miten Xygeni estää allintextin:login tiedostotyyppi: lokitapahtumat
Ongelma ei ole Googlen tyhmyys, vaan sen paljastuminen. Siksi ennaltaehkäisy on tehtävä ennen indeksointia.
7.1 Salaisten asioiden havaitseminen lokeissa ja artefakteissa
Xygeni-skannaukset:
- Sovelluslokit
- CI/CD työjäljet
- Rakenna esineitä
- Docker-kerrokset
- Sarjallistetut lähdöt
Jos tunnistetiedot, tunnukset tai arkaluontoiset arvot näkyvät kohdassa .log tiedostot, Xygeni merkitsee ne välittömästi.
7.2 CI/CD Guardrails Se estää altistumisen
Sen sijaan, että luottaisit manuaalisiin tarkistuksiin, Xygeni valvoo turvallisuutta pipeline taso:
Tämä:
- Koontit epäonnistuvat, kun lokitiedostoissa näkyy salaisuuksia
- Estää artefaktien julkaisun
- Estää tahattoman altistumisen yleisölle
- Pysäyttää vaaralliset yhdistämiset ennen pääreitin saavuttamista
Jos CI-työ tulostaa tunnuksen, pipeline epäonnistuu.
Ei indeksointia.
Ei altistumista.
Ei välikohtausta.
7.3 Vaihto vasemmalle -suojaus ennen kuin Google näkee sen
Ajoituksella on väliä.
Sen sijaan, että reagoisit:
Xygeni ratkaisee ongelman:
- At commit aika
- Aikana pull request validointi
- Aikana pipeline teloitus
- Ennen artefaktin julkaisua
Jos loki ei koskaan tule julkiseksi, Google ei koskaan indeksoi sitä.
Loppupäätelmä: Jos Google pystyy indeksoimaan sen, hyökkääjät ovat jo tehneet niin.
Lokit eivät ole vaarattomia. Itse asiassa ne ovat harvoin väliaikaisia. Oletusarvoisesti ne eivät ole yksityisiä. Siksi jokaista lokitiedostoa tulisi käsitellä turvallisuuden kannalta olennaisena resurssina, ei pelkästään virheenkorjaustulosteena.
Jos arkaluonteiset tiedot saavuttavat .log tiedosto ja tulee julkisesti saataville, siitä tulee heti hyökkäyspinta. Lisäksi, kun hakukone on indeksoinut sivustosi, näkyvyys skaalautuu hallitsemattomaksi.
Ratkaisu ei ole lokitietojen tallentamisen lopettaminen, vaan vastuullinen lokitietojen tallentaminen ja tiukkojen valvontatoimien toteuttaminen tallennuksen ja jakelun suhteen. Toisin sanoen turvallisuuden on ulotuttava itse sovelluksen ulkopuolelle ja havainnointikerrokseen.
Sen sijaan:
- Lopeta salaisuuksien kirjaaminen
- Lukitse lokivarasto
- valvoa pipeline guardrails
- Automatisoi tunnistus ja käytäntöjen valvonta
Lopulta, ehkäisyssä on kyse ajoituksesta. Koska kerran allintext:login tiedostotyyppi:loki palauttaa verkkotunnuksesi, välikohtaus on jo alkanut.
