Компанії все частіше використовують хмарні послуги для зберігання даних, віртуальних машин, контейнерів, безсерверних функцій та багато іншого. Зі зростанням популярності хмарних сервісів інтерес кіберзловмисників до них відповідно зростає. Через те, що будь-яка людина може легко встановити хмарний інстанс – і не завжди відповідно до протоколів ІТ-безпеки, – зловмисники використовують нові способи отримання доступу до даних та активів організації. Коли ми говоримо про хмарні сервіси в цілому, і про AWS зокрема, не можна ігнорувати зв’язок між локальним середовищем та хмарою. Використання технології обману в хмарі є життєво важливим для захисту сучасних швидкозростаючих середовищ.
У міру того, як ваша мережа переходить у хмару, рівень обману також має переміщатися. Існує безліч способів розгортання ресурсів-обманок у хмарі. Давайте розглянемо сценарій атаки та покажемо деякі оповіщення, викликані рівнем обману.
У цьому сценарії атаки почнемо з кіберсупротивника, який вже отримав доступ до вашої мережі, і покажемо різні способи отримання облікових даних AWS. Потім покажемо деякі сценарії, які можуть бути використані зловмисниками для збору розвідувальної інформації про хмарне середовище, щоб підвищити привілеї та підключитися до деяких хмарних інстансів.
Експлойти нульового дня з’являються часто, і вони спливають, коли ви найменше цього очікуєте. Розгортання рішення для обману дозволяє проактивно підготувати мережу до кібер-атак. Після розгортання приманки чекатимуть на всіх зловмисників, які проберуться у ваше середовище – як локальне, так і хмарне.
Сценарій: Кібер-атаки у хмарних середовищах без технології обману
Кожна велика атака починається з одного невеликого кроку. Насправді існує безліч способів, за допомогою яких зловмисник може отримати доступ до мережі. Нещодавно були опубліковані дві атаки нульового дня, які дозволяють віддалено виконати код (RCE) і отримати швидкий доступ до вразливих машин: Log4j і Spring4shell. В недавньому блозі Fidelis було показано, як такі атаки можна використовувати для швидкого отримання облікових даних AWS. Багато подібних атак дають доступ до машин жертв, і, опинившись усередині, зловмисники можуть отримати облікові дані AWS, які відкривають двері для латерального переміщення через хмару.
Ось як кіберпротивники отримують такий доступ:
Початковий доступ: Облікові дані AWS
Наприклад, щоб підключитися до AWS за допомогою програмного доступу, адміністратору облікового запису необхідно згенерувати ключ доступу та секрет ключа доступу для конкретного користувача AWS. Це часто зустрічається під час роботи з інтерфейсом командного рядка (CLI) AWS. Зловмисник, який має доступ до цих ключів, отримає доступ до середовища AWS цього користувача.
Якщо на машині жертви використовується AWS CLI, ці облікові дані зазвичай зберігаються відкритим текстом на цій машині. Зазвичай їх легко знайти в одному з цих місць:
· Під час завантаження облікових даних із AWS вони зберігаються у файлі формату CSV. Стандартне ім’я файлу: <USER>_credentials.csv.
· У більшості випадків автоматичні інструменти (наприклад, AWS CLI або Python’s boto3) використовують файл облікових даних, розташований у каталозі “.aws”. На машинах Linux цей файл буде тут: ~/.aws/credentials, а на машинах Windows – тут: C:\Users\USERNAME\.aws\credentials
• Замість збереження їх у файлах, деякі конфігурації будуть зберігати ключі в змінних оточеннях на машині: AWS_ACCESS_KEY_ID І AWS_SECRET_ACCESS_KEY. Їх можна легко отримати за допомогою команд середовища Windows чи Linux.
• В окремих випадках облікові дані будуть записані та жорстко закодовані в коді або скриптах, які їх використовують. Зберігати ключі у коді – погана практика, але це робиться, особливо під час початкового написання коду.
Перераховані вище місця та вектори атак – це верхівка айсбергу. Існує набагато більше способів отримання доступу та крадіжки ключів доступу. Важливо захистити облікові дані. Крім того, будьте готові до сценарію, коли ваші ключі доступу будуть зламані. Давайте розглянемо наступний етап і те, як швидко може розвиватися атака, якщо зловмисник опанує ваші ключі.
Розширення плацдарму: Перерахування та ескалація
Ключі доступу дають зловмиснику певний доступ до вашого хмарного середовища. Мета зловмисника – використовувати цей ключ, щоб все глибше і глибше проникнути у ваше середовище. Рівень доступу, якого він зможе досягти, буде залежати від того, як був налаштований конкретний користувач, конфігурації вашого хмарного середовища і, звичайно, навичок вашого кіберпротивника.
Щоб прискорити доступ, давайте скористаємось двома скриптами перерахування хмар, які були нещодавно опубліковані. Один із них перераховує інстанси EC2, а інший – ролі AWS. Їх можна використовувати для збирання інформації, підвищення привілеїв та спроби підключення до працюючих інстансів. За наявності доступу до цих ключів етап перерахування та ескалації не обов’язково має відбуватися всередині вашої мережі. Зловмисник може зробити це, не виходячи з дому чи будь-якого іншого місця.
Сценарій 1 – ec2_enumeration
Цей сценарій має два режими: перерахування та підключення. У режимі перерахування будуть перераховані інстанси EC2 у цільовому середовищі AWS. Він перерахує доступні екземпляри та покаже, до яких із цих інстансів маємо дозволи на підключення. Режим підключення відкриє SSH з’єднання з інстансом. Для режиму підключення використовуємо опцію Amazon “EC2 Instance connect”, яка дозволяє користувачам відкривати з’єднання з інстансом без використання відкритих чи закритих ключів. Цей сценарій в основному базується на AWS SDK для phyton, Boto3 і AWS EC2 instance connect CLI. Для отримання більш детальної інформації ознайомтеся з цим скриптом на GitHub.
Сценарій 2 – перерахування_ролей
Рольовий сценарій має три режими: перерахування, деталізація та прийняття. У режимі перерахування будуть перераховані ролі, подана коротка інформація про кожну з них та зазначено, які ролі можуть бути прийняті з існуючими дозволами. У режимі деталізації буде показано докладнішу інформацію про роль та її політиків. В режимі assume буде зроблено спробу взяти обрану роль. Цей сценарій в основному базується на AWS SDK для phyton, Boto3. Для отримання більш детальної інформації ознайомтеся з цим скриптом на GitHub.
Будемо використовувати ці два сценарії разом для перерахування та ескалації привілеїв, які маємо спочатку. Спочатку перевіримо, до яких інстанцій та ролей можемо отримати доступ з початковим користувачем, до якого підключаємося. Потім ми візьмемо на себе ролі, до яких маємо доступ, і повторимо спробу перерахування, щоб визначити додаткові ролі та інстанси, які тепер відкриті. Нарешті, скористаємося сценарієм інстансів, щоб отримати shell доступ до одного з інстансів і виконати дії з ним.
Крок 1: Перелік
На цьому етапі перераховуємо доступні інстанси EC2 та ролі. Він показує, до яких інстанс можна підключитися і які ролі можна взяти. Коли знаходимо роль, яку можна прийняти і яка має цікаві дозволи, ми можемо описати її докладніше.
Зображення кроку 1.1 – перерахування інстансів – до жодного з екземплярів не можна підключитися з обліковими даними.
Зображення кроку 1.2 – перерахування ролей – 3 ролі можуть бути прийняті користувачем, одна з них має права на EC2 та S3.
Зображення кроку 1.3 – опис ролі: Iam_role_1
Крок 2: Призначити роль
Далі давайте скористаємося опцією “Assume Role” у скрипті. Сценарій прийме цю роль і дасть нам дійсний токен, який можна використовувати для наступних ітерацій.
Зображення кроку 2 – отримання облікових даних після Assume Role
Крок 3: Перерахування
Використовуйте новий токен і повторно виконайте перелічені команди, щоб визначити додаткові інстанси. На зображенні нижче бачимо, що були визначені нові екземпляри EC2, включаючи ті, які дозволяють нам використовувати облікові дані для підключення.
Зображення кроку 3 – перерахування інстансів – 7 екземплярів можуть бути підключені до наших нових облікових даних
Крок 4: Підключення до інстансу
Зрештою, на основі ідентифікованих екземплярів виберемо той, до якого хочемо підключитися, використовуючи режим підключення скрипту. Підключимося до цього екземпляра.
Залишимо на розсуд читачів, якими можуть бути подальші кроки на цьому етапі. Зловмисники зазвичай вважають за краще добувати біткоїни або шифрувати файли даних.
Зображення кроку 4 – підключення до інстансу
Розгортання технології обману для проактивного кіберзахисту
Рішення на основі технології обману, таке як Fidelis Deception®, дозволяє користувачам швидко та легко поширювати неправдиві ресурси у реальному хмарному середовищі. Вся активність на цих ресурсах постійно відстежуватиметься і видаватиме високоточні, дієві попередження.
У цьому прикладі середовища використовували такі ресурси-приманки.
· Примірники EC2 – ми розгорнули 2 неправдиві екземпляри EC2.
· Ролі IAM – розгорнули три помилкові ролі з різними політиками.
· S3 – розгорнули два сховища S3 з кількома хибними документами.
Також було створено зв’язки між хибними ресурсами. Наприклад, роль decoy має права доступу до екземплярів decoy EC2 та файлів decoy S3.
Подібно до того, як мережеве середовище обману має відповідати локальній місцевості, хмарні ресурси-обманки повинні органічно вписуватися в хмарне середовище. Атакуючий не повинен зрозуміти, що його привели до хибних ресурсів за допомогою технології обману, і повинен повірити, що він взаємодіє з цінними активами.
У наведених нижче сповіщеннях побачимо оповіщення, що спрацювали під час фази перерахування та фази ескалації привілеїв, описаних вище.
Попередження 1 – Перелік EC2
Попередження 2 – Присвоєння ролі
Попередження 3 – Підключення EC2
Захист хмари за допомогою технології виявлення
Для забезпечення безпеки організації необхідно захищати хмару так само ретельно, як мережу. Описали кілька способів, за допомогою яких зловмисник може отримати доступ без технології обману.
Кіберпротивники можуть робити ці дії з будь-якого місця, і їм, звичайно, не обов’язково перебувати всередині вашої мережі. Проте атаки можуть виходити від внутрішніх загроз. Традиційні засоби мережевої безпеки не зможуть ефективно відобразити ці атаки. Технологія обману забезпечує захист від зовнішніх загроз та шкідливого ПЗ, а також захист від внутрішніх загроз.
За допомогою правильних інструментів ви можете перейти до проактивного кіберзахисту за допомогою обманного рішення, яке не залежить від того, як зловмисник проник у ваше середовище. Мета технології обману – швидко виявити зловмисників, які проникли у ваше середовище, та відвернути їх від виробничих активів.
Fidelis Deception має кілька рівнів обману, які можуть бути розгорнуті у вашому хмарному середовищі. У цьому блозі було розглянуто розгортання хмарних ресурсів-обманок. Додаткові рівні – це обманки, які можуть бути розгорнуті на серверах у хмарі або обманки, які можуть бути розгорнуті у вигляді капсул у контейнерах. Ви можете ще більше посилити захист у хмарних середовищах, забезпечивши видимість цих динамічних, розподілених та різноманітних систем. Створена для хмари платформа управління положенням, захисту робочих навантажень та безпеки контейнерів, така як Fidelis CloudPassage Halo®, у поєднанні з Fidelis Network®, може забезпечити вам глибоку видимість хмари, яка вам необхідна, а також оцінку ризиків ваших хмарних активів у режимі реального часу щоб ви могли постійно вдосконалювати свій захист.
Джерело: https://bit.ly/3ZzUIwW
