Захист PostgreSQL від кампаній криптоджекінгу в Kubernetes
PostgreSQL — це потужна система керування реляційними базами даних (RDBMS) із відкритим кодом. Завдяки своїй надійності та масштабованості PostgreSQL широко використовується в хмарі. Більшість публічних хмарних провайдерів, включаючи AWS, Azure і GCP, надають своїм клієнтам послуги баз даних на основі PostgreSQL.
Згідно зі звітом Google “Threat Horizons” за січень 2023 року, PostgreSQL є одним з найбільш часто компрометованих клієнтських додатків Google, посідаючи третє місце за частотою (17%) після SSH (26%) і Jenkins (22%). Слабкі паролі залишаються найпоширенішим вектором початкового доступу, відіграючи роль у 41% зареєстрованих випадків компрометації. Зловмисники часто шукають погано налаштовані або незахищені екземпляри PostgreSQL, розгорнуті в хмарі, Kubernetes або локальній інфраструктурі.
Багато гравців на ринку криптоджекінгу, в тому числі TeamTNT і Kinsing, використовують неправильно налаштовані екземпляри PostgreSQL для майнінгу криптовалюти. У цій статті розглядаються найпопулярніші неправильні конфігурації, що використовуються цими зловмисниками.
Неправильна конфігурація PostgreSQL підвищує ймовірність криптоджекінгу
Поширені сервіси PostgreSQL, розміщені провайдерами хмарних послуг (такими як Amazon RDS для PostgreSQL, Azure Database для PostgreSQL або GCP Cloud SQL для PostgreSQL), не дозволяють налаштовувати елементи керування автентифікацією, які можуть призвести до таких порушень. Однак при розгортанні PostgreSQL вручну можна допустити багато неправильних конфігурацій методів автентифікації, ролей користувачів, доступу та дозволів, що може призвести до створення вразливостей, якими можуть скористатись зловмисники.
При ручному розгортанні PostgreSQL підтримує декілька методів автентифікації. З них “trust” автентифікація є найбільш незахищеною і надає доступ без необхідності введення пароля, саме тому групи криптомайнінгу полюбляють атакувати хмарні екземпляри PostgreSQL з увімкненим типом автентифікації “trust”. Увімкнути автентифікацію “trust” можна двома способами:
- Використовуючи файл pg_hba.conf
- Використовуючи значення змінної середовища POSTGRES_HOST_AUTH_METHOD=trust
На рисунку 1 показано “trust” автентифікацію за допомогою pg_hba.conf, де будь-який користувач з будь-якого IP може під’єднатися до сервера PostgreSQL без пароля. Ім’я користувача може бути ім’ям суперкористувача, в цьому випадку зловмисник отримає всі привілеї суперкористувача PostgreSQL.
Рисунок 1. Незахищений файл pg_hba.conf
Автентифікацію “trust” також можна ввімкнути, налаштувавши змінну середовища POSTGRES_HOST_AUTH_METHOD=trust в модулі Kubernetes або на сервері. Після встановлення будь-яка IP-адреса або користувач може під’єднатися до бази даних без пароля.
Крім того, “trust” автентифікація в поєднанні з базовими ролями користувачів PostgreSQL за замовчуванням (зазначеними нижче) надає зловмисникам ідеальну можливість зловживати базами даних для зчитування або запису конфіденційних файлів у файловій системі, модифікації конфігурації та підвищення привілеїв.
- pg_read_server_files (дозволяє зчитувати файли ОС)
- pg_write_server_files (дозволяє записувати файли ОС)
- pg_execute_server_program (дозволяє виконання двійкових файлів ОС)
Під час атаки на неправильно сконфігурований PostgreSQL зловмисник може авторизуватися як суперкористувач або користувач з відповідними ролями, наприклад, pg_execute_server_program дозволяє йому завантажити та запустити приховані файли для майнінгу криптовалюти. На рисунку 2.A показано, як зловмисники за допомогою команди COPY завантажують і запускають xmrig, який майнить цифрову валюту типу Monero; на рисунку 2.B – процес xmrig, запущений всередині контейнера, успішно майнить криптовалюту.
Рисунок 2.A. Зловмисник використовує команду COPY для завантаження та запуску xmrig
Рисунок 2.B. Xmrig майнить криптовалюту шляхом віддаленого доступу до неправильно налаштованого PostgreSQL
Як ще один приклад, на рисунках 3.A і 3.B показано, як неправильно налаштований PostgreSQL може бути використаний для відображення переліку всіх вразливих файлів без використання будь-яких підозрілих інструментів. Після того, як зловмисник отримав доступ до служби PostgreSQL, він може налаштувати завдання cron, щоб отримати реверсну оболонку, підвищити привілеї до root контейнера і перейти до атаки на хост Kubernetes, API або API хмарного провайдера, щоб підвищити привілеї та захопити кластер Kubernetes або хмарний обліковий запис.
Рисунок 3.A. Зловмисник використовує команду COPY для зчитування конфіденційних файлів у /etc /passwd
Рисунок 3.B. Результати використання зловмисником команди COPY для зчитування конфіденційних файлів
Виявлення та захист від CrowdStrike
Платформа Falcon об’єднує хмарну безпеку для забезпечення комплексного захисту клієнтів від будь-яких атак на Kubernetes, хмарну або гібридну інфраструктуру.
Платформа Falcon, завдяки своїм моделям машинного навчання, виявляє та запобігає загрозам під час роботи хмари, Kubernetes або безсерверної інфраструктури. У прикладі, показаному на рисунку 4.A, платформа Falcon ідентифікує і виявляє дочірній процес PostgreSQL, який намагається завантажити та запустити майнер xmrig в контейнері. На рисунку 4.B показано, як платформа Falcon ідентифікує і зупиняє шкідливий процес на ранній стадії kill chain, коли завантажується шкідливий файл. На рисунку 4.C показано, як платформа Falcon виявляє неправильну конфігурацію PostgreSQL під час роботи.
Рисунок 4.A. Платформа Falcon виявляє та попереджає на кожному етапі kill chain
Рисунок 4.B. Платформа Falcon зупиняє процес wget, який використовується для завантаження шкідливого програмного забезпечення
Рисунок 4.C. Платформа Falcon виявляє небезпечну конфігурацію PostgreSQL за допомогою змінної середовища
Платформа Falcon застосовує підхід на основі глибокого захисту, використовуючи вхідну телеметрію для виявлення та усунення загроз в режимі реального часу. Вона включає наступні індикатори, які використовуються для виявлення спроб криптоджекінгу, подібних до розглянутих:
- Запобігання дрифту контейнера
- Підроблений контейнер, що працює на вашому екземплярі Docker
- Неправильно налаштований екземпляр Kubernetes або Docker
Загальнодоступні хмарні сервіси для PostgreSQL не вразливі до такої неправильної конфігурації. Управління безпекою хмарних сервісів CrowdStrike Falcon Horizon дозволяє фахівцям з DevOps забезпечувати безпеку таких додатків, як PostgreSQL, шляхом проактивного моніторингу, виявлення неправильних конфігурацій і забезпечення відповідності вимогам в інфраструктурі публічної хмари. У наступній таблиці наведено перелік індикаторів неправильних конфігурацій (IOM) Falcon Horizon для PostgreSQL, які допомагають виявити прогалини в безпеці.
| Платформа | Сервіс | Серйозність | Назва політики | Опис політики |
| Azure | PostgreSQL | Medium | PostgreSQL database does not enforce SSL | Було виявлено сервер бази даних PostgreSQL, який не використовує SSL для з’єднань з базою даних. Це означає, що клієнти можуть встановлювати відкриті з’єднання з базою даних, що дозволяє відстежувати/перехоплювати їхній трафік, якщо вони підключаються через ненадійні мережі. |
| Azure | PostgreSQL | Informational | PostgreSQL database has the connection throttling parameter disabled | Виявлено базу даних PostgreSQL з параметром дроселювання з’єднань, встановленим у значення “вимкнено”. Дроселювання з’єднань тимчасово блокує вхідні з’єднання з IP-адреси після декількох невдалих спроб входу, захищаючи базу даних від атак грубої сили |
| Azure | PostgreSQL | Informational | PostgreSQL database has the log checkpoints parameter disabled | Було виявлено базу даних PostgreSQL з параметром логування контрольних точок, встановленим на “вимкнено”. Без цього типу логування ви не матимете уявлення про процес перевірки контрольних точок, що може негативно вплинути на продуктивність бази даних та надійність з’єднання. |
| Azure | PostgreSQL | Informational | PostgreSQL database has the log connections parameter disabled | Було виявлено базу даних PostgreSQL з параметром логування з’єднань, встановленим на “вимкнено”. Без цього типу логування ви не матимете уявлення про спроби з’єднання з базою даних. Логи з’єднань можуть допомогти визначити, коли на базу даних намагаються здійснити атаку грубою силою, і можуть допомогти у відстеженні зловмисників під час розслідування. |
| Azure | PostgreSQL | Informational | PostgreSQL database has the log disconnections parameter disabled | Було виявлено базу даних PostgreSQL з параметром логування роз’єднань, встановленим на “вимкнено”. Без цього типу логування ви не матимете уявлення про сеанси з’єднання з базою даних, які можуть містити інформацію про тривалість сеансу і час роз’єднання. |
| Azure | PostgreSQL | Informational | PostgreSQL database has the log duration parameter disabled | Було виявлено базу даних PostgreSQL з вимкненим параметром реєстрації тривалості. Без цього типу реєстрації ви не матимете уявлення про час, необхідний для виконання запитів до бази даних. Це може допомогти визначити, коли база даних перебуває під стресовим навантаженням або якщо є інші проблеми з продуктивністю запитів і/або бази даних. |
| GCP | Cloud SQL | Informational | Cloud SQL for PostgreSQL “log_checkpoints” flag is disabled | Увімкнення log_checkpoints призводить до того, що контрольні точки та точки перезапуску записуються до логів сервера. До повідомлень логу додається деяка статистика, зокрема кількість записаних буферів і час, витрачений на їх запис. Цей параметр можна встановити лише у файлі postgresql.conf або у командному рядку сервера. Ця рекомендація стосується екземплярів баз даних PostgreSQL. |
| GCP | Cloud SQL | Informational | Cloud SQL for PostgreSQL “log_connections” flag is disabled | За замовчуванням PostgreSQL не реєструє спроби з’єднання. Увімкнення параметра log_connections створюватиме записи в логах для кожної спроби з’єднання, а також для успішного завершення автентифікації клієнта, що може бути корисним при усуненні несправностей і для визначення будь-яких незвичайних спроб з’єднання з сервером. Ця рекомендація стосується екземплярів баз даних PostgreSQL. |
| GCP | Cloud SQL | Informational | Cloud SQL for PostgreSQL “log_ disconnections” flag is disabled | За замовчуванням PostgreSQL не реєструє дані про тривалість і час завершення сеансу. Увімкнення параметра log_disconnections створюватиме записи логів наприкінці кожного сеансу, що може бути корисним для усунення несправностей і визначення будь-якої незвичної активності протягом певного періоду часу. Параметри log_disconnections і log_connections працюють разом, і зазвичай їх слід вмикати/вимикати разом. Ця рекомендація стосується екземплярів баз даних PostgreSQL. |
| GCP | Cloud SQL | Informational | Cloud SQL for PostgreSQL “log_lock_waits” flag is disabled | Тайм-аут блокування визначає час очікування на блокування перед перевіркою на наявність будь-яких умов. Часті перевищення тайм-ауту очікування блокування можуть свідчити про основну проблему. Логування таких затримок блокування шляхом увімкнення параметра log_lock_waits може бути використано для виявлення низької продуктивності через затримки блокування або якщо спеціально розроблений SQL намагається використати ресурси, утримуючи блокування протягом надмірної кількості часу. Ця рекомендація стосується екземплярів баз даних PostgreSQL. |
| GCP | Cloud SQL | Informational | Cloud SQL for PostgreSQL “log_temp_files” flag is disabled | Параметр log_temp_files вимкнено. Тимчасові файли не записуються до логів, тому може бути складніше виявити потенційні проблеми з продуктивністю, які можуть бути спричинені навмисними спробами виснаження ресурсів. |
| GCP | Cloud SQL | Informational | Cloud SQL for PostgreSQL “log_min_ duration_ statement” flag is enabled | Логування SQL-запитів може містити конфіденційну інформацію, яку не слід записувати. Ця рекомендація стосується екземплярів баз даних PostgreSQL. |
| GCP | Cloud SQL | Medium | Cloud SQL database instance does not require SSL | Підключення до бази даних SQL у разі успішного перехоплення (MITM) може розкрити конфіденційні дані, такі як облікові дані, запити до бази даних, результати запитів тощо. Для безпеки рекомендується завжди використовувати SSL-шифрування при підключенні до вашого екземпляра. Ця рекомендація стосується екземплярів PostgreSQL, MySQL покоління 1 і MySQL покоління 2. |
| GCP | Cloud SQL | Informational | Cloud SQL instance not configured for backups | Резервні копії надають можливість відновити екземпляр хмарного SQL для повернення втрачених даних або усунення проблем з цим екземпляром. Автоматичне резервне копіювання потрібно налаштувати для будь-якого екземпляра, який містить дані, що мають бути захищені від втрати або пошкодження. Ця рекомендація стосується екземплярів SQL Server, PostgreSQL, MySQL покоління 1 і MySQL покоління 2. |
| GCP | VPC | High | VPC allows access to PostgreSQL from all networks | Дозволяючи вхідний мережевий трафік з глобального IP-простору (0.0.0.0/0), ви відкриваєте непотрібні, часто використовувані сервіси для будь-якого зловмисника в Інтернеті. Цей порт високого ризику зазвичай сканується зловмисниками, і одна неправильна конфігурація або застарілий сервер може становити серйозну загрозу для організації. Доступ, отриманий зловмисником, може призвести до компрометації даних або подальшої експлуатації в мережі, де розміщені вразливі сервіси. |
MITRE для захисту інфраструктури як послуги (IaaS)
Crowdstrike об’єднався з MITRE Engenuity Center for Threat-Informed Defense, щоб розробити ATT&CK Defense для IaaS. Метою цього проєкту була розробка ефективних методів і стратегій захисту від зловмисників, які атакують IaaS у хмарі, контейнерах та Linux aaS. Оскільки найпопулярнішою технікою, яку використовують зловмисники для отримання початкового доступу до хмарної інфраструктури, є використання загальнодоступних додатків, таких як PostgreSQL, вкрай важливо оцінити вразливість вашого корпоративного додатка в Інтернеті й згодом слідувати найкращим практикам для його захисту.
Найкращі практики захисту PostgreSQL
Захист робочого навантаження PostgreSQL вимагає поєднання належних практик конфігурації та регулярного моніторингу. Ось деякі загальні рекомендації щодо безпечного розгортання PostgreSQL у хмарних середовищах та середовищах Kubernetes:
- Використовуйте останню версію PostgreSQL та встановіть необхідні патчі.
- Використовуйте надійний пароль при застосуванні методів автентифікації на основі пароля.
- Застосовуйте відповідні дозволи для захисту конфігураційних файлів, таких як pg_hba.conf.
- Увімкніть SSL/TLS для захисту з’єднання між клієнтом і службою PostgreSQL.
- Проводьте аудит користувачів та їхніх ролей безпеки та дотримуйтесь принципу найменших привілеїв.
- Використовуйте секрети простору імен Kubernetes.
- Запускайте службу PostgreSQL від імені користувача не root, що додасть додатковий рівень захисту на випадок компрометації.
- Обмежте ресурси контейнерів, доступні службі PostgreSQL, до розумних меж.
- Відстежуйте хости та контейнери на предмет будь-якої зловмисної активності.
- Використовуйте механізм нульової довіри, щоб дозволити необхідний доступ до сервісу в кластері.
- Використовуйте проактивні рішення безпеки для виявлення неправильної конфігурації та вразливостей
Висновок
Захист PostgreSQL, популярної хмарної програми, має вирішальне значення для запобігання атакам на вашу інфраструктуру. Неправильні конфігурації в PostgreSQL можуть служити точкою входу для зловмисників, як це видно у випадках, коли групи криптозловмисників скористалися такими вразливими місцями для майнінгу криптовалюти з метою отримання прибутку. Щоб захиститися від таких порушень, важливо дотримуватися найкращих практик захисту PostgreSQL, активно стежити за неправильними конфігураціями та підтримувати надійну загальну безпеку.
Одним зі способів досягти цього є використання комплексної хмарної платформи безпеки, такої як платформа захисту хмарних додатків CrowdStrike (CNAPP), яка пропонує поєднання засобів захисту під час роботи та проактивних заходів, включаючи оцінку МОМ та індикаторів атак (IOA), а також перевірку на відповідність нормативним вимогам. Крім того, вона виявляє і запобігає порушенням з боку різних типів суб’єктів, включаючи хактивістів, що займаються криптозлочинністю, групи eCrime і хакерів спонсорованих державами, забезпечуючи комплексне і надійне рішення для захисту вашої хмарної інфраструктури.
Нагадаємо, що iIT Distribution забезпечує дистрибуцію та просування рішень CrowdStrike на території України, Казахстану, Узбекистану та Грузії та надає професійну підтримку у їхньому проєктуванні та впровадженні. Ми завжди забезпечуємо необхідний рівень інформаційної підтримки нашим партнерам та замовникам по кожному продукту, а наші експерти готові надати консультацію з будь-яких питань, пов’язаних з підвищенням ефективності функціонування та захисту вашої IT-інфраструктури.
