Re: Tentatives possible réussies attaque serveur
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02/10/2015 15:13, andre_debian@numericable.fr wrote:
> On Friday 02 October 2015 13:38:21 BERTRAND Joc3abl wrote:
>> andre_debian@numericable.fr a écrit :
>>> On Friday 02 October 2015 12:34:49 yamo' wrote:
>>>> andre_debian@numericable.fr a écrit le 02/10/2015 11:10 :
>>>>> Je reçois ce message d'alerte (logwatch), venant d'un
>>>>> serveur sous Debian : ==================== A total of 3
>>>>> possible successful probes were detected (the following
>>>>> URLs contain strings that match one or more of a listing of
>>>>> strings that indicate a possible exploit):
>>>>> /index.php?rev=../ect/passwd HTTP Response 200
>>> /index.php?rev=../../../../../../../../../../../../../../../../../..
/etc/passwd
>>>>>
>>>
HTTP Response 200
>>>>> /index.php?rev=../../../../../../../../../etc/passwd HTTP
>>>>> Response 200 ==================== Il est indiqué "3
>>>>> possible tentatives avec succès..." Y a t-il un danger que
>>>>> les mots de passe soient connus... ?
Cette alerte fait référence à une attaque nommé "Local File Inclusion".
Cette technique permet à un utilisateur mal attentionnée d'inclure dans
le contenu d'une page, soufrant de ce problème de conception, un fichier
présent sur le serveur hébergeant le site internet (Fichier Local au
serveur). Dans le cas de votre extrait de Log, le fichier qui à tenté
d'être inclut est le fichier '/etc/passwd'.
Que ces trois requêtes HTTP répondent toutes les trois le code de
réponse HTTP 200 (Code signifiant réponse HTTP réussi). Cela ne signifie
pas distinctement la réussite de l'attaque visant à accéder au fichier
'/etc/passwd' de votre serveur. En effet toute requête HTTP valide vers
une page mise à disposition par un serveur HTTP (apache, nginx, etc..)
renvoie le code 200 lorsque la page est accessible. Vulgairement, si le
fichier 'index.php' existe sur votre serveur, votre serveur répondra le
code 200 lorsqu'un utilisateur tentera d'accéder à cette page, et ce
quelque soit l'argument passé à cette page.
Dans le cas de votre log, nous voyons que les 3 requêtes relevés par
l'utilitaire 'watchlog' répondent toutes les 3 un code 200. Et c'est 3
requêtes ont à chaque fois un argument différent :
* ?rev=../ect/passwd
* ?rev=../../../../../../../../../../../../../../../../../../etc/passwd
* ?rev=../../../../../../../../../etc/passwd
La réponse d'un code de réponse HTTP 200 n'étant pas un élément
suffisant pour dire que cela est l'efficience d'une intrusion, il faut
aussi savoir que l'inclusion réussi d'un fichier ne génère aucune
erreurs. Dans ce genre de cas, l'audit, communément appeler "analyse
forensic", permettant de savoir si il y eu réellement une intrusion peut
s'avérer vraiment difficile.
Pour vous donner un ordre idée, les éléments techniques nécessaires pour
le diagnostique des 3 paragraphes ci-dessus nécessite la connaissance
des éléments suivants :
La concepts de base du protocole HTTP :
http://abcdrfc.free.fr/rfc-vf/rfc3229.html
Les concepts de base du langage PHP : http://fr.php.net/manual/fr/
Les chemins d'accès aux fichiers :
http://www.cyberciti.biz/faq/relative-pathname/
Les rudiments sur le fichier de mots de passe de Linux :
http://man7.org/linux/man-pages/man5/passwd.5.html
A votre niveau, votre extrait de log fait référence à 3 tentatives
d'inclusion de fichier avec un argument différent. Ces arguments étant
des chemin d'accès, cela laisse la chance qu'il ait un échec d'inclusion
et donc une erreur dans vos log.
L'erreur relative à l'inclusion d'un fichier, dans une configuration
conventionnel, n'est pas une réponse du protocole HTTP mais un message
générer par le moteur de script permettant la génération d'un contenu
dynamique : PHP, ASP, Python, etc...
Il est intéressant de regarder les erreurs de ce dernier afin d'avoir
une meilleur idées au sujet de l'éventuelle inclusion survenu sur votre
serveur.
Ce sont les motifs suspicieux "../" et "/etc/passwd" qui ont fait réagir
l'utilitaire 'watchlog'. Ces motifs sont des éléments rencontrés lors
d'intrusion et il est intrigant de les trouver dans une requête HTTP
conventionnelle. Je pense que ces lignes de log sont à voir comme des
éléments initiaux d'une investigation plus avancées pouvant être
décider par le responsable d'un serveur. Et cela est unique l'intêret
d'un outil d'analyse de fichier Log.
A ce niveau, cette investigation est la vérification des erreurs PHP
via le fichier 'syslog', le systéme de journal de 'systemd' ou les
logs de votre services de serveur WEB. Vous avez fait référence à
"apache" dans les messages précédant et au vu de la sortie de votre
outils d'audit de log votre moteur de script dynamique est PHP. Il
serait intéressant, dans le cas d'un désir d'investigation de votre
part, de regarder les erreurs de PHP relatives aux fonctions
d'inclusion de contenu de PHP dans le fichier de Log
'/var/log/apache/error.log'.
Je précise que la lecture des documentations ci-dessus sont
nécessaires pour cette investigation.
>>>
>>>> Les mots de passe, non, mais les logins et les mots de passe
>>>> chiffrés. Sans indiscrétion, quel est ce index.php moisi ?
>>>> Cordialement, JKB
>>>
>>> Le fichier d'index du site et pourquoi serait-il "moisi" ? p.
>>> ex : "http://trucmuche.fr/index.php?rev=kata.php";
>>
>> Ce qui m'inquiète, c'est la réponse '200' qui aurait tendance à
>> indiquer qu'un utilisateur distant peut récupérer le contenu de
>> /etc/passwd. Si c'est le cas, le fichier index.php est moisi et
>> la configuration d'apache est à revoir. La question était :
>> est-ce que le index.php est fait maison ou provient d'un logiciel
>> tiers (spip, joomla ou autre) ? JKB
>
> fait maison, c'est du classique dans les sites Web, la page
> "index.php" reçoit les contenus des autres pages.
>
J'imagine que vous faites référence à l'utilisation des fonctions
"include" ou "require" de PHP. Ces dernières sont connu pour être
sensible pour la sécurité d'un site Internet et du serveur qui l'héberge
.
> Comment faire autrement ?
Le plus sure est d'utiliser des pages statique (100% HTML) avec des
liens fixe pointant vers les pages que vous souhaitez rendre accessible
depuis votre pages.
Si vous souhaitez maintenir une technologie dynamique pour votre page
Internet, il est intéressant de connaître les risques d'implémentation
de se type de langage.
Dans le contexte de votre question, il est capitale de savoir que pour
la sécurité d'une page Internet dynamique tout les arguments passés a
une page Internet, qu'ils soit par l'URL ou par des formulaires, sont à
considérer comme potentiellement dangereux. La sécurité de toute votre
infrastructure dépends du fait qu'ils soient filtrés le plus strictement
possible.
Dans le cas de la sécurité lors d'inclusion de fichier, qui n'est qu'un
concept de sécurité des sites internet dynamique parmi plusieurs autres,
il faut que tout les tentatives d'inclusions de fichiers soit vers des
fichiers que vous avez expressément vérifié comme étant légitimes.
>
> André
>
Bonne chance
Florian.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWFAHwAAoJEBGYNnE0a7qPXqoQAJw6dcA2YDVbQeu1e7aY0et6
hOcycVGobJ7h0Uj8u8/B/j3/TkQbWxMnY6FjCkgbIJrvwlVU381pbWjNI/OCmF8X
DvCqqXViTxvkoPhInV8MWDVR/Q+S7qIKsrY60Gx4kTuEtYjSFBX20RTNlgAWRNZe
D+eEiuN+q+Kbwf3gfNhLB4vuvfrx8z49VCYDbhAqVf0HihK69o98La+QDFeD2iVI
kcE0hxsu7N6IS1SXeWpi0fv91RSZSUM1i4By9wO8O/XVfutKRhKSxNs4RIhSULGJ
VXbW3JGs4MsQic0W3BveGeq5AQ8BBJksQNZ2gAuP/OpjRB43PQKICfKh2LfQZJAv
oyhLVkhf1ANWciznxT5fF22WaQVeFdqyOcr185M+pURWcPKBoWkbFxdCI9xxnP/j
1fXg0wevTeU2oZuzDlBM65dugoWL5PZrp6BYi/70AltbLzvWj2quvMAUyFbCbfmK
LyzEKy/BikV8uj9Qf6x+HVBZQBZ3839OC44Sr6fm5QT6Ve5zYG2w13uKbCkFjPWR
Da5TPYEwceASEJqg76Uf7OS0o8tscH/EK6ihkCE/uyzqvY0vt2Kbhoc5JHtWL1/K
S07omnpJVfpFzm03XbYt0ayD8sdH65P4m1Ov59BB46pQWlV+5s8RIhkY+73jAdMi
iZLT+9rxEH2ZEtlTnUoV
=5oR5
-----END PGP SIGNATURE-----
Reply to: