PHPUnit vulnerability on 1.6 shops?

[Masteries 13]

Are shops on 1.6 affected? I couldn't find any folder named "PHPUnit" in any of our modules so I presume we're safe?

[Daresh 522]

From what I read it should be fine, but check what version of the autoupgrade module do you have.

[selectshop.at 1,424]

Shops PS 1.5., 1.6. and PS 1.7. are affected from the vulnerability XSAM_XADOO this means vulnerability in phpunit. For to make sure you are save, please delete all the sub-folders /phpunit/ in the folder /modules mentioned below:

Mainly the knowing modules possibly containing a security lack are:

/modules/autoupgrade/vendor/phpunit

/modules/ps_facetedsearch/vendor/phpunit - if exist, as newer module versions do not have this folder.

/modules/gamification/vendor/phpunit - if exist, as newer module versions do not have this folder.

and third development:

/modules/pscartabandonmentpro/vendor/phpunit

/modules/ps_checkout/vendor/phpunit

If you are on root server, then you can clean them via command line:

find . -type d -name "phpunit" -exec rm -rf {} \;

This command requires the relevant user rights.

[Masteries 13]

2 minutes ago, selectshop.at said:

Shops PS 1.5., 1.6. and PS 1.7. are affected from the vulnerability XSAM_XADOO this means vulnerability in phpunit. For to make sure you are save, please delete all the sub-folders /phpunit/ in the folder modules mentioned below:

Mainly the knowing modules possibly containing a security lack are:

/modules/autoupgrade/vendor/phpunit

/modules/ps_facetedsearch/vendor/phpunit - if exist, as newer module versions do not have this folder.

/modules/gamification/vendor/phpunit - if exist, as newer module versions do not have this folder.

and third development:

/modules/pscartabandonmentpro/vendor/phpunit

/modules/ps_checkout/vendor/phpunit

If you are on root server, then you can clean them via command line:

find . -type d -name "phpunit" -exec rm -rf {} \;

This command requires the relevant user rights.

1.6 only has autoupgrade but the rest of the modules are exclusive to 1.7 I believe. Fortunately, I couldn't find any vendor or phpunit directory in any of the modules. Our autoupgrade module version is older as well maybe that's why.

[selectshop.at 1,424]

No. gamification module is also a part of the latest PS 1.6. Versions. Furthermore, the problem is the use of external libraries. PS 1.5. could also be affected. Also ps_facettedsearch is a module in PS 1.6. It depends which module version you are using, its possible to contain external libraries as well.

[Masteries 13]

2 minutes ago, selectshop.at said:

No. gamification module is also a part of the latest PS 1.6. Versions. Furthermore, the problem is the use of external libraries. PS 1.5. could also be affected.

Oh I see, well just checked it as well. No phpunit folder found. Thanks for providing the information!

[Ether Création 43]

Hi,

We just develop a free module that solve this problem, you can find this here : https://www.shopmodule.fr/en/list-of-prestashop-addons/503-faille-phpunit.html

[dan.florea 0]

I found the folder :
 ../modules/gamification/vendor/bin/phpunit

should be also deleted ?
 

[dead_meme 0]

I don't have phpunit folder but found this file in one of autoupgrade module subfolders: phpunit.xml.dist

Should it be deleted as well?

[fiddlestix 0]

I found and deleted the folder. Unsure what to do next though.

[selectshop.at 1,424]

5 hours ago, fiddlestix said:

I found and deleted the folder. Unsure what to do next though.

Nothing. It's done, if you have deleted all the folders I named before.

[tuk66 796]

We have developed a free module M4 Check for vulnerabilities which you can use to check all directories.

Download at https://www.presta-addons.com/free/m4check.zip without registration.

[Lindsay_lfb 0]

13 hours ago, dead_meme said:

I don't have phpunit folder but found this file in one of autoupgrade module subfolders: phpunit.xml.dist

Should it be deleted as well?

I have the folder "phpunit.xml" in the /www/modules/gamification.

should be also deleted ?

[tuk66 796]

No, it's not necessary. This XML file is only a configuration file and does not pose a threat.

[Prestashop Addict 44]

Free module for ps 1.6 and 1.7 to remove phpunit folders and infected files.

[rogersjl1 0]

I'm using PS 1.6 and while there are no vendor or phpunit folders I do see a phpunit file and a phpunit.xml file in the advancedeucompliance module.  

The phpunit file contains this: 

#!/usr/bin/env sh

main_test_path=../../../tests
${main_test_path}/vendor/bin/phpunit -c .

which includes the "vendor" folder in the path but there's no vendor folder anywhere on the site.

The phpunit.xml file contains this:

<phpunit bootstrap="bootstrap.php">
    <testsuites>
        <testsuite name="Unit">
            <directory>Unit</directory>
        </testsuite>
        <testsuite name="Integration">
            <directory>Integration</directory>
        </testsuite>
    </testsuites>
</phpunit>

I'm assuming these phpunit files are not part of the vulnerability?

[Daresh 522]

Exactly, those files are safe.

[tuk66 796]

You are right. The eval-stdin.php file in phpunit is the real problem.

[ms_hassan 2]

there is a "PhpUnit" folder in "/prestashop/vendor/symfony/symfony/src/Symfony/Bridge/" is it safe ? 

[Masteries 13]

3 minutes ago, ms_hassan said:

there is a "PhpUnit" folder in "/prestashop/vendor/symfony/symfony/src/Symfony/Bridge/" is it safe ? 

 

I wouldn't take the risk. You should remove any folder/directory that is named "PHPUnit".

[ms_hassan 2]

I found the answer, you SHOULDN'T delete it. https://build.prestashop.com/news/critical-security-vulnerability-in-prestashop-modules/

8 minutes ago, Masteries said:

 

I wouldn't take the risk. You should remove any folder/directory that is named "PHPUnit".

[Masteries 13]

1 minute ago, ms_hassan said:

I found the answer, you SHOULDN'T delete it. https://build.prestashop.com/news/critical-security-vulnerability-in-prestashop-modules/

Oops my bad, I own a 1.6 shop so had no idea.

[CedCommerce Team 29]

On 1/6/2020 at 7:26 AM, Masteries said:

Are shops on 1.6 affected? I couldn't find any folder named "PHPUnit" in any of our modules so I presume we're safe?

Yes, if phpunit not found in vulnerable places, it means you are safe  

you can find it by running below command at prestashop root 

find . -type d -name "phpunit" -exec rm -rf {} \;

But please follow prestashop instructions and keep your prestashop up to date 

[Phil.It 1]

On 1/6/2020 at 2:00 PM, selectshop.at said:

Shops PS 1.5., 1.6. and PS 1.7. are affected from the vulnerability XSAM_XADOO this means vulnerability in phpunit. For to make sure you are save, please delete all the sub-folders /phpunit/ in the folder /modules mentioned below:

If you are on root server, then you can clean them via command line:

find . -type d -name "phpunit" -exec rm -rf {} \;

This command requires the relevant user rights.

I am sorry I disagree with the way you propose using straight such a command line, for many reasons, mainly risk of doing wrong :  

0) You should remind people to make backups first and check backup in second place. 

1) No one should ever perform a [

rm -rf

] without checking first what they are going to delete. For instance, running a [find] command without any [-exec] argument.

2) Using a [rm] with [-rf] is also the most destructive command ever, being performed with root account. Anybody could make a typo, for instance typing a forward "/" slash before the "\;" backslash. Furthermore, if the person reading this line was not able to find this command-line on his own, hazard is high that they could make any mistake in typing this. Last, anyone makes typos.

3) Following Unix principles, (one is that a program (command) should be doing one thing only), [find] is great to locate files, and result of this command should be passed to an [xargs] command that would print (and delete after checking).

4) I would rather advise to :

a) List folders to delete with a harmless command-line : [

find (your "modules" folder absolute pathname) -type d -name "phpunit"

]

 b) Delete them one by one with FTP client If FTP account has appropriate access rights,

c) If not possible, then remove folders one by one using [rm] command-line with absolute filepath using a shell script textfile that could be tested in a dry-run on a test site first before removing recursively on a production web site.

 

 

But people in a hurry could do this directly on the command-line : 

(0) Do your backups and check them 

(1) as a dry-run, using a [find]  piped to an [xargs] command with an harmless [ls] command.

[

find Your_"modules"_folder_absolute_pathname -type d -name "phpunit" -print0|xargs -0 -I {} ls -al {}

]

for instance, for a server where "modules" folder is [ /www/htdocs/modules/ ]

find /www/htdocs/modules/ -type d -name "phpunit" -print0|xargs -0 -I {} ls -al {}

 

 

(2) Secondly, using a [find]  piped to an [xargs] command with a [rm -r] command.

[

find (your "modules" folder absolute pathname) -type d -name "phpunit" -print0|xargs -0 -I {} rm --recursive {}

]

 

(3) Check by using the command-line in (1) again to check if some folder are still there

 

(4) If some folders were not removed because of access rights, you can use the same command as 2), but adding the [--force] argument :  

[

find (your "modules" folder absolute pathname) -type d -name "phpunit" -print0|xargs -0 -I {} rm --recursive --force {}

]

(Yes, I also recommend using long-names for arguments anytime you can - that also may save you from some typo someday 😉 and improve code readabilty & maintenance)

 

<!> Warning <!> If you don't understand what these commands do, or you got lost or bored before this line 😉  , you should NOT try to use them, and you would better find someone who does understand them.

 

But hey, I can figure that a lot of people are going to disagree with me.  🙂

 

[selectshop.at 1,424]

3 minutes ago, Phil.It said:

I am sorry I disagree with the way you propose using straight such a command line,

This is not my suggestion, but the official suggestion of Prestashop's core developers. It is an official suggestion ! Furthermore for those knowing how to use command lines, also know what they are doing with such command. For users without knowledge of command lines and/or root privileges they can follow the suggestion to delete the before named folders via FTP.

As server admin I cannot see any risk on the execution of the command line mentiioned before. You cannot do anything wrong. Perhaps you missed, that you should execute the commando inherit from the folder /modules. So you need to cd before to /modules and then execute the command from this directory. By changing the directory and executing the command with relevant user rights it does the same as your code.

On 1/6/2020 at 2:00 PM, selectshop.at said:

For to make sure you are save, please delete all the sub-folders /phpunit/ in the folder /modules mentioned below:

 

[Billy 11]

I have a 1.6 shop that was hacked after i went thru all the steps in the bulletin. I didn't have any of these folders at all so i went about my business.

Anyway we just restored a backup and it's jacked bad. It has all kinds of different files uploaded to it now.

They even installed their own /modules/autoupgrade/vendor/phpunit folder.

I am restoring another backup now that doesn't have any of this in it at all that i can tell.

However they are getting into the site "some other way" than whats posted here.

[Billy 11]

Again when the Critical Security Vulnerability came out my site was fine. I went thru everything and i only had the autoupgrade module installed out of the whole list.

Inside that folder i had nothing. Yet my site went down yesterday over this where they installed all kinds of crazy.php files.

In

public_html/

public_html/modules

[dead_meme 0]

Did You check them manually or via modul or command line?

[Billy 11]

Hey dead thanks for replying. I did in fact miss the /autoupgrade/vendor/phpunit folder. When i manually checked them based on what i see in my backups. Live and learn i say! So i am in the process of doing another restore now. Thanks for you're support!

 

Edited February 7, 2020 by Billy (see edit history)

[dead_meme 0]

I am sorry to hear that. 

Good luck with restoring.

[Billy 11]

Hey how do i check my version of phpunit & or upgrade it? Is this something that my hosting company would do at the server level? TIA

[dead_meme 0]

You mean Your PHP version? Depending on Your server provider You could change it by Your self or by notifing hosting company. Do You log on server by cPanel or Direct Admin for example?

[Billy 11]

No was specifically talking about phpunit version.

 https://phpunit.de/supported-versions.html

I seen somewhere that i should check what version i have. I will get my hosting provided to check for me. Thanks

[Masteries 13]

34 minutes ago, Billy said:

No was specifically talking about phpunit version.

 https://phpunit.de/supported-versions.html

I seen somewhere that i should check what version i have. I will get my hosting provided to check for me. Thanks

You actually don't need to upgrade your version of PHPUnit, it's only used for development & testing purposes by Prestashop/third-party module developers. All you have to do is delete the ones found in any vendor folder. You could also upgrade your Prestashop version to the latest as well if you're worried.

The issue is fixed in PHPUnit 7.5.19 and 8.5.1. So we can presume all versions prior to those are affected.

[Rsking dom 0]

My work is sell RuneScape gold in www.rsgoldfast.com.

[George441 4]

On 1/8/2020 at 8:30 AM, fiddlestix said:

I found and deleted the folder. Unsure what to do next though.

No need to do anything it's done

[Mercader Virtual 9]

If you manually setup Prestashop on your server, make sure you run:

composer install --no-dev

and not just:

composer install

Otherwise vendor/phpunit will be installed and probably other libraries not supposed to be exposed to public.

[namarang2020 0]

To be safe, encryption must always be used to ensure everything

 

Edited August 17, 2020 by namarang2020 (see edit history)

[Josephbinder 0]

Thanks