В прошлую пятницу прошел наш митап, посвященный информационной безопасности на стадии разработки продукта.

На встрече мы рассказали, как контролировать уровень безопасности между участками цикла разработки и как внедрять процессы Secure SDLC.

Кому не удалось присоединиться к нам, можете посмотреть запись прямой трансляции по ссылке — https://www.youtube.com/watch?v=B-CE-Bwp0dA

Если у вас остались вопросы, задавайте их в комментариях :)

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

Читайте по ссылке. Делитесь своим мнением в комментариях!

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

https://inc.click/cybersecurity-startup/

Когда используешь Kubernetes, чтобы запустить Hello world

5-ти минутная интеграция SAST в Gitlab CI/CD

Если ты используешь Gitlab как инструмент для хранения и управления репозиториями, но все еще не внедрил SAST в свой CI/CD, то этот пост для тебя.

Gitlab дает возможность одной строчкой внедрить статический анализатор кода в проект. Для этого необходимо в файл .gitlab-ci.yml добавить необходимый шаблон: Security/SAST.gitlab-ci.yml. Сервис сам определит на каком стеке написан проект и запустит нужный анализатор кода, а результаты можно будет посмотреть в отдельном стейдже или в security dashboard.

Конечно, инструменты нужно настраивать под себя. К сожалению, в community версии можно определить только некоторые переменные, например, SAST_GOSEC_LEVEL (игнорировать уязвимости, найденные Gosec при заданном уровне,. 0 = Не определено, 1 = Низкие, 2 = Средние, 3 = Высокие). В enterprise же можно добавлять и изменять rulesets.

Поддерживаемые языки программирования для быстрой интеграции: https://docs.gitlab.com/ee/user/application_security/sast/

В случае если необходимо использовать SAST со своими правилами и кастомными настройками, всегда можно обратиться к нам за помощью 😉

#soft #ssdlc

Это я пытаюсь сделать скрытный пентест

Что изменилось в OWASP Top 10 с 2017 года

Broken Access Control - данная категория стала наиболее серьезной угрозой для веб-приложений. Например, доступ к API интерфейсам без аутентификации с возможностью отправки POST, PUT, DELETE запросов.

Cryptographic Failures - новое название для категории Sensitive Data Exposure, внимание уделяется ошибкам, которые приводит к раскрытию конфиденциальных данных. Категория выходит на 2-ое место.

Insecure Design - новая категория в 2021, в которой основное внимание уделяется рискам, связанными с недостатками проектирования и реализации веб-приложений.

Многие категории переместились, появились новые, более подробно можно ознакомиться на официальном сайте: https://owasp.org/Top10/

Собственный SOC на OpenSource

Для многих SOC ассоциируется с большим и дорогим решением, которое всегда требует точной настройки и множества специалистов. На самом деле, можно бесплатно внедрить свой небольшой SOC за несколько дней.

Уже несколько лет компания Elastic дает возможность воспользоваться их SIEM на базе стека ELK (Elasticsearch, Logstash и Kibana).

Можно собирать все типы журналов и событий с серверов, сетевых устройств, АРМов пользователей с помощью Beats.

После сбора логов с конечных точек, нужно собрать данные со средств защиты. В ELK SIEM уже встроена функциональность сбора данных с Network и Host Based IDS (Suricata, Wazuh), Iptables, Cisco ASA, Palo Alto FW, это позволяет достаточно быстро получить события с СЗИ и красиво визуализировать их.

Кроме того, в ELK SIEM можно посмотреть сетевые потоки, DNS, для поиска и анализа трафика.

Все данные: системные журналы, события ИБ попадают в Logstash. Logstash — это инструмент для сбора, фильтрации и нормализации логов. Более понятным языком – это штука, в которую закидываются логи в непонятном виде, а на выходе получается структурированный JSON. После обработки данных Elasticsearch будет обрабатывать индексацию данных, это нужно для оптимизации процесса хранения и поиска данных. Затем данные передаются в Kibana, которая, в свою очередь, проводит анализ и визуализацию сохраненных данных.

В расширенной версии ELK SIEM можно применить машинное обучение для выявления аномалий. Сам ELK SIEM можно развернуть у себя или воспользоваться Cloud решением.

Ссылка на официальный сайт: https://www.elastic.co/siem/

Когда понял, что оставил данные на фишинговом сайте.

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

С каждым годом банковские веб-приложения становятся более отказоустойчивыми и имеют все меньше технических уязвимостей: SQL-инъекции, XSS, RFI/LFI и так далее. Более актуальными становятся атаки, направленные на эксплуатацию уязвимостей в бизнес-логике.

Злоумышленники могут:

— Обходить механизмы защиты, пропуская шаг подтверждения входа в личный кабинет с помощью N-значного кода в СМС. Например, чат-боты в мессенджерах позволяют более удобно и быстро пользоваться картами, переводами и платежами, но могут представлять угрозу безопасности, если не протестированы в полном объеме.

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

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

— Совершать множественные операции, требующие больших вычислительных ресурсов, тем самым вызывая отказ в обслуживании, что наносит компании-жертве репутационный ущерб.

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

Избегать проблем в логике приложений позволяют анализ кода и процессы безопасной разработки (Secure SDLC), о которых мы так много говорили на митапе.

#pentest

Безопасность 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С есть у вас?