Продвинутый поиск секретов: как находить утекшие учетные данные в нестандартных местах

Продвинутый поиск секретов: как находить утекшие учетные данные в нестандартных местах

@Ent_TranslateIB

Как хакеры и исследователи безопасности обнаруживают скрытые API-ключи, токены и учетные данные?

Введение

Хотя поиск хардкоденных API-ключей и учетных данных в исходном коде — распространенная практика, опытные исследователи безопасности выходят за рамки стандартных методов. Они анализируют логи, дампы памяти, облачное хранилище и сетевой трафик, чтобы обнаружить утечки конфиденциальных данных.

📌 В этой статье разбираются продвинутые техники поиска утекших учетных данных, включая:

Форензика памяти (Memory Forensics)

Анализ сетевого трафика (Network Traffic Analysis)

Ошибки конфигурации облачных сервисов (Cloud Misconfigurations)

Автоматизированная разведка (Reconnaissance), которую используют атакующие для поиска утекших данных

Где еще могут скрываться секреты?

Помимо исходного кода, учетные данные могут случайно утечь в:

Дампах памяти и работающих процессах — приложения могут временно хранить пароли и токены в RAM.

Сетевом трафике и API-запросах — нешифрованные API-ключи могут перехватываться.

Публичных облачных хранилищахS3-бакеты, Azure Blobs, Google Cloud Storage могут содержать конфиденциальные файлы.

CI/CD логах и сборочных пайплайнахJenkins, GitHub Actions, Travis CI могут случайно логировать API-ключи.

Образах контейнеров и Dockerfilesсекреты, встроенные в контейнеры, могут быть извлечены.

Давайте разберем продвинутые техники поиска скрытых учетных данных из этих источников.

Метод 1: Извлечение секретов из памяти и работающих процессов

Приложения часто хранят учетные данные в оперативной памяти, и если атакующий получает доступ к системе, он может извлечь их из дампа памяти.

1️⃣ Поиск учетных данных в запущенных процессах

В Linux можно использовать команду strings, чтобы сканировать память запущенных процессов на наличие паролей и API-ключей:

sudo strings /proc/[PID]/mem | grep -i "password\|token\|apikey"

📌 Пример: Поиск AWS-ключей, хранящихся в памяти приложения:

sudo strings /proc/$(pgrep -f application_name)/mem | grep -i "aws_secret_access_key"

2️⃣ Дамп памяти процесса для анализа

Можно создать дамп памяти запущенного процесса с помощью gcore:

sudo gcore -o memory_dump $(pgrep -f application_name)

После этого можно использовать strings или hexdump, чтобы найти учетные данные в дампе:

strings memory_dump | grep -i "secret"

💡 Для продвинутого анализа памяти можно использовать Volatility или Rekall. 🚀

Метод 2: Захват секретов из сетевого трафика

Если приложения отправляют нешифрованные API-ключи или учетные данные по сети, их можно перехватить с помощью Wireshark или tcpdump.

1️⃣ Снифинг сетевого трафика с tcpdump

📌 Захватываем пакеты, содержащие конфиденциальные данные:

sudo tcpdump -i eth0 -A -n | grep -i "Authorization:"

2️⃣ Фильтрация API-запросов в Wireshark

📌 Открываем Wireshark и начинаем захват трафика.

📌 Применяем фильтр для поиска Authorization заголовков:

http contains "Authorization"

🔹 Что искать?

API-запросы с токенами аутентификации

Сессионные куки и авторизационные заголовки

💡 Злоумышленники часто используют MITM-прокси (Burp Suite, mitmproxy) для перехвата API-запросов.

Метод 3: Поиск утекших учетных данных в облачных хранилищах

📌 Ошибки конфигурации облачных сервисов могут случайно раскрыть файлы с API-ключами, учетными данными и приватными данными.

1️⃣ Поиск публичных AWS S3 бакетов

📌 Проверяем доступность публичного S3-бакета:

aws s3 ls s3://target-bucket --no-sign-request

📌 Если бакет открыт, ищем учетные данные внутри:

aws s3 cp s3://target-bucket/config.json .
cat config.json | grep -i "key"

2️⃣ Поиск публичных Google Cloud бакетов

gcloud storage buckets list --public

3️⃣ Проверка утечек в Azure Blob Storage

az storage blob list --container-name mycontainer --account-name mystorageaccount --output table

💡 Для автоматизированного сканирования бакетов используйте Bucket Finder, S3Scanner, GCPBucketBrute.

Метод 4: Извлечение секретов из CI/CD пайплайнов и логов

📌 Неправильная настройка CI/CD пайплайнов может случайно утечь учетные данные в логах.

1️⃣ Поиск API-ключей в логах GitHub Actions

gh actions list | grep -i "secret"

2️⃣ Извлечение учетных данных из логов Jenkins

grep -r "password" /var/lib/jenkins/jobs/

3️⃣ Поиск утекших учетных данных в Travis CI

curl -s https://api.travis-ci.org/repos/target-org/target-repo/builds | jq

💡 Проверяйте, чтобы логи CI/CD не содержали переменные окружения с секретами.

Метод 5: Поиск секретов в Docker-контейнерах

Разработчики иногда хардкодят учетные данные в Docker-образах. Их можно извлечь следующими методами.

1️⃣ Поиск секретов в Dockerfile

grep -r "SECRET" Dockerfile

2️⃣ Извлечение переменных окружения из работающего контейнера

docker exec -it container_name env | grep -i "key"

3️⃣ Поиск утекших учетных данных в слоях контейнера

docker history --no-trunc container_id | grep -i "password\|token\|apikey"

4️⃣ Извлечение секретов из файловой системы контейнера

📌 Если контейнер работает, монтируем его файловую систему и ищем секреты:

docker cp container_id:/etc/environment ./container_env
cat container_env | grep -i "key"

💡 Чтобы предотвратить утечки, избегайте хранения секретов в Docker-образах. Используйте переменные окружения и безопасное управление секретами. 🚀

Метод 6: Извлечение секретов из веб-приложений и JavaScript-файлов

Иногда API-ключи и учетные данные хранятся в фронтенд-коде JavaScript, что делает их легкодоступными для атакующих.

1️⃣ Поиск API-ключей в JavaScript-файлах

📌 Скачиваем все JavaScript-файлы с целевого сайта:

wget -r --no-parent https://target.com -P js_files/
grep -r "API_KEY" js_files/

2️⃣ Анализ сетевых запросов в DevTools

📌 Открываем Chrome DevTools (F12) → Вкладка Network

📌 Фильтруем XHR-запросы, проверяем авторизационные заголовки

📌 Ищем секреты в локальном хранилище и сессионных данных:

console.log(localStorage);
console.log(sessionStorage);

💡 Если API-ключ встроен в JavaScript, он считается публичным и требует дополнительных мер защиты!

Метод 7: Поиск секретов с помощью OSINT

📌 Иногда секретные данные случайно утекают на GitHub, Pastebin и в открытые репозитории.

1️⃣ Использование Google Dorks для поиска утечек

site:github.com "API_KEY=" "password="
site:pastebin.com "AWS_SECRET_ACCESS_KEY"

2️⃣ Поиск утекших API-ключей в GitHub

📌 Используем поиск по коду на GitHub:

https://github.com/search?q=API_KEY&type=code

3️⃣ Поиск утечек через Shodan

📌 Проверяем публичные файлы с паролями:

shodan search "password.txt"

💡 Если что-то загружено в публичные репозитории или облачные хранилища — считайте, что это может быть найдено.

Как предотвратить утечки учетных данных?

🔒 1️⃣ Используйте безопасное управление секретами

✅ AWS Secrets Manager

✅ HashiCorp Vault

✅ Azure Key Vault

✅ Doppler

🔒 2️⃣ Включите GitHub Secret Scanning & Token Protection

📌 GitHub автоматически сканирует репозитории на предмет утечек учетных данных.

🔒 3️⃣ Настройте автоматизированное сканирование секретов в CI/CD

✅ Используйте Gitleaks, TruffleHog, GitGuardian для сканирования репозиториев и пайплайнов.

🔒 4️⃣ Регулярно обновляйте API-ключи и учетные данные

📌 Частая ротация API-ключей снижает риски утечек.

🔒 5️⃣ Ограничивайте права доступа API-ключей

📌 Принцип минимально необходимого доступа (Least Privilege) — не давайте глобальные разрешения, если в этом нет необходимости.

Заключение: продвинутые методы поиска и защиты учетных данных

🔹 Секреты могут утекать в неожиданных местах: в дампах памяти, сетевом трафике, логах, CI/CD и облачных сервисах.

🔹 Атакующие используют OSINT, форензику памяти и сканирование кода для поиска учетных данных.

🔹 Разработчики должны применять лучшие практики безопасности: переменные окружения, хранилища секретов и автоматическое сканирование.

🔹 Проактивные меры безопасности предотвращают утечки до того, как они станут критическими уязвимостями.


Оригинал статьи - здесь.
Поддержите автора хлопками на Medium.

Ссылки автора статьи:


Перевод статьи был выполнен проектом перевод энтузиаста:

  • 📚 @Ent_TranslateIB - Телеграмм канал с тематикой информационной безопасности

Report Page