Громим PrestaShop. Как я захватил инсталл интернет-магазина на багбаунти

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

• Как все начиналось
• RCE через плагин
• RCE через cache engine deserialization (?)
• Десериализация гаджетов PHP
• Эксплуатация
• Ответственное разглашение

В этой статье я рас­ска­жу, как одна малень­кая ошиб­ка с уста­новоч­ным скрип­том в CMS PrestaShop может открыть дверь для уда­лен­ного выпол­нения кода. Ока­залось, что некото­рые аспекты этой CMS устро­ены так, что не под­лежат исправ­лению и соз­дают опас­ные лазей­ки для опыт­ных хакеров. Pentest Award

Этот текст получил третье мес­то на пре­мии Pentest Award 2024 в катего­рии «Про­бив WEB». Это сорев­нование еже­год­но про­водит­ся ком­пани­ей Awillix.

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

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

Как все начиналось

Эта исто­рия слу­чилась со мной не так дав­но. Я учас­тво­вал в баг­баун­ти и бороз­дил прос­торы ско­упа в поис­ках уяз­вимос­тей. И тут нат­кнул­ся на ненас­тро­енный инстанс PrestaShop у одно­го из боль­ших вен­доров с хороши­ми вып­латами. Я был впе­чат­лен сво­ей наход­кой и сра­зу же начал искать информа­цию о век­торах про­ник­новения и спо­собах экс­плу­ата­ции.

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

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

Про­цесс устро­ен так же, как и в дру­гих CMS вро­де WordPress или Joomla. Необ­ходимо прой­ти нес­коль­ко шагов уста­нов­ки. Из важ­ных я могу выделить два:

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

Но мы не хотим отвле­кать­ся на дол­гие про­вер­ки, потому что в это вре­мя кто‑то может успеть увес­ти у нас дос­туп к уста­нов­щику. По‑вся­кому ска­ниро­вать сеть через под­клю­чение к MySQL зву­чит не очень пер­спек­тивно и не даст нам никаких реаль­ных спо­собов ата­ки. Из дру­гих век­торов же ничего не сра­бота­ло.

Ес­ли ука­зать localhost в качес­тве хос­та для базы дан­ных, то получа­ем сооб­щение об ошиб­ке service timeout.

Но без базы завер­шить уста­нов­ку не вый­дет, поэто­му быс­трень­ко под­нимем свой сер­вис MySQL и ука­жем его при нас­трой­ке PrestaShop.

За­вер­шаем уста­нов­ку, и вот мы вла­дель­цы сер­виса и пол­ностью кон­тро­лиру­ем его БД. Теперь никакие кон­курен­ты не смо­гут угнать учет­ную запись.

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

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