All my wordpress were exposed & get hacked

Discussion in 'Installation/Configuration' started by 1337isp, Sep 23, 2020.

  1. 1337isp

    1337isp New Member


    I just want to share my story here to warn you guys & let you secure your infrastructure (if you didn't notice this problem already).

    On 12 September one of my client's wordpress was hacked through the 0 day of wp-file(fail)-manager (CVE-2020-25213).
    Attacker was able to upload a .php file & take control of the website.

    The worst part is on 21 September when the attacker was able to read other wp-config.php.
    Reason of this was because by default APS set wordpress wp-config.php to 744 instead of 440 attacker was able to read it & inject backdoor in all my wordpress website thought hacked websites directly to the database.

    I had noticed that the attacker use one shell user to launch 2 commands (find & pwd)

    Unfortunately i didn't have enough backup retention to come back before the hack, so all wordpress are infected (even i remove backdoor) & potentially hackable.

    350 000 users of wp-file-manager are potentially exposed and worst if they are using ispconfig with a wordpress installed through aps installer.

    I have warned the support & I'm going to make a check with schaal it.
    Stay safe!
    Taleman likes this.
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    The permissions you suggest will not protect you from such an attack, which is not ISPConfig specific or caused by ISPConfig btw., its just an attack against wp-file manager, so any site hosted on any server with any control panel is affected in the same way. If a PHP file shall be readable for a specific website user only, then the permissions must be set so that only this user and not the group or other users can read it. Means 0400 or 0600 or 0700 is ok, but the 440 that you suggested is not ok as it will give access to other sites in case the user is able to break out of the open basedir restriction. Your issue is probably not only caused by the file permissions, you probably have exec functions enabled in PHP as the user would have been kept in his website.

    That's what I mentioned with PHP exec functions, but that's not using a shell user, it's just a command that got executed because you configured PHP to allow that.
    ahrasis likes this.
  3. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    Command to examine the permissions of wp-config.php file in your ISPConfig host:
    find /var/www/clients -name wp-config.php -exec ls -lh {} \;
    On my host the permissions are mixed, but there are lots of them with -rw-rw-rw- so other has both read and write.
    Should those permissions be changed with o-rw?
  4. 1337isp

    1337isp New Member

    I mistaked i actually put 400 on all my wp-config.

    From official wordpress doc (cannot post link here)

    "All files should be 644 or 640. Exception: wp-config.php should be 440 or 400 to prevent other users on the server from reading it."
  5. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    On one ISPConfig hosted machine:
    # find /var/www/clients -name wp-config.php -exec ls -lh {} \;
    -rw-rw-rw- 1 web261 client1 3,1K heinä 22 16:43 /var/www/clients/client1/web261/web/wp-config.php
    -rw-rw-rw- 1 web267 client1 3,1K elo   31 17:30 /var/www/clients/client1/web267/web/wp-config.php
    -rw-r--r-- 1 web193 client1 3,0K huhti 10  2018 /var/www/clients/client1/web193/web/wp-config.php
    -rw-rw-rw- 1 web253 client1 3,3K touko 22 16:19 /var/www/clients/client1/web253/web/wp-config.php
    -rw-rw-rw- 1 web235 client1 3,1K heinä  9  2019 /var/www/clients/client1/web235/web/wp-config.php
    -rw-rw-rw- 1 web254 client1 3,1K touko 28 13:10 /var/www/clients/client1/web254/web/wp-config.php
    -rw-rw-rw- 1 web262 client1 3,1K elo   26 13:14 /var/www/clients/client1/web262/web/wp-config.php
    -rw-rw-rw- 1 web213 client1 3,0K loka  18  2018 /var/www/clients/client1/web213/web/wp-config.php
    -rw-rw-rw- 1 web257 client1 3,1K kesä   5 13:48 /var/www/clients/client1/web257/web/wp-config.php
    -rw-r----- 1 web243 client1 3,8K loka  16  2019 /var/www/clients/client1/web243/web/wp-config.php
    -rw-rw-rw- 1 web227 client1 3,1K huhti 24  2019 /var/www/clients/client1/web227/web/wp-config.php
    -rw-r--r-- 1 web229 client1 3,1K touko  3  2019 /var/www/clients/client1/web229/web/wp-config.php
    -rw-rw-rw- 1 web234 client1 3,1K heinä  3  2019 /var/www/clients/client1/web234/web/wp-config.php
    -rw-rw-rw- 1 web248 client1 3,1K helmi  7  2020 /var/www/clients/client1/web248/web/wp-config.php
    -rw-rw-rw- 1 web216 client1 3,2K joulu 12  2018 /var/www/clients/client1/web216/web/wp-config.php
    Strange those permissions are so willy nilly. All Worpress I have installed are by the usual WP installer, and that is what I believe makes the permissions to those files. Some users may have installed their WP by some other means. Ore maybe the editor changes permissions when modifying wp-config.php?
    All wordpress sites work, even the one with least permissions -rw-r-----
  6. nhybgtvfr

    nhybgtvfr Well-Known Member HowtoForge Supporter

    i put the real wp-config.php file in /private.

    the wp-config.php in /web contains:
    include __DIR__ . '../../private/wp-config.php';
    i also put this in .htaccess in /web:
    <files wp-config.php>
    order allow,deny
    deny from all
    ahrasis and Jesse Norell like this.
  7. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    Thanks for sharing the info and awareness, @1337isp. There are definitely things you can do to improve the situation to limit the damage from cross-site access. There's lots of info on server and network security about, so I'll just make some comments pertaining specifically to ISPConfig servers.

    For wordpress specifically, I fix permissions on wp-config.php and check for world writable files and directories with a cronjob. Note that much of the advise you get on what permissions "should" be can be wrong, even official recommendations. Plugins/themes often create files and directories insecurely, probably ignorantly, rather than the cynical possibility of trying to reduce support for the plugin/theme author to have to understand a setup and do things correctly (which admittedly isn't always clear/easy), so you need to continue to check for them. You can limit routes for some damage done via .htaccess file directives (on apache), and use wordfence and other tools to help with attacks. There's lots of info on wordpress security about...

    For php apps in general on an ISPConfig system, use php-fpm mode (with suexec enabled). In the upcoming 3.2 release and maybe latest 3.1, you can have the php-fpm daemon chroot to the website root folder, which will add another layer of protection that helps a bunch in cross-account issues like that. Be sure open_basedir is set to something sane. Disable all dangerous functions you can; admittedly, it's hard to run a wordpress site with them all disabled, as plugins/themes update and such, but you can disable most of the dangerous ones at least.

    Ensure any shell users you have are setup with chroot (via jailkit), as are any cronjobs you allow (or better, just limit to url cron jobs).

    In your server design, running multi-server is more secure. Use a dedicated control panel node, and separate other services to different servers (eg. mail separate from web). Of course "have a good backup strategy" pretty much goes without saying, but if you use ISPConfig's website/database/email backups, you might consider saving on remote storage (in a secure manner).

    You might look at ISPProtect to scan servers (I've not used it myself, but it sounds like it finds more than a free alternative like maldet+clamav), and run a virus scanner (I use maldet+clamav with multiple signature sources).
    Gwyneth Llewelyn likes this.

Share This Page