Пошукові системи були створені для індексації контенту. Однак зловмисники використовують їх для індексації ваших помилок. Запит allintext:login тип файлу: журнал може здаватися нешкідливим. Насправді це один із найпростіших способів виявити розкриті файли журналів, що містять процеси автентифікації, облікові дані, токени та дані внутрішньої інфраструктури.
Якщо Google може бачити ці журнали, то зловмисники також можуть. Після індексації викриття стає неминучим. Більше того, коли облікові дані з'являються у загальнодоступному файлі, порушення вже розпочалося.
1. Чому саме allintext:login тип файлу:log небезпечніший, ніж здається
Google-дорк — це пошуковий запит, який використовує розширені оператори для пошуку конфіденційного або неправильно налаштованого контенту, проіндексованого пошуковими системами. Він не використовує Google. Натомість він використовує вашу видимість.
Цей запит поєднує два оператори:
- allintext: повертає сторінки, де всі терміни з'являються в основному тексті
- тип файлу: журнал обмежує результати до
.logфайли
Тому:
Означає: «Показати мені файли журналів, що містять це слово login».
На перший погляд, це здається банальним. Однак на практиці це часто повертає:
- Публічно доступні журнали веб-сервера
- CI/CD журнали, завантажені як артефакти
- Випадково виправлено журнали налагодження commitперенесено до репозиторіїв
- Журнали програм із обліковими даними у відкритому тексті
Це не помилка пошукової системи. Натомість це вразливість до витоку даних спричинено неправильною конфігурацією. Google просто проіндексував те, що було загальнодоступним.
2. Що насправді знаходять зловмисники у викритих файлах журналів
Коли нападники тікають allintext:login тип файлу: журнал, вони не переглядають сторінки випадковим чином. Вони шукають сліди автентифікації.
2.1 Облікові дані у відкритому тексті
Журнали часто містять такі записи, як:
or
Або навіть облікові дані SMTP:
Реєстрація корисних навантажень автентифікації – один із найшвидших способів витоку облікових даних у виробничому середовищі. Як наслідок, один відкритий файл журналу може зробити недійсною всю вашу модель контролю доступу.
2.2 Токени сесії та JWT
Навіть коли паролі не реєструються, токени часто реєструються.
Наприклад:
Дійсний JWT або сеансовий cookie всередині .log файл може вмикати:
- Перехоплення сесії
- Ескалація привілеїв
- Латеральний рух по внутрішніх системах
Іншими словами, токени в журналах перетворюють вивід налагодження на вектор обходу автентифікації.
2.3 CI/CD Артефакти
Збірні журнали особливо небезпечні. Фактично, CI/CD Системи часто виводять змінні середовища під час етапів збірки.
Зловмисники часто виявляють:
Що містить такі рядки, як:
If CI/CD артефакти публічні, тоді й секрети публічні. Цей гугл-дорк просто пришвидшує відкриття.
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 та контейнерів
Контейнерні середовища запроваджують нові шляхи впливу:
- Журнали, змонтовані у спільні томи
- Експорт журналів до незахищених кінцевих точок за допомогою додаткових пристроїв
- Ввійти dashboardз публічним доступом
Якщо журнали контейнерів доступні через HTTP або відкрите сховище, вони доступні для пошуку. Зрештою, вони індексуються.
4. Реалістичний потік атак: від дурня до прориву
Типовий ланцюжок атак виглядає так:
Зловмисник біжить:
- Знахідки викриті
.logфайл - Екстракти:
- Токен JWT
- Базовий заголовок автентифікації
- Рядок підключення до бази даних
Спроби автентифікації щодо:
- Кінцеві точки API
- Панелі адміністратора
- Внутрішні послуги
Якщо автентифікація пройшла успішно, зловмисник може:
- Підвищити привілеї
- Рухайтеся вбік
- Доступ CI/CD
- Поставити під загрозу ланцюг поставок
Те, що починалося як пошуковий запит, стає:
- Перехоплення сесії
- Внутрішнє заповнення облікових даних
- Pipeline поглинання
- Отруєння артефактами
Все з публічно індексованого файлу журналу.
5. Чому «занадто багато» логування є проблемою AppSec
Ведення журналу не є нейтральним. Натомість воно створює вторинне сховище даних.
Якщо ви реєструєте конфіденційні дані, ви фактично створюєте другу копію своїх секретів.
Однак, журнали часто виключаються з моделювання загроз. У STRIDE це чітко відображає:
Інформація про розкриття інформації
Отже, безпечно SDLC практики повинні розглядати журнали як:
- Артефакти, що стосуються безпеки
- Конфіденційні активи
- Компоненти інфраструктури, що потребують захисту
Якщо ваша модель загроз ігнорує журнали, вона є неповною.
6. Як запобігти витоку облікових даних у файлах журналів
6.1 Припинення ведення журналу секретів
Ніколи не реєструйте:
- Паролі
- Жетони
- Ключі API
- Ідентифікатори сеансу
- Заголовки авторизації
Навіть у режимі налагодження.
По можливості впроваджуйте автоматичне редагування.
6.2 Структуроване та безпечне ведення журналу
Використовуйте структуроване логування з маскуванням та фільтрацією.
Приклад (Node.js):
Приклад (Python):
Ключовий принцип простий: секрети ніколи не повинні досягати поглинача.
6.3 Блокування сховища журналів
Контрольні заходи безпеки повинні включати:
- Вимкнути список каталогів
- Захист
/logs/шляхи з автентифікацією - Обмежити доступ до кошика
- Застосувати політики збереження
- Шифрувати журнали в стані спокою
Журнали ніколи не повинні бути публічно доступними через HTTP.
6.4 CI/CD Guardrails
Ручних перевірок недостатньо. Натомість впровадьте автоматизовані засоби контролю:
- Таємне сканування журналів перед публікацією артефактів
- Збірки не вдалися, якщо виявлено токени
- Запобігти завантаженню артефактів, що містять облікові дані
- Перевірка хешу для артефактів
CI/CD слід блокувати експозицію до початку індексації.
7. Як Xygeni запобігає використанню allintext:login тип файлу: журнал Інциденти
Проблема не в гугл-дурні. Проблема у викритті. Тому профілактика має відбутися до індексації.
7.1 Виявлення секретів у журналах та артефактах
Сканування Xygeni:
- Журнали програм
- 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 тип файлу: журнал повертає ваш домен, інцидент вже почався.
