Претраживачи су направљени да индексирају садржај. Међутим, нападачи их користе да индексирају ваше грешке. Упит сав текст:login тип датотеке:дневник може изгледати безопасно. У стварности, то је један од најједноставнијих начина за откривање изложених лог датотека које садрже токове аутентификације, акредитиве, токене и податке о интерној инфраструктури.
Ако Гугл може да види те логове, могу и нападачи. Када се индексирају, изложеност постаје неизбежна. Штавише, када се акредитиви појаве у јавно доступној датотеци, провал је већ у току.
1. Зашто аллинтекст:login filetype:log је опаснији него што изгледа
Гугл штребер је упит за претрагу који користи напредне операторе за проналажење осетљивог или погрешно конфигурисаног садржаја који индексирају претраживачи. Не искоришћава Гугл. Уместо тога, искоришћава вашу изложеност.
Овај упит комбинује два оператора:
- сав текст: враћа странице где се сви термини појављују у основном тексту
- тип датотеке:дневник ограничава резултате на
.logдатотеке
Због тога:
Значи: „Прикажи ми лог датотеке које садрже реч login".
На први поглед, то делује тривијално. Међутим, у пракси се често враћа:
- Јавно изложени логови веб сервера
- CI/CD логови отпремљени као артефакти
- Случајно отклањање грешака у евиденцији commitпослато у репозиторијуме
- Дневници апликација са акредитивима у отвореном тексту
Ово није грешка претраживача. Уместо тога, то је рањивост изложености података узроковано погрешном конфигурацијом. Гугл је једноставно индексирао оно што је било јавно доступно.
2. Шта нападачи заправо проналазе у откривеним датотекама дневника
Када нападачи трче сав текст:login тип датотеке:дневник, они не прегледају насумично. Они траже трагове аутентификације.
2.1 Акредитиви у отвореном тексту
Записи често садрже записе као што су:
or
Или чак SMTP акредитиви:
Пријављивање корисних података за аутентификацију један је од најбржих начина за цурење производних акредитива. Сходно томе, једна откривена датотека дневника може поништити цео ваш модел контроле приступа.
2.2 Токени сесије и JWT-ови
Чак и када се лозинке не бележе, токени се често бележе.
На пример:
Важећи JWT или колачић сесије унутар .log датотека може омогућити:
- Отмица сесије
- Ескалација привилегија
- Латерално кретање кроз унутрашње системе
Другим речима, токени у логовима претварају излаз за отклањање грешака у вектор за заобилажење аутентификације.
2.3 CI/CD Артефакти
Записи о изградњи су посебно опасни. У ствари, CI/CD Системи често исписују променљиве окружења током корака изградње.
Нападачи често откривају:
Садржи линије као што су:
If CI/CD Ако су артефакти јавни, онда су тајне јавне. Гуглов кретен једноставно убрзава откривање.
2.4 Подаци о облаку и инфраструктури
Изложени логови често откривају:
- AWS приступни кључеви
- Низови за повезивање са Azure складиштем
- Интерни URL-ови услуга
- Акредитиви базе података
- Редис крајње тачке
Чак и ако се акредитиви касније ротирају, нападач сада поседује:
- Мапирање инфраструктуре
- Именовања конвенције
- Циљајте обавештајне податке за будуће нападе
Стога, изложени логови омогућавају и приступ и извиђање.
3. Како ови записи уопште постају јавни
Записи се не појављују магично у Гуглу. Они се индексирају зато што су били јавно доступни.
3.1 Погрешно конфигурисани веб сервери
Уобичајени обрасци укључују:
/logs/директоријуми доступни без аутентификације- Омогућен је унос у директоријум
- Nginx или Apache приказују raw
.logдатотеке
Ако је лог доступан преко HTTP-а, он се може индексирати.
3.2 CI/CD Изложеност артефаката
Типичне грешке:
- Јавни артефакти омогућени у ГитХуб Ацтионс
- Дневници отпремљени за отварање S3 канти
- Pipeline трагови доступни без аутентификације
A pipeline који чува логове у јавном корпи ефикасно објављује своје тајне.
3.3 Режим отклањања грешака у продукцији
Подразумеване вредности оквира могу бити опасне:
Поред тога, прекомерно евидентирање захтева може исписати:
- Заглавља
- Токени
- Комплетна тела захтева
Евидентирање грешака у продукцији трансформише вашу апликацију у програм за извоз акредитива.
3.4 Докер и контејнер логови
Контејнеризована окружења уводе нове путеве изложености:
- Дневници монтирани у дељене томове
- Спољни прикључци за извоз логова на необезбеђене крајње тачке
- Приступи dashboardса јавним приступом
Ако су логови контејнера изложени путем HTTP-а или отвореног складишта, могу се претраживати. На крају се индексирају.
4. Реалистични ток напада: Од штребера до пробоја
Типичан ланац напада изгледа овако:
Нападач трчи:
- Налази откривени
.logфајл - Екстракти:
- JWT токен
- Основни заглавак за аутентификацију
- Низ за повезивање са базом података
Покушава аутентификацију на:
- Крајње тачке API-ја
- Административни панели
- Интерне услуге
Ако аутентификација успе, нападач може:
- Повећајте привилегије
- Померите се бочно
- Приступ CI/CD
- Компромитовати ланац снабдевања
Оно што је почело као упит за претрагу постаје:
- Отмица сесије
- Интерно попуњавање акредитива
- Pipeline Преузимање
- Тровање артефактима
Све из јавно индексиране датотеке дневника.
5. Зашто је „превише“ евидентирања проблем AppSec-а
Сеча није неутрална. Уместо тога, она ствара секундарно складиште података.
Ако евидентирате осетљиве податке, ефикасно креирате другу копију својих тајни.
Међутим, логови су често искључени из моделирања претњи. У оквиру STRIDE-а, ово се јасно односи на:
Објављивање информација
Стога, Безбедно SDLC праксе треба да третирају логове као:
- Артефакти релевантни за безбедност
- Осетљива имовина
- Компоненте инфраструктуре које захтевају заштиту
Ако ваш модел претње игнорише логове, он је непотпун.
6. Како спречити цурење акредитива у датотекама дневника
6.1 Зауставите евидентирање тајни
Никад не бележи:
- Лозинке
- Токени
- АПИ кључеви
- ИД-ови сесија
- Заглавља ауторизације
Чак и у режиму дебаговања.
Кад год је то могуће, имплементирајте аутоматско редактирање.
6.2 Структурирано и безбедно евидентирање
Користите структурирано евидентирање са маскирањем и филтрирањем.
Пример (Node.js):
Пример (Пајтон):
Кључни принцип је једноставан: тајне никада не смеју доспети до судопере.
6.3 Закључавање складишта логова
Безбедносне контроле треба да укључују:
- Онемогући списак директоријума
- Заштитити
/logs/путање са аутентификацијом - Ограничи приступ канти
- Примените политике задржавања
- Шифруј логове у мировању
Записи никада не смеју бити јавно доступни путем HTTP-а.
6.4 CI/CD Guardrails
Ручни прегледи нису довољни. Уместо тога, имплементирајте аутоматизоване контроле:
- Тајно скенирање логова пре објављивања артефаката
- Неуспешне изградње ако се открију токени
- Спречите отпремање артефаката који садрже акредитиве
- Валидација хеша за артефакте
CI/CD требало би да блокира изложеност пре него што се деси индексирање.
7. Како Xygeni спречава allintext:login тип датотеке:лог Инциденти
Проблем није Гуглов кретен. Проблем је изложеност. Стога, превенција мора да се деси пре индексирања.
7.1 Детекција тајних података у логовима и артефактима
Ксигени скенирања:
- Дневници апликација
- CI/CD трагови послова
- Изградите артефакте
- Докер слојеви
- Серијализовани излази
Ако се акредитиви, токени или осетљиве вредности појављују у .log датотеке, Xygeni их одмах обележава.
7.2 CI/CD Guardrails То блокира изложеност
Уместо да се ослањате на ручне прегледе, Ксигени спроводи безбедност на pipeline ниво:
Ово:
- Неуспешно изградњавање када се тајне појаве у логовима
- Објављивање артефаката Блокова
- Спречава случајно излагање јавности
- Зауставља небезбедна спајања пре него што стигне до главне зграде
Ако CI задатак одштампа токен, pipeline не успева.
Без индексирања.
Без излагања.
Без инцидената.
7.3 Заштита од Shift-Left пре него што је Google види
Време је важно.
Уместо да реагујете на:
Ксигени зауставља проблем:
- At commit време
- Током pull request потврђивање
- Током pipeline извршење
- Пре објављивања артефакта
Ако дневник никада не постане јаван, Гугл га никада неће индексирати.
Закључак: Ако Гугл може да га индексира, нападачи су то већ урадили
Записи нису безопасни. У ствари, ретко су привремени. Подразумевано, нису приватни. Стога, сваку датотеку дневника треба третирати као безбедносно релевантну имовину, а не само као излаз за отклањање грешака.
Ако осетљиви подаци доспеју до .log датотека и постаје јавно доступна, одмах се претвара у нападну површину. Штавише, када их претраживач индексира, изложеност се скалира ван ваше контроле.
Решење није заустављање евидентирања. Уместо тога, реч је о одговорном евидентирању и спровођењу строгих контрола око складиштења и дистрибуције. Другим речима, безбедност мора да се протеже изван саме апликације и на слој видљивости.
Уместо тога:
- Заустави евидентирање тајни
- Закључајте складиште дневника
- Спровести pipeline guardrails
- Аутоматизујте откривање и спровођење смерница
На крају, превенција је ствар времена. Јер једном сав текст:login тип датотеке:дневник враћа ваш домен, инцидент је већ почео.
