Поисковые системы созданы для индексирования контента. Однако злоумышленники используют их для индексирования ваших ошибок. Запрос всетекст:login тип файла: журнал На первый взгляд это может показаться безобидным. В действительности же это один из самых простых способов обнаружить открытые файлы журналов, содержащие потоки аутентификации, учетные данные, токены и данные внутренней инфраструктуры.
Если Google может видеть эти журналы, то и злоумышленники тоже. После индексации утечка становится неизбежной. Более того, когда учетные данные появляются в общедоступном файле, взлом уже начался.
1. Почему allintext:login filetype:log опаснее, чем кажется.
«Дорк» Google — это поисковый запрос, использующий расширенные операторы для поиска конфиденциального или неправильно настроенного контента, индексируемого поисковыми системами. Он не использует уязвимости Google, а использует вашу уязвимость.
Этот запрос объединяет два оператора:
- всетекст: Возвращает страницы, на которых все термины присутствуют в основном тексте.
- тип файла: журнал ограничивает результаты
.logфайлов
Следовательно:
allintext:login filetype:log
Означает: "Покажите мне файлы журналов, содержащие это слово. login".
На первый взгляд, это кажется пустяком. Однако на практике это часто повторяется:
- Общедоступные журналы веб-сервера
- CI/CD Журналы загружены в качестве артефактов
- Журналы отладки случайно commitотправлено в репозитории
- Журналы приложений с учетными данными в открытом текстовом виде
Это не ошибка поисковой системы. Это скорее ошибка... уязвимость к утечке данных Это произошло из-за неправильной конфигурации. Google просто проиндексировал общедоступную информацию.
2. Что на самом деле обнаруживают злоумышленники в открытых лог-файлах
Когда нападающие бегут всетекст:login тип файла: журналОни не просматривают сайты случайным образом. Они ищут следы аутентификации.
2.1 Учетные данные в открытом тексте
В журналах часто встречаются записи следующего содержания:
POST /login username=admin password=SuperSecret123or
Authorization: Basic YWRtaW46cGFzc3dvcmQ=
Или даже учетные данные SMTP:
smtp_user=mailer
smtp_pass=ProdMailPass!Запись в лог аутентификационных данных — один из самых быстрых способов утечки учетных данных в рабочую среду. Следовательно, один-единственный открытый лог-файл может сделать недействительной всю вашу модель контроля доступа.
2.2 Токены сессии и JWT
Даже если пароли не записываются в журнал, токены часто это делают.
Например:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Set-Cookie: session=abc123xyz789;
Generated API token: sk_live_ABC123SECRETДействительный JWT или сессионный cookie внутри .log файл может включать:
- Угон сеанса
- Эскалация привилегий
- Боковое перемещение по внутренним системам
Иными словами, токены в логах превращают отладочный вывод в инструмент обхода аутентификации.
2.3 CI/CD Артефакты
Журналы сборки особенно опасны. На самом деле, CI/CD В процессе сборки системы часто выводят на экран переменные окружения.
Злоумышленники часто обнаруживают:
Содержит такие строки, как:
AWS_ACCESS_KEY_ID=AKIA...
DATABASE_URL=postgres://admin:password@internal-db:5432/appIf CI/CD Если артефакты общедоступны, то и секреты тоже общедоступны. Поисковый запрос Google просто ускоряет процесс обнаружения.
2.4 Данные облачных и инфраструктурных решений
В открытых журналах часто обнаруживается следующее:
- Ключи доступа к АВС
- строки подключения к хранилищу Azure
- Внутренние URL-адреса сервисов
- Учетные данные базы данных
- Конечные точки Redis
Даже если учетные данные будут впоследствии изменены, злоумышленник теперь обладает:
- Картографирование инфраструктуры
- Соглашения об именах
- Целевая информация для будущих атак
Таким образом, открытые бревна обеспечивают как доступ, так и разведку.
3. Как эти журналы вообще становятся общедоступными.
Журналы событий не появляются в Google волшебным образом. Они индексируются, потому что были общедоступны.
3.1 Неправильно настроенные веб-серверы
К распространенным моделям относятся:
/logs/каталоги, доступные без аутентификации- Включено отображение списка каталогов
- Nginx или Apache предоставляют необработанные данные.
.logфайлов
Если журнал доступен по протоколу HTTP, он индексируем.
3.2 CI/CD Экспозиция артефактов
Типичные ошибки:
- Общедоступные артефакты включены в Действия GitHub
- Журналы загружены в открытые хранилища S3.
- Pipeline трассировки, доступные без аутентификации
A pipeline Тот, кто хранит журналы в общедоступном хранилище, фактически раскрывает свои секреты.
3.3 Режим отладки в производственной среде
Настройки фреймворка по умолчанию могут быть опасны:
APP_DEBUG=trueКроме того, чрезмерное количество запросов в журнале может привести к выводу следующих данных:
- Заголовки
- Лексемы
- Полные тела запросов
Включение отладочного логирования в рабочей среде превращает ваше приложение в экспортер учетных данных.
3.4 Docker и журналы контейнеров
Контейнерные среды открывают новые пути утечки данных:
- Журналы событий монтируются в общие тома.
- Sidecar-контейнеры экспортируют журналы на незащищенные конечные точки.
- Журнал dashboardдоступ для публики
Если журналы контейнеров доступны по протоколу HTTP или через открытое хранилище, то в них можно осуществлять поиск. В конечном итоге они индексируются.
4. Реалистичный ход атаки: от занудства до прорыва.
Типичная цепочка атак выглядит следующим образом:
Атакующий запускает:
allintext:login filetype:log- Обнаружены улики
.logфайл - Экстракты:
- JWT-токен
- заголовок базовой аутентификации
- Строка подключения к базе данных
Попытки аутентификации с использованием:
- Конечные точки API
- Панели администратора
- Внутренние услуги
Если аутентификация пройдена успешно, злоумышленник может:
- Повышение привилегий
- Двигайтесь в сторону
- О компании CI/CD
- Нарушить цепочку поставок
То, что начиналось как поисковый запрос, превращается в:
- Угон сеанса
- Внутренняя подмена учетных данных
- Pipeline поглощение
- отравление артефактов
Все данные взяты из общедоступного индексированного файла журнала.
5. Почему чрезмерное ведение журналов является проблемой безопасности приложений
Ведение журналов не является нейтральным процессом. Вместо этого оно создает вторичное хранилище данных.
Если вы записываете конфиденциальные данные, вы фактически создаете вторую копию своих секретов.
Однако журналы событий часто исключаются из моделирования угроз. В рамках STRIDE это явно соответствует следующему:
Раскрытие информации
Следовательно, безопасность SDLC В соответствии с установленными правилами, журналы следует рассматривать следующим образом:
- Артефакты, имеющие отношение к безопасности
- Конфиденциальные активы
- Компоненты инфраструктуры, требующие защиты.
Если ваша модель угроз игнорирует журналы событий, она неполна.
6. Как предотвратить утечку учетных данных в файлах журналов
6.1 Прекратите запись секретных данных
Никогда не заходить в систему:
- пароли
- Лексемы
- API ключи
- Идентификаторы сеанса
- Заголовки авторизации
Даже в режиме отладки.
По возможности внедряйте автоматическое редактирование.
6.2 Структурированная и безопасная регистрация событий
Используйте структурированное логирование с маскированием и фильтрацией.
Пример (Node.js):
const logger = require('pino')({
redact: ['req.headers.authorization', 'body.password']
});Пример (Python):
class RedactFilter(logging.Filter):
def filter(self, record):
record.msg = record.msg.replace("password=", "password=***")
return TrueГлавный принцип прост: секреты ни в коем случае не должны попадать в хранилище секретной информации.
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 уровень:
dotnet xygeni enforce --rules secrets,artifacts,logs --fail-on-riskЭта:
- Сборка завершается с ошибкой, если в логах обнаруживаются секретные данные.
- Блоки публикации артефактов
- Предотвращает случайное обнажение в общественных местах.
- Предотвращает небезопасные слияния до достижения основной ветки.
Если задание CI выводит токен, то pipeline не удается.
Индексирование отсутствует.
Отсутствие воздействия.
Никаких инцидентов.
7.3 Защита от нажатия клавиши Shift+Leg до того, как Google её увидит
Сроки имеет значение.
Вместо того чтобы реагировать на:
allintext:login filetype:logXygeni решает проблему:
- At commit время
- Во время pull request Проверка
- Во время pipeline казнь
- Перед публикацией артефакта
Если запись в журнале никогда не станет общедоступной, Google никогда её не проиндексирует.
Главный вывод: если Google смог это проиндексировать, то злоумышленники уже это сделали.
Журналы событий не безобидны. На самом деле, они редко бывают временными. По умолчанию они не являются приватными. Поэтому каждый файл журнала следует рассматривать как важный с точки зрения безопасности ресурс, а не просто как отладочную информацию.
Если конфиденциальные данные попадут в ловушку .log файл становится общедоступным, оно мгновенно превращается в поверхность для атаки. Более того, после индексации поисковой системой масштаб охвата выходит за рамки вашего контроля.
Решение заключается не в прекращении ведения журналов. Скорее, оно состоит в ответственном ведении журналов и обеспечении строгого контроля над хранением и распространением данных. Другими словами, безопасность должна выходить за рамки самого приложения и распространяться на уровень мониторинга.
Вместо:
- Прекратите записывать секреты.
- Заблокируйте склад дров
- обеспечивать соблюдение pipeline guardrails
- Автоматизация обнаружения и обеспечения соблюдения политик.
В конечном счете, Профилактика – это вопрос времени. Потому что однажды всетекст:login тип файла: журнал Возвращает ваш домен, инцидент уже начался.
