1

I've been asked by a customer of mine, to manage a few hundred WordPress sites.

Doing an initial security assessment, I've found that every site (350 sites) has unusual file permissions on every php file (755) that means executable bit on all groups (user, group and other)...

Trying to investigate further, I've checked umask settings and it seems ok: 0002 (that means 775 for newly created directories and 664 for files) which is the default on Linux systems.

Asking my customer about this unusual permissions, he confirmed that he wasn't aware of this issue...

Which could be the security implications of such a setting? Can this be exploited somehow by a remote user?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Roberto Jobet
  • 21
  • 2

2 Answers2

0

From what you have written, it does seem to me, this is fairly standard and not too unusual for file permissions. Compare this to other blogging websites of a similar fashion for example. I do not believe that the vulnerability is much higher than for a usual blog website or any other such similar service.

schroeder
  • 123,438
  • 55
  • 284
  • 319
rakan epicness
  • 1
-1

Any WordPress site with publicly available file-upload functionality or vulnerable plug-ins could be tricked to upload custom/malicious php-files.

If a php file's executable bits are set, then they could possibly be made to do a lot of bad things... They could be run from shell, from a script or as a cron-job.

If a second php file (containing shell-execute or filesystem functionality) is uploaded, it could change init-files or add cron-jobs for the user who owns the php/web server process and it would run when someone enters the correct URL for it in their browser.

That means their attack opens up possibilities to do anything and everything that the server and the process owner has permissions to do.

Which means it will be easy to have it hidden and to persist across reboots and service restarts...

Hardening

  • Config files containing secrets should be located outside of the document root if possible without breakage.
  • If config files must reside within document root, then re-route/block direct path http requests and restrict file permissions.
  • Remove any read/write/execute permissions that aren't required for your site to function.
  • Disable/prevent listing of directories to the world.
  • Disable execute bit on uploads with umask.
  • Limit uploads to specific file types. Identify file types by content instead of the last part of the file name.
svin83
  • 159
  • 6
  • This is overly simplistic. If the web host runs php as user, you're better off with 400, especially on config files that may contain secrets. There's no cure all when it comes to permissions, and that's essentially why we can fine tune permissions. – vidarlo Jan 08 '22 at 11:46
  • @vidarlo Yeah. You're right. Thanks for pointing it out. Better now? – svin83 Jan 11 '22 at 04:03