Пос­коль­ку Burp Suite авто­мати­чес­ки стро­ит кар­ту сай­та, видим, что на pokatmon.htb дос­тупен файл CHANGELOG, из которо­го узна­ём о сущес­тво­вании неко­его при­ложе­ния для Android, а так­же WAF ModSecurity.

Мы зна­ем вер­сии уста­нов­ленно­го ПО, поэто­му можем поп­робовать поис­кать в интерне­те опи­сания уяз­вимос­тей и экс­пло­иты.

Точка входа

OpenStack Keystone

Служ­ба Keystone вхо­дит в облачную плат­форму OpenStack и обес­печива­ет аутен­тифика­цию кли­ентов API, обна­руже­ние служб и рас­пре­делен­ную мно­гополь­зователь­скую авто­риза­цию. В слу­чае с Keystone поиск экс­пло­итов ока­зал­ся нелег­кой задачей, но все же находим уяз­вимость с иден­тифика­тором CVE-2021-38155, которая поз­волит опре­делить сущес­тву­ющих поль­зовате­лей.

Суть бага в том, что если мы поп­робу­ем нес­коль­ко раз авто­ризо­вать­ся от име­ни сущес­тву­юще­го поль­зовате­ля, то он будет на вре­мя заб­локиро­ван и нам вер­нут соот­ветс­тву­ющее сооб­щение. Для име­ни поль­зовате­ля, акка­унта которо­го не сущес­тву­ет, мы такого сооб­щения не получим. Возь­мем спи­сок имен из набора SecLists и поп­робу­ем авто­ризо­вать­ся с каж­дым из имен и десятью раз­ными пароля­ми с помощью Burp Intruder. Для авто­риза­ции исполь­зуем зап­рос к /v3/auth/tokens со сле­дующи­ми дан­ными.

В ито­ге получа­ем двух поль­зовате­лей: admin и andrew. Перебор паролей ничего не дает, поэто­му перехо­дим к дру­гому сер­вису.

OpenStack Object Store (Swift) — ПО для облачно­го хра­нили­ща, поз­воля­ющее хра­нить и извле­кать боль­шое количес­тво дан­ных с помощью прос­того API. По зап­росу «keystone swift» получа­ем до­кумен­тацию, из которой узна­ём о том, что мож­но получить дос­туп к откры­тым дан­ным, зная толь­ко имя поль­зовате­ля и исполь­зуя пре­фикс AUTH_. Поп­робу­ем переб­рать хра­нили­ще поль­зовате­ля andrew.

По­луча­ем один каталог, который содер­жит при­ложе­ние для Android.

Ви­димо, это при­ложе­ние, которое упо­мина­лось в чен­жло­ге. Ска­чива­ем его для ана­лиза.

Точка опоры

Анализ APK

В качес­тве вир­туаль­ной машины я исполь­зую AVD из Android Studio. Пос­ле запус­ка вир­туаль­ного смар­тфо­на про­верим, опре­дели­лось ли устрой­ство в adb.

Те­перь с помощью adb уста­новим ска­чан­ное при­ложе­ние и запус­тим уже с мобиль­ного устрой­ства.

Нас встре­чает фор­ма авто­риза­ции, но, вве­дя тес­товые дан­ные, мы не получа­ем дос­туп к сер­веру.

На хос­товой сис­теме запус­каем Wireshark и смот­рим, куда идут зап­росы. В тра­фике отме­чаем DNS-зап­рос для резол­ва api.pokatmon-app.htb.

В качес­тве сво­его DNS-сер­вера исполь­зуем dnsmasq. Для най­ден­ного адре­са сде­лаем запись в фай­ле /etc/dnsmasq.conf и запус­тим dnsmasq.

А теперь переза­пус­тим вир­туаль­ную машину, но с ука­зани­ем DNS-сер­вера и пов­торим зап­рос на сер­вер.

На­конец при­ложе­ние может общать­ся с сер­вером. Теперь про­пус­тим весь его тра­фик через Burp Proxy, для чего в нас­трой­ках Burp соз­дадим новый лис­тенер на VPN-интерфей­се. Соз­данный лис­тенер ука­зыва­ем в нас­трой­ках прок­си AVD.

Но сно­ва не получа­ем дос­туп к сер­веру. При­чину можем пос­мотреть в логах Burp Proxy. Все дело в SSL-сер­тифика­те.

Что­бы ошиб­ка исчезла, нам нуж­но уста­новить сер­тификат Burp в вир­туаль­ное устрой­ство. Для это­го сна­чала ска­чива­ем сам сер­тификат, кон­верти­руем его в фор­мат PEM и пере­име­новы­ваем. В Android имя сер­тифика­та — это его кон­троль­ная сум­ма.

Те­перь нуж­но сох­ранить наш серт в катало­ге /system/etc/security/cacerts/ устрой­ства. Но прос­то записать его не получит­ся, так как фай­ловая сис­тема вир­туаль­ной машины дос­тупна толь­ко для чте­ния. Переза­пус­тим вир­туаль­ную машину с парамет­ром -writable-system.

А затем «руту­ем» устрой­ство и перемон­тиру­ем основной каталог. Если все про­ходит успешно, сох­раня­ем сер­тификат Burp.

Пов­торя­ем попыт­ку авто­риза­ции и видим зап­рос в Burp Proxy.

Я сра­зу отпра­вил зап­рос в Burp Repeater, но ока­залось, что у сер­вера заготов­лены раз­ные вари­анты отве­та. Как мож­но видеть на скри­не, на зап­рос без заголов­ка authorization сер­вер отве­тит, что дан­ные не под­писаны. А при изме­нении дан­ных зап­роса сер­вер сооб­щит о несо­ответс­твии под­писи.

Тог­да будем работать через само при­ложе­ние. Я поп­робовал отпра­вить базовую наг­рузку ' or 1=1 -- -, это мог­ло бы помочь обой­ти авто­риза­цию, при­сутс­твуй здесь воз­можность для SQL-инъ­екции. Ока­залось, что при­ложе­ние не поз­воля­ет вво­дить некото­рые сим­волы.

Тог­да при­дет­ся понять, как фор­миру­ется под­пись. При прос­мотре содер­жимого APK-фай­ла мож­но най­ти два клю­ча RSA.

Че­рез две‑три попыт­ки под­писать отправ­ляемые дан­ные с помощью при­ват­ного клю­ча получа­ем валид­ную под­пись!

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

В отве­те получа­ем поч­товый адрес и ключ‑инвайт. С эти­ми дан­ными авто­ризу­емся в при­ложе­нии и получа­ем редирект на www.pokatmon-app.htb.

Этот адрес мы уже посеща­ли, там рас­положен основной сайт, при этом в Burp Proxy видим те же инвайт и поч­товый ящик. Но обра­тим вни­мание и на веб‑сер­вер APISIX 2.10.1.

Обход каталога в Apache APISIX

По­ищем готовые экс­пло­иты для гей­твея APISIX. Зап­рос «apisix Vulnerabilities» при­водит к под­борке ста­тей про уяз­вимос­ти. Из всех упо­мяну­тых CVE наибо­лее при­мени­ма CVE-2021-43557, которая даст воз­можность обхо­да катало­га. Тут сто­ит вер­нуть­ся к ска­ниро­ванию катало­гов, так как изна­чаль­но я не при­дал зна­чения мно­жес­тву резуль­татов с кодом отве­та 403.

Теги: CSS