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

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

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

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

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

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

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

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

1. Нас­трой­ка базы дан­ных (MySQL). Необ­ходимо ука­зать адрес сер­вера, логин и пароль к нему (есть воз­можность сра­зу про­верить соеди­нение).
2. Ввод пароля для акка­унта адми­нис­тра­тора.

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

1. Воз­можна ли тут сле­пая SSRF с импактом (нап­ример, поменять про­токол, исполь­зовать врап­перы, под­клю­чить­ся к внеш­нему хос­ту и пред­ложить NTLM-аутен­тифика­цию, пос­канить локаль­ную сеть).
2. Пос­коль­ку это MySQL, воз­можно ли у нас чте­ние фай­лов через Rogue MySQL (вклю­чена ли фун­кция --enable-local-infile на кли­енте).

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

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

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

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

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

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