🛠 Autoswagger: легкая проверка на доступность без авторизации

Салют,
Сталкивался пару раз с общим описанием Autoswagger by intruder.io. Решил посмотреть быстрый и легковесный инструмент.

Инструмент позволяет пробежаться по торчащим ручкам API наружу у продукта. Поэтому мне захотелось поделиться с тобой его особенностями. Тип лицензии: BSD 3-Clause License. Установка как python библиотекf, для использования в CLI.

Какой функционал может:

- Сканирует домены для обнаружения открытой документации API, где есть возможность указания отдельно OpenAPI спецификации
- Анализ спецификации и формирование списка конечных точек для тестирования. Отправляет запросы с допустимыми параметрами из документации и помечает любые конечные точки, возвращающие данные без надлежащего контроля доступа, т.е. без ошибок 401 или 403

Пример: сработал явно на вектор по 429 - Too Many Requests и позволил понять, что надо смотреть в сторону тестирования лимитов запросов (простое)

- Определяет конфиденциальные данные в ответе, как учетные данные, персональную информацию PII
- Использование флага --brute, чтобы попытаться обойти проверки, что помогает выявить уязвимости в конечных точках, которые отклоняют стандартные входные данные, но принимают определённые форматы данных, значений

Применение:

git clone git@github.com:intruder-io/autoswagger.git
pip install -r requirements.txt
python3 autoswagger.py -h
autoswagger--help 
python3 autoswagger.py https://example.ru/api/users/swagger/v1/swagger.json  -v -risk -all

Флаги:

autoswagger.py [-h] [-v] [-risk] [-all] [-product] [-stats] [-rate RATE] [-b] [-json] [urls ...]

-h, --help # Показать это справочное сообщение и выйти
-v, --verbose # Включить подробный вывод
-risk # Включить в тестирование запросы, отличные от GET
-all # Включить все коды состояния HTTP в результаты, исключая 401 и 403
-product # Вывести все эндпоинты в формате JSON, пометив те, что содержат PII или имеют большие ответы
-stats # Показать статистику сканирования. Включается в JSON при использовании -product или -json
-rate RATE # Установить лимит скорости в запросах в секунду
-b, --brute # Включить исчерпывающее тестирование значений параметров
-json # Вывести результаты в формате JSON в режиме по умолчанию

Сценарии:

1. Режим автообнаружения OpenAPI-спецификации
- принимает доменное имя - example.com
- выполняет сканирование целевого домена, проверяя стандартные пути к OpenAPI/ Swagger-документации типа /openapi.json, /swagger.json, /api-docs, /v3/api-docs
- если спецификация обнаружена, инструмент парсит её и извлекает все доступные эндпоинты
- для каждого эндпоинта выполняет автоматизированные запросы GET, POST, PUT, DELETE и др., если они указаны, без авторизации, анализируя ответы: статус-коды, тело ответа, headers

2. Режим работы с предоставленной спецификацией
- инструмент принимает на вход одну или несколько OpenAPI-спецификаций в формате JSON/YAML, локальные файлы или URL
- парсит каждую спецификацию, извлекая все эндпоинты и поддерживаемые HTTP-методы
- для каждого эндпоинта выполняет автоматизированные запросы без авторизации, фиксируя отклонения - ошибки 5xx, неожиданные 200/403, утечки данных и т. д.

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

#toolchain #reserch #dast

🛠 Bandit как linter на pre-commit

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

Bandit парсит код каждого файла проекта в AST (Abstract Syntax Tree - дерево абстрактного синтаксиса) и прогоняет набор правил (плагины через entry points). Тип лицензии: Apache-2.0 license. Форматы отчетов: csv, custom, html, json, screen, txt, xml, yaml.

Самое классное, что если использовать wemake-python-styleguide в совокупности с Bandit как анализатором, то мы решаем вопросы разименования, затенения встроенных функций, когнитивной сложность, а также проблемы с непоследовательными возвратами, неправильными разрывами строк, непоследовательными выражениями и сработка с явными уязвимостями.

Команды

python -m venv .venv
pip install bandit

bandir -r ./my_python_project/  # Рекурсивное сканирование

--severity-level
--confidence-level # Пороги  
--profile 
-t # Выбор правил
-s # Пропуск правил
nosec # Точечное игнорирование

docker pull ghcr.io/pycqa/bandit/bandit:<tag>
 
cosign verify ghcr.io/pycqa/bandit/bandit:latest \ # проверка подписи образа перед использованием
--certificate-identity https://github.com/pycqa/bandit/.github/workflows/build-publish-image.yml@refs/tags/<version> \
--certificate-oidc-issuer https://token.actions.githubusercontent.com

Файл конфигурации

# .bandit
exclude_dirs: ['tests', 'venv']
skips: ['B101', 'B311']

any_other_function_with_shell_equals_true:
  no_shell: ['subprocess.Popen']

hardcoded_password_string:
  hardcoded_password_string_re: '(?i)(password|passwd|pwd)'

Использование как pre-commit

#.pre-commit-config.yaml
repos:
-   repo: https://github.com/PyCQA/bandit
    rev: 1.7.5
    hooks:
    -   id: bandit
        args: ['-ll', '-ii']

CI/CD

variables:
  BANDIT_SEVERITY: "medium"
  BANDIT_CONFIDENCE: "medium"
  BANDIT_OUTDIR: "bandit-report"
      
bandit_scan:
  stage: security
  image: ghcr.io/pycqa/bandit/bandit:<tag>
  script:
    - mkdir -p "$BANDIT_OUTDIR"
    - bandit -r . \
        --severity-level="$BANDIT_SEVERITY" \
        --confidence-level="$BANDIT_CONFIDENCE" \
        -f json  -o "$BANDIT_OUTDIR/bandit.json"

pipeline {
  agent any
  options { timestamps() }
 
  environment {
    BANDIT_SEVERITY   = 'medium'
    BANDIT_CONFIDENCE = 'medium'
    REPORT_DIR        = 'bandit-report'
  }
 
  stages {
    stage('Setup Python venv') {
      steps {
        sh '''
          python3 -m venv .venv
          . .venv/bin/activate
          pip install --upgrade pip
          pip install bandit
          mkdir -p "${REPORT_DIR}"
        '''
      }
    }
    stage('Bandit Scan') {
      steps {
        sh '''
          . .venv/bin/activate
          bandit -r . --severity-level=${BANDIT_SEVERITY} --confidence-level=${BANDIT_CONFIDENCE} \
            -f json  -o ${REPORT_DIR}/bandit.json
          bandit -r . --severity-level=${BANDIT_SEVERITY} --confidence-level=${BANDIT_CONFIDENCE} \
            -f sarif -o ${REPORT_DIR}/bandit.sarif
          bandit -r . --severity-level=${BANDIT_SEVERITY} --confidence-level=${BANDIT_CONFIDENCE} \
            -f html  -o ${REPORT_DIR}/bandit.html
        '''
      }
    }
  }
 
  post {
    always {
      archiveArtifacts artifacts: 'bandit-report/**', fingerprint: true
    }
    unsuccessful {
      script { currentBuild.result = 'UNSTABLE' }
    }
  }
}

Итого: сам SAST дает AST-подход без исполнения кода, где baseline позволяет внедрять постепенно и расширяем через плагины, но большое количество некорректных правила дающих FP, которые надо перебрать руками. Инструмент легковесен, но не как целевой SAST, а очень комфортное решение для проверок до Merge/ Pull Requeste. Совместно с wemake-python-styleguide решается проблема структуры и стилистики кода внутри команды разработки.

#toolchain #sast

Типовые "грешки" использования JWT

Салют,
Тут недавно пересекался с коллегами, с которыми записывали подкаст по безопасной разработке - инфо тут.

Так вышло, что хотел бы поделиться с вами интересным подходом, чем-то напоминает классическую модель. У этих ребят, занимающихся консалтингом и Compliance, есть обзоры в части рисков ИБ по теме уязвимостей в разработке.

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

Давай посмотрим на JWT сессии в том же ключе на примере обычного внедрения

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

JWT (Json Web Token) токен аутентификации пользовательской сессии, то есть самого пользователя для запросов к методам API. Нужен для передачи учетных данных к серверу на каждый вызываемый метод.

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

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

- путем ограничения его временем жизни
- валидация изначально проверяет время жизни токена
- blacklist
- защищенный канал передачи данных
- сброс сессии после конца времени жизни токена в неактивном состоянии
- привязка к action button в случае активности пользователя внутри окна аутентифицированного приложения
- дебажить на jwt.io вне команды разработки для тестов ИБ путем модификации
- не передавать чувствительные пользовательские данные (

база

)
- использовать ключевые фразы большой длины и их периодическое изменение
- принудительная смена токенов
- на стороне приложения реализовать белый список разрешенных алгоритмов
- санитизировать полученные от пользователей данные
- мы можем просто отозвать токен в любой момент времени, а после его перевыпустить
- дополнительно можем использовать контроль версии
- усилить схему подписи по модели Эскроу
- покрыть солью (salt) в специфичных случаях

Получается, что мы имеем access token - доступ при каждом запросе, refresh token - перевыпуск пары, а также указанное значение жизни по time-delay. Сама структура состоит из данных в payload, header как тип и алгоритм шифрования, cripto signature.

Итого: базово механизм реализует только обновление и передачу, но без доп мер защиты могут быть реализованы атаки по типу:

- отсутствие проверки подписи, где если поставить alg none, сервер неподписанный токен примет в явном виде с payload и права например admin
- манипуляция ключевыми идентификаторами из-за отсутствия сложности key id
- подбор ключа симметричной подписи и подбор ключевой фразы
- для ассиметричных путем изменения алгоритма через hex с использование логических ошибок реализации
- перехват токена и UrlDecode

И да, все-таки стоит посмотреть на коллег и их кейсы в AKTIV.CONSULTING @aktivcons.

#reco #reserch #secrets #pmcases

🤔 Терминология MITM

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

Будем брать нетиповую базу, как обычно, но все же что-то классическое будем затрагивать. Далее мы будем рассматривать некоторые из них детальнее.

Начнем с атаки "человека по середине" и отметим, что есть такие виды как:

- Подслушивание Wi-Fi
- "Злой двойник"
- Мошенническая точка доступа
- "Человек-в-браузере"
- Перехват сеанса (рассмотрели в примере)
- Сниффинг пакетов
- и тд

#term #pmcases

🛠 Grype как SCA для артефактов

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

Grype работает на уровне артефактов, а не исходного кода и сканирует программные пакеты.

Поддерживает Python, JavaScript (NPM, Yarn), Java, Ruby, Golang, PHP, Rust, .NET. Образы Docker, OCI, Singularity (SIF).

Тип лицензии: Apache 2.0
Форматы отчетов: JSON, SARIF, CycloneDX

Grype используется в связке с Syft

Syft создает список всех зависимостей, который проверяет Grype на наличие уязвимостей. Это позволяет проводить быстрые повторные сканирования без доступа к исходному коду или образу

Применение

curl -sSfL https://get.anchore.io/grype | sh -s -- -b /usr/local/bin # Разворачивание
grype <image:tag> # Сканирование контейнерного образа
grype <image> --scope all-layers # Сканирование с учетом слоев образа
grype dir:path/to/yourproject # Сканирование директории
grype sbom:./sbom.json # Сканирование с использованием SBOM, созданного Syft
grype <image> -o sarif > results.sarif # Сканирование с выводом в SARIF
grype <image> -o json > results.json # Сканирование с выводом в JSON
grype --add-cpes-if-none --distro alpine:3.10 sbom:./sbom.json # Генерация CPE и указание дистрибутива

docker run --rm \ # Запуск сканирования docker
  -v /var/run/docker.sock:/var/run/docker.sock \
  anchore/grype:latest \
  <image:tag>

Gitlab CI

stages:
  - security
 
Syft:
  stage: security
  image: nixos/nix:latest
  script:
    - nix-shell -p syft --run "syft ${DOCKER_IMAGE}:latest -o cyclonedx-json=sbom.json"
  artifacts:
    paths:
      - sbom.json
 
Grype:
  stage: security
  image: nixos/nix:latest
  needs: ["Syft"]
  script:
    - nix-shell -p grype --run "grype --fail-on high sbom:sbom.json"

Jenkins

pipeline {
  agent any
  stages {
    stage('Grype Scan') {
      steps {
        sh '''
          docker run --rm --volume $(pwd):/tmp/results anchore/grype:latest \
          your-image:tag -o json > /tmp/results/grype_report.json
        '''
      }
    }
  }
  post {
    always {
      archiveArtifacts artifacts: 'grype_report.json'
    }
  }
}

Итого:

- локально разработчиком можно использовать для проверки образов перед их отправкой в registry
- имеет интеграции: SARIF, JSON в GitLab Vulnerability Report, DefectDojo, Jira и т.д.
- может сканировать образы контейнеров, файловые системы, docker save и SBOM
- помимо стандартной Severity CVSS, Grype использует EPSS - вероятность эксплуатации и индикатор KEV, чтобы помочь расставить приоритеты
- достаточно часто покрывает false positive, но после исключений срабатывания более точечные если настроить файл .grype.yaml для подавления не влияющих на конкретный проект уязвимостей
- подходит с лету для проектов с Docker-образами и/ или OCI-артефактами
- охватывает и ОС, и языковые пакеты
- политики можно настраивать с помощью флага --fail-on, указывая минимальный уровень Severity, при котором пайплайн должен быть остановлен
- результаты по умолчанию сортируются по Risk Score, но можно изменить сортировку с помощью --sort-by, как пример, по severity, epss, package

#toolchain #containersecurity #sca #sbom

🤔 Терминология CyberDefend

Салют, начнем рассматривать базу и как работает бизнес в рамках условий рисков ИБ.

#term #pmcases #riskanalys

🤔 Терминология Malicious

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

#term #pmcases

🤔 Терминология Security Champion

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

#term #pmcases

🤔 Терминология Access Control

Салют, давай закончим день с рассмотрения прав доступа и отдельно вынесем take-grant как классный механизм, он тебе поможет разобраться с nix и понять каким образом работает ролевая модель.

А я плавно вкатываюсь обратно и готовлю классный контент для тебя 🙏

#term #pmcases