Иногда в самом сердечке

#lol

Двигаем ЛАНИТ по приятному приглашению от коллег из РБПО.рф

Красивое 🙃

#appsec #devsecops #paper

Салюты,
Напоминаю про премию, о которой рассказывал вот тут.

Почитай новости коллег из АФТ и буду рад видеть твои работы на ревью 🙏

#appsec #devsecops #specialty #toolchain #vulnmanagement #toolchain #compliance #gost #techsolution #pmicases

Как бы уже все, подкралась, незаметно, концовка эпохи 🫡🙂‍↕️

#lol

Салюты,
Прям в точку, особенно когда ждал его

#lol

Хорошо то как, нравится

А завтра уже будет интересное

#lol

🛠 Hydra для таргетинга целей

Салют,
Сегодня посмотрим с тобой на инструмент, который всегда будет под рукой и ты можешь потыкать с ним сервисы на защищенность кред для веб‑приложений, API и инфраструктуры как в простом формате, так и более узконаправленно (псы: но ты можешь использовать xhydra для мини интерфейса).

THC Hydra - это инструмент для brute форса, по сути это перебор кред к сервисам. Тип лицензии: GNU Affero General Public License (AGPL). Применяется для аудита безопасности, проверки надежности паролей, тестирования систем аутентификации. Может, при желании, привести к DoS в зависимости от твоих "мощей".

Поддержка протоколов

• Веб‑приложения: HTTP/ HTTPS Basic/ Digest auth, формы логина (http-post-form, https-post-form)
• Инфраструктура: SSH, FTP, RDP, SMB, VNC, Telnet, SNMP, Redis, RDP
• Сервисы: SMTP, POP3, IMAP, LDAP
• Базы данных: MySQL, PostgreSQL, Oracle

Структура команд

hydra [опции] -l ЛОГИН | -L файл_логинов \
      -p ПАРОЛЬ | -P файл_паролей \
      -t ПОТОКИ ... \
      ПРОТОКОЛ://ХОСТ[:ПОРТ][/ПУТЬ]

# SSH to user
$ hydra -l root -P /usr/share/wordlists/rockyou.txt -t 6 ssh://192.168.1.123

# FTP
$ hydra -L users.txt -P passwords.txt ftp://10.0.0.5

# RDP
$ hydra -l admin -P /path/to/rdp_pass.txt -V rdp://192.168.1.50

# HTTP Basic auth с модулями http-get/ http-head
hydra -L users.txt -P passwords.txt -s 8080 http-get://target.local/protected

# CSRF
hydra -L users.txt -P passwords.txt target.com \
  http-post-form "/login:username=^USER^&password=^PASS^&submit=Login:F=Invalid credentials"

Особенности

• Параллельные потоки и есть возможность ими управлять, что решает большое количество проблем
• Работа через proxy (SOCKS, HTTP)
• Поддержка SSL/ TLS
• Настраиваемые таймауты, задержки, стратегия перебора (вертикально по паролю, горизонтально по логинам)
• Гибкая настройка задержек, таймаутов, форматов HTTP‑форм, заголовков и т.п.
• Отдельный инструмент pw-inspector для фильтрации и генерации словарей, включая переиспользование

Пример

# Проксирование и обход rate лимитов

hydra -L users.txt -P passwords.txt \ # -L и -P - словари
  -s 443 -S \ # порт 443 с SSL/ TLS (HTTPS)
  -e ns \ # пробовать пустой пароль и пароль по логину
  -W 3 -f \ # задержка 3 секунды между новыми соединениями и -f остановиться после первой удачи
  -V \ # подробный вывод
  -o found.txt \ # вывод данных
  -x -I \ # специальный режим перебора и игнорировать предупреждения
  -u \  # по всем пользователям для одного пароля, затем для другого
  http-post-form "https://target.com/login:username=^USER^&password=^PASS^:F=Login failed"

Итого: удобен именно как низкоуровневый перебор с оберткой скриптами и Makefile. Hydra позволяет быстро находить слабые пароли на SSH, RDP, веб‑логинах, БД и других сервисах, используя wordlists и сценарии атак. Особенно важно, инструмент требуется хорошее понимание протоколов и механик HTTP‑форм и тд, иначе можно получить ложные результаты.

#appsec #toolchain #dast #secrets

Салюты,
Уже не 1-ое марта, не, ну, как бы да в наших реалиях, но по-моему это сожрет нас

#lol

Коллеги, напоминаю, что скоро новый поток в МФТИ по курсу ИБ, вовлекайтесь, буду рад вас видеть 🙃

#course #appsec #devsecops #specialty

🛠 FRIDA must for Mobile AST

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

Frida — это динамический инструмент для перехвата вызовов в процессах и последующего инжектирования. Работает в связке клиент (CLI/ Python/ Node.js) и рантайм внутри процесса целевого приложения. Также используют Frida Gadget как встроенную библиотеку.

Помогает

• перехватывать и модифицировать вызовы функций хуками
• изменять аргументы и выводы результатов
• воздействовать на память процесса в рантайме
• обходить клиентские проверки (root/ jailbreak detect, SSL pinning, лицензирование)
• делать живой динамический анализ без исходников и перекомпиляции

Команды

$ frida-ps -U       # процессы на USB‑устройстве
$ frida-ps -ai      # приложения с иконками (mobile)

$ frida-trace -U -i "com.example.app.auth.LoginManager.validateCredentials" com.example.app # android трассировка без написания JS
$ frida-trace -i "SSL_*" -f /usr/bin/curl # трассировка всех функций SSL_* в нативном бинарнике
$ frida-trace -i "fopen" -p <PID> # трассировка всеx вызовов fopen в текущем процессе

Пример

$ frida -U -f -n com.example.app -l script.js # загрузить JS‑скрипт attach по имени пакета через USB

Java.perform(function () {
  var LoginManager = Java.use("com.example.app.auth.LoginManager");

  // Перехватываем метод validateCredentials(String user, String pass)
  LoginManager.validateCredentials.implementation = function (user, pass) {
    console.log("[*] validateCredentials called");
    console.log("    user:", user);
    console.log("    pass:", pass);

    // Можно менять параметры
    // user = "test@example.com";
    // pass = "P@ssw0rd!";

    var result = this.validateCredentials(user, pass);
    console.log("    result:", result);
    return result;
  };
});

QA auto

import frida, sys

JS_CODE = """
Java.perform(function () {
  var Cls = Java.use("com.example.app.auth.LoginManager");
  Cls.validateCredentials.implementation = function (user, pass) {
    send("validateCredentials: " + user + " / " + pass);
    return this.validateCredentials(user, pass);
  };
});
"""

def on_message(message, data):
    print("[*] Message:", message)

device = frida.get_usb_device()
pid = device.spawn(["com.example.app"])
session = device.attach(pid)
script = session.create_script(JS_CODE)
script.on("message", on_message)
script.load()
device.resume(pid)
sys.stdin.read()

Итого:

• Позволяет динамически наблюдать и изменять поведение приложений без исходников и перекомпиляции
• Идеален для AppSec‑задач на уровне mobile/desktop‑клиентов, крипто‑логики, протоколов, анти‑фрод и анти‑тампер механизмов
• Требует аккуратности и понимания внутренних API и платформенных особенностей
• Практически незаменим в pentest’ах мобильных приложений, когда нужно обходить защиты и «заглядывать внутрь» рантайма

#toolchain #sast #appsec #reco #dast #mast

Салют,
Родная, с праздником, что бы также была прекрасна и чувствовала себя восхитительнее, с каждым днем, получала чего заслуживаешь и достойна, с твоим днем 🫶🙏

Салют,
Не, ну, секьюрно же - памагите

#lol

🏆 Курс МФТИ по DevSecOps

Салюты,
Сегодня хочу поделиться приятностью от своих же классных ребяток, по курсу МФТИ, очень рад, когда так стимулируют

#course #paper

Простите, но как то жизненно

#lol

🛠 WSO2 MI/ APIM с точки зрения AppSec

Салют,
Что то душновато было на прошлой неделе,
Надеюсь у меня одного так было, ну и мемасики были полезны для тебя, иногда же надо мозг расплавить 🙃

Часто в практике и при исследовании кейсов по интеграциям я смотрю в сторону WSO2, еще со времен РБ, поэтому сейчас хочу рассказать почему это решение имеет преимущество. WSO2 воспринимается всегда как очередной ESB и API‑шлюз, но для безопасной архитектуры это классный слой между внешним и внутренним сегментом сети.

Micro Integrator отвечает за интеграцию и обмен данными (можно навесить аутентификацию, авторизацию, WS‑Security, шифрование, логирование и трансформацию трафика до того, как он попадёт в бизнес‑сервисы), а API Manager за публикацию и защиту, управление доступом, трафиком и разработчиками ( по факту граница для всех HTTP/ REST/ gRPC API с OAuth2/ OIDC, JWT, rate‑limit и тд).

Фича для AppSec в том, что бы Security‑политики были как конфигурация, а не код. Пароли, сертификаты, правила подписи/ шифрования и аутентификации оформляются как политики и артефакты MI/ APIM, версионируются и проходят code‑review как часть инфраструктурного кода. AppSec Toolchain сканирует как API‑слой, так и интеграционные сервисы в MI. То есть логи MI/ APIM идут в SIEM, где можно строить корреляцию между уязвимостями и реальным трафиком. Zero‑trust‑подход на интеграционном уровне.

Ключевые фичи

• Аутентификация и авторизация на уровне интеграции — можно проверять username, token, роли и права до обращения к backend, в том числе через WS‑Security
• Шифрование и подпись SOAP/ WS сообщений, до 16 типовых сценариев WS‑Security (sign, encrypt, username token, X.509 и их комбинации)
• Шифрование и управление секретами через keystore/ truststore — защита SSL/ mutual TLS, ключей и паролей, отказ от дефолтных хранилищ
• Валидация и санитайзинг данных: проверка XSD/ JSON‑схем, фильтрация полей, вырезание чувствительных данных до логирования
• Централизация интеграционных политик

Типовой контур, который дает защиту всего потока API‑вызовов через общие политики

• Клиенты/ партнёры стучатся через WSO2 APIM
• APIM аутентифицирует запрос в зависимости от политики, валидирует токены, применяет throttling, IP‑фильтры, CORS и др.
• Запрос идёт в микросервис, либо в WSO2 MI, где выполняются интеграционные потоки: маршрутизация, обогащение, трансформация, вызовы систем
• На уровне MI включаются WS‑Security, подпись и шифрование сообщений, дополнительная аутентификация/ авторизация, проверка схем и валидация полезной нагрузки
• Все события уходят в логи, а метрики и ошибки — в аналитику APIM и платформенный мониторинг

Итого

• WSO2 как способ собрать безопасность и интеграцию в единый управляемый слой
• Единый периметр для API и интеграций
• Меньше уязвимостей в приложениях
• Команды фокусируются на бизнес‑логике, а типовые задачи интеграции и безопасности решаются готовыми фичами WSO2 MI/ APIM; новые интеграции добавляются конфигурацией, а не кастомным кодом
• Из коробки есть трейсинг вызовов, метрики, логирование и аналитика по API
• WSO2 заточен под сценарии, когда есть и облако, и on‑prem, и микросервисы, и старые SOAP‑системы

Сноска

• ESB (Enterprise Service Bus) - интеграционная шина, то есть централизованный программный слой, который подключает разнородные приложения и сервисы, беря на себя маршрутизацию, трансформацию и безопасность сообщений между ними.
• API‑шлюз (API Gateway) - единая точка входа для API‑клиентов, обратный прокси перед набором backend, который принимает запросы, маршрутизирует их к сервисам, агрегирует ответы и одновременно реализует политики безопасности (аутентификация, авторизация, rate limiting, мониторинг)

#appsec #pmicases #devsecops #techsolution #reco #toolchain

🤔 WSO2 InfoSec Reco

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

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

• Учитывать стандарты безопасности Открытых API

— СТО БР ФАПИ.СЕК‑1.6‑2024 (безопасность OpenID API)
— СТО БР ФАПИ.ПАОК‑1.0‑2024 (аутентификация по отдельному каналу)

• ГОСТ 57580.1 и процессы

— Для фин информации и ПДн применять состав мер ГОСТ 57580.1: защита каналов, контроль доступа, регистрация событий, управление уязвимостями, обеспечение целостности и актуальности ПО
— Логи WSO2 и бэкенд‑сервисов по API должны попадать в централизованный журнал
— Для каждого API, обрабатывающего ПДн, должна быть проведена оценка рисков ИБ в рамках 57580.1 и внутренних политик по 152‑ФЗ

• Требования по персональным данным

— Факт передачи ПДн через WSO2 должен быть отражён в договорных документах и в перечне информационных систем ПДн, и трансграничных передач
— Внутренние документы должны описывать порядок уведомления Роскомнадзора об инцидентах с ПДн (72 часа на расследование и отчёт) и ответственность ролей
— Для API, где минимально возможен объём ПДн, следует применять минимизацию, маскировку и обезличивание: передавать только необходимый набор атрибутов, а также, где можно, использовать токены/ псевдонимы вместо прямых идентификаторов клиента

• Архитектурные требования

— Настроить WSO2 с использованием HTTPS/ TLS 1.2+ с Forward Secrecy для всех публичных endpoint’ов, включить проверку клиентских сертификатов, если используется mutual TLS
— Использовать OAuth 2.0 + OpenID Connect как основной механизм аутентификации клиентов API (в соответствии с ФАПИ.СЕК), ограничивать доступ по scope/ role и, при необходимости, по IP/ ASN
— Обеспечить защиту от типичных атак на API: rate limiting, throttling, защита от replay‑атак, CSRF, injection, а также валидацию схемы JSON/ REST

• Дополнение

— Для каждого интеграционного кейса должна быть выполнена модель угроз и оценка рисков с фиксацией мер защиты в архитектуре
— Необходим отдельный регламент «Управление внешними интеграциями», описывающий: жизненный цикл API, ответственность Integration Layer, порядок ревью ИБ и архитекторов, требования к логированию и мониторингу
— Нужен регламент по управлению уязвимостями и интеграционных сервисов: периодичность сканов, порядок установки обновлений, SLA по устранению критичных уязвимостей
— Доступ с BYOD во внутренний контур должен быть ограничен путем контроля привелегированных пользователей путем Segregation-of-Duties
— Необходимо реализовать отсутствие прав доступа во внутренним системам
— Предшествующая аутентификация является необходимой для источников данных и при ее отсутствии, используемые каналы связи и используемые ресурсы должны быть зашифрованы (блокировка целостности, шифрование, контроль источника и т.п.)
— Все файлы, которые передаются (также для последующих случаев - в обе стороны, если будут использоваться) должны быть зашифрованы и проходить через песочницу
— Доступ к данным по id из внешнего периметра должен исключать инкрементальный id
— При проектировании API через WSO2 ориентироваться на профили безопасности OpenID/ OAuth2: обязательно TLS, защищённое хранение и передача токенов, защита от подмены запросов/ ответов

#reco #devsecops #pmicases #specialty #techsolution #compliance #paper

Яндекс хорошие номера подобрал 😅🙃

#lol

🏆 Информационная безопасность на всех этапах жизненного цикла разработки ПО

Салюты, напомню, что стартует, совсем скоро курс по МФТИ, поделюсь расписанием вот тут.
А пока ты можешь покачаться на лабках, которые скоро получат новый релиз и будут также обкатываться на МФТИ.
Почекай лабки тут.

—————————————————————
🗓 Сроки обучения:
23 марта – 05 мая 2026 г.

⏰ Время занятий:
18:00 – 19:30 / 20:30 / 21:30
—————————————————————

🔰 НЕДЕЛЯ 1 | Основы ИБ и защиты информации ИС

• 23.03 (Пн) | Вводная лекция | 1 ак.ч. | 18:00-18:45 | Zoom
• 24.03 (Вт) | Лекция 1 и 2 | 4 ак.ч. | 18:00-21:30 | Zoom
• 26.03 (Чт) | ПР 1 и Лекция 3 | 2 ак.ч. | 18:00-19:30 | Zoom

🔰НЕДЕЛЯ 2 | Обследование ИС, анализ уязвимостей и угроз

• 31.03 (Вт) | Лекция 4 | 2 ак.ч. | 18:00-19:30 | Zoom
• 02.04 (Чт) | Лекция 5 и ПР 2 | 2 ак.ч. | 18:00-19:30 | Zoom

🔰НЕДЕЛЯ 3 | Формирование и реализация требований по ИБ к ИС
• 07.04 (Вт) | Лекция 6 и 7 | 4 ак.ч. | 18:00-21:30 | Zoom
• 09.04 (Чт) | Лекция 8 и ПР 3 | 2 ак.ч. | 18:00-19:30 | Zoom

—————————————————————
⬅️ НЕДЕЛЯ 4 | Shift-Left: от анализа до требований ИБ

• 15.04 (Ср) | Лекция 9 и ПР 4 | 3 ак.ч. | 18:00-20:30 | Zoom
• 17.04 (Пт) | Лекция 10 и 11 | 3 ак.ч. | 18:00-20:30 | Zoom

⬅️ НЕДЕЛЯ 5 | Жизненный цикл безопасной разработки ПО

• 22.04 (Ср) | Лекция 12 и 13 | 4 ак.ч. | 18:00-21:30 | Zoom
• 24.04 (Пт) | ПР 5 и Лекция 14 | 3 ак.ч. | 18:00-20:30 | Zoom

🎯 НЕДЕЛЯ 6 | Завершение

29.04 (Ср) | Лекция 15 и ПР 6 | 3 ак.ч. | 18:00-20:30 | Zoom
—————————————————————
🏆 Защита итоговой работы
—————————————————————

#course #devsecops #appsec #toolchain