Пентест провайдера. Как цепочка классических багов привела к полной компрометации

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

Суть про­екта зак­лючалась в тес­тирова­нии срав­нитель­но скром­ного сег­мента внеш­ней инфраструк­туры заказ­чика — на стар­те было пре­дос­тавле­но все­го девять IP-адре­сов. Ско­уп, конеч­но, неболь­шой, но, как показы­вает прак­тика, даже это­го быва­ет дос­таточ­но для весь­ма инте­рес­ных находок. Так про­изош­ло и здесь!

В область тес­тирова­ния вхо­дила кор­поратив­ная ERP-сис­тема, при­чем это был даже не вен­дор­ский про­дукт, а внут­ренняя раз­работ­ка. Самопис­ные решения (еще и для внут­ренне­го исполь­зования) осо­бен­но инте­рес­ны тем, что к ним могут предъ­являть­ся гораз­до менее стро­гие тре­бова­ния по безопас­ности. Веро­ятность того, что такие сис­темы про­ходят регуляр­ный пен­тест, тем более мала. Собс­твен­но, о зах­вате этой сис­темы я сегод­ня и рас­ска­жу.

Разведка, первая зацепка

Пер­вый этап при про­веде­нии пен­теста — это, конеч­но же, раз­ведка — поиск мак­сималь­ного чис­ла под­доменов, веб‑сай­тов, служб и сер­висов, дос­тупных в обоз­начен­ном ско­упе.

По­это­му в пер­вую оче­редь я прос­каниро­вал пор­ты на получен­ных девяти IP-адре­сах, что­бы опре­делить дос­тупные служ­бы.

Я начал с поис­ка веб‑при­ложе­ний на стан­дар­тных пор­тах — 80 и 443. Это помог­ло быс­тро очер­тить базовую повер­хность ата­ки и про­вес­ти ска­ниро­вание без лиш­него шума. На тот момент было непонят­но, исполь­зует ли заказ­чик средс­тва защиты и нас­коль­ко стро­го они нас­тро­ены, поэто­му я ста­рал­ся дей­ство­вать осто­рож­но.

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

Ко­ман­да выг­лядела так:

В резуль­тате ска­ниро­вания я обна­ружил три узла с дос­тупны­ми веб‑сер­верами. Кро­ме того, Nmap по умол­чанию выпол­няет обратное раз­решение DNS-имен, поэто­му в про­цес­се я так­же получил исполь­зуемое домен­ное имя (в тек­сте я буду исполь­зовать вмес­то него example.ru).

Те­перь мож­но исполь­зовать его для поис­ка под­доменов. Для это­го я обыч­но поль­зуюсь инс­тру­мен­тари­ем ProjectDiscovery, в час­тнос­ти ути­лита­ми subfinder и dnsx. Пер­вая пред­назна­чена для поис­ка под­доменов в откры­тых источни­ках, а вто­рая — для выпол­нения DNS-зап­росов, ана­лог nslookup или dig. Инс­тру­мен­тарий PD при­меча­телен тем, что вывод одной ути­литы мож­но сра­зу пай­пить на ввод дру­гой. Бла­года­ря это­му мож­но собирать инте­рес­ные ком­бай­ны, поз­воля­ющие одним однос­троч­ником про­вес­ти раз­ведку, обна­ружить дей­ству­ющие HTTP-сер­висы и сра­зу же прос­каниро­вать их на наличие уяз­вимос­тей.

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

Пос­ле филь­тра­ции вывода по IP-адре­сам из ско­упа мое вни­мание прив­лек один адрес, в который раз­решались око­ло десяти под­доменов. Это был как раз один из ранее най­ден­ных хос­тов с дос­тупным веб‑интерфей­сом.

Я изу­чил дос­тупные веб‑при­ложе­ния и выяс­нил, что на этом узле раз­мещена ERP-сис­тема (erp.example.ru). Боль­шинс­тво под­доменов ока­зались ее копи­ями для офи­сов ком­пании в раз­ных городах. Так­же были дос­тупны под­домены с говоря­щими наз­вани­ями files и api, судя по все­му, пред­назна­чен­ные для работы с фай­лами и API-зап­росами.

Сле­дующий этап, разуме­ется, — это фаз­зинг дос­тупных фай­лов и дирек­торий на обна­ружен­ных веб‑при­ложе­ниях. Здесь и жда­ла пер­вая наход­ка: на под­домене files.example.ru ока­зал­ся дос­тупен кон­фиг Nginx.

Первая уязвимость — читаем файлы

Мое вни­мание сра­зу же прив­лекла одна из пер­вых стро­чек кон­фига:

Здесь мож­но уви­деть, что все мар­шру­ты, начина­ющиеся с /avatar, обра­баты­вают­ся rewrite-пра­вилом, его мож­но про­читать так: «возь­ми все, что идет пос­ле /avatar/, и под­ставь в аргу­мент парамет­ра file». То есть если мы обра­тим­ся по пути /avatar/test/example.png, то Nginx прев­ратит это в /api.php?type=getAvatar&file=test/example.png.

GET-параметр file вызыва­ет очень боль­шие подоз­рения на воз­можный LFR / Path Traversal, но, если мы под­ста­вим наг­рузку в изна­чаль­ный URL, ничего не про­изой­дет: Nginx обру­бает подоб­ные зап­росы и воз­вра­щает ошиб­ку 400. Но сто­ит про­верить, мож­но ли обра­тить­ся к скрип­ту api.php нап­рямую и под­ста­вить наг­рузку туда.

Бин­го! Теперь есть воз­можность читать содер­жимое фай­лов в сис­теме, дос­тупных текуще­му поль­зовате­лю, — веро­ятно, www-data. А еще в кон­фиге Nginx был виден эндпо­инт, пред­назна­чен­ный для заг­рузки фай­лов, но он уже тре­бовал авто­риза­ции (одна­ко он все еще будет полезен в даль­нейшем).

Новый поддомен

Ис­поль­зуя обна­ружен­ную уяз­вимость, я при­нял­ся изу­чать содер­жимое фай­лов сер­вера, вклю­чая мно­гочис­ленные кон­фиги в дирек­тории /etc. И тут всплы­ла сле­дующая наход­ка: нас­трой­ка зоны (назовем ее example.ru) для DNS-сер­вера BIND. В ней — нес­коль­ко новых под­доменов, которые я не встре­чал на эта­пе раз­ведки, при­чем они резол­вились все в тот же IP-адрес, с которым я работал. Одним из них был xyz.example.ru, на котором наш­лось новое при­ложе­ние.