#bruteforce

[ LEGBA ]
A multiprotocol credentials bruteforcer / password sprayer and enumerator

AMQP (ActiveMQ, RabbitMQ, Qpid, JORAM and Solace)
DNS
FTP
HTTP
IMAP
Kerberos
LDAP
MongoDB
MQTT
Microsoft SQL
MySQL
Oracle
PostgreSQL
POP3
RDP
Redis
ScyllaDB / Cassandra
SSH / SFTP
SMTP
STOMP (ActiveMQ, RabbitMQ, HornetQ and OpenMQ)
TCP Port Scanner
Telnet
VNC

P.S. Активно развивается, коллеги хвалят.

https://github.com/evilsocket/legba

Абсолютно волшебная тула, которая может о-о-о-о-чень медленно, но о-о-о-чень тайно таскать данные по NTP. Причём автор совершенно честно пишет, что стремился сделать обнаружение этого канала утечки практически невозможным, тщательно эмулируя работу реального NTP, и не выходить за границы существующих полей.
+1 паранойя

https://github.com/evallen/ntpescape

Как мы уже неоднократно рассказывали одним из способов уменьшить «шум» от сканеров известных уязвимостей — это уменьшить количество компонентов, которые лежат в образе. И к этому глобально можно подойти 2 способами (multi-stage сборку рассматриваем как само собой разумеющееся):
1) На основе специализированного образа (scratch, alpine, distroless, chainguard)
2) На основе динамического анализа

Если о первом способе мы много пишем и многие знают, то про второй как раз нет. Ввиду того что нужен специальный инструментарий для этого. И такой инструментарий как раз есть - проект Slim (или SlimToolkit ранее известный как DockerSlim).

Проект позволяет посмотреть, что действительно используется во время работы и только это и оставить в итоговом образе! Но как вы понимаете тут очень важно (как и в случае любого динамического анализа) это покрытие кода тестами ...

Но сегодня хотелось бы отметить и еще одну новую экспериментальную фичу/флаг --obfuscate-metadata, которая вдохновлена докладом "Malicious Compliance" (мы писали о нем тут и тут). Да, он автоматом обфусцирует (реализация тут) данные о пакетах python, ruby, node и сканеры не видят уязвимости ;)

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

River - сервис для запуска бекграунд джоб на #golang

Мне нравятся такие штуки. Идея очевидна, но вот реализовали только сейчас

Сайт https://riverqueue.com/

Исходники тут https://github.com/riverqueue/river

Go mods Examples

Like as brute passwords in passwd or ssh, scan ports through nmap and etc..:

https://github.com/dreddsa5dies/goHackTools

The penetration testing execution standard consists of seven (7) main sections...

These cover everything related to a penetration test - from the initial communication and reasoning behind a pentest, through the intelligence gathering and threat modeling phases where testers are working behind the scenes in order to get a better understanding of the tested organization, through vulnerability research, exploitation and post exploitation, where the technical security expertise of the testers come to play and combine with the business understanding of the engagement, and finally to the reporting, which captures the entire process, in a manner that makes sense to the customer and provides the most value to it..:

http://www.pentest-standard.org/index.php/Main_Page

#Threat_Research
"Argo CD End User Threat Model: Security Considerations for Hardening Declarative GitOps CD on Kubernetes", 2023.

GitHub - brinhosa/apidetector: APIDetector: Efficiently scan for exposed Swagger endpoints across web domains and subdomains. Supports HTTP/HTTPS, multi-threading, and flexible input/output options. Ideal for API security testing.

https://github.com/brinhosa/apidetector

Последнее время то там, то тут слышишь про "Фиолетовые команды", видимо, "Красными" и\или "Синими" уже никого не удивишь 😁 Вот попался неплохой BOK по превращению "фиолетового движения" из ad-hoc в системную работу:
https://github.com/scythe-io/purple-team-exercise-framework

🗜 Смотрите какой клёвый pastebin сервис, работающий по SSH и доступный как в tui, так и в веб-морде... https://snips.sh/

А ещё, всё это можно развернуть на собственном сервере, судя по всему:

https://github.com/robherley/snips.sh

#tui #pastebin #ssh

Разработчики любят писать микросервисы для "перекладывания JSON". Стандарт устоявшийся и, как правило, не сулит проблем. Но так ли это на самом деле?

Возьмем небольшое приложение с двумя микросервисами:
— Cart — реализует бизнес-логику корзины
— Payment — используется для обработки платежей

Cart написан на Python с Flask и принимает ID товаров с их количеством. Попробуем отправить в него запрос с двумя одинаковыми ключами:

"cart": [
    {
        "id": 0,
        "qty": 5
    },
    {
        "id": 1,
        "qty": -1,
        "qty": 1
    }
]

Сервис провалидирует JSON в соответствии со схемой jsonschema.validate(instance=data, schema=schema). Убедится, что id: 0 <= x <= 10 and qty: >= 1. На этом этапе не будет ошибки (не смотря на то, что один из отправленных qty не подходит под условие), поскольку Flask использует стандартный JSON-парсер из Python, а тот сериализует данные, отдавая приоритет последнего ключа (qty = 1).

Дальше провалидированный JSON отправляется в микросервис Payment.

А микросервис Payment написан уже на Go и использует другой парсер buger/jsonparser. Он уже не валидирует JSON (ведь валидация была на предыдущем шаге), но использует приоритет первого ключа (qty = -1). Считает итоговую сумму total = total + productDB[id]["price"].(int64) * qty и генерирует чек.

Мы смотрим в чек, который вернулся в ответе, и видим ошибку. Нам будет отправлено шесть товаров стоимостью 700 долларов, но с нас взяли только 300 долларов, из-за расчетов со вторым ключом.

Такие ошибки возникают из-за того, что существует много стандартов JSON:
1. json.org
2. IETF RFC 4627
3. ECMAScript 262
4. ECMA 404
5. IETF RFC 7158
6. IETF RFC 7159
7. JSON5
8. HJSON

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

Полезные ссылки:
— https://seriot.ch/json/parsing.html — большая таблица-сравнение: как разные парсеры обрабатывают разные значения.
— https://bishopfox.com/blog/json-interoperability-vulnerabilities — я рассказал только об одном баге, но их гораздо больше: здесь можно почитать обо всех остальных.
— https://github.com/a1phaboy/JsonDetect — расширение для Burp для определения того, какой парсер используется.

https://github.com/Hackmanit/TInjA

TInjA (the Template INJection Analyzer) — CLI-утилита для проверки веб-приложений на наличие уязвимостей инъекции шаблонов.

Она поддерживает 44 наиболее актуальных шаблонизатора (по состоянию на 2023 год) для восьми различных языков программирования и поддерживает поиск как SSTI, так и CSTI.

Очень интересный канал Дэрека Джемисона раскрывающий весь потенциал flipper zero