Jump to content

PHPUnit vulnerability on 1.6 shops?

Masteries

By Masteries
in General topics

 Share

Recommended Posts

selectshop.at Newbie

selectshop.at

Posted
Posted

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.

Link to comment
Share on other sites
Masteries Newbie

Masteries

Posted
  • Author
Posted
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.

  • Like 1
Link to comment
Share on other sites
selectshop.at Newbie

selectshop.at

Posted
Posted

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.

Link to comment
Share on other sites
Masteries Newbie

Masteries

Posted
  • Author
Posted
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!

Link to comment
Share on other sites
Lindsay_lfb Newbie

Lindsay_lfb

Posted
Posted
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 ?

Link to comment
Share on other sites
rogersjl1 Newbie

rogersjl1

Posted
Posted

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?

Link to comment
Share on other sites
CedCommerce Team Enthusiast

CedCommerce Team

Posted
Posted
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 

Link to comment
Share on other sites
Phil.It Newbie

Phil.It

Posted
Posted
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.  🙂

 

Link to comment
Share on other sites
selectshop.at Newbie

selectshop.at

Posted
Posted
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:

 

Link to comment
Share on other sites
  • 4 weeks later...
Billy Contributor

Billy

Posted
Posted

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.

Link to comment
Share on other sites
Billy Contributor

Billy

Posted
Posted

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

Link to comment
Share on other sites
Billy Contributor

Billy

Posted
Posted (edited)

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 by Billy (see edit history)
Link to comment
Share on other sites
Masteries Newbie

Masteries

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
  • 2 weeks later...
  • 1 month later...
  • 4 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...