AppSECT.A.
378 subscribers
434 photos
9 videos
129 links
Блог Ильи Шмакова

geminishkv.tech

- AppSec Toolchain
- DevOps
- Процессы DevSecOps
- Infosec Risks
- PMI
- Кулуарный ИБ

AppSec Teamlead СберСпасибо @sberbank

Лидер findevsecops.ru @fintechassociation

Преподаватель @bmstu1830, @miptru
Download Telegram
🛠 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
🔥4❤‍🔥1
🛠 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
🔥4
🛠 Вектора атак метода 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
🔥5❤‍🔥2
🏆 Коллектив МГТУ им. Баумана награжден орденом "За доблестный труд"

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

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

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

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


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

Stay tuned 🙏

#appsec #devsecops #course #paper
🔥10🤣2
Салют, напоминание для важных и очень занятых, берегите себя 🫶🙏🙃

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

#lol
🔥8🤣3
Иногда это так «волнительно»

#lol
🤣8🔥4
Новые смыслы до боли старого и знакомого

#lol
🤣5
🙃 Новая точка роста канала

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

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

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

#paper
❤‍🔥12
🥶 Обзор 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
🔥6
Салюты,
В тему «сплита» для лавки и Деливери 😅🤣

#lol
🤣62
Салюты,
ИБшное черное 🙃

#lol
🤣5
🥶 Обзор PrintNightmare CVE‑2021‑34527

Салют,
Сегодня посмотрим PrintNightmare, про который писал в прошлом посте, - это классический пример того, как служба в Windows превращается в точку входа для RCE и площадку для намеренных злодеяний Vice Society и Magniber. Этот пост поможет тебе собрать воедино логику работы свежей уязвимости Metro4Shell.

Исследователи Sangfor выложили на GitHub технический разбор CVE‑2021‑1675 и PoC, который быстро эволюционировал в отдельный идентификатор CVE‑2021‑34527, а также был связан с CVE‑2021‑36958 и CVE‑2021‑1678.
PrintNightmare благодаря службе печати даёт возможность выполнить произвольный код, а LPE (Local Privilege Escalation, по русски - повышение привелегий) — захватить права уровня SYSTEM для контроля над Active Directory.


Это именно тот баг, который дал дыру в очереди печати spoolsv.exe, так как Print Spooler включена по умолчанию практически на всех тачках WinOS, включая контроллер домена. Уязвимость сидит в RPC‑вызове RpcAddPrinterDriver/ RpcAddPrinterDriverEx , который позволяет аутентифицированному пользователю загрузить драйвер печати с произвольного пути. Дальше драйвер, представляющий собой зловредную DLL, копируется в системный каталог драйверов принтера и исполняется с правами SYSTEM в контексте spoolsv.exe. Результат — RCE, LPE.

Эксплуатация:

• Клиент вызывает RpcAddPrinterDriver/ RpcAddPrinterDriverEx на удалённом принт‑сервере
• pDataFile  указывается как путь к драйверу на SMB‑шаре, где вместо драйвера лежит вредоносная DLL
• Print Spooler копирует DLL в  C:\Windows\System32\spool\drivers\… и загружает её с правами SYSTEM как часть инфраструктуры печати


Что дает злоумышленнику?

• Полный контроль над тачкой
• Создание новых учётных записей с полными правами
• Сбор и кража учётных данных
• Дамп LSASS
• Установка DLL, INI на другие тачки
• Распространение вредоносных драйверов по сети


Кейсы

• Magniber использует PrintNightmare для LPE: зловредная DLL подгружается в процесс, распаковывает крипто‑код, шифрует файлы и удаляет резервные копии
• Vice Society эксплуатирует PrintNightmare: применяет proxychains, impacket для lateral movement, целенаправленно бьёт по резервным копиям, реализует деградацию ESXi, реализует кражу credits


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

• Отключить службу Print Spooler на всех системах, где печать не нужна, либо
— Отключить входящую удалённую печать через локальные/ групповые политики
— Запретить драйверы и принтеры, устанавливаемые пользователями без админ‑прав
• Усиление аутентификации на RPC‑интерфейсе принтера для IRemoteWinspool и снижения риска атак релея и спуфинга (CVE‑2021‑1678):


[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print]
"RpcAuthnLevelPrivacyEnabled"=dword:00000001


• Запретить установку драйверов без прав администратора (при условии соблюдения Segregation of Duties)
• Включить уведомления и запросы UAC при установке новых драйверов
• Ограничить список доверенных серверов печати и источников драйверов
• Не использовать контроллеры домена как универсальные сервера печати и выносить Spooler отдельно
• Мониторить вызовы spoolsv.exe, необычные операции с RpcAddPrinterDriverEx, появление новых DLL в каталоге драйверов принтера, активность impacket/ proxychains, нетипичные подключения к ESXi и серверам бэкапов
• Установить все внеочередные обновления Microsoft, связанные с CVE‑2021‑34527 / CVE‑2021‑1675 / CVE‑2021‑36958 / CVE‑2021‑1678.

Итого: ты понимаешь как выглядит проход RCE и какие риски он несет, что и как работает. Также ты сможешь по аналогии с этими примерами разбираться в том, как реализуются новые типы и видов атак, а мы все еще будем ждать очередной четверг обновлений от нашего любимого вендора ОС 🤔


Сноска

LSASS - служба, которая отвечает за аутентификацию пользователей, применение локальной и доменной политики безопасности и выдачу access‑токенов, в памяти которой хранятся хэши паролей, тикеты и другие чувствительные учётные данные.


#research #riskanalysis #appsec #specialty #pmcases #term
🔥4
Оставлю, пожалуй, это тут

#lol
🤣9
Ну понятно, пробейте оборотку просто
Глядя на цены квартир 😟

#lol
🤣5
🛠 ShellCheck как small helper

Салют,
Сегодня хочу с тобой посмотреть инструмент ShellCheck.

Это статический анализатор shell‑скриптов типа sh, bash, dash, ksh, который ищет небезопасные конструкции и не ­портируемый код.

Это CLI‑утилита (GPLv3), которая gарсит скрипты, cтроит AST и првоеряет правила, выводит типичные синтаксические ошибки в runtime, а также семантические.


Еще одна полезная фича - corner‑case.

Команды


# Выборка типа shell
shellcheck -s bash script.sh
shellcheck --shell=sh script.sh

# Проверка нескольких файлов
shellcheck scripts/*.sh
find . -type f -name '*.sh' -print0 | xargs -0 shellcheck

# Игнорирование
shellcheck -e SC2086,SC1090 script.sh

# Опциональные проверки
shellcheck -o avoid-nullary-conditions script.sh

# Сужение проверки
shellcheck --source-path=./lib:./scripts main.sh

# Управление ENV
export SHELLCHECK_OPTS='--shell=bash --exclude=SC2016 -o all'
shellcheck script.sh


Вывод


shellcheck -f tty script.sh
shellcheck -f gcc script.sh # файл:строка:колонка:msg
shellcheck -f json script.sh # JSON
shellcheck -f checkstyle script.sh # XML для CI
shellcheck -f sarif script.sh # SARIF


Пример бага почти как фичи


# Давай теперь чекнем почему он может помочь и что может быть неприятно.
# потеря состояния в циклах, где while выполняется в subshell, а count снаружи останется 0.
# ShellCheck подсветит while read как потенциальную проблему, что нам и важно

count=0
cat file | while read -r line; do
count=$((count + 1))
done
echo "$count"


CI/CD



name: shellcheck

on: [push, pull_request]

jobs:
lint-shell:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4

- name: Install ShellCheck
run: sudo apt-get update && sudo apt-get install -y shellcheck

- name: Run ShellCheck
run: |
git ls-files '*.sh' | xargs shellcheck -s bash -o all -e SC1090


Итого:

• Этот хелпер помогает тебе его использовать как премерджер и контролировать разработчиков, что бы они могли избегать проблемные паттерны, которые повлияют на безопасность
• Тула поможет быть более уверенным, что при настройке правил - ты снизишь частично входной вектор атак и покроешь то, что обычно думается "да ладно, этого не будет"
• Глобально отключать только заведомо не уместные правила и использовать точечные  shellcheck disable
• Использовать фиксированной версии, что бы не сломать билд при изменениях, а только выводить в отдельный лог реко по апгрейду
• Собирать список скриптов git ls-files '*.sh' 
• Запускать с профилем -s ,  -o ,  -e ,  -P
• Использовать non‑zero exit code критерием падения


Сноска

• Shell — это оболочка, которая интерпретирует команды через системные вызовы позволяя управлять ядром и приложениями с помощью shebang
• Corner‑case - ситуация, когда система ведёт себя иначе, например, скрипт, который корректно работает с файлами, но падает, когда файлов нет, то есть имеет необработанный “пустой список файлов”.


#toolchain #sast #appsec #reco #term
🔥3
🛠 Semgrep Rules OWASP A08:2024 – Software and Data Integrity Failures

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

Это категория, которая включает в себя “Insecure Deserialization”, где приложение не проверяет целостность кода, данных или обновлений, что позволяет внедрять вредоносное ПО или модифицировать данные.


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

• Недостаточная проверка подлинности и подгрущка кода из недоверенных источников
• Небезопасная десериализация, включая подделку объектов в памяти. Опасность в Remote Code Execution через сериализованные объекты.
• Отсутствие проверки целостности, как пример использование CDN без SRI (Subresource Integrity) и обновления без валидации.


Примеры атак

• SolarWinds (2020): атакующие взломали CI/CD пайплайн SolarWinds и внедрили бэкдор в обновление Orion, где федеральные агенства США его поставили напрямую
• 3CX Desktop App (2023): злоумышленники скомпрометировали официальную версию приложения 3CX, добавив в неё malware
• Codecov (2021): атака на процесс сборки Docker-образа Codecov, где модифицированный bash-скрипт крал credentials, токены и PII из CI/CD окружений пользователей


Пример сценария атаки

• Небезопасная десериализация в Java


// React вызывает Spring Boot микросервисы, где состояние
// пользователя сериализуется и передаётся с каждым запросом
// отслеживается сигнатура Java "rO0" (base64), где
// реализуется Java Serial Killer для RCE

ObjectInputStream in = new ObjectInputStream(request.getInputStream());
UserState state = (UserState) in.readObject();


• JS из недоверенных источников


<!-- Нет SRI и проверки целостности -->

<script src="https://untrusted-cdn.com/library.js"></script>


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


rules:
# Небезопасная десериализация Java
- id: unsafe-java-deserialization
patterns:
- pattern-either:
- pattern: |
ObjectInputStream $IN = new ObjectInputStream(...);
...
$IN.readObject()
- pattern: (ObjectInputStream $IN).readObject()
- pattern-not-inside: |
class $CLASS extends ValidatingObjectInputStream {
...
}
message: |
Обнаружена небезопасная десериализация через JAVA ObjectInputStream
и может привести к Remote Code Execution.
severity: ERROR
languages:
- java
meta
cwe: "CWE-502"
owasp: "A08:2021"
category: security

# npm-пакеты без проверки
- id: npm-install-without-lock-file
patterns:
- pattern-either:
- pattern: |
exec("npm install ...")
- pattern: |
subprocess.run(["npm", "install", ...])
- pattern: |
os.system("npm install ...")
- pattern-not-inside: |
...
"package-lock.json"
...
message: |
Установка npm-пакетов без проверки package-lock.json
severity: WARNING
languages:
- python
- javascript
meta
cwe: "CWE-829"
owasp: "A08:2021"

# Динамическое выполнение кода из недоверенных источников
- id: dangerous-code-execution
patterns:
- pattern-either:
- pattern: eval($INPUT)
- pattern: exec($INPUT)
- pattern: __import__($INPUT)
- pattern: compile($INPUT, ...)
- pattern-either:
- pattern-inside: |
$INPUT = request.$METHOD(...)
...
- pattern-inside: |
$INPUT = $_GET[...]
...
- pattern-inside: |
$INPUT = input(...)
...
message: |
Динамическое выполнение кода из недоверенного источника
eval()/ exec() на данных приводящий к Remote Code Execution
severity: ERROR
languages:
- python
- javascript
- php
meta
cwe: "CWE-94"
owasp: "A08:2021"
likelihood: MEDIUM
impact: CRITICAL


#toolchain #sast #appsec #course #reco #techsolution
🔥5
🛠 GoSec Checker

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

Инструмент сканирует AST и SSA для обнаружения уязвимостей, которые упускают grep-based сканеры. Находит небезопасные запросы к БД, Path Traversal, захардкоженные секреты, токены, ключи и тд, а также и умеет в taint analysis, то есть поиск от user input до sink. Работает out-of-the-box. Форматы вывода - JSON, SARIF, JUnit XML, HTML, md по типу gosec -fmt=json -out=report.json ./...


Команды


brew install gosec

# Через go install
go install github.com/securego/gosec/v2/cmd/gosec@latest

# Скан конкретного пакета
gosec ./cmd/server/...

# Скан с детализацией
gosec -verbose=text ./...

# Только конкретные правила
gosec -include=G101,G201,G401 ./...

# Исключить конкретные правила
gosec -exclude=G104,G304 ./...

# Только высокие уязвимости
gosec -severity=high ./...


Конфигурация .gosec.json


{
"exclude": ["G104", "G304"],
"severity": "medium",
"confidence": "medium",
"exclude-dirs": [
"vendor",
"test"
],
"global": {
"nosec": "enabled",
"audit": "enabled"
}
}


Пример по Path Traversal


func ReadFile(filename string) ([]byte, error) {
return ioutil.ReadFile("/data/" + filename)

// Атакующий может передать: ../../etc/passwd
}


CI/CD


name: Gosec Security Scan

on:
push:
branches: [main, develop]
pull_request:
branches: [main]

jobs:
gosec:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4

- uses: actions/setup-go@v5
with:
go-version: '1.22'

- name: Run Gosec
uses: securego/gosec@master
with:
args: '-fmt sarif -out gosec.sarif ./...'

- name: Upload SARIF
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: gosec.sarif


Полезная фишка в виде метрик


# Получить количество находок по severity
gosec -fmt=json ./... | jq '.Stats.num_issues'

# Топ-5 правил с наибольшим количеством срабатываний
gosec -fmt=json ./... | jq '.Issues | group_by(.rule_id) | map({rule: .[0].rule_id, count: length}) | sort_by(.count) | reverse | .[0:5]'


Итого:

• Некоторые правила, например, G104 ("errors.go") генерируют огромное количество предупреждений при сканировании в стандартном проекте коде
• Встроенные правила поиска credentials могут выдавать FP на комментарии и текстовые строки в коде
• Поддежка gosec ruleset есть в инструменте Semgrep, что ставит под вопрос использование двух разных инструментов
• Можно переиспользовать вместо нескольких тулов как единый вход, если у вас база только на golang
• Максимально простой и user friendly
• Zero Config и работает из коробки
• Не является policy engine, следовательно, не осуществляет policy-as-code подхода
• Ограниченно способен поддерживать политики в качестве инструмента Security Gate
• Парсит код в AST с помощью стандартного пакета "go-ast" и применяет набор встроенных правил для поиска небезопасных паттернов
• Инструмент имеет 40 базовых правил
• Исключать правила из сканирования, а также их настраивать возможно с помощью файла конфигурации "gosec.json"


Сноска

• AST - Abstract Syntax Tree: — древовидное представление структуры исходного кода, то есть "Что написано"


FuncDecl
├── Name: "add"
├── Params: [a int, b int]
├── Results: [int]
└── Body:
└── ReturnStmt
└── BinaryExpr (+)
├── Ident: "a"
└── Ident: "b"


• SSA - Static Single Assignment: промежуточное представление, где для каждой переменной присваивание разовое, то есть "откуда и куда"

#toolchain #sast #appsec #reco #techsolution #term
🔥6
Салюты,
Интересное взаимодействие и маркетинг у hh, но парень реально открыл ящик пандоры в наших сердцах (не ну было такое полюбому).

#lol
🤣9
Forwarded from hh.ru
Ультанул