Smarty cache mysteriously activates randomly

[braffas]

Hello!

I've encountered a bizarre issue that's driving me nuts.

For some unknown reason, the smarty cache (PS_SMARTY_CACHE in configuration) becomes active at random times throughout the day.

I've searched the source files, both in core and modules, to locate where this might be happening (PS_SMARTY_CACHE and SMARTY_CACHE) and I simply can't find it.

I searched for Configuration::updateValues/set etc. changes and direct changes to the configuration table in the database.

Furthermore, I'm the only one with rights to access the AdminPerformanceController, so it's not a manual change.

Right now, I have set up a CRON job to check the value and email me when the value changes. The last time it happened was Saturday evening at 21:05

This time doesn't match any CRON job that I have running, and no one is active in the store at this time (other than customers).

The problem is our server suffers a slow death when the file cache starts to build up large due to our catalog of over 4 million products.

The issue started happening a couple of months ago. I'm running TB 1.4 (this issue did not start after an update).

For now, I've set up the CRON job to disables the cache whenever it becomes active … That works … but would REALLY appreciate it if anyone has any input about why/where this is happening?! 😄

Best regards
Kasper

 

[datakick]

Let me start by saying that this is, most likely, caused by some module.

But it is also possible that this is a side effect of hack attempt, especially since this is related to smarty cache. 

If attacker discovers an SQL injection vulnerability in your store, they can use it to read and write arbitrary data to your database - they can construct custom PHP script and save it inside tb_smarty_cache table. Old versions of thirty bees (<1.4.0) would then execute this custom script when the page is displayed. That's extremely dangerous, because it elevates SQL injection vulnerability to absolute PHP code execution.

Because you are on 1.4, you can at least be sure that this attempt was blocked. However, the sql injection vulnerability might be there, so it's essential that you investigate further and find the root cause of this.

[Yabber]

It's worth checking if you have some module from prestashop with security vulnerabilities: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prestashop

[braffas]

Thank you so much! I'm looking into it further. The possibility of a security breach hadn't occurred to me. I am examining the log files and related data immediately.

I will get back to you as soon as I have determined the cause.

[braffas]

It was a significant security breach. Thank you for directing my attention to it.

The breach was initiated through the vulnerability detailed here: https://build.prestashop-project.org/news/2022/major-security-vulnerability-on-prestashop-websites/ It turns out that our old blog module, Prestablog, contained the vulnerability. The attack used a payload with an injection (hex value) sent to a text processing function (getByRewrite) that generates SEO URLs for blog categories.

Fortunately, the script triggered multiple warnings so the POST data was captured by the collectlogs module, which provided the critical lead I needed.

All database queries in the module have now been escaped and thoroughly tested for SQL injection vulnerabilities. Everything is secure now. Phew!

Edited March 19 by braffas

[the.rampage.rado]

Nice opportunity to update to 1.5.1 where at least 10 other security fixes are introduced 😉

[braffas]

Yes, an update to 1.5.1 has just been moved to the top of my to-do list. I am already in the process of testing it. 🙂