Перехід до звичайної безпеки та досліджень Offensive Security, я натрапив на незахищену панель керування Kubernetes, яка була відкрита в Інтернеті.
Після підтвердження її доступності та того, що вона не була призначена для публічного доступу, я зрозумів, що кластер належить активному бізнесу, який працює за межами ЄС.
Переміщуючись через ресурси кластера, я залишався без слів. Я зміг отримати доступ до Pods, Deployments, Services, ConfigMaps, і навіть SECRETS!
Заглиблюючись, я зміг переміщуватися латерально від кластера до облікового запису компанії AWS, де я отримав повний доступ до середовища AWS цілі. Наслідки? Катастрофічні.
У цьому дописі я пройду з вами через атаку латерального переміщення: від виявлення до відповідального розкриття, і поділюся важливими уроками для всіх, хто використовує Kubernetes у виробництві.
Давайте розпочнемо.
Розвідка / Виявлення
Після позитивної ідентифікації цілі, я почав досліджувати відкриту панель керування. Рівень доступу був необмеженим (див. скріншоти нижче):
- Я міг переглядати та керувати Namespaces, pod'ами, deployment'ами, сервісами, ConfigMaps і Secrets.
- Не було обмежень доступу на основі ролей (RBAC).
Після перевірки всіх секретів, один секрет привернув мою увагу — секрет, що використовується службою Backend:
Як ви бачите, секрет містить закодовані в Base64 дані для, серед іншого, AWS та MonogDB.
data:
AWS_ACCESS_KEY_ID: ****
AWS_S3_BUCKET_NAME: ****
AWS_SECRET_ACCESS_KEY: ***
JWT_SECRET: ***
MONGO_CONNECTION_STRING: ***
S3_BASE_URL: ***
SENDGRID_FROM_EMAIL: ***
SENDGRID_KEY: ***
Заглиблюючись далі, я знайшов ще один секрет, що містить ім’я користувача та пароль адміністратора:
На цей момент я знайшов облікові дані, які потенційно дозволять мені переміщуватися латерально до інших систем — таких як AWS.
Експлуатація
У цій атаці я намагатимуся переміститися з K8s кластеру до облікового запису AWS і виконати безпечні дії.
Перед тим, як використовувати знайдені облікові дані, мені потрібно підготувати їх. Якщо ви пам’ятаєте, K8s Secrets містять облікові дані у форматі Base64 — це означає, що нам потрібно їх спочатку декодувати. Для цього достатньо виконати:
echo "" | base64 -d
Тепер у мене є коректні облікові дані AWS, але чи є вони дійсними? — Давайте перевіримо.
Для цього я просто налаштував AWS CLI з отриманими обліковими даними.
AWS CLI налаштовано з витягнутими обліковими даними
Ми налаштували AWS CLI і готові почати перевірку дійсності облікових даних.
Щоб перевірити облікові дані, які ми тільки що налаштували, я виконую:
aws iam get-user
Це дасть мені більше інформації про користувача (облікові дані), з яким я зараз взаємодію в обліковому записі AWS.
Ну, здається, облікові дані готові до використання через CLI — перевіримо це.
Перелічення всіх AWS S3 Buckets
Перелічення всіх бакетів завершилось успішно
Завантаження файлів до AWS S3 Bucket
Завантаження Security Note до одного з бакетів було успішним.
Перелічення всіх AWS EKS (K8s) кластерів
Взаємодія з AWS EKS (K8s) кластером
Ось, наразі, знайдені облікові дані, здається, мають доступ до кількох EKS (K8s) кластерів.
Почнемо використовувати kubectl і взаємодіяти з одним з кластерів.
Я спробував перерахувати всі Pods у всіх просторах імен — це спрацювало!
Тепер я хотів перевірити, чи можу я створювати нові ресурси в кластері, тому я спробував створити простий Pod — і це теж спрацювало.
Чи можу я його видалити? Так, можу.
Успішно видалено створений Pod.
Чи можу я отримати інформацію про оплату?
Здається, що CLI також має доступ до Billing API.
Доступ до AWS Console
Давайте розширимо межі дослідження трохи далі, чи можу я отримати доступ до AWS Console з обліковими даними, які я маю?
На щастя, для доступу через консоль увімкнено MFA.
Але…, чи не можу я просто вимкнути MFA для користувача? Через AWS CLI?
За допомогою AWS CLI я дізнався, що для користувача зареєстровано два MFA. Теоретично, я повинен мати змогу обійти MFA, просто видаливши реєстрацію MFA.
Я не буду пробувати це на цілі, оскільки це не відповідає моїм етичним намірам. Я протестую це на своєму власному обліковому записі AWS і додам це до своєї бази знань.
Уроки для читачів
- Ніколи не виставляйте Kubernetes Dashboards на публічний доступ: Завжди обмежуйте доступ до внутрішніх мереж або використовуйте захищені методи тунелювання, такі як VPN або SSH. Публічно відкриті панелі є критичним ризиком.
- Захищайте Kubernetes Secrets: Ставтесь до Kubernetes secrets як до чутливих облікових даних. Використовуйте шифрування, обмежуйте доступ і періодично оновлюйте секрети, щоб зменшити ризик їх розголошення.
- Увімкніть контролі доступу на основі ролей (RBAC): Дотримуйтесь принципу найменших прав, налаштовуючи правила RBAC. Переконайтесь, що кожна служба або користувач має лише ті права, які йому дійсно необхідні.
- Регулярно перевіряйте конфігурації Kubernetes і хмарні налаштування: Використовуйте автоматизовані інструменти для сканування помилок у конфігураціях Kubernetes і хмарних облікових записах. Проактивний моніторинг може запобігти порушенням до того, як вони відбудуться.
Висновок
Це дослідження показує, як одна помилка в налаштуванні, наприклад, відкритий Kubernetes Dashboard, може призвести до серйозної загрози безпеці, надаючи зловмисникам доступ набагато більший, ніж початкові системи.
Ключовий висновок очевидний: проактивні заходи безпеки є невід'ємною частиною роботи в хмарних середовищах. Захист Kubernetes та підключених систем вимагає пильності, правильного налаштування та регулярних перевірок, щоб запобігти експлуатації таких вразливостей.
Сподіваюся, вам сподобався цей допис. Дякую за читання.
Відмова від відповідальності: Дії, описані в цьому пості, є частиною контрольованого, відповідального дослідження без наміру завдати шкоди. Виявлені вразливості були негайно повідомлені постраждалій організації для покращення їхньої безпеки. Цей пост має на меті підвищити обізнаність про важливість цієї теми.
Примітка 1: Під час мого дослідження не було зроблено несанкціонованих змін. Метою було підтвердити вплив, забезпечивши при цьому цілісність системи.
Примітка 2: Власник був проінформований про знахідки та отримав час для виправлення.
Перекладено з: How an Exposed Kubernetes Dashboard granted me full AWS Access