19 липня 2019 року банк Capital One отримав повідомлення, якого боїться кожна сучасна компанія — стався витік даних. Вона торкнулася більше 106 мільйонів людей. 140 тисяч номерів соціального страхування США, один мільйон номерів соціального страхування Канади. 000 80 банківських рахунків. Неприємно, погодьтеся?
На жаль, злом стався зовсім не 19 липня. Як з'ясувалося, Пейдж Томпсон, вона ж Нестійкий, здійснила його між 22 березня та 23 березня 2019 року. Тобто майже чотири місяці тому. Насправді лише за допомогою зовнішніх консультантів Capital One зуміла дізнатися, що щось сталося.
Колишню співробітницю Amazon заарештовано, їй загрожує штраф у розмірі $250 тис. та п'ять років в'язниці… але залишилося багато негативу. Чому? Тому що багато компаній, які постраждали від зломів, намагаються відмахнутися від відповідальності за зміцнення своєї інфраструктури та додатків на тлі зростання кіберзлочинності.
У будь-якому випадку ви можете легко загуглити цю історію. Ми не вдаватимемося в драматизм, а поговоримо про технічної стороні справи.
По-перше, що сталося?
У Capital One працювало близько 700 бакетів S3, які Пейдж Томпсон скопіювала та викачала.
По-друге, це ще один випадок неправильно настроєної політики бакетів S3?
Ні, не цього разу. Тут вона отримала доступ до сервера з неправильно налаштованим файрволом та звідти провела всю операцію.
Зачекайте, як це можливо?
Ну, давайте почнемо з входу на сервер, хоч у нас мало подробиць. Нам тільки сказали, що це сталося через «неправильно налаштований файрвол». Отже, щось настільки просте, як неправильні налаштування груп безпеки або конфігурація файрвола веб-програми (Imperva), або мережевого файрвола (iptables, ufw, shorewall тощо). Capital One лише визнала свою провину і сказала, що закрила дірку.
Стоун сказав, що Capital One спочатку не помітив вразливість файрвола, але швидко відреагував, як тільки дізнався про неї. Безумовно, цьому допоміг той факт, що хакер імовірно залишила у відкритому доступі ключову інформацію, що ідентифікує, сказав Стоун.
Якщо вас цікавить, чому ми не заглиблюємося в цю частину, зрозумійте, що через обмежену інформацію ми можемо лише спекулювати. Це безглуздо з огляду на те, що злом залежав від пролому, залишеного Capital One. І якщо вони не розкажуть нам більше, ми просто перераховуватимемо всі можливі способи, як Capital One залишила свій сервер відкритим у комбінації з усіма можливими способами, якими хтось може використовувати один із цих різних варіантів. Ці проломи та методи можуть змінюватись від дико дурних помилок до неймовірно складних патернів. Враховуючи діапазон можливостей, це перетвориться на довгу сагу без реального укладання. Тому зосередимося на аналізі тієї частини, де ми маємо факти.
Так що перший висновок: знайте, що дозволяють ваші файрволи
Встановіть політику або правильний процес для гарантії, що відкрито ТІЛЬКИ те, що має бути відкрито. Якщо ви використовуєте ресурси AWS, такі як Security Groups або Network ACL, очевидно, чекліст для перевірки може бути довгим… але як багато ресурсів створюються автоматично (тобто CloudFormation), також можна автоматизувати їхній аудит. Будь то саморобний скрипт, який переглядає нові об'єкти на предмет проломів, або щось подібне до аудиту безпеки в процесі CI/CD… є багато простих варіантів, щоб уникнути цього.
«Кумедна» частина історії полягає в тому, що якби Capital One закрила дірку з самого початку… нічого не сталося б. І тому, відверто кажучи, завжди шокує бачити, як справді щось досить просте стає єдиною причиною злому компанії. Особливо такий великий як Capital One.
Отже, хакер усередині - що трапилося далі?
Ну, після проникнення в інстанс EC2... багато може піти не так. Ви ходите практично лезом ножа, якщо дозволяєте комусь зайти так далеко. Але як вона потрапила до бакетів S3? Щоб зрозуміти це, обговоримо ролі IAM (IAM Roles).
Отже, один із способів отримати доступ до сервісів AWS – бути Користувачем (User). Гаразд, це досить очевидно. Але що робити, якщо ви хочете надати іншим сервісам AWS, наприклад своїм серверам додатків, доступ до своїх бакетів S3? І тому існують ролі IAM. Вони складаються з двох компонентів:
- Trust Policy — які служби чи люди можуть використовувати цю роль?
- Permissions Policy – що дозволяє ця роль?
Наприклад, ви хочете створити роль IAM, яка дозволить інстансам EC2 отримати доступ до бакету S3: по-перше, для ролі встановлюється Trust Policy, що EC2 (вся служба) або конкретні інстанси можуть «взяти на себе» роль. Прийняття ролі означає, що вони можуть використовувати дозволи для виконання дій. По-друге, Permissions Policy дозволяє службі/людині/ресурсу, яка «взяла на себе роль», робити щось на S3, чи то доступ до одного конкретного бакета… або до понад 700, як у випадку Capital One.
Як тільки ви перебуваєте в інстансі EC2 за участю IAM, ви можете отримати облікові дані декількома способами:
- Можете запросити метадані інстансу на адресу
http://169.254.169.254/latest/meta-dataСеред іншого, за цією адресою можна знайти роль IAM з будь-яким ключем доступу. Звичайно, тільки в тому випадку, якщо ви перебуваєте в інстансі.
- Використовувати AWS CLI…
Якщо встановлено інтерфейс командного рядка AWS, він завантажується з обліковими даними з ролей IAM, якщо вони присутні. Залишається тільки працювати ЧЕРЕЗ інстанс. Звичайно, якби їхня політика Trust Policy була відкритою, Пейдж могла б зробити все безпосередньо.
Таким чином, сутність ролей IAM полягають у тому, що вони дозволяють одним ресурсам діяти ВІД ВАШОГО ІМЕНІ на ІНШИХ РЕСУРСАХ.
Тепер, коли ви розумієте роль IAM, ми можемо поговорити про те, що зробила Пейдж Томпсон:
- Вона отримала доступ до сервера (інстанс EC2) через пролом у файрволі
Будь то групи безпеки/ACL або їх власні файрволи веб-застосунків, ймовірно, дірку виявилося досить легко закрити, як зазначено в офіційних записах.
- Опинившись на сервері, вона змогла діяти «начебто» сама була сервером
- Оскільки роль IAM сервера дозволила доступ S3 до цих 700+ бакетів, вона змогла отримати доступ до них
З цього моменту їй залишалося лише запустити команду List Buckets, а потім команду Sync з AWS CLI…
. Запобігання такому збитку — ось чому компанії так багато інвестують у захист хмарної інфраструктури, DevOps та експертів з безпеки. І наскільки цінним та економічно ефективним є перехід у хмару? Настільки, що навіть перед все нових і нових проблем кібербезпеки !
Мораль цієї історії: - перевіряйте свою безпеку; регулярно проводьте аудит; шануйте принцип найменших привілеїв для політик безпеки.
( можете переглянути повний юридичний звіт).
Джерело: habr.com