Quels sont les risques de sécurités connus si on utilise plusieurs
VHosts avec plusieurs "oscommerce" dessus?
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Entre elles, mais vraiment strictement entre elles, c'est pas mon problème. Mon problème c'est quand ça touche au système.
Même vis à vis d'autres sites, de plus tout comportement anormal suite à un hack sera bien plus facile à localiser (la création des fichiers aura l'uid/gid de l'utilisateur et non d'apache, etc... Dans un /tmp justement ca permet de repérer le problème au premier coup d'oeil.
Bon... déjà on va essayer de trouver un moyen se créer une /tmp et /var/tmp montée en noexec, sur un serveur distant, en minimisant les pertes de données...
Attention certains serveurs utilisent /tmp et ont besoin d'y exécuter des choses (à vérifier donc en testant). Personnellement j'utilise souvent les droits suivants sur /tmp :
drwx-wx-wt 4 root root 80 fév 20 23:21 tmp
Mon truc de "pscan" n'aurai pas _facilement_ pu s'executer si j'avais une partition /tmp noexec.
Il ne faut pas oublier les classiques comme /var/tmp ou encore /dev/shm qui sont des lieux de prédilection pour ce genre d'utilisation abusive.
Entre elles, mais vraiment strictement entre elles, c'est pas mon
problème.
Mon problème c'est quand ça touche au système.
Même vis à vis d'autres sites, de plus tout comportement anormal suite à un
hack sera bien plus facile à localiser (la création des fichiers aura
l'uid/gid de l'utilisateur et non d'apache, etc... Dans un /tmp justement
ca permet de repérer le problème au premier coup d'oeil.
Bon... déjà on va essayer de trouver un moyen se créer une /tmp et
/var/tmp montée en noexec, sur un serveur distant, en minimisant les
pertes de données...
Attention certains serveurs utilisent /tmp et ont besoin d'y exécuter des
choses (à vérifier donc en testant). Personnellement j'utilise souvent les
droits suivants sur /tmp :
drwx-wx-wt 4 root root 80 fév 20 23:21 tmp
Mon truc de "pscan" n'aurai pas _facilement_ pu s'executer si j'avais une
partition /tmp noexec.
Il ne faut pas oublier les classiques comme /var/tmp ou encore /dev/shm qui
sont des lieux de prédilection pour ce genre d'utilisation abusive.
Entre elles, mais vraiment strictement entre elles, c'est pas mon problème. Mon problème c'est quand ça touche au système.
Même vis à vis d'autres sites, de plus tout comportement anormal suite à un hack sera bien plus facile à localiser (la création des fichiers aura l'uid/gid de l'utilisateur et non d'apache, etc... Dans un /tmp justement ca permet de repérer le problème au premier coup d'oeil.
Bon... déjà on va essayer de trouver un moyen se créer une /tmp et /var/tmp montée en noexec, sur un serveur distant, en minimisant les pertes de données...
Attention certains serveurs utilisent /tmp et ont besoin d'y exécuter des choses (à vérifier donc en testant). Personnellement j'utilise souvent les droits suivants sur /tmp :
drwx-wx-wt 4 root root 80 fév 20 23:21 tmp
Mon truc de "pscan" n'aurai pas _facilement_ pu s'executer si j'avais une partition /tmp noexec.
Il ne faut pas oublier les classiques comme /var/tmp ou encore /dev/shm qui sont des lieux de prédilection pour ce genre d'utilisation abusive.
Si quelqu'un est admin sur son OsCommerce, il peut browser tous les fichiers en lecture du file-system et uploader/créer des fichiers partout où il a des droits d'écriture (pas seulement dans son espace, hein, *partout* où il a les droits donc y compris /tmp la plupart du temps).
Oui dans le cas ou php, etc... est configuré avec les droits qui le permettent. Il est possible également de restreindre tout ca. Cela dit posséder les droits de l'utilisateur ne doit pas crée de problème sur le système.
Restreindre l'exécution sur /tmp ne sera de toute façon pas suffisant, il faudrait aussi le faire dans les web-roots. Sinon, le scénario est facile à écrire : upload de nc, upload d'un local r00t, upload d'un phpshell, et hop, on se retrouve avec un reverse-shell root ;-) A partir de là, suExec ou pas ...
Cela sous entends que le système est rootable facilement avec un shell, ce qui ne doit pas être le cas lorsque le shell est une fourniture standard livrée avec l'hébergement.
Si quelqu'un est admin sur son OsCommerce, il peut browser tous les
fichiers en lecture du file-system et uploader/créer des fichiers partout
où il a des droits d'écriture (pas seulement dans son espace, hein,
*partout* où il a les droits donc y compris /tmp la plupart du temps).
Oui dans le cas ou php, etc... est configuré avec les droits qui le
permettent. Il est possible également de restreindre tout ca. Cela dit
posséder les droits de l'utilisateur ne doit pas crée de problème sur le
système.
Restreindre l'exécution sur /tmp ne sera de toute façon pas suffisant,
il faudrait aussi le faire dans les web-roots. Sinon, le scénario est
facile à écrire : upload de nc, upload d'un local r00t, upload d'un
phpshell, et hop, on se retrouve avec un reverse-shell root ;-) A partir
de là, suExec ou pas ...
Cela sous entends que le système est rootable facilement avec un shell, ce
qui ne doit pas être le cas lorsque le shell est une fourniture standard
livrée avec l'hébergement.
Si quelqu'un est admin sur son OsCommerce, il peut browser tous les fichiers en lecture du file-system et uploader/créer des fichiers partout où il a des droits d'écriture (pas seulement dans son espace, hein, *partout* où il a les droits donc y compris /tmp la plupart du temps).
Oui dans le cas ou php, etc... est configuré avec les droits qui le permettent. Il est possible également de restreindre tout ca. Cela dit posséder les droits de l'utilisateur ne doit pas crée de problème sur le système.
Restreindre l'exécution sur /tmp ne sera de toute façon pas suffisant, il faudrait aussi le faire dans les web-roots. Sinon, le scénario est facile à écrire : upload de nc, upload d'un local r00t, upload d'un phpshell, et hop, on se retrouve avec un reverse-shell root ;-) A partir de là, suExec ou pas ...
Cela sous entends que le système est rootable facilement avec un shell, ce qui ne doit pas être le cas lorsque le shell est une fourniture standard livrée avec l'hébergement.
Si quelqu'un est admin sur son OsCommerce, il peut browser tous les fichiers en lecture du file-system et uploader/créer des fichiers partout où il a des droits d'écriture (pas seulement dans son espace, hein, *partout* où il a les droits donc y compris /tmp la plupart du temps).
Pfff... On pourra jamais être tranquille sur cette Terre. Je pense que c'est la première piste alors (cf mon "pscan" ;-) ). Sur le serveur il y a 3 instances d'oscommerce, et un petit site en php. Mais chaque admin d'oscommerce (en fait chaque admin de chaque Vhost) à un compte shell sur la machine. Il y a autant d'users que de Vhosts. Eeeeeeeeuh pourquoi? je me rappelle plus mais je pense bien que c'est pour qu'ils puissent uploader leur site facilement, en mettant leur $HOME direct dans le DocumentRoot de leur Vhost. Ils n'ont pas de shell.
Bon aller on continue à travailler.... -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Sun, 20 Feb 2005 22:44:12 +0000 ) Nicob :
Si quelqu'un est admin sur son OsCommerce, il peut browser tous les
fichiers en lecture du file-system et uploader/créer des fichiers partout
où il a des droits d'écriture (pas seulement dans son espace, hein,
*partout* où il a les droits donc y compris /tmp la plupart du temps).
Pfff... On pourra jamais être tranquille sur cette Terre.
Je pense que c'est la première piste alors (cf mon "pscan" ;-) ).
Sur le serveur il y a 3 instances d'oscommerce, et un petit site en
php.
Mais chaque admin d'oscommerce (en fait chaque admin de chaque
Vhost) à un compte shell sur la machine. Il y a autant d'users que de
Vhosts. Eeeeeeeeuh pourquoi? je me rappelle plus mais je pense bien que
c'est pour qu'ils puissent uploader leur site facilement, en mettant leur
$HOME direct dans le DocumentRoot de leur Vhost. Ils n'ont pas de shell.
Bon aller on continue à travailler....
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Si quelqu'un est admin sur son OsCommerce, il peut browser tous les fichiers en lecture du file-system et uploader/créer des fichiers partout où il a des droits d'écriture (pas seulement dans son espace, hein, *partout* où il a les droits donc y compris /tmp la plupart du temps).
Pfff... On pourra jamais être tranquille sur cette Terre. Je pense que c'est la première piste alors (cf mon "pscan" ;-) ). Sur le serveur il y a 3 instances d'oscommerce, et un petit site en php. Mais chaque admin d'oscommerce (en fait chaque admin de chaque Vhost) à un compte shell sur la machine. Il y a autant d'users que de Vhosts. Eeeeeeeeuh pourquoi? je me rappelle plus mais je pense bien que c'est pour qu'ils puissent uploader leur site facilement, en mettant leur $HOME direct dans le DocumentRoot de leur Vhost. Ils n'ont pas de shell.
Bon aller on continue à travailler.... -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Nicob
On Mon, 21 Feb 2005 18:19:19 +0000, Rakotomandimby (R12y) Mihamina wrote:
Ils n'ont pas de shell.
Euh ... c'est une façon de voir les choses. Pour moi (sauf hardening sérieux de la config), toute personne pouvant uploader en dessous de la webroot est techniquement en possession d'un shell.
Et cela est valable quelque soit le langage interprété par le serveur (PHP, ASP, JSP, ....)
Nicob
On Mon, 21 Feb 2005 18:19:19 +0000, Rakotomandimby (R12y) Mihamina wrote:
Ils n'ont pas de shell.
Euh ... c'est une façon de voir les choses. Pour moi (sauf hardening
sérieux de la config), toute personne pouvant uploader en dessous de la
webroot est techniquement en possession d'un shell.
Et cela est valable quelque soit le langage interprété par le serveur
(PHP, ASP, JSP, ....)
On Mon, 21 Feb 2005 18:19:19 +0000, Rakotomandimby (R12y) Mihamina wrote:
Ils n'ont pas de shell.
Euh ... c'est une façon de voir les choses. Pour moi (sauf hardening sérieux de la config), toute personne pouvant uploader en dessous de la webroot est techniquement en possession d'un shell.
Et cela est valable quelque soit le langage interprété par le serveur (PHP, ASP, JSP, ....)
