Protezione completa da iniezioni di script di shell (come una "Iniezione di Bash") - È persino possibile?

Naviga le tue risposte
0

Supponiamo che ci sia un sito web creato con alcuni CMS FOSS (come Drupal) e la directory dei siti web è di proprietà e raggruppata da root (invece www-data come comune in Apache in Nginx) e un amico del proprietario del sito vede erroneamente e dice al proprietario:

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.

Mi chiedo se un tale "injection scripting injection" attacchi anche possibile.

Supponiamo anche che il proprietario ora crei un utente normale come (ad esempio, con il nome di " Boobinio ") ed esegue: 

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

Non riesco ancora a vedere come protegge completamente il proprietario perché se l'hacker conosce questo utente "boobinio" (e immagino che ci siano diversi modi per scoprirlo) allora potrebbe provare a iniettare il codice shell quando è plausibile che il il proprietario è in sudo attivo e quindi, dov'è la differenza totale tra questo caso, in un caso di iniezione della shell quando il proprietario si trova in root attiva ?

La mia domanda:

Se sono preciso in ciò che ho appena descritto, cosa può fare chiunque per assicurarsi di non avere iniezioni di shell sul CMS quando funzionano come sudo attivo o root attivo?

    
posta JohnDoea 03.01.2017 - 09:01
fonte

2 risposte

3

AFAIK, non importa quale sia il proprietario del gruppo di file (a meno che non siano setuid). Ciò che importa è che questo è un suggerimento che l'applicazione possa essere eseguita come root che è una minaccia alla sicurezza.

Le regole sono:

  • l'applicazione web deve essere eseguita come utente non privilegiato, in particolare, a quell'utente non dovrebbe mai essere permesso di sudo!
  • dovrebbe avere solo accesso in scrittura ai file che deve essere scritto o modificato dall'applicazione
  • tutti gli altri file (statici) dovrebbero essere leggibili e dovrebbero appartenere a un altro utente (amministratore)
risposta data 03.01.2017 - 10:08
fonte
1

  1. Il fatto che una directory o un file sia di proprietà di root non dà il privilegio di root alle persone che vi accedono. (A meno che non sia impostato il bit suid ). Avere file e directory di proprietà di root garantisce che nulla venga scritto da un altro utente, a meno che non si modifichi l'autorizzazione su 777 (autorizzazioni complete per tutti).

  2. L'utente che serve web (principalmente www-data attraverso qualsiasi server web) non deve essere in grado di eseguire sudo ! Ho appena potuto leggere alcuni file e dirs, questo deve essere sufficiente.

  3. Poiché bash è noto per difetti di sicurezza regolari, tu devi usare un'altra shell (come csh , dash o anche ksh ) come shell di default (link a /bin/sh ).

Alcuni aggiornamenti su autorizzazioni per file e directory: 

drwxrwxrwx

C'è un primo segno che potrebbe essere - per un file, d per una directory, l per un link simbolico, b per un dispositivo a blocchi o c per un dispositivo a carattere.

Quindi 3 gruppi di 3 segni 

Type User Group Other
   d  rwx   rwx   rwx

Per ogni gruppo:

  • r significa che il file o la directory sono leggibili da [Utente, Gruppo, Nessuno]
  • w significa che il file o la directory sono scrivibili da [Utente, Gruppo, Nessuno]
  • Il file medio di x è eseguibile da ... o la directory media è accessibile da ...

Quindi, per esempio: 

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

Chiunque è in grado di leggere myfile.txt , ma non sarà in grado di

  • modifica questo file
  • esegui questo file (eccetto per php sotto server web)
  • cancella questo file
  • leggi, modifica o cancella la directory mysite . (quindi l'accesso a /var/www/mysite/myhidden-dc22e606-a281-410c-be4f-df6b2ea175d9.txt è riservato ... Attenzione a usare solo https per questo tipo di trucchi.)

Prenditi cura di setuid e setgid bit, dai un'occhiata a GNU / Linux Strumenti da riga di comando Riepilogo / autorizzazioni file

    
risposta data 03.01.2017 - 11:09
fonte

Leggi altre domande sui tag

Captcha è l'unica cosa che impedisce la creazione infinita di account Se faccio il backup dei miei file su "The Cloud", saranno conservati lì per sempre? [chiuso]