vulnerability on PrestaShop sites

[netamismb]

There is a post https://www.mediacom87.fr/vulnerabilite-majeure-de-securite-sur-les-sites-prestashop/ created by @Mediacom87 is this vulnerability present in thirtybees as well?

[the.rampage.rado]

@datakick

[janoo]

ThirtyBees and PS 1.6 has this code slightly different from in PS 1.7:
you can find it in "./config/smarty.config.inc.php"

if (Configuration::get('PS_SMARTY_CACHING_TYPE') == 'mysql') {
    include(_PS_CLASS_DIR_.'/SmartyCacheResourceMysql.php');
    $smarty->caching_type = 'mysql';
}

but principle is as same as in original Prestashop files v 1.6.x and 1.7.x
described in https://build.prestashop.com/news/major-security-vulnerability-on-prestashop-websites/

I prefer to comment these lines, not remove at all, but it´s my decision only

Edited July 22, 2022 by janoo

[datakick]

there is no information at all about the actual vulnerability, so we can't tell if tb is affected or not.

All we know is that the ps16/ps17 is vulnerable to some attack if mysql smarty cache is enabled. Most stores are using filesystem cache

[datakick]

I did a little more investigation.

Thisbis a chained exploit. In order for this to be dangerous, you first have to have sql injection vulnerability present in your store.

As far as we know, there is no such vulnerability in core. But there may be, of course. And any native or third party modules can have sql injection vulnerability in their code as well.

If your store is vulnerable to sql injection it is already huge issue. Attacker can update, delete, and possibly read any data in your database. They can change passwords, delete orders, or whatnot.

But if you have enabled mysql smarty cache, this problem is elevated to the stars. Attacker can insert data inside smarty cache table, and smarty library will evaluate this data as php code. Which means that attacker can run arbitrary php code in your store. That's fuc*ing scary 

The fix will be quite simle. We will sign any data stored inside this table with secret that is know to php only, not stored in db. Attacker don't know the secret, so they will not be able to insert correctly signed data into the database.

Until the fix is designed, pleas go to Performance settings and ensure you are using filesystem smarty cache implementation. Do not edit core files as suggested above, please.

 

[the.rampage.rado]

Thank you for the clarification! 

[Acer]

2 hours ago, datakick said:

I did a little more investigation.

Thisbis a chained exploit. In order for this to be dangerous, you first have to have sql injection vulnerability present in your store.

As far as we know, there is no such vulnerability in core. But there may be, of course. And any native or third party modules can have sql injection vulnerability in their code as well.

If your store is vulnerable to sql injection it is already huge issue. Attacker can update, delete, and possibly read any data in your database. They can change passwords, delete orders, or whatnot.

But if you have enabled mysql smarty cache, this problem is elevated to the stars. Attacker can insert data inside smarty cache table, and smarty library will evaluate this data as php code. Which means that attacker can run arbitrary php code in your store. That's fuc*ing scary 

The fix will be quite simle. We will sign any data stored inside this table with secret that is know to php only, not stored in db. Attacker don't know the secret, so they will not be able to insert correctly signed data into the database.

Until the fix is designed, pleas go to Performance settings and ensure you are using filesystem smarty cache implementation. Do not edit core files as suggested above, please.

 

Thanks @datakick for the update. Please keep us posted and let us know when a patch / update has been released. 

[Raymond]

Thank you DataKick for the information, your explication is very synthetic and clear to understand for the final users

[musicmaster]

One line in the Prestashop article says that versions 2.0.0~2.1.0 of the Wishlist (blockwishlist) module are vulnerable.

That means that the Thirty Bees version - that is derived from Prestashop - may be vulnerable too. Does that module need an upgrade?

[WBNet-Wout]

@musicmaster: I do not think so. https://github.com/PrestaShop/blockwishlist/commit/be79516175d564f60a657627482b0a60c3da353e seems to be the commit fixing it, but that file does not even exist in the thirty bees module.

@datakick: The PrestaShop article however mentions that the attacker is able to enable using MySQL Smarty cache storage features remotely and that is why they recommend removing those lines, so that if the attacker enables it remotely it will not actually be enabled due to lacking the code for that. Unfortunately there does not seem to be any detail on how the attacker is able to enable it remotely.

[WBNet-Wout]

PrestaShop has now made a patch available to fix the vulnerability: https://github.com/PrestaShop/PrestaShop/commit/f342765697f5f980e4c6bb537f6575bf5e657077

[Acer]

Any idea when we'll have a patch available for 30Bz, please @datakick? 

[Acer]

13 hours ago, WBNet-Wout said:

PrestaShop has now made a patch available to fix the vulnerability: https://github.com/PrestaShop/PrestaShop/commit/f342765697f5f980e4c6bb537f6575bf5e657077

While we wait for @datakick

What are you guys doing to fix this on your sites? Do you know if it's possible to apply the Prestashop fix to TB in this case? 

@WBNet-Wout @musicmaster

[wakabayashi]

As Petr clearly pointed out: just deactivate the mysql cache. IMO you should anyway not use it... Are you using it?

Unfortunately security is still my weakness in coding. I understand, that there is some sql injection possibility. Prestashop seems to believe, that it happens in caching. But the fix does irritate me. There is already pSQL() in use. They just replaced it with another encrypt method. 

[wakabayashi]

Is there even one TB shop with an issue right now? 🤔

[Acer]

1 minute ago, wakabayashi said:

As Petr clearly pointed out: just deactivate the mysql cache. IMO you should anyway not use it... Are you using it?

Unfortunately security is still my weakness in coding. I understand, that there is some sql injection possibility. Prestashop seems to believe, that it happens in caching. But the fix does irritate me. There is already pSQL() in use. They just replaced it with another encrypt method. 

From what we gathered it seemed that the attackers could somehow override the Smarty cache setting regardless, which means it doesn't matter that we have it on the correct setting. Unless I'm completely mistaken?

So what to do here? 

[Acer]

2 minutes ago, wakabayashi said:

Is there even one TB shop with an issue right now? 🤔

Do we  really want to find out? Some could be compromised already and they won't know for a while 

[wakabayashi]

2 minutes ago, Theo said:

Do we  really want to find out? Some could be compromised already and they won't know for a while 

Ofc not. But it might be helpful to know. Maybe the chain doesn't exist 1 to 1 in tb.

4 minutes ago, Theo said:

From what we gathered it seemed that the attackers could somehow override the Smarty cache setting regardless, which means it doesn't matter that we have it on the correct setting. Unless I'm completely mistaken?

Where does this information come from? I would guess, that this can only be true, if you are already infected...

[Acer]

On 7/25/2022 at 9:23 AM, WBNet-Wout said:

The PrestaShop article however mentions that the attacker is able to enable using MySQL Smarty cache storage features remotely and that is why they recommend removing those lines, so that if the attacker enables it remotely it will not actually be enabled due to lacking the code for that. Unfortunately there does not seem to be any detail on how the attacker is able to enable it remotely.

See above

[Mediacom87]

I made an update on this article about some other information on multi possible hack.

https://www.mediacom87.fr/vulnerabilite-majeure-de-securite-sur-les-sites-prestashop/#update-20220725

Eolia Script can be used on TB too.

[janoo]

Maybe you are aware already of Dominik Shaim (CZ) who helped PS guys with this, and as @WBNet-Wout found link to patch for PS1.7,
Dominik also wrote code for rough check your eshop:
https://www.openservis.cz/pedido_checker.php?url=domain.tld

and further reading in czech language is on:
https://www.openservis.cz/prestashop-blog/dulezita-bezpecnostni-aktualizace-modulu-balikovna-update-nutny/

there you can find also link to download zip with code do clear attacked eshop with Dominik´s code:
https://psmoduly.cz/modules_download_22/psql_find_nakaza_SPECIFIC_46045e87d3366a10dde0c1e80e0dd3aa.zip

I really appreciate his effort

Edited July 26, 2022 by janoo

[Acer]

That's excellent, thanks to all involved and @Mediacom87 @janoo

The instructions and blog post from Janoo and MediaTek seems to cover everything that needs to be done to patch your TB site in this case. 

And I know I'm atting @datakicklots here, but will you remove those lines for 1.4 or in a patch update please? 

Edited July 27, 2022 by Theo

[janoo]

thank you @Theo

Quote

So the PS 1.6 instructions to delete line 40-60 applies to TB as well?

but who count lines 40-60? 🙂  read carefully original: https://build.prestashop.com/news/major-security-vulnerability-on-prestashop-websites/
don´t count lines, find exact code there with your eyes, you aren´t robot

And: that is rough correction, not a fix. Guys from Prestashop don´t care about PS 1.6 anymore, and patch for PS 1.7 doesn´t fit neither to PS 1.6 nor TB.
So this rough correction is temporary good until some great coder make patch for TB here.
I am not so good, so I use this rough correction. But not deleting these rows, just disable by commenting it.
Question is: who use mysql cache and not file chaching? Who use mysql caching is vulnerable more now.

Edited July 27, 2022 by janoo

[Acer]

Yeah I just found the code block as you mentioned before and did not go line specific. And ran the URL checker plus cleaner script as referenced in the articles you guys posted. 

Thankfully my sites are clean. 

Anyway, appreciate the posts. It's nice that there is still a TB community with fellow TBers 👍

On 7/22/2022 at 10:02 PM, janoo said:

ThirtyBees and PS 1.6 has this code slightly different from in PS 1.7:
you can find it in "./config/smarty.config.inc.php"

if (Configuration::get('PS_SMARTY_CACHING_TYPE') == 'mysql') {
    include(_PS_CLASS_DIR_.'/SmartyCacheResourceMysql.php');
    $smarty->caching_type = 'mysql';
}

but principle is as same as in original Prestashop files v 1.6.x and 1.7.x
described in https://build.prestashop.com/news/major-security-vulnerability-on-prestashop-websites/

I prefer to comment these lines, not remove at all, but it´s my decision only

Thanks again.

I'd also like to take the opportunity to thank Google Translate 😉 If it wasn't for you buddy, everything would be French for me or better, Czech. You help me make sense if it all 🙂

Edited July 27, 2022 by Theo

[led24ee]

I can't use Filesystem cache, because I run out of inodes. I just disabled cache at all. Ans i f i look my log files then more than week almost every day there is one or two try to put something in some database.