Търсачките са създадени, за да индексират съдържание. Хакерите обаче ги използват, за да индексират вашите грешки. Заявката 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 Docker & Container Logs
Контейнеризираните среди въвеждат нови пътища на експозиция:
- Логове, монтирани в споделени томове
- Експортиране на лог файлове към незащитени крайни точки от странични карети
- Вход dashboardс публичен достъп
Ако лог файловете на контейнерите са достъпни чрез HTTP или отворено хранилище, те са достъпни за търсене. В крайна сметка те се индексират.
4. Реалистичен поток на атака: От Dork до Breach
Типична верига за атака изглежда така:
Атакуващият бяга:
- Находки, изложени на показ
.logдосие - Екстракти:
- JWT токен
- Основен заглавен файл за удостоверяване
- Низ за свързване с база данни
Опити за удостоверяване срещу:
- API крайни точки
- Административни панели
- Вътрешни услуги
Ако удостоверяването е успешно, нападателят може:
- Ескалиране на привилегии
- Движете се странично
- Достъп CI/CD
- Компрометирайте веригата за доставки
Това, което започна като заявка за търсене, се превърна в:
- Отвличане на сесия
- Вътрешно попълване на идентификационни данни
- Pipeline поглъщане
- Отравяне с артефакти
Всичко от публично индексиран лог файл.
5. Защо „твърде многото“ записване на данни е проблем на AppSec
Дърводобивът не е неутрален. Вместо това, той създава вторично хранилище за данни.
Ако регистрирате чувствителни данни, вие ефективно създавате второ копие на вашите тайни.
Въпреки това, лог файловете често се изключват от моделирането на заплахите. В STRIDE това ясно се свързва със:
Информация за разкриване
Следователно, Secure SDLC практиките трябва да третират лог файловете като:
- Артефакти, свързани със сигурността
- Чувствителни активи
- Компоненти на инфраструктурата, изискващи защита
Ако вашият модел на заплахи игнорира регистрационните файлове, той е непълен.
6. Как да предотвратите изтичане на идентификационни данни в лог файловете
6.1 Спрете записването на тайни
Никога не се регистрирайте:
- Passwords
- Знаците
- API ключове
- Идентификатори на сесии
- Заглавки за оторизация
Дори в режим на дебъгване.
Винаги, когато е възможно, внедрявайте автоматично редактиране.
6.2 Структурирано и безопасно регистриране
Използвайте структурирано регистриране с маскиране и филтриране.
Пример (Node.js):
Пример (Python):
Ключовият принцип е прост: тайните никога не трябва да достигат до дъното на света.
6.3 Заключване на съхранението на лог файлове
Контролът за сигурност трябва да включва:
- Деактивиране на списъка с директории
- Защитете
/logs/пътища с удостоверяване - Ограничаване на достъпа до кофата
- Прилагане на правила за съхранение
- Шифроване на лог файлове в покой
Логовете никога не трябва да бъдат публично достъпни чрез HTTP.
6.4 CI/CD Guardrails
Ръчните прегледи са недостатъчни. Вместо това, внедрете автоматизирани контроли:
- Тайно сканиране на лог файлове преди публикуване на артефакти
- Неуспешни компилации, ако бъдат открити токени
- Предотвратяване на качването на артефакти, съдържащи идентификационни данни
- Проверка на хеш за артефакти
CI/CD трябва да блокира експозицията, преди да се осъществи индексирането.
7. Как Xygeni предотвратява allintext:login тип файл:log Инциденти
Проблемът не е в глупака на Google. Проблемът е в разкриването. Следователно, превенцията трябва да се случи преди индексирането.
7.1 Откриване на тайни елементи в лог файлове и артефакти
Ксигени сканирания:
- Регистри на приложението
- CI/CD следи от работа
- Изграждане на артефакти
- Докер слоеве
- Сериализирани изходи
Ако се появят идентификационни данни, токени или чувствителни стойности в .log файлове, Xygeni ги маркира незабавно.
7.2 CI/CD Guardrails Това блокира експозицията
Вместо да разчитате на ръчни прегледи, Xygeni осигурява сигурност на pipeline ниво:
Това:
- Неуспешни компилации, когато тайните се появят в лог файловете
- Публикуване на артефакти от блокове
- Предотвратява случайно публично излагане
- Спира опасните сливания преди достигане на основната част
Ако CI задача отпечата токен, pipeline неуспешна.
Без индексиране.
Без експозиция.
Няма инцидент.
7.3 Защита от Shift-Left, преди Google да я види
Времето има значение.
Вместо да реагирате на:
Xygeni спира проблема:
- At commit път
- По време на pull request утвърждаване
- По време на pipeline изпълнение
- Преди публикуването на артефакта
Ако логът никога не стане публичен, Google никога не го индексира.
Последен извод: Ако Google може да го индексира, значи нападателите вече са го направили
Лог файловете не са безобидни. Всъщност те рядко са временни. По подразбиране те не са поверителни. Следователно, всеки лог файл трябва да се третира като актив, свързан със сигурността, а не само като резултат от отстраняване на грешки.
Ако чувствителни данни достигнат .log файл и става публично достъпен, тя веднага се превръща в повърхност за атака. Освен това, след като бъде индексирано от търсачката, експозицията се мащабира извън вашия контрол.
Решението не е да се спре регистрирането. По-скоро е да се регистрира отговорно и да се наложи строг контрол върху съхранението и разпространението. С други думи, сигурността трябва да се простира отвъд самото приложение и да обхваща наблюдаемия слой.
Вместо:
- Спрете да регистрирате тайни
- Заключване на хранилището за логове
- Налагане pipeline guardrails
- Автоматизиране на откриването и прилагането на правилата
в края на краищата, превенцията е въпрос на време. Защото веднъж allintext:login тип файл: лог връща вашия домейн, инцидентът вече е започнал.
