Безопасность Docker-контейнеров

Если вы используете Docker, то наверняка задумывались о том, как правильно, с точки зрения безопасности, собрать образ и развернуть контейнер. Компания Linode подготовила интересный документ - “Основы безопасности Docker”, в котором разобрали следующие темы:

- Как правильно настроить сервер, на котором будет работать Docker
- Настройка логирования
- Конфигурация Docker Deamon
- Безопасность Docker-контейнеров
- Аудит и сканирование безопасности Docker-контейнеров
- Безопасная сборка Docker-образов

И еще много всего интересного, с радостью делюсь материалом :)

Уязвимости в бизнес-логике, которые не распознает ни один сканер (сфера ecom)

Продолжаем поднимать тему атак, направленных на эксплуатацию уязвимостей в бизнес-логике. На этот раз в сфере ecom-а и ритейла.

Несколько популярных примеров логических уязвимостей:

— Заказ без подтверждения, который ломает логистику. Если функциональность интернет-магазина позволяет оформить заказ без подтверждения по телефону, то оператор не сможет отличить его от фейка. Примет заказ и отправит товар со склада по адресу, где никого нет. При многократном повторении злоумышленник может перегрузить логистику, остановить работу магазина и нанести огромный ущерб бизнесу. Необходимо всегда делать подтверждение по SMS/звонку и использовать механизм ограничения множественных запросов.

— Некорректная авторизация по номеру телефона. Многие онлайн-сервисы используют SMS-коды в качестве механизма авторизации пользователей. Но допускают ошибки, например, не делают ограничений по количеству попыток или сроку жизни кода подтверждения. Как правило, код состоит из 4-6 цифр, так что максимальное количество запросов, необходимых для перебора — 1 миллион, что совсем немного.

— Отсутствие механизма защиты от перебора промокодов.
Промокод генерируется при выдаче и сохраняется в базе данных. Если владелец промокода еще не активировал его, злоумышленник может перебирать и активировать такие коды. Нужно привязывать промокод к конкретному пользователю и реализовывать механизмы защиты от множественных запросов.

— Класс атаки Circumvention of Work Flows
Позволяет злоумышленнику обойти последовательность взаимодействия с приложением или условия его бизнес-логики. Например, если механизм реализован некорректно, то злоумышленник сможет оформить заказ, пропустив этап оплаты, и получить подтверждение заказа в CRM.

В следующий раз расскажу о популярных логических уязвимостях в интернет-сервисах.

#pentest

Каждого компетентного специалиста рано или поздно настигает профессиональная деформация. Безопасники не исключение. Загибай пальцы если ты:

1. Используешь больше 32 символов для пароля на WiFi;
2. Можешь вытащить модуль микрофона из телефона;
3. Не используешь WiFi, кроме домашнего;
4. Всегда пользуешься VPN;
5. Всегда шифруешь данные;
6. Выпаеваешь USB-порты на ноутбуке;
7. Испытываешь проблемы с оформлением визы;
8. Блокируешь компьютер, каждый раз отходя от него;
9. В социальных сетях и мессенджерах тебя нельзя узнать по аватарке или имени.

Если загнул больше 5 — значит у тебя безопасность головного мозга :)

Пишите, какие признаки и стереотипы про нашу профессию слышали вы 👇

Не так давно вышла новость про новую активность хакеров RedCurl в крупном ритейлере. Мы в Awillix рассматриваем подобные кейсы в разрезе supply chain атак, которые представляют целый спектр возможностей для хакерских группировок и только набирают обороты в последнее время.

Supply chain атаки производятся на жертву не напрямую, а через цепочку ее поставщиков. Целью группировок подобных RedCurl, описанных специалистами Group-IB, необязательно должна быть сама компания-жертва.

Так как жертва атаки — топовый ритейлер, можно предположить, что конечной целью могут быть его клиенты. Речь идет о десятках миллионов конечных клиентов компании. Под угрозой могут быть все те же реквизиты банковских карт, персональные данные клиентов и все истории покупок.

Проводя пентесты для крупных ритейлеров, нам удавалось пробиться в сегмент серверов обслуживающих POS-терминалы по всей стране. Из этого сегмента можно дальше развивать атаки на платежные карты клиентов. Данные самой компании скорее могут иметь интерес для недобросовестных конкурентов, но доступ к данным конечных клиентов представляет собой куда большую ценность.

У крупнейших ритейлеров гигантский масштаб ИТ-инфраструктуры — тысячи серверов. Факт того, что группировка навсегда покинула ее, остается спорным. Хакеры могли оставить множество имплантов, которые позволят им в любой момент вернуться и продолжить контролировать различные узлы инфраструктуры.

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

Компрометация одной такой компании автоматически ведет к компрометации всех их клиентов. Наиболее ярким примером является кейс Solar Winds, когда в результате их взлома только в США пострадали десятки (возможно сотни) тысяч компаний, включая Microsoft, Cisco, FireEye, а также множество правительственных агентств США, включая Гос­деп и Национальное управление по ядерной безопасности.

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

Ссылка на статью-первоисточник —
https://xakep.ru/2021/11/18/redcurl-attacks/

Когда с друганом нашел критическую багу в защищенной приложухе:

Безопасность REST API

Привет! Мне вдруг стало интересно, а есть ли у вас политика безопасности для API?

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

OWASP уже предложил несколько стандартных пунктов в своем документе:

— Использование HTTPS: все интерфейсы должны работать по HTTPS протоколу, поскольку в передаче данных присутствуют токены, пароли, возможно, конфиденциальная информация.

— Контроль доступа: не должно быть публичных интерфейсов, которые работают с чувствительными данными.

— Ограничение использования HTTP-методов: каждый интерфейс API должен работать только с нужными методами, например GET, POST, PUT. На все остальные методы сервер должен возвращать 405 Method not allowed.

— Валидация данных: на эту тему уже много всего написано) параметризация, ограничение по длине, санитизация.

— Использование точного content type: если приложение отдает JSON, то content type обязательно должен быть application/json, иначе возможны атаки, например XSS.

— Обработка ошибок: исключать подробный вывод ошибок приложения пользователю, например, стектрейсы или экспешены.

— Логирование: тут все должно быть понятно, пишем audit log, коррелируем события, выявляем аномалии.

— Использование заголовков безопасности: не забываем про заголовки, такие как HSTS, CSP, X-Frame и т.д.

И еще много-много всего интересного можно найти для себя, прочитав тот самый REST Security Cheat Sheet.

Например, когда я разбираю дизайн API, люблю делить интерфейсы по уровням критичности, допустим:

- работают с финансами — Critical
- работают с данными пользователей — High
- работают с данными приложения/окружения косвенно с данными пользователя — Medium
- работают со статикой, например, изображения — Low
- работают с открытыми данными приложения — Info

Каждая такая градация, должна покрываться соответствующими мерами, например, Critical обязательно находится под мониторингом и логированием 24/7, должны быть за аутентификацией и так далее, все зависит от модели угроз.

Делюсь интересными ссылками по безопасности API:

- API Security Checklist: Cheatsheet
- API Audit Checklist
- JSON Web Token Security Cheat Sheet
- REST API Design Guide

Всем привет! В последнее время мы в Awillix наблюдаем растущий интерес компаний к процессам безопасной разработки и много противоречивых мнений.

SSDLС – Secure Software development lifecycle исповедует идею, что в процессе разработки ПО нужно оценивать возможные уязвимости и сразу предусматривать меры, которые их нейтрализуют.
Качественный код и безопасный код — далеко не одно и тоже. Например:

У бизнеса есть сервис, позволяющий привязать накопительную скидочную карту к аккаунту клиента. Пользователю становится доступно накопление бонусных баллов. Бизнес-заказчик описывает разработчику задачу: после авторизации в личном кабинете, пользователю предлагается заполнить поля «Номер карты» и «sms-код». Если введенные данные верны — карта привязывается к пользователю и ему предоставляется скидка.

Разработчик реализует нужную форму и запрос к базе данных, в котором проверяется соответствие номера карты и коды. Программный код качественный, все тесты пройдены, ошибок нет. Обновление выкатывается в production, и в этот момент выясняется, что количество попыток ввода данных было неограниченно. В результате — злоумышленник, завладев номером карты, может подобрать sms-код простым перебором вариантов. Программный код в нашем примере оказался небезопасным.

Качество кода — определяется уровнем квалификации разработчиков. А его безопасность — в первую очередь зависит от анализа модели угроз.

Сейчас мы готовим статью о мифах, которые мы слышим вокруг аббревиатуры SSDLС и о том, что нужно сделать IT-компаниям для безопасности, создаваемых программных продуктов.

Какие вопросы относительно SSDLС есть у вас?

Всем привет! В прошлую пятницу мы снова организовали митап для ИБ-специалистов. На этот раз посвятили вечер безопасности доменной инфраструктуры на базе Microsoft Active Directory.
⠀
Менеджер практики кибербезопасности PwC Дмитрий Забелин и руководитель направления анализа защищенности Awillix Илья Костюлин выступили с докладами.
⠀
Рассказали про:
⠀
— Защиту доменов: ошибки, которые хакеры используют, чтобы получить контроль над доменом, паттерны взлома, кейсы захвата, стратегии по защите и многое другое.
⠀
— Оптимальный набор сценариев выявления инцидентов, SOC и мониторинг безопасности.
⠀
Запись трансляции доступна по ссылке: https://www.youtube.com/watch?v=08dVYePNW_E

К сожалению бизнес часто задумывается о киберзащите уже после того, как их взломали. Но есть много рабочих способов повысить уровень безопасности продукта еще до релиза и сэкономить затраты на защиту в будущем.

Мы наконец выпустили статью, где просто и по-существу рассказываем о принципах «безопасной» разработки и главных мифах связанных с ней 👇(лайк/шэр/коммент)

https://vc.ru/services/337251-bezopasnaya-razrabotka-kak-sokratit-zatraty-na-kiberzashchitu-do-reliza-produkta

Уязвимости в бизнес-логике, которые не распознает ни один сканер (интернет-сервисы)

Ранее мы уже рассказывали об уязвимостях в бизнес-логике приложений в сфере финтеха, ecom-а и ритейла. На этот раз мы собрали несколько забавных примеров логических уязвимостей в интернет-сервисах.

Такси

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

Иногда приложение может быть уязвимо для получения информации о клиенте. Были случаи, когда водители находили номер клиента, звонили и предлагали отменить поездку — отвезти за наличные деньги и меньшую сумму.

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

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

Подмена локации

Игра Pokеmon GO — еще один забавный пример. Охотники за эксклюзивными покемонами брали эмулятор андроида на компьютере, меняли локацию на Иран, где водились редкие покемоны и ловили их там :)

Или акция сотового оператора, который давал бонусы за шаги в своем приложении: чтобы заработать их, энтузиасты меняли локацию, строили плавную кривую, будто человек плавно перемещается, и сидя дома, участвовали в акции. Конечно, этим может воспользоваться далеко не каждый пользователь, и скорее всего, акция принесла гораздо больше прибыли компании, чем понесла потерь от находчивых пользователей.

Часто при тестировании API встречается уязвимость класса Broken Access Control. Она может быть связана с недостаточным контролем доступа к тому или иному интерфейсу API. Например, в одном из приложений был найден эндпоинт /api/v1/admin/notifications, который отдавал информацию обо всех событиях, в том числе о смене пароля. В событиях о смене пароля фигурировала ссылка на сброс. Таким образом, можно запросить смену пароля для администратора, обратиться к интерфейсу /api/v1/admin/notifications, получить ссылку на сброс пароля, установить новый пароль и войти в систему как администратор.

С чего можно начать путь DevSecOps?

Есть интересный ресурс DevSecOps University. Там собрано много материалов в одном месте: статьи, книги, видеоуроки, инфографика, инструменты. Есть даже лабораторные работы ☝🏻

Ребята покрывают следующие темы:

- Системы управления версиями (git).
- CI/CD и все что связано с ним. Можно потренироваться на лабораторных работах.
- Управление артефактами сборки.
- IAC: инфраструктура как код. Ansible, Vagrant и другие умные слова))
- Облачные решения и их безопасность, в основном рассматривают AWS
- Модель угроз: расскажут, как правильно реализовать модель угроз под свой проект.
- Статическое тестирование безопасности (SAST): что такое, как внедрить, какие инструменты существуют.
- Динамическое тестирование безопасности (DAST): темы аналогичные SAST.
- И другие интересные темы, вроде: Security as Code, Compliance as Code.

Делитесь своими ресурсами на тему DevSecOps в комментариях)

Разрываем k8s

Вы наверняка уже встречались с Kubernetes. Уверен, кто-то из вас активно использует их у себя в компании и заботится о том, чтобы злоумышленник, попав в контейнер, не устроил побег.

Для того чтобы проаудировать k8s можно воспользоваться различными чек-листами, документами вроде CIS Benchmarks. Но куда быстрее и нагляднее воспользоваться автоматизированными инструментами.

Есть на github интересный репозиторий, в котором собраны документы, утилиты, подкасты, презентации и все-все, что связано с безопасностью k8s. Бери и пользуйся, например, kube-bench в автоматическом режиме проверяет соответствие по CIS Benchmarks, а peirates проверяет известные недостатки конфигурации и уязвимости.

Есть ли у вас любимые инструменты для анализа безопасности кубов?

#soft #k8s

Для чего нужна база знаний MITRE ATT&CK

База MITRE ATT&CK представляется в виде матриц, в которых столбцы — это основные этапы кибератаки, а ячейки — способы и техники их реализации. Например, этап - «Рекогносцировка», а «Активное сканирование» — техника.

MITRE ATT&CK достаточно полно отображает поведение злоумышленников и становится полезной, например, для реагирования на киберинциденты и применения защитных мер. Кроме того, для каждой техники представлено детальное описание, защитные меры и способы обнаружения.

Существует несколько матриц, и каждая из них покрывает разные системы, например:

— Матрица Enterprise: состоит из техник, которые применяются в ходе атак на организацию. В частности, содержатся тактики и техники кибератак на определенные операционные системы.
— Матрица Mobile: содержит тактики и техники, которые применяются к мобильным устройствам.
— Матрица PRE-ATT&CK: содержит тактики и техники, которые злоумышленники используют, до эксплуатации уязвимостей и проникновения, другими словами, на этапе подготовки к кибератаке.
— ATT&CK for ICS: из названия становится ясно, что в ней содержатся тактики и техники, которые используются в кибератаках на промышленные системы.

Имея перед собой эти инструменты, специалисты по информационной безопасности могут:

— Проанализировать текущие защитные меры и оценить угрозы, узнать какие техники могут быть реализованы в системах и принять соответствующие меры .
— Правильно реагировать на возникающие инциденты. Достаточно найти в матрице соответствующую технику и определить на каком из этапов находится кибератака, а дальше использовать предложенные меры.
— Изучать модель поведения APT-группировок. Это позволяет расширить текущие знания и быть готовым к возможным атакам.

Выдаем все свои профессиональные секреты в подкасте — SoftWare development podcast.
Александр Герасимов, CISO Awillix, и Сергей Овчинников, cloud security architect — гости нового выпуска.

Поговорили о том, что такое Application Security (AppSec), как обеспечивается безопасность на всех этапах жизненного цикла разработки ПО и какие методы можно применить. Обсудили взаимодействие бизнеса, разработки, специалистов по информационной безопасности и devops инженеров.

Говорили о подходах, приемах и инструментах для разработки безопасных приложений, таких как шаблоны приложений, инструменты анализа кода, подходы к созданию контейнеров и базовых образов. Отдельно поговорили про фаззинг приложений: что это такое, как он устроен и как его применять.

Слушайте по ссылке — https://sdcast.ksdaemon.ru/2022/02/sdcast-141/

А так же:
https://twitter.com/SDCast_podcast/status/1490637799111933956
https://twitter.com/KSDaemon/status/1490638980001447938
https://vk.com/feed?w=wall-194574132_55
https://www.patreon.com/posts/62231555
https://www.facebook.com/SDCastPodcast/posts/478973357133540

Как за несколько секунд просканировать внешний периметр на наличие открытых портов и уязвимостей?

Недавно коллега рассказал о новом инструменте Nrich, который позволяет очень быстро проанализировать список IP-адресов на наличие общеизвестных уязвимостей (баннерный поиск) и открытых сервисов.

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

Nrich проверил пулл адресов из маски /24 за 5 секунд:

➜ ~ wc -l scope.txt
255 scope.txt

time nrich scope.txt > /dev/null
nrich scope.txt > /dev/null 0.07s user 0.04s system 2% cpu 4.913 total

Рассказали журналу IT-World о том, как не стать жертвами атаки через цепочку поставок. Статья по ссылке👇

​​Киберугрозы новой реальности: Supply chain attack.

Успешная атака на цепочку поставок может привести не только к большим финансовым и репутационным потерям или компрометации ИT-инфраструктуры, но и к остановке производства или опасности экологической катастрофы.

https://www.it-world.ru/cionews/security/182552.html

Соскучились по встречам в оффлайне? Приходите на наш третий, уже традиционный ламповый митап :)

25 марта в 18:00 поговорим на тему: «Workflow разработки при внедрении инструментов и техник безопасности. Принципы использования SCA- и SAST-анализаторов».

Собираемся обсудить:
— Трансформирование workflow разработки с учетом требований безопасности на каждом этапе;
— Software component analysis и как обойти сложности во внедрении CI/CD пайплайнов;
— Лучшие практики внедрения SCA- и SAST-анализаторов, которые помогут быстро получить по-настоящему качественное и безопасное ПО

А после — нетворкинг, обсуждения и кофе-брейк. Будем рады всем, кому интересна эта тема и полезные знакомства!

Москва, Духовской переулок 17 стр. 10.
Количество мест ограничено. Регистрация обязательна — https://awillix--eksperty-po-kibe.timepad.ru/event/1956607/

Каждое обновление операционных систем несет в себе новые «дыры» в системе безопасности, а количество атак из-за этого растет каждый день.

Android прошел тернистый путь улучшений системы безопасности от простого PIN экрана до конкурентоспособной многоуровневой защиты. Но даже его механизмы можно обойти.

Анастасия Худоярова, специалист по безопасной разработке в Awillix, дала советы разработчикам и атакующим, рассказала об эволюции системы безопасности Android и актуальных способах защиты системы.

Читайте по ссылке — https://habr.com/ru/post/655745/

Semgrep умный grep или швейцарский нож?

Хотите одним инструментом проанализировать свой код на наличие типичных уязвимостей, проверить качество кода, выявить секреты в коде или ошибки в IaC и Dockerfile? Для решения таких задач можно воспользоваться инструментом Semgrep.

Semgrep — статический анализатор, который для поиска использует правила, написанные в yaml формате. У semgrep есть свой репозиторий с правилами, где можно подобрать нужный для вас стек и проверки: https://semgrep.dev/r / https://github.com/returntocorp/semgrep-rules

Semgrep поддерживает следующие языки:

- C#
- Go
- Java
- JavaScript
- JSON
- JSX
- Python
- Ruby
- TypeScript
- TSX
- YAML
- Generic (ERB, Jinja, и тд.)

И многие другие в Beta или Experimental режиме, например, C++, Rust, PHP.

Интересно то, что можно свободно писать собственные правила с указанием уровня критичности, описания, рекомендаций, CWE, ссылок на источники. Еще semgrep очень просто встраивается в процесс CI/CD.

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