Помилки конфігурації AWS, які варто виправити першими

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

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

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

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

На відміну від вразливості в коді, тут нічого не треба експлуатувати. Сама настройка і є всією проблемою.

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

Згруповано за рівнем, де живе настройка, бо в кожного свій власник і свій фікс.

Назви бакетів слідують конвенціям компанії й зʼявляються в коді сторінок, мобільних застосунках і документації підтримки, тож зловмиснику рідко доводиться вгадувати наосліп. Перелік вмісту бакета й читання обʼєктів це окремі дозволи, які видають разом випадково, і саме так анонімний запит завершується поверненням клієнтського експорту. Вправа Public Storage Buckets дає знайти й прочитати саме таку експозицію, а потім закрити її block-public-access на рівні акаунта як страхувальним контролем і політикою бакета, яка називає, хто саме може читати.

Security group це фаєрвол, і одне поле в одному правилі вирішує, чи база даних доступна лише з рівня застосунку, чи з будь-якої адреси в інтернеті. Відкритий порт бази даних це запрошення, а не злам сам по собі, але команди, які вважають порт недосяжним, рідко ставлять за ним надійний логін. Вправа Cloud Network Exposure дає підключитися прямо до продакшн-бази даних без застосунку на шляху, а потім звузити правило до підмережі застосунку й обґрунтувати, чому базам даних узагалі не місце в публічних підмережах.

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

Журнал аудиту, що покриває один регіон і жодного іншого, має сліпу зону, яку зловмисник з будь-якою точкою опори знайде і використає негайно, а вимкнення журналу посеред інциденту ховає все, що станеться після. Неможливо відтворити те, що ніколи не було записано. Вправа Cloud Audit Logging Gaps дає розслідувати інцидент, де сталося саме це, а потім виправити це журналюванням на весь акаунт, перевіркою цілісності журналу, тривогою на будь-яку зміну конфігурації самого трейла й доставкою логів в акаунт, до якого джерело не має доступу.

У порядку того, скільки експозиції знімає кожен фікс, а не того, як він виглядає в чеклісті аудиту.

1. Увімкніть block-public-access на рівні акаунта до того, як чіпати будь-яку окрему політику бакета. Це страхувальний контроль, який тримає навіть тоді, коли хтось наступного кварталу знову напише необережну політику.
2. Видавайте перелік вмісту бакета й читання обʼєктів як окремі, свідомі дозволи. Ставлення до них як до одного гранту і є тим, як анонімний запит закінчується читанням даних, які ніхто не планував публікувати.
3. Звужуйте кожне правило security group до підмережі чи сервісу, якому справді потрібен порт, ніколи не 0.0.0.0/0. Правило, що відповідає всьому інтернету, рідко є свідомим рішенням.
4. Тримайте бази даних поза публічними підмережами взагалі. Правило фаєрвола відділяє одну настройку від помилки. Приватна підмережа прибирає експозицію як категорію.
5. Видаляйте DNS-запис того самого дня, коли ресурс виводиться з експлуатації, а не пізнішим тікетом. Висячий запис це назва, яку можна заявити собі, доки вона існує.
6. Скануйте на записи, що досі вказують на ресурси, якими ви більше не володієте. Виведення з експлуатації зазвичай відбувається швидше, ніж хтось це документує, тож сканування знаходить те, що самою лише політикою пропустять.
7. Увімкніть журнал аудиту хмари на весь акаунт, у кожному регіоні, до того, як він знадобиться. Трейл, що покриває лише той регіон, у якому ви розгорнулися першим, це сліпа зона з вашим імʼям на ній.
8. Увімкніть перевірку цілісності файлів журналу й тривогу на будь-яку зміну конфігурації самого трейла. Вимкнення журналювання це та єдина дія, успіх якої ховає всі дії після неї.

Більшість команд вчаться на цьому так само, як компанія з початку статті: зі звіту дослідника чи рахунку в пʼять разів більшого за звичайний. Це дороге навчання, і воно покриває лише ту одну помилку конфігурації, яку випадково знайшли.

Альтернатива це пройти експозицію самому до того, як вона стане живою в продакшні. Інженер, який перелічив вміст бакета без облікових даних і побачив, як повертається клієнтський експорт, після цього перевіряє block-public-access на кожному акаунті без нагадувань.

Саме так працюють наші вправи Cloud Infrastructure Security — девʼять вправ, які ми випустили в категорії Cloud Security поряд з наявним курсом про контейнери. Кожна ставить вас на бік атакуючого в реальній експозиції першою, а потім дає задеплоїти фікс і довести, що він закрив діру.

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

Як зловмисники знаходять публічні S3-бакети, якщо не знають назви?

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

Чи достатньо виправити одну політику бакета, коли знайдено експозицію?

Ні. Політика бакета це конкретна помилка, але настройка на рівні акаунта це страхувальний контроль. Виправлення лише знайденого бакета лишає ту саму помилку доступною на кожному іншому бакеті в акаунті, тому block-public-access має бути на рівні акаунта в першу чергу.

Чому захоплення субдомену працює, навіть якщо наш домен ніколи не був скомпрометований?

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

Чим security group відрізняється від network ACL?

Security group зі станом і привʼязана до ресурсу, тож правило, яке дозволяє вхідний трафік, автоматично дозволяє відповідну вихідну відповідь. Network ACL без стану й привʼязана до підмережі, оцінюється до того, як трафік узагалі дістанеться security group. Більшість експозицій зводяться до правила security group, бо саме його команди редагують найчастіше.

Чи відновлює увімкнення журналу аудиту після інциденту те, що було пропущено?

Ні. Увімкнення журналювання не заповнює заднім числом нічого з того, що сталося до зміни настройки, а регіон, який ніколи не покривався, не має запису, який можна відновити, незалежно від того, коли ви це помітите. Єдиний фікс, що допомагає після факту, це покриття кожного регіону до наступного інциденту, а не цього.

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

Наші вправи Cloud Infrastructure Security безкоштовні для тестування, а щоб розгорнути їх на всю інженерну команду, звʼяжіться з нами.