Витік секретів: один крок до розкриттяsaster

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

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

Боже мій! Я переніс свої ключі доступу до хмари до публічного репозиторію.

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

Озираючись назад, це тривожно як часто проста недоглядність призводила до серйозного порушення безпеки. Просто погугліть "Витоки ключів AWS»,«Витік токенів доступу до GitHub«, і так далі. Не сприймайте ці приклади як приховані рекомендації для того чи іншого постачальника. Використовуйте свої власні!

Наприклад, (не)відомий Атака Codecov Зміна у квітні 2021 року стала можливою завдяки тому, що образ Docker Codecov містив облікові дані git, які дозволяли зловмиснику отримати доступ до приватних репозиторіїв git Codecov та додати один рядок у скрипті завантаження bash Codecov для змінних середовища колекції та URL-адрес репозиторіїв git.

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

Проблема в тому жорстко закодовані секрети є звичайним явищемУ березні 2022 року Lapsus$ APT витік 189 ГБ вихідного коду Samsung та інших конфіденційних файлів. Аналіз показав, що він містив деякі 6,600 жорстко закодованих секретів90% для внутрішніх систем, але 10% для зовнішніх сервісів та інструментів, таких як GitHub, AWS або Google. Ці секрети включали ключі API AWS / Twilio / Google, рядки підключення до бази даних та іншу конфіденційну інформацію. Це найсучасніший рівень у більшості баз коду.

Витік секретів – найпростіший шлях до атак на ланцюги поставок

Залежності пакетів наразі є найчастішою, хоча й не єдиною, ціллю атак на ланцюги поставок. Зловмисники можуть створити новий пакет, який встановлюється в програмне забезпечення жертв (використовуючи друкарський сквот та інші методи), але зазвичай вони намагаються заразити існуючий пакет, додаючи модифікації до вихідного коду в репозиторіях програмного забезпечення (SCM), як-от GitHub, GitLab або BitBucket, або шляхом додавання шкідливих версій до публічних реєстрів, таких як NPM, PyPI, RubyGems, Maven Central.

Але впровадження шкідливого коду або шкідливої ​​залежності, прихованої в складному графі залежностей, вимагає login облікові дані, такі як ім'я користувача/пароль, токени або ключі доступу (назвемо їх «ключі«скорочено» ), для цільового вихідного репозиторію або публічного реєстру відповідно. 

Погані хлопці іноді отримують ключі через соціальна інженерія,  атака на event-stream популярний пакет NPM є гарним прикладом. Але пошук витоків login облікові дані або ключі доступу є найпоширенішим методом атаки на ланцюги постачання програмного забезпечення.

Репозиторії вихідного коду та реєстри пакетів – це дві важливі системи у збірці програмного забезпечення. pipelineАле в DevOps є багато інструментів: CI/CD системи, інструменти для проведення тестів, автоматизації конфігурації та забезпечення, або розгортання та випуску. Усі вони можуть бути використані для впровадження шкідливого коду в програмне забезпечення. Витік дійсних ключів для цих інструментів призводить безпосередньо до страждань та страждань. Уявіть собі витік ключів root-доступу з повним контролем над вашими публічними хмарними ресурсами…

Звичайні рекомендації

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

• Якщо ви відповідаєте за управління ІТ-безпекою, визначити, як слід поводитися з секретами у політиці безпеки. Але політики ефективні лише за умови їхнього забезпечення: переконайтеся, що у вашій організації застосовуються правила поводження з секретами, включаючи не лише ваші команди DevOps, але й постачальників програмного забезпечення, а також що план реагування на інциденти вашої організації містить положення щодо інцидентів витоку секретів.
• Впровадити та забезпечити виконання багатофакторна аутентифікація (MFA, 2FA або будь-яка інша абревіатура). І жодних скорочень безпеки: USB-ключ безпеки вартий своїх кількох доларів. Вам доведеться надіслати будь-які з тисяч облікових даних за допомогою git-push (легко), а потім напитися та залишити свої ключі в барі з чимось, що пов'язано з вами (ймовірність трохи менша, особливо якщо ви непитущий).
• Використовуйте менеджер паролів із надійним, незбереженим паролем. Для роботи з секретами в системах використовуйте Таємні сховища. CI/CD системи, хмарні провайдери, SCMта інші інструменти DevOps надають цю послугу, але ви можете обрати універсальне рішення Secret Vault.
• Віддавайте перевагу недовговічні токени на довговічні ключі доступу. Їх легше відкликати, і вони надають обмежені можливості зловмисникам.
• Обмеження повторного використання облікових даних: зловмисники повторно використовуватимуть зібрані облікові дані для цілі в інших системах, що є ще одним аргументом на користь використання менеджера паролів. Менеджери паролів та секретні сховища повинні зробити повторне використання облікових даних пережитком минулого.
• Обмежте та контролюйте використання адмін паролі. Вони достатньо потужні, щоб заслуговувати на особливе відстеження.
• Здійснювати надійне хешування та шифруванняПовертаючись до USB (криптографічних) ключів, суворих процедур передачі облікових даних партнерам та колегам тощо.
• Використовувати сканер секретів, наприклад, запустити в pre-commit гачок щоб уникнути витоків у системах контролю версій, як захисний шлюз. Перед тим, як це сталося тут важливо. Як варіант, використовуйте постфактумне сканування для виявлення витоків секретів, наприклад, як перевірку перед pull request злиття. Примітка: Наша платформа Xygeni містить сканер секретів, що дозволяє працювати в обох режимах. 
• Ручний варіант використання код огляди пошук жорстко закодованих секретів має вищі витрати та працює післяcommit (але, сподіваємося, принаймні до того, як секрет стане доступним для сторонніх). Однак перевірки можуть виявити нетрадиційні секрети, які можуть уникнути сканерів секретів.       
• Уникайте випадкового commitперенесення спільних файлів із секретами до системи контролю версій з відповідними виключити шаблони (як шаблон `gitignore`), враховуючи файли типу .env, .npmrc, .pypirc, тимчасові файли… Дійсно, додатковий рівень безпеки.
• І останнє у цьому довгому списку: дозвольте постачальникам хмарних послуг виконувати сканування на наявність витоків ключів, коли це можливо. Принаймні, це може повідомить вас про витік, коли він стався, але безпека є обов'язковою для постачальників хмарних послуг. Це ретроспективному Приховане сканування не дуже прозоре щодо того, де і як часто воно виконується, і часто потребує чіткого налаштування, але, безумовно, є останнім ресурсом, коли все інше не допомагає.

Боже мій! Я передав свої ключі доступу до хмари до публічного репозиторію, дубль №2.

Це може статися з найкращими з нас. Засукайте рукави!

Негайно поновіть / скасуйте / деактивуйте витік секрету! Якщо обліковий запис має пристойну багатофакторну автентифікацію (MFA), то ризик набагато нижчий. Це може бути складніше, наприклад, із закритими ключами на веб-сайтах (вам потрібно створити новий сертифікат для нового закритого ключа та скасувати існуючий), але сучасні інструменти мають швидкий спосіб поновлення облікових даних або скасування токенів. 

Виконайте кроки, рекомендовані постачальником, якщо вони доступні, наприклад AWS у цьому прикладі.

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

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

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

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

Якщо ви любите пригоди та хочете на власні очі побачити, скільки часу потрібно ботам, щоб виявити витік секрету, такі як розтяжки Канарські токени дозволить вам експериментувати. Пам’ятайте, що боти додають до чорного списку значення за замовчуванням canarytokens.org домен…