Outils pour audit sécurité suite piratage exploitant une faille script PHP

Gérald Niel a écrit :

Suite à une négligence de ma part le serveur web a été victime d'une
attaque exploitant une faille du script phpMyAdmin et des fichier ont
été écrit dans le répertoire de ce script.

La première chose que je vois (outre le fait d'avoir des paquets à jour
régulièrement de manière automatique):
- vérifier la conf de PHP (allow_url_include = Off, register_globals =
Off, enable_dl = Off, par exemple)
- vérouiller les droits des répertoires "data" du serveur web en non
executable, non suid (je suppose que c'est possible sous BSD), si aucun
script ne nécessite de flag "executable" ; cela permet de limiter un peu
les ennuis en cas de faille (on ne peut pas copier de shell dedans, par
exemple) - idem pour tout ce qui n'est pas utile (un /tmp en noexec est
tentant, mais cela peut poser des soucis à certains scripts, à vérifier)
- accessoirement coller toute partition qui n'a pas besoin de droits en
écriture en "read-only" (typiquement, je le fais pour ce qui héberge
/lib, /usr, /bin, /etc, etc.)
- filtrer les services sensibles (phpmyadmin..) via le firewall, sur
quelques IP autorisées

Bon évidemment tout cela n'est pas suffisant pour éviter les ennuis,
mais cela rend la tâche plus ardue pour le script kiddie qui en règle
générale se contente de (péniblement) utiliser des exploits que d'autres
ont écrit.

Je souhaiterais auditer plus avant le système bien que théoriquement
l'attaque ne devrait pas avoir débordé du serveur web et de la faille
du script PHP.

Pas facile après coup.. si on suit les procédures classiques, le serveur
devrait être réinstallé entièrement, mais c'est peut être trop
contraignant ici :)
(en théorie aussi, un backup quotidien pourrait rsync'er le jail a
l'extérieur ; par exemple dans un autre jail ; en espérant que le backup
ne date pas d'après la faille)

D'autre part afin d'être un peu plus réactif, puisque c'est mon
fournisseur de service qui m'a informé du piratage du serveur suite à
une pleinte, quelles sont les méthode pour surveiller au quotidien
l'activité d'un serveur web, et en particulier des scripts ?

AIDE ("Advanced intrusion detection environment") est pas mal pour avoir
des rapports en cas de modification "non attendue" des filesystem (voir
petit topo http://www.hsc.fr/ressources/breves/aide.html.fr)

Il y a sûrement pas mal d'autres trucs a ajouter, mais c'est un petit début.

Xavier Roche a écrit :
[...]

Bon évidemment tout cela n'est pas suffisant pour éviter les ennuis,
mais cela rend la tâche plus ardue pour le script kiddie qui en règle
générale se contente de (péniblement) utiliser des exploits que d'autres
ont écrit.

Vérifier aussi la base de donnée s'il y en a une ;)

L'ennui sur de l'hébergé est qu'on ne maîtrise pas forcément tous les
paramètres de l'install : est-ce toi qui gère entièrement le serveur ou
est-ce un pré-installé où tu as seulement accès par ftp ?

Autrement dit, peux-tu vérifier les paramètres de php and Co ? Si oui,
les conseils de Xavier sont de bon sens, sinon, tu vas avoir du mal à
sécuriser totalement ton serveur et hormis blinder tes scrpts php contre
les XSS et autres attaques du même style, tu ne peux pas grand-chose (à
part prévenir ton hébergeur si tu t'aperçois que son install de php est
moisie, par exemple :)

Je souhaiterais auditer plus avant le système bien que théoriquement
l'attaque ne devrait pas avoir débordé du serveur web et de la faille
du script PHP.

Pas facile après coup.. si on suit les procédures classiques, le serveur
devrait être réinstallé entièrement, mais c'est peut être trop
contraignant ici :)

L'un n'empêche pas l'autre : tu peux très bien procéder à un backup
total de la machine avant de la réinstaller de A à Z et voir par
quelle(s) faille(s) s'est introduit le pirate. C'est même plutôt
conseillé d'agir sur un backup pour l'audit... Ou dans ton cas, un
backup du backup : comme ça, en cas de soucis (mauvaise manipulation,
plainte après coup, etc.), il te reste une preuve de ta bonne foi. Et
cela peut également te servir si, par hasard, tu souhaites déposer une
plainte en bonne et due forme (oui, je suis un doux rêveur :D

De toute manière, je ne saurais trop te conseiller un formatage et
réinstallation complète : changer les mots de passe ne servira pas à
grand-chose si tu ne sais pas l'origine de l'intrusion => rien ne dit
que tu n'as pas pris un rootkit au passage.

(en théorie aussi, un backup quotidien pourrait rsync'er le jail a
l'extérieur ; par exemple dans un autre jail ; en espérant que le backup
ne date pas d'après la faille)

Si la machine qui sert de serveur rsync est sur une autre machine,
pourquoi pas ? Mais sur le même serveur, j'avoue que je suis
dubitatif... Même s'il n'est pas facile de sortir d'un jail, ce n'est
pas pour autant impossible, alors, tant qu'à être parno, autant l'être
complètement et ne pas mettre tous ses oeufs dans le même serveur.

AIDE ("Advanced intrusion detection environment") est pas mal pour avoir
des rapports en cas de modification "non attendue" des filesystem (voir
petit topo http://www.hsc.fr/ressources/breves/aide.html.fr)

AIDE est bien, à condition d'ajouter au moins un zéro au nombre de
lignes par défaut du message quotidien ;) Et, sur un serveur chargé
(pleins de services), les logs peuvent être très lourds (et très long :
sur ma machine perso, il peine à analyser mes disques => 80Go (système)
+ 160 Go (home) + 1 To Sata2 (/srv) 4 DD externes (2 X 160 Go + 250 Go +
300G). Aucun des disques n'est plein à plus de 50% mais l'analyse dure
plus de 24H. En désactivant la recherche sur les disques externes, ça
tombe en-dessous de 24H mais les mises-à-jour d'AIDE (sur debian) me
réactivent régulièrement la config par défaut (ça ne devrait pas
normalement, mais j'avoue n'avoir pas trouvé le temps de chercher d'où
provient ce désagrément - mineur puisque c'est une machine
essentiellement bureautique et tests divers ;)

Pour les logs, il y a logcheck qui est bien et qu'on peut configurer
assez finement. Ensuite, pas mal d'outils existent, mais tout dépend de
ton usage et de tes besoins, en fait : pour empêcher les intrus sur SSH,
j'utilise le duo fail2ban/denyhosts (fail2ban n'agit pas que sur SSH : à
configurer selon ses besoins)

Quelques pistes de plus pour toi, en espérant que ça t'aide un peu à y
voir plus clair :)

--
Claude

Le Samedi 15 août 2009 à 16:10 UTC, claude écrivait sur
fr.comp.securite :

Vérifier aussi la base de donnée s'il y en a une ;)

Evidement. Mais de ce coté pas de soucis.

L'ennui sur de l'hébergé est qu'on ne maîtrise pas forcément tous les
paramètres de l'install : est-ce toi qui gère entièrement le serveur ou
est-ce un pré-installé où tu as seulement accès par ftp ?

C'est un serveur que j'administre. C'est un dédié low cost. Avant
c'était @home.

Autrement dit, peux-tu vérifier les paramètres de php and Co ?

Quand je paralis de néglidence de ma part, ça commence par la
configuration de PHP.

L'un n'empêche pas l'autre : tu peux très bien procéder à un backup
total de la machine avant de la réinstaller de A à Z et voir par
quelle(s) faille(s) s'est introduit le pirate.

C'est bien une faille de PHP (lié donc à ma négligence) et à
phpMyadmin qui a été utilisé pour ce faire.
Je peux poster les logs du serveur web, j'y ai les traces.

Si la machine qui sert de serveur rsync est sur une autre machine,
pourquoi pas ? Mais sur le même serveur, j'avoue que je suis
dubitatif... Même s'il n'est pas facile de sortir d'un jail, ce n'est
pas pour autant impossible, alors, tant qu'à être parno, autant l'être
complètement et ne pas mettre tous ses oeufs dans le même serveur.

Certes, mais là ça commence à avoir un coût non négligeable.
Je vais toutefois me pencher sur le sujet. Jusqu'à présent je ne
sauvegardait que la config, et le spool du serveur news ainsi que les
comptes mail.

Pour les logs, il y a logcheck qui est bien et qu'on peut configurer
assez finement.

Merci, je vais regarder de ce coté.

@+
--
Gérald Niel
<http://news.gegeweb.org>
Gleb Bones : <http://www.jamendo.com/fr/album/46018>

Gérald Niel a écrit :
[...]

C'est bien une faille de PHP (lié donc à ma négligence) et à
phpMyadmin qui a été utilisé pour ce faire.
Je peux poster les logs du serveur web, j'y ai les traces.

En ce qui me concerne, c'est pas la peine : j'y comprendrais pas
grand-chose... Je ne suis pas spécialiste de la sécurité ;)

Certes, mais là ça commence à avoir un coût non négligeable.
Je vais toutefois me pencher sur le sujet. Jusqu'à présent je ne
sauvegardait que la config, et le spool du serveur news ainsi que les
comptes mail.

Tu peux très bien faire un rsync de ta machine @home et y récupérer les
logs : en prenant le temps de bien configurer logrotate et en remplaçant
syslog (si c'est ce que tu utilises) par syslog-ng ou mieux rsyslog
(rsyslog est devenu le standard sur debian et je m'en tire mieux avec sa
syntaxe - et sa doc - qu'avec syslog-ng), tu peux aussi récupérer tous
les logs @home : ça ne réduit pas le risque de compromission, mais la
détection sera facilité. Et, pour un pirate éventuel, ce sera plus
difficile de dissimuler ses traces.

--
Claude

Le 13-08-2009, Gérald Niel <gerald.niel+spam@gegeweb.invalid> a écrit :

j'administre un serveur dédié sur lequel tourne plusieurs services
dont certains hebergés dans une jail sous FreeBSD 7.
Suite à une négligence de ma part le serveur web a été victime d'une
attaque exploitant une faille du script phpMyAdmin et des fichier ont
été écrit dans le répertoire de ce script. C'est le serveur web
tournant dans une jail qui a été victime de cette attaque (c'est
ns.grisbi.org).
Je souhaiterais auditer plus avant le système bien que théoriquement
l'attaque ne devrait pas avoir débordé du serveur web et de la faille
du script PHP.
J'avoue être un peu pris au dépourvu (et quelque peu ignorant de
certains aspects lié à la sécurité) et souhaiterais des conseils sur
les outils à utiliser, les fichier logs à surveiller

Je pense qu'en priorité, tu devrais analyser le fichier de log
apache afin de savoir à quelle heure et quel jour il est entré. Ca
te donnera une idée du temps que le pirate a pu passer sur ta machine.
Si apache est paramétré pour enregistrer dans les logs les referrer,
essayes de voir d'ou est arrivé le pirate.
Si c'est un kiddie, alors tu auras sans doute en referrer une page google.
A l'aide de celui-ci, reprends la même recherche que lui et
va visiter les autres sites. Sans doute en trouveras tu d'autre piraté.
Ceci te permettra de cibler ce que fait le pirate. Tu auras peut
être un blog ou un admin qui fera un compte rendu de l'attaque qu'il
aura subi, te permettant ainsi de creuser certains points.

Une fois que tu as vu le log apache, essayes de voir ce qu'il a fait
et surtout comment il est rerentré sur ton serveur après son premier
passage. Si c'est toujours par le web, consultes les logs pour retracer
son parcours.

et tout ce qui
pourrait m'aider à vérifier que ça n'a pas débordé hors du serveur web.

D'abord faire une vérif anti-rootkits, ensuite utiliser les outils sains
pour trouver les fichiers nouvellement créés, les connexions réseaux,
les processus lancés, etc.

D'autre part afin d'être un peu plus réactif, puisque c'est mon
fournisseur de service qui m'a informé du piratage du serveur suite à
une pleinte, quelles sont les méthode pour surveiller au quotidien
l'activité d'un serveur web, et en particulier des scripts ?

Pas d'idée la dessus.
--
Kevin

Le Vendredi 14 août 2009 à 07:04 UTC, Xavier Roche écrivait sur
fr.comp.securite :

La première chose que je vois (outre le fait d'avoir des paquets à jour
régulièrement de manière automatique):

C'est déjà le cas. J'ai portaudit qui tourne, je fait un portsnap
qotidien. Il n'y a que la mise à jour des paquets que je ne fais pas
automatiquement.

- vérifier la conf de PHP (allow_url_include = Off, register_globals =
Off, enable_dl = Off, par exemple)

Comme je le disais, c'est une négligence de ma part. Avec en plus une
erreur de débutant à savoir avoir nommé le répertoire où se trouvait
le script 'phpmyadmin' et ne pas effacer le script de configuration.
C'est visiblement un robot qui est tombé dessus. Donc si ça peut
servir à d'autres : éviter de nommer de manière trop évidente ces
répertoires servant à administrer divers services, et surtout une foi
la conf effectuée, supprimer les scripts qui doivent l'être.

- vérouiller les droits des répertoires "data" du serveur web en non
executable, non suid (je suppose que c'est possible sous BSD), si aucun
script ne nécessite de flag "executable" ; cela permet de limiter un peu
les ennuis en cas de faille (on ne peut pas copier de shell dedans, par
exemple) - idem pour tout ce qui n'est pas utile (un /tmp en noexec est
tentant, mais cela peut poser des soucis à certains scripts, à vérifier)

Les répertoires ont déjà des permissions limitées, je vais voir pour
le bit nonsuid, merci.

- filtrer les services sensibles (phpmyadmin..) via le firewall, sur
quelques IP autorisées

En effet, c'est ce que j'aurais dût faire...

Pas facile après coup.. si on suit les procédures classiques, le serveur
devrait être réinstallé entièrement, mais c'est peut être trop
contraignant ici :)

Pas forcément, ça tourne dans une jail. Donc même si je n'ai que la
conf de sauvegardé, je peux remonter une jail à coté.

AIDE ("Advanced intrusion detection environment") est pas mal pour avoir
des rapports en cas de modification "non attendue" des filesystem (voir
petit topo http://www.hsc.fr/ressources/breves/aide.html.fr)

Merci, je vais regarder ça.
Sinon j'ai fait tourner tkhunter et chkrootkit sur l'hôte, rien à
signaler à priori. Pas réussis à installer tkhunter dans la jail
n'ayant pas accès aux sources (entre autres) depuis la jail.
chkrootkit a trouvé les fichier php concerné par l'intrusion, rien
d'autre à priori.

@+
--
Gérald Niel
<http://news.gegeweb.org>
Gleb Bones : <http://www.jamendo.com/fr/album/46018>

Gérald Niel a écrit :

- vérouiller les droits des répertoires "data" du serveur web en non
executable, non suid (je suppose que c'est possible sous BSD)

Les répertoires ont déjà des permissions limitées, je vais voir pour
le bit nonsuid, merci.

Je parlais des options de montage et non des doits en fait,
contrairement à ce que ma phrase ambigüe pouvait indiquer.

Xavier Roche :

Gérald Niel a écrit :

Suite à une négligence de ma part le serveur web a été victime d'une
attaque exploitant une faille du script phpMyAdmin et des fichier ont
été écrit dans le répertoire de ce script.

La première chose que je vois (outre le fait d'avoir des paquets à jour
régulièrement de manière automatique):
- vérifier la conf de PHP (allow_url_include = Off, register_globals =
Off, enable_dl = Off, par exemple)

Applquer le patch suhosin aussi (le port FreeBSD indique des problèmes
dans des jails mais j'ai jamais eu de soucis).

Je dirais qu'il faut éviter php autant que possible, mais bon.

(un /tmp en noexec est tentant, mais cela peut poser des soucis à certains scripts, à
vérifier)

Ça pose des soucis dans /tmp pour les scripts d'installation des ports.

- accessoirement coller toute partition qui n'a pas besoin de droits en
écriture en "read-only" (typiquement, je le fais pour ce qui héberge
/lib, /usr, /bin, /etc, etc.)

Sous FreeBSD, chaque jails a son propre "securelevel", ce qui permet
d'appliquer des attributs de fichiers comme le flag immuable qu'un root
dans une jail ne pourra pas enlever. Tout en gardant la possibilité de
le faire à partir de l'hôte pour les mises à jours.

- filtrer les services sensibles (phpmyadmin..) via le firewall, sur
quelques IP autorisées

Je compte le traffic IP sur chaque jail, comme ça je vois d'un
coup d'½il si il y a des problèmes (FTP troué, Feed de news qui
déconne...)

AIDE ("Advanced intrusion detection environment") est pas mal pour avoir
des rapports en cas de modification "non attendue" des filesystem (voir
petit topo http://www.hsc.fr/ressources/breves/aide.html.fr)

On a mtree(8).