Ми використовуємо файли cookie для нашого веб-сайту.Продовжуючи перегляд сайту, ви погоджуєтеся з використанням нами файлів cookie.

Головна Блог Новини Використання технології обману в хмарних середовищах

Використання технології обману в хмарних середовищах

Компанії все частіше використовують хмарні сервіси для зберігання даних, віртуальних машин, контейнерів, безсерверних функцій тощо. Із зростанням популярності хмарних сервісів інтерес кіберзловмисників відповідно зріс. Оскільки будь-кому легко налаштувати хмарний екземпляр – і не завжди відповідно до протоколів ІТ-безпеки – зловмисники користуються перевагами нових способів отримати доступ до організаційних даних та активів. Коли ми говоримо про хмарні послуги загалом і AWS зокрема, не можна ігнорувати підключення від локального середовища до хмари. Використання технології обману в хмарі є життєво важливим для захисту сучасного середовища, що швидко розвивається.

Коли ваша мережа переходить у хмару, ваш шар “обману”(приманка) також повинен перейти. Існує багато способів розгорнути ресурси-приманки в хмарі. Давайте подивимося на сценарій атаки та покажемо деякі сповіщення, які спрацьовують із нашого шару обману.

У цьому сценарії атаки ми розпочнемо з кібер-зловмисника, який уже отримав доступ до вашої мережі, і покажемо різні способи отримання облікових даних AWS. Потім ми покажемо деякі сценарії перерахування, які можуть використовуватися зловмисниками для збору розвідувальної інформації про хмарне середовище, щоб підвищити привілеї та підключитися до деяких екземплярів хмари.

Експлойти нульового дня виявляються часто, і вони з’являються, коли ви найменше очікуєте їх. Розгортання рішення для обману дозволяє завчасно підготувати вашу мережу до кібер-зловмисників. Після розгортання приманки чекатимуть будь-яких завчасних зловмисників, які потраплять у ваше середовище — локально чи в хмарі.

Сценарій: кібератаки в хмарних середовищах без технології обману

Кожна велика атака починається з одного маленького кроку. Насправді зловмисник може отримати доступ до вашої мережі багатьма способами. Нещодавно було опубліковано дві атаки нульового дня, які дозволяють віддалено виконувати код (RCE) і швидкий доступ до вразливих машин: Log4j і Spring4shell . У нашому нещодавньому блозі ми показали, як такі атаки можна використовувати для швидкого отримання облікових даних AWS. Багато таких атак дають доступ до машин-жертв, і, потрапивши всередину, зловмисники можуть отримати облікові дані AWS, які відкривають двері для бічного переміщення через хмару.

Ось як кібер-зловмисники отримують такий доступ:

Початковий доступ: облікові дані AWS

Наприклад, щоб підключитися до AWS за допомогою програмного доступу, адміністратор облікового запису повинен згенерувати ключ доступу та секретний ключ доступу для певного користувача AWS. Це часто зустрічається під час роботи з інтерфейсом командного рядка (CLI) AWS . Зловмисник, який має доступ до цих ключів, отримає доступ до середовища AWS цього користувача.

Якщо машина-жертва використовує AWS CLI, ці облікові дані зазвичай зберігаються відкритим текстом на цій машині. Зазвичай їх легко знайти в одному з цих місць:

  • Під час завантаження облікових даних з AWS вони зберігаються у файлі у форматі CSV. Ім’я файлу за замовчуванням: <USER>_credentials.csv.
  • У більшості випадків автоматичні інструменти (наприклад, AWS CLI або boto3 Python) використовуватимуть файл облікових даних, розташований у каталозі «.aws». На машинах Linux цей файл буде тут: ~/.aws/credentials, а на машинах Windows — тут: C:UsersUSERNAME.awscredentials
  • Замість того, щоб зберігати їх у файлах, деякі конфігурації зберігатимуть ключі у змінних середовища на машині: 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 connect CLI . Щоб дізнатися більше, перегляньте цей сценарій на нашому GitHub .

Сценарій 2 – role_enumeration

Сценарій ролі має три режими: перерахування, деталі та припущення. Режим перерахування перераховує ролі, підсумовує деталі щодо кожної з них і позначає, які ролі можна прийняти з наявними дозволами. У режимі деталей буде показано більше деталей про роль та її політику. Режим припущення спробує взяти на себе обрану роль. Цей скрипт в основному базується на AWS SDK для phyton, Boto3 . Щоб дізнатися більше, перегляньте цей сценарій на нашому GitHub.

Ми будемо використовувати два сценарії разом, щоб перерахувати та підвищити привілеї, які ми маємо спочатку. Давайте спочатку перевіримо, до яких екземплярів і ролей ми можемо отримати доступ з початковим користувачем, до якого ми підключаємося. Потім ми візьмемо на себе ролі, до яких маємо доступ, і знову спробуємо виконати перерахування, щоб визначити додаткові ролі та екземпляри, які зараз відкриті. Нарешті, ми скористаємося сценарієм екземплярів, щоб отримати доступ оболонки до одного з екземплярів і виконувати з ним дії.

 Крок 1: Перерахування

На цьому кроці ми перераховуємо доступні екземпляри EC2 і ролі. Він показує, до яких екземплярів можна підключити і які ролі можна взяти на себе. Коли ми знайдемо роль, яку можна прийняти і має цікаві дозволи, ми можемо описати її докладніше.

Крок зображення 1.1 – перерахування екземплярів – жоден із екземплярів не може бути пов’язаний з нашими обліковими даними
Крок зображення 1.2 – перерахування ролей – наш користувач може взяти на себе 3 ролі, одна з яких має права на EC2 та S3.
Крок зображення – 1.3 – з описом ролі: Iam_role_1

Крок 2: Прийміть роль

Далі скористаємося опцією «Приняти роль» у сценарії. Сценарій візьме на себе цю роль і надасть нам дійсний маркер, який можна використовувати для наступних ітерацій.

Крок 2 зображення – отримання облікових даних після прийняття ролі

Крок 3: Перерахування

Використовуйте новий маркер і повторно виконайте команди перерахування, щоб визначити додаткові екземпляри. На зображенні нижче ми бачимо, що були ідентифіковані нові екземпляри EC2, у тому числі ті, які дозволяють нам використовувати облікові дані, які ми маємо для підключення.

Зображення, крок 3 – перерахування екземплярів – 7 екземплярів можна підключити до наших нових облікових даних

Крок 4. Підключіться до екземпляра

Нарешті, на основі ідентифікованих екземплярів ми виберемо, до яких ми хочемо підключитися, використовуючи режим підключення сценарію. Підключіться до цього екземпляра.
Ми залишимо уяву читачів, якими можуть бути наступні кроки на цьому етапі. Зловмисники зазвичай люблять майнити біткойни або шифрувати файли даних.

Крок 4 зображення – підключення до екземпляра

Розгортання технології обману для активного кіберзахисту

Технологічне рішення для обману, таке як Fidelis Deception®, дозволяє користувачам швидко й легко поширювати ресурси-приманки в реальному хмарному середовищі. Тоді вся активність цих ресурсів буде постійно відстежуватися, а також надаватися високоточні сповіщення, які можна діяти.

У цьому прикладі середовища ми поширюємо такі ресурси-приманки.

  • Примірники EC2 – ми розгорнули 2 екземпляри приманки EC2.
  • Ролі IAM – ми розгорнули 3 ролі приманки з різними політиками
  • S3 – ми розгорнули два відра S3 з кількома документами-приманками

Ми також створили зв’язки між ресурсами приманки. Наприклад, роль приманки має дозволи на екземпляри приманки EC2 і файли приманки S3.

Подібно до того, як мережеве середовище для обману повинно відповідати вашому локальному ландшафту, ваші ресурси-приманки в хмарі повинні плавно поєднуватися з вашим хмарним середовищем. Ваш зловмисник не повинен усвідомлювати, що він був приманок за допомогою технології обману, і натомість повинен вірити, що він взаємодіє з цінними активами.

У наведених нижче сповіщеннях ми побачимо сповіщення, які запускаються під час фази перерахування та фази підвищення привілеїв, описаної вище.

Попередження 1 – перерахування EC2

Попередження 2 – Прийміть роль

Попередження 3 – підключення EC2

Захистіть свою хмару за допомогою технології виявлення Щоб забезпечити безпеку вашої організації, ви повинні захищати свою хмару так само суворо, як і ландшафт мережі. Ми окреслили кілька способів, за допомогою яких зловмисник може отримати доступ за відсутності технології обману.

Кібер-зловмисники можуть виконувати ці дії з будь-якого місця і, звичайно, не повинні перебувати у вашій мережі. Однак атаки можуть походити і від внутрішніх загроз. Традиційні засоби безпеки мережі не будуть ефективними для виявлення цих атак. Технологія Deception забезпечує захист від зовнішніх загроз і шкідливих програм, а також забезпечує захист від внутрішніх загроз.

За допомогою правильних інструментів ви можете перейти до проактивного кіберзахисту з рішенням для обману, яке не залежить від того, як зловмисник проник. Мета технології обману — швидко виявити зловмисників, які потрапили у ваше середовище, і виманити їх із виробництва.

Fidelis Deception має кілька рівнів обману, які можна розгорнути у вашому хмарному середовищі. У цьому блозі ми розповіли про розгортання хмарних ресурсів-приманок. Додаткові шари — це приманки, які можна розгорнути на серверах у хмарі, або приманки, які можна розгорнути як модулі на контейнерах. Ви можете додатково розширити свій захист у хмарних середовищах, забезпечивши видимість цих динамічних, розподілених та різноманітних систем. Створений для хмари керування положенням, захист робочого навантаження та платформа безпеки контейнерів, як-от Fidelis CloudPassage Halo®, у поєднанні з Fidelis Network®, можуть надати вам необхідну видимість глибокої хмари, а також оцінку ризиків вашої хмари в реальному часі активи, щоб ви могли постійно покращувати свій захист.

Звучить занадто добре, щоб бути правдою? Дізнайтеся більше про Fidelis Deception. Спеціалісти компанії Wise IT проконсультують та допоможуть з підбором рішення з інформаційної безпеки в залежності від ваших потреб. Зателефонуйте нам за номером +38 (044) 277-23-23 або надішліть нам листа за адресою info@wiseit.com.ua

Бажаєте використовувати передові рішення з кібербезпеки? Wise IT ваш надійний партнер у світі цифрової трансформації!