Статический анализ JavaScript

Всем привет!

По ссылке можно найти вводную статью, посвященную статическому анализу JavaScript-приложений, подготовленную Snyk.

Автор разбирает разделы:
🍭 Что такое статический анализ и зачем он нужен
🍭 Отличие статического анализа от динамического
🍭 Статический анализ для нужд Quality и Security
🍭 Введение в Abstract Syntax Tree (AST) и его использование в анализе ПО

Каждый из блоков рассматривается на минималистичном примере, к которому даются комментарии.

В качестве инструмента анализа упоминается Snyk и ESLint.

Статья направлена на изучение базовых принципов и используемых технологий анализа кода на примере JavaScript и может пригодиться тем, кто только начинает свой путь в этой области.

Компрометация кластера Kubernetes: пример сценария

Всем привет!

В статье рассматривается возможный сценарий компрометации кластера Kubernetes. Про «подготовку» такого кластера можно почитать вот тут (чтобы контекст был более понятен).

Сама «лабораторная среда» содержит множество некорректных конфигураций, которыми сможет воспользоваться злоумышленник.

Автор проделывают следующий путь:
🍭 Получают reverse shell в Pod. Для этого используется supply chain атака с подменой requests на request(typosquating) ***🍭*** Сбор первичной информации об окружении – какой runtime используется, что есть «внутриPod», анализ полномочийServiceAccount, из\-под которой запущенPod`
🍭 Получение доступа к базе данных, используя роль Kubernetes, права которой только RO
🍭 Компрометация GitHub Runners / GitHub Actions и не только

Может показаться, что все подстроено. Отчасти – да, отчасти – нет, т.к. некорректные конфигурации в реальности встречаются чаще, чем хотелось бы. Поэтому некоторые из этих сценариев могут быть не совсем «теоретическими».

Вывод из этого можно сделать достаточно простой – не стоит пренебрегать практиками и средствами автоматизации, которые могут помочь в безопасной настройке окружения, необходимого как для разработки, так и для эксплуатации ПО.

«Вредные советы» по безопасной разработке

Всем привет!

Обычно рассказывают про хорошие / лучшие практики по чему-либо. Безопасная разработка – не исключение.

Однако, все мы помним Григория Остера и его замечательные «Вредные советы». Которые весело читались и сохранялись в памяти на долгие годы.

Поэтому сегодня хотим рассказать про статью от CISA, в которой собраны такие вот "советы" по вопросам безопасности разрабатываемого ПО.

Например:
🍭 Использование memory unsafe languages (спорно, но)
🍭 Возможность добавления пользовательского ввода в SQL-запросы
🍭 Возможность добавления пользовательского ввода в команды ОС
🍭 Использование «чего-либо», обладающего известными уязвимостями и т.д.

Для каждого «совета» приводится описание и как делать «правильно». Да, выглядит «избито и банально», но, возможно, в такой трактовке лучше запомнится 😊

P.S. А если вы не знаете, кто такой Григорий Остер и что за «Вредные советы» - очень настойчиво рекомендуем ознакомиться 😊**

Основы сети и сетевая безопасность в Kubernetes

Всем привет!

Если вы хотите познакомиться с основами сетевого устройства Kubernetes и подходами по защите, то эта обзорная статья может вам подойти.

Команда Otterize описывает следующее:
🍭 Ключевые концепты (Kube-proxy, Service и их типы)
🍭 Network Policies и как их можно использовать
🍭 «Путешествие» пакета и то, как можно анализировать трафик на примере простого приложения
🍭 Создание Network Policy для вышеуказанного приложения с использованием Open Source наработок Otterize (о которых мы писали тут и тут)

Очень много схем, комментариев и примеров. Отдельно хочется отметить часть, связанную с «путешествием» пакета – Авторы разобрали все весьма подробно.

Kubelab: интерактивные лабораторные по Kubernetes

Всем привет!

Самый простой способ что-то изучить – практика, практика и еще раз практика. Поэтому сегодня предлагаем вам познакомиться с проектом Kubelab.

Он позволяет реализовать «интерактивный Kubernetes-тренажер» локально и проходить различные задания.

Например:
🍭 Основы работы с Kubernetes (Networking, Storage, Jobs, RBAC и т.д.)
🍭 «Продвинутые» задания (выстраивание «цепочек» из того, что поясняется в «Основах»)

Для лабораторных есть подсказки или готовые решения, если не получилось сделать самостоятельно. Кроме этого, Kubelab обладает Web UI и редактором кода, чтобы упростить обучение.

Важно: проект еще достаточно «молодой», поэтому возможны различные нюансы, связанные с его работой

ℹ️ Материалы по NIST CSF на русском

NIST CSF на мой взгляд один из лучших фреймворков по управлению рисками кибербезопасности. Изначально целевая группа NIST CSF – критически важные объекты, новая же (v 2.0) структура стала адаптируемой и полезной для более широкого круга организаций.

Все материалы NIST CSF на английском, но энтузиасты перевели их на русский и поделились с киберсферой:
1️⃣ Перевод NIST CSF от Вячеслава Аксенова (itsec.by). Получилось довольно качественно, переведены даже картинки (приложил к посту)
2️⃣ Перевод методики оценки по NIST CSF от Дмитрия Шапошникова. Структура документа подготовлена для ее загрузки в BI для визуализации прогресса

Забираем в закладки)
#framework

Наш друг ведет отличный канал по информационной безопасности в целом и по обновлениям различных стандартов в частности.

Не совсем по тематике DevSecOps, но вдруг кому-нибудь будет интересно :)

Эксплуатация software supply chain уязвимостей в Consul

Всем привет!

Сегодня предлагаем вам небольшую статью, в которой Авторы рассказывают о том, как им удалось найти dependency confusion в проекте Consul.

Началось все с того, что они обнаружили пакет, управление версиями для которого не осуществлялось. Да, был еще один конфигурационный файл, который это нивелировал. Однако, не все пакетные менеджеры смогли бы это «понять». Например, с pnpm могли возникнуть нюансы.

Продолжив исследование, команда нашла еще несколько подобных пакетов.  Оказалось, что они «свободны» и их можно «занять».

Именно это и сделали исследователи. Создали простой payload, который возвращает следующую информацию: hostname, whoami и path. После чего разместили пакет на общедоступном ресурсе.

И… это сработало! Спустя некоторое время команда получила pingback с информацией о «жертве». После успешного PoC пакет был удален, а команда HashiCorp («владельцы» Consul) внесли необходимые изменения.

Хорошо то, что хорошо заканчивается! Тем не менее это лишний раз подчеркивает важность и значимость обеспечения безопасности цепочки поставки ПО.

P.S. Информацию об уязвимых версиях и особенностях эксплуатации можно найти в статье.

И тот самый Whitepaper (~ 40 страниц) ☺️