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