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

Безопасность 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. Тогда в несколько шагов можно получить отличный инструмент для статического анализа кода, который в автоматическом режиме будет выявлять ошибки, уязвимости, недостатки в качестве кода.

Как взломать сайт веб-студии и получить за это работу? Где учатся на хакеров? Может ли гуманитарий стать специалистом по кибербезопасности?

Дал интервью каналу Loftblog рассказал о своем карьерном пути, поиске клиентов, российских хакерах, зарплатах безопасников и возможностях для стажировки.

Подробно о профессии пентестера из первых уст по ссылке —
https://www.youtube.com/watch?v=V0FsX1M_SGg&list=LLjc5iKfl2NJBPsoPLa4xXBg

Запись нашего третьего митапа, посвященного workflow разработки при внедрении инструментов и техник безопасности

Все, кто не смог посетить нас оффлайн, подключайтесь к записи трансляции на Ютубе — https://www.youtube.com/watch?v=QfYEkh9hxLQ
⠀
Обязательно сделаем вторую часть митапа и копнем эти темы еще глубже, следите за анонсами, пишите вопросы для разбора.
⠀
#meetup

Когда защитил только внешнюю инфраструктуру, но забил на внутрянку.