0

Assume there's a website built with some FOSS CMS (like Drupal) and the websites' directory is owned and grouped by root (instead www-data as common in Apache in Nginx) and a friend of the site's owner mistakenly sees that and tells the owner:

Beware that if an hacker finds a way to inject shell code through inodes in that sites directory it could destroy your server and this code will run without problem because the inodes are are owned and grouped by root.

I wonder if such "shell scripting injection" attack even possible.

Let's even assume the owner now creates a usual user like (say, by the name of "Boobinio") and runs:

chown boobinio /var/www/html/mysite -R && chgrp boobinio /var/www/html/mysite

I still can't see how it fully protects the owner because if the hacker knows this user "boobinio" (and I guess there are several ways to discover it) then it could try to inject shell code when it's plausible that the owner is in active sudo, and then, where's the total difference between this case, to a case of shell injection when the owner is in active root?

My question:

If I'm accurate in what I just described, what can anyone do to ensure not to have shell injections on the CMS when either working as active sudo or active root?

  • 2
    I don't understand the attack. Does the attacker create a new file containing bash code? How is this then executed? – Sjoerd Jan 03 '17 at 09:04
  • From what I could grasp on the discussion on this in a Hebrew Facebook group the attack is this: An hacker manages in some way to execute a command on the webserver after finding a breakage in the website and thus destroyed the server. –  Jan 03 '17 at 09:08

2 Answers2

3

AFAIK, it does not matter what the owner of group of files is (unless they are setuid). What matters is that this is a hint that the application could be run as root which is a security threat.

The rules are:

  • the web application should be runned as a non priviledged user - in particular, that user should never be allowed to sudo!
  • it should only have write access to the files this must be written or changed by the application
  • all other files (static) should only be readable and should belong to another (admin) user
Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • F. Hauri gave a good remark about the `www-data` user common for Apache and Nginx as for 2018. This user especially shouldn't have `sudo`. –  Nov 25 '18 at 14:30
1

  1. The fact a directory or a file is owned by root don't give root privilege to people who access them. (Unless suid bit are set). Having files and directories owned by root ensure nothing won't be written by another user, unless changing permission to 777 (full permissions for everybody).

  2. The user who serve web (mostly www-data through any webserver) must not be able to run sudo! I they just could read some dirs and files, this must be enough.

  3. As is know for regular security flaw, you have to use another (like csh, dash or even ksh) as default shell (link to /bin/sh).

Some refresh about files and directories permissions:

drwxrwxrwx

There is a 1st sign that could be - for a file, d for a directory, l for a symlink, b for a block device or c for a character device.

Then 3 group of 3 signs

Type User Group Other
   d  rwx   rwx   rwx

For each group:

  • r mean file or directory is readable by [User,Group,Anybody]
  • w mean file or directory is writeable by [User,Group,Anybody]
  • x mean file is executable by ... or mean directory is accessible by ...

So, for sample:

drwxr-xr-x /var
drwxr-xr-x /var/www
drwx--x--x /var/www/mysite
-rw-r--r-- /var/www/mysite/myfile.txt

Anybody would by able to read myfile.txt, but won't be able to

  • modify this file
  • execute this file (exept for php under web server)
  • delete this file
  • read, modify or delete the directory mysite. (so accessing /var/www/mysite/myhidden-dc22e606-a281-410c-be4f-df6b2ea175d9.txt is reserved... Care to only use https for this kind of tricks.)

Care about setuid and setgid bits, have a look at GNU/Linux Command-Line Tools Summary / File Permissions

F. Hauri - Give Up GitHub
  • 4,597
  • 2
  • 19
  • 32