Re: Tentatives possible réussies attaque serveur

[andre_debian]

On Saturday 17 October 2015 13:33:10 pmenier wrote:
> >site  fait maison, c'est du classique dans les sites Web,
> > la page "index.php" reçoit les contenus des autres pages.
> > Comment faire autrement ?

> Pour éviter ce genre d'inclusion j'utilise le module mod_security 
> d'apache2. Bien configuré il ne ralentit pas trop les accès.
> Patrick

Merci de ce rappel de module à installer.

J'ai bien dans "/etc/apache2/mods-enabled" : 
mod-security.conf & mod-security.load

Re: Tentatives possible réussies attaque serveur

[pmenier]

Le 02/10/2015 15:13, andre_deb...@numericable.fr a écrit :

On Friday 02 October 2015 13:38:21 BERTRAND Joc3abl wrote:

andre_deb...@numericable.fr a écrit :

On Friday 02 October 2015 12:34:49 yamo' wrote:

andre_deb...@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... ?



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.

Comment faire autrement ?

André



Bonjour,

Pour éviter ce genre d'inclusion j'utilise le module mod_security 
d'apache2. Bien configuré il ne ralentit pas trop les accès.


Patrick

Re: Tentatives possible réussies attaque serveur

[nathan malo]

Bonjour,

+1 pour un mod_security bien configuré, couplé à ceci c'est bien pratique !
https://github.com/derhansen/logwatch-modsec2

Cordialement,

Nathan Malo
Le 17 oct. 2015 1:33 PM, "pmenier"  a écrit :

> Le 02/10/2015 15:13, andre_deb...@numericable.fr a écrit :
>
>> On Friday 02 October 2015 13:38:21 BERTRAND Joc3abl wrote:
>>
>>> andre_deb...@numericable.fr a écrit :
>>>
 On Friday 02 October 2015 12:34:49 yamo' wrote:

> andre_deb...@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... ?
>>
>
 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.
>>
>> Comment faire autrement ?
>>
>> André
>>
>>
>> Bonjour,
>
> Pour éviter ce genre d'inclusion j'utilise le module mod_security
> d'apache2. Bien configuré il ne ralentit pas trop les accès.
>
> Patrick
>
>
>

Re: Tentatives possible réussies attaque serveur

[Eric Degenetais]

@andre, une dernière fois, au cas où:
si tu veux avoir une indication sur le succès ou non des requêtes
relevées, tente ce qui t'a été suggéré:
fais la même requête depuis ton navigateur, et vois si tu obtiens ou
non le contenu d' /etc/passwd
si oui => il y a un risque que l'attaque ait réussi
si non=> l'attaque a dû échouer

on ne peut rien dire de plus sans connaître le contenu de index.php ...

si jamais ça marche, c'est à dire qu'index.php utilise la valeur du
paramètre rev alors il EST mal écrit et il FAUT le changer pour
refermer la faille.
La meilleure manière de limiter les failles c'est de réduire la partie
dynamique au strict minimum.
Pour naviguer de page en page, il vaut 100 fois mieux utiliser des
liens vers des URL statiques, car alors les contrôles de sécurité du
serveur HTTP (apache2, par exemple) ne sont pas contournés, donc la
sécurité est meilleure.

__
Éric Dégenètais
Henix


http://www.henix.com
http://www.squashtest.org



Le 13 octobre 2015 23:17, Philippe Gras  a écrit :
>
> Le 13 oct. 2015 à 21:54, andre_deb...@numericable.fr a écrit :
>>
>> Je pense que tu ne sais même pas ce que veut dire :
>
> Ce n'est pas très grave tout ça, au fond. Parfois, on a la tête dans le 
> guidon,
>
> on ne vois pas forcément ce qu'il y a juste devant gros comme un montagne.
>
> Mais quelques semaines plus tard, on y repense et on y trouve ce que l'on a
>
> désespérément cherché.
>
> J'avais déjà posé la question il y a plusieurs mois ici donc c'est avec un 
> petit
>
> décalage que j'ai appris plein de trucs grâce à ce sujet.
>
> Alors s'il n'a pas (encore) servi à celui qui pose la question, il a quand 
> même
>
> servi. Mais peut-être sera-t-il utile de poser encore une fois la question.
>
> Bis repetita placent.

Re: Tentatives possible réussies attaque serveur

[andre_debian]

On Wednesday 14 October 2015 10:12:59 Eric Degenetais wrote:
> @andre, une dernière fois, au cas où:
> si tu veux avoir une indication sur le succès ou non des requêtes
> relevées, tente ce qui t'a été suggéré:
> fais la même requête depuis ton navigateur, et vois si tu obtiens ou
> non le contenu d' /etc/passwd
> si oui => il y a un risque que l'attaque ait réussi
> si non=> l'attaque a dû échouer
> on ne peut rien dire de plus sans connaître le contenu de index.php ...
> si jamais ça marche, c'est à dire qu'index.php utilise la valeur du
> paramètre rev alors il EST mal écrit et il FAUT le changer pour
> refermer la faille.
> La meilleure manière de limiter les failles c'est de réduire la partie
> dynamique au strict minimum.
> Pour naviguer de page en page, il vaut 100 fois mieux utiliser des
> liens vers des URL statiques, car alors les contrôles de sécurité du
> serveur HTTP (apache2, par exemple) ne sont pas contournés, donc la
> sécurité est meilleure.  Éric Dégenètais

Je voulais simplement marquer le coup sur un mail
de mauvais aloi, accusateur d'un serveur web et
scripts php, moisis. C'est désagréable.

Maintenant, un mail peut agacer, je comprends,
et on y répond par le silence.
Le silence est d'or, la parole est d'argent,
et l'écriture est...

Concernant ton mail, aimable et courtois,
il est équivalent au silence :-)

L'incident est clos.

Bonne fin de soirée.

André

Re: Tentatives possible réussies attaque serveur

[andre_debian]

On Sunday 11 October 2015 10:08:35 Sylvain L. Sauvage wrote:
> À moins que celui qui a écrit le fichier PHP moisi soit aussi 
> celui qui a écrit le serveur  HTTP

> Le vendredi 9 octobre 2015, 23:07:45 andré a écrit :
> > ça veut dire quoi "écrire le serveur HTTP" ?

>   Concevoir, programmer. La même chose que «écrire un script» :
C'est assez flou.
HTTP n'est pas un langage en soit, c'est un protocole de 
communication, une syntaxe pour formuler des requêtes. 
On l'utilise via un vrai langage de programmation, le PHP ou le C, 
par exemple. 

> Que ce membre lise bien les réponses qui lui sont faites 
> est  tout aussi très important :

Alors le dialogue est aussi (cra)moisi :-)

Ma question était la suivante :
comment vérifier que les logs d'Apache disant "possible exploit",
soit une attaque, intrusion réussies ?
càd vérifier si les codes de sécurité fonctionne ?

Ma serrure blindée peut avoir résistée ou non,
je peux le constater.

Mais bon, pas grave, je clos le sujet.

André

Re: Tentatives possible réussies attaque serveur

[andre_debian]

On Tuesday 13 October 2015 20:53:49 Sylvain L. Sauvage wrote:
> Le mardi 13 octobre 2015, 19:41:51 andre a écrit :
> > > > ça veut dire quoi "écrire le serveur HTTP" ?

>   Tu ne comprends pas « écrire le serveur HTTP ».
>   Tu ne comprends pas « programmer, concevoir le serveur HTTP ».
>   Je suppose que tu ne comprendras pas non plus « écrire un 
> programme qui soit un serveur pour HTTP », il faudra que je 
> t’explique que « serveur » signifie « programme qui propose un 
> service à d’autres programmes » et « serveur pour HTTP », « un 
> serveur qui donne des réponses à des requêtes selon le protocole 
> spécifié par les RFC 1945 ou 7230 ».
>   Faut-il aussi expliquer « écrire un programme » ? 
>   C’est trop  « flou » 

Je pense que tu ne sais même pas ce que veut dire :
"écrire le serveur HTTP"
"programmer, concevoir le serveur HTTP"

du genre : "ma voiture est en panne" :
"c'est le piston moisi qui s'est accroché au pare-choc et
 qui l'empêche d'écrire la carburation moisie"

>   On l’aura compris. Ça fait douze fois que tu reposes la même 
> question. Tout le monde t’a déjà répondu : on n’en sait foutre 
> rien parce qu’on ne sait pas ce qu’il y a dans ton foutu script.
> Mais repose-la encore une fois…

>   Toi, peut-être, nous non : on ne sait pas comment est faite ta 
> serrure et tout ce que tu nous répètes inlassablement, c’est 
> « mon voisin m’a dit qu’il a vu quelqu’un devant ma porte, je 
> veux savoir s’il est entré ».
> 
>   La dernière fois, je t’ai demandé d’essayer d’essayer les URLs 
> toi-même pour voir ce que tu obtenais. C’est-à-dire, dans la 
> suite de ton analogie, de « faire les mêmes gestes que le gars 
> qui était devant ta porte » pour voir si « tu peux entrer et 
> piquer l’argenterie ».

Tu utilises le "nous" :
"on te dit que" ,  "nous te répétons" ,  "nous non" :
c'est qui le "nous" ?

C'est surtout que tu es un communicant (cra)moisi.

> Mais bon, pas grave, je clos le sujet.

>   Il n’y a pire sourd…

Il n’y a pire sourd et un communicant (cra)moisi... :
le sujet était clos.

André

Re: Tentatives possible réussies attaque serveur

[Sylvain L. Sauvage]

Le mardi 13 octobre 2015, 19:41:51 andre_deb...@numericable.fr a 
écrit :
>[…]
> > > ça veut dire quoi "écrire le serveur HTTP" ?
> > > 
> >   Concevoir, programmer. La même chose que «écrire un
> > script» :
> C'est assez flou.
> HTTP n'est pas un langage en soit, c'est un protocole de
> communication, une syntaxe pour formuler des requêtes.
> On l'utilise via un vrai langage de programmation, le PHP ou
> le C, par exemple.

  Tu ne comprends pas « écrire le serveur HTTP ».
  Tu ne comprends pas « programmer, concevoir le serveur HTTP ».
  Je suppose que tu ne comprendras pas non plus « écrire un 
programme qui soit un serveur pour HTTP », il faudra que je 
t’explique que « serveur » signifie « programme qui propose un 
service à d’autres programmes » et « serveur pour HTTP », « un 
serveur qui donne des réponses à des requêtes selon le protocole 
spécifié par les RFC 1945 ou 7230 ».
  Faut-il aussi expliquer « écrire un programme » ? C’est trop 
« flou » ?

> > Que ce membre lise bien les réponses qui lui sont faites
> > est  tout aussi très important :
> Alors le dialogue est aussi (cra)moisi :-)
> 
> Ma question était la suivante :
> comment vérifier que les logs d'Apache disant "possible
> exploit", soit une attaque, intrusion réussies ?
> càd vérifier si les codes de sécurité fonctionne ?

  On l’aura compris. Ça fait douze fois que tu reposes la même 
question. Tout le monde t’a déjà répondu : on n’en sait foutre 
rien parce qu’on ne sait pas ce qu’il y a dans ton foutu script.
Mais repose-la encore une fois…

> Ma serrure blindée peut avoir résistée ou non,
> je peux le constater.

  Toi, peut-être, nous non : on ne sait pas comment est faite ta 
serrure et tout ce que tu nous répètes inlassablement, c’est 
« mon voisin m’a dit qu’il a vu quelqu’un devant ma porte, je 
veux savoir s’il est entré ».

  La dernière fois, je t’ai demandé d’essayer d’essayer les URLs 
toi-même pour voir ce que tu obtenais. C’est-à-dire, dans la 
suite de ton analogie, de « faire les mêmes gestes que le gars 
qui était devant ta porte » pour voir si « tu peux entrer et 
piquer l’argenterie ».
  Tu ne l’as sans doute toujours pas fait…

> Mais bon, pas grave, je clos le sujet.

  Il n’y a pire sourd…

-- 
 Sylvain Sauvage

Re: Tentatives possible réussies attaque serveur

[Philippe Gras]

Le 13 oct. 2015 à 21:54, andre_deb...@numericable.fr a écrit :
> 
> Je pense que tu ne sais même pas ce que veut dire :

Ce n'est pas très grave tout ça, au fond. Parfois, on a la tête dans le guidon,

on ne vois pas forcément ce qu'il y a juste devant gros comme un montagne.

Mais quelques semaines plus tard, on y repense et on y trouve ce que l'on a

désespérément cherché.

J'avais déjà posé la question il y a plusieurs mois ici donc c'est avec un petit

décalage que j'ai appris plein de trucs grâce à ce sujet.

Alors s'il n'a pas (encore) servi à celui qui pose la question, il a quand même

servi. Mais peut-être sera-t-il utile de poser encore une fois la question.

Bis repetita placent.

Re: Tentatives possible réussies attaque serveur

[Sylvain L. Sauvage]

Le vendredi 9 octobre 2015, 23:07:45 andre_deb...@numericable.fr 
a écrit :
>[…]
> ça veut dire quoi "écrire le serveur HTTP" ?

  Concevoir, programmer. La même chose que « écrire un script ».

> Qu'en sais tu que mes scripts PHP sont moisis ?
>[…] qu'en sais tu ?

  Je n’en sais rien. J’ai dit « *un* script moisi blabla, *un* 
script moins moisi blabla ».
  On ne peut être que général puisqu’on ne connaît pas ton 
script.

> Je ré-explique la problèmatique par comparaison :
>[…]
> Je voulais donc juste savoir si le fichier "/etc/passwd" a été
> téléchargé ou pas, point.

  Ça fait 25 messages dans ce fil qui t’expliquent qu’on n’en 
sait rien parce qu’on ne sait pas ce que fait ton script, que la 
réponse « 200 OK » ne donne aucun indice autre que le script a 
bien été exécuté et a renvoyé « quelque chose ».
  Il n’y a que toi qui puisse aller plus loin mais tu sembles 
bloqué sur la même question générale sans lire ou essayer de 
comprendre les réponses qui te sont faites.
  Est-ce que tu as même seulement essayé les URL suspectes toi-
même ? Si tu les essaies, tu verras bien si tu récupères le 
contenu de passwd ou pas.

> Bien lire la demande d'un membre de la liste est très
> important.

  Que ce membre lise bien les réponses qui lui sont faites est 
tout aussi très important.

-- 
 Sylvain Sauvage

Re: Tentatives possible réussies attaque serveur

[andre_debian]

On Friday 09 October 2015 15:39:57 Sylvain L. Sauvage wrote:
> Le vendredi 9 octobre 2015, 14:47:01 andre_deb...@numericable.fr 
> a écrit :
> > Merci de la piqûre de rappel ci-dessous concernant les
> > langages dynamiques Web.
> > Les documents sur la sécurité abondent en ce sens,
> > dont surtout la réinjection de codes dans les pages Web.
> > La question initiale était :
> > /index.php?rev=../../../../../../../../../etc/passwd
> > HTTP Response 200, possible tentatives avec succès..."
> > Mais rien n'empêche de taper directement ceci :
> > "www.monsite.com/../../../../... /etc/passwd
> > Le fait d'avoir une page d'index ou non,
> > "/index.php?rev=../../../../../../../../../etc/passwd"
> > ne doit pas changer grand chose...

> Ok, donc, malgré tout ce qui a été dit dans ce fil, tu n’as 
> pas compris le protocole HTTP : ces requêtes ne sont pas 
> équivalentes.
> Passer par un fichier PHP mal écrit qui va pouvoir lire 
> n’importe quel fichier sur ta machine si on lui passe un chemin 
> dans le bon paramètre n’est pas équivalent à faire une requête 
> que le serveur va savoir refuser. À moins que celui qui a écrit 
> le fichier PHP moisi soit aussi celui qui a écrit le serveur 
> HTTP, ce dernier n’acceptera pas d’aller remonter plus haut que 
> sa racine (p.ex. /var/www).

> celui qui a écrit le fichier PHP moisi soit aussi celui qui a 
> écrit le serveur  HTTP :
ça veut dire quoi "écrire le serveur HTTP" ?

Qu'en sais tu que mes scripts PHP sont moisis ?
(humm, en plus le terme "moisi" ne va pas... plutôt "édulcoré").

Jje me vois répondre par une polémique sur la validité de 
mes scripts, php, page d'index, variables, écriture HTTP, moisis...  !
qu'en sais tu ?

Je ré-explique la problèmatique par comparaison :
je monte dans ma voiture la matin qui possède un logwatch de sécurité.
Il m'annonce "qu'une tentative d'intrusion" a eu lieu à 03h40, code 200.
Je pose la question : 
y a t-il eu "une tentative d'intrusion" ou "une intrusion" ?
Si "tentative d'intrusion", la sécurité de ma voiture n'est pas moisie,
si "intrusion réussie" : oui, elle est moisie (scripts édulcorés).

Je voulais donc juste savoir si le fichier "/etc/passwd" a été 
téléchargé ou pas, point.

Bien lire la demande d'un membre de la liste est très important.

André

Re: Tentatives possible réussies attaque serveur

[andre_debian]

Merci de la piqûre de rappel ci-dessous concernant les
langages dynamiques Web.

Les documents sur la sécurité abondent en ce sens,
dont surtout la réinjection de codes dans les pages Web.

La question initiale était :
/index.php?rev=../../../../../../../../../etc/passwd 
HTTP Response 200, possible tentatives avec succès..." 

Mais rien n'empêche de taper directement ceci :
"www.monsite.com/../../../../... /etc/passwd

Le fait d'avoir une page d'index ou non,
"/index.php?rev=../../../../../../../../../etc/passwd"
ne doit pas changer grand chose...

André

On Friday 09 October 2015 14:30:54 Sébastien NOBILI wrote:
> Le vendredi 09 octobre 2015 à 13:27, andre_deb...@numericable.fr a écrit :
> > Je ne sais plus qui, je ne sais plus quand (ça a été tronqué) a écrit :
> > > 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 :
> > 
> > Le PHP est un langage de sites dynamiques,
> > comment faire autrement ?
> 
> PHP a une très mauvaise réputation de nid à failles. Cette réputation n'est 
pas
> forcément très objective mais parmi les arguments qui l'ont faite, on 
trouve :
> - que l'API n'est pas très rigoureuse;
> - qu'on peut développer un site en PHP sans trop de connaissances (et 
donc
>   sans forcément trop de sécurité non plus).
> 
> > "php.ini" traite les variables de formulaires,
> > selon le mode "register_global = off",
> > avec transmission de la variable à la page de traitement par :
> > ...$_POST["name"]...
> > Que peut-on faire de plus ?
> 
> Ma réponse est indépendante du langage utilisé et vaut autant pour PHP que 
pour
> tout autre langage utilisé pour créer des sites dynamiques (et même d'une
> manière large des programmes client/serveur) :
> 
> Ne _jamais_ faire confiance à ce qui arrive du client !
> 
> Tu considères que tout est douteux et tu vérifies _scrupuleusement_ tout ce 
qui
> arrive :
> - est-ce que le nombre que tu attends est bien seulement un nombre;
> - est-ce que la chaîne que tu attends ne contient pas de quoi faire de
>   l'injection SQL;
> - est-ce que la chaîne que tu attends ne contient pas de quoi faire du 
XSS;
> - etc.
> 
> Pour ça, les expressions rationnelles sont un très bon allié.
> 
> Sébastien
> 
> 

Re: Tentatives possible réussies attaque serveur

[andre_debian]

Merci de cette réponse aussi détaillée que longue :-)

Le error.log d'apache2 n'indique pas d'erreur particulière.

si je tape dans la barre d'URL :
"www.monsite.com/index?rev==../../../../... /etc/passwd",
je reçois : Erreur !
J'y ai mis une protection sur l'accès aux répertoires sensibles.

> 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 page :

C'est ce qui est fait, mais les pages 100% html
sont nommées ".php".

> 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 :

Le PHP est un langage de sites dynamiques,
comment faire autrement ?

"php.ini" traite les variables de formulaires,
selon le mode "register_global = off",
avec transmission de la variable à la page de traitement par :
...$_POST["name"]...
Que peut-on faire de plus ?

sinon de ne pas créer de sites Web :-)

André

On Tuesday 06 October 2015 19:16:32 BERBAR Florian wrote:
> On 02/10/2015 15:13, andre_deb...@numericable.fr wrote:
> > 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 

[HS] Re: Tentatives possible réussies attaque serveur

[BERBAR Florian]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/10/2015 13:27, andre_deb...@numericable.fr wrote:
> Merci de cette réponse aussi détaillée que longue :-)
> 
> Le error.log d'apache2 n'indique pas d'erreur particulière.
> 
> si je tape dans la barre d'URL : 
> "www.monsite.com/index?rev==../../../../... /etc/passwd", je reçois
> : Erreur ! J'y ai mis une protection sur l'accès aux répertoires
> sensibles.
> 
>> 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 page :
> 
> C'est ce qui est fait, mais les pages 100% html sont nommées
> ".php".

Je voulais dire par pages 100% HTML des pages contenant aucun code
dynamique (pas de PHP).

> 
>> 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 :
> 
> Le PHP est un langage de sites dynamiques, comment faire autrement
> ?
> 
> "php.ini" traite les variables de formulaires, selon le mode
> "register_global = off", avec transmission de la variable à la page
> de traitement par : ...$_POST["name"]... Que peut-on faire de plus
> ?

Filtrer en supprimant tout motif suspicieux du contenu des variables
dites super-globales telle que $_GET, $_POST, $_FILE, etc...
(http://php.net/manual/fr/language.variables.superglobals.php). Ces
variables peuvent contenir des informations venant des visiteurs de
votre sites Internet et donc potentiellement contenir des vecteurs de
compromissions.

Dans le cas spécifique à votre question la méthode de ma réponse
prétendante est un moyen possible. Je cite :

"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." (Création d'une Whitelist par exemple.)

> 
> sinon de ne pas créer de sites Web :-)

Les pages statiques, sans code dynamique telle que PHP, sont une
solution sûre.

> 
> André
> 

Florian.

> On Tuesday 06 October 2015 19:16:32 BERBAR Florian wrote:
>> On 02/10/2015 15:13, andre_deb...@numericable.fr wrote:
>>> 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 

Re: Tentatives possible réussies attaque serveur

[Sébastien NOBILI]

Le vendredi 09 octobre 2015 à 13:27, andre_deb...@numericable.fr a écrit :
> Je ne sais plus qui, je ne sais plus quand (ça a été tronqué) a écrit :
> > 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 :
> 
> Le PHP est un langage de sites dynamiques,
> comment faire autrement ?

PHP a une très mauvaise réputation de nid à failles. Cette réputation n'est pas
forcément très objective mais parmi les arguments qui l'ont faite, on trouve :
- que l'API n'est pas très rigoureuse;
- qu'on peut développer un site en PHP sans trop de connaissances (et donc
  sans forcément trop de sécurité non plus).

> "php.ini" traite les variables de formulaires,
> selon le mode "register_global = off",
> avec transmission de la variable à la page de traitement par :
> ...$_POST["name"]...
> Que peut-on faire de plus ?

Ma réponse est indépendante du langage utilisé et vaut autant pour PHP que pour
tout autre langage utilisé pour créer des sites dynamiques (et même d'une
manière large des programmes client/serveur) :

Ne _jamais_ faire confiance à ce qui arrive du client !

Tu considères que tout est douteux et tu vérifies _scrupuleusement_ tout ce qui
arrive :
- est-ce que le nombre que tu attends est bien seulement un nombre;
- est-ce que la chaîne que tu attends ne contient pas de quoi faire de
  l'injection SQL;
- est-ce que la chaîne que tu attends ne contient pas de quoi faire du XSS;
- etc.

Pour ça, les expressions rationnelles sont un très bon allié.

Sébastien

Re: Tentatives possible réussies attaque serveur

[Dominique Asselineau]

Sylvain L. Sauvage wrote on Fri, Oct 09, 2015 at 03:39:57PM +0200
> Le vendredi 9 octobre 2015, 14:47:01 andre_deb...@numericable.fr 
> a écrit :
> > Merci de la piqûre de rappel ci-dessous concernant les
> > langages dynamiques Web.
> > 
> > Les documents sur la sécurité abondent en ce sens,
> > dont surtout la réinjection de codes dans les pages Web.
> > 
> > La question initiale était :
> > /index.php?rev=../../../../../../../../../etc/passwd
> > HTTP Response 200, possible tentatives avec succès..."
> > 
> > Mais rien n'empêche de taper directement ceci :
> > "www.monsite.com/../../../../... /etc/passwd
> > 
> > Le fait d'avoir une page d'index ou non,
> > "/index.php?rev=../../../../../../../../../etc/passwd"
> > ne doit pas changer grand chose...
> 
>   Ok, donc, malgré tout ce qui a été dit dans ce fil, tu n’as 
> pas compris le protocole HTTP : ces requêtes ne sont pas 
> équivalentes.
> 
>   Passer par un fichier PHP mal écrit qui va pouvoir lire 
> n’importe quel fichier sur ta machine si on lui passe un chemin 
> dans le bon paramètre n’est pas équivalent à faire une requête 
> que le serveur va savoir refuser. À moins que celui qui a écrit 
> le fichier PHP moisi soit aussi celui qui a écrit le serveur 
> HTTP, ce dernier n’acceptera pas d’aller remonter plus haut que 
> sa racine (p.ex. /var/www).
> 
>   La requête '/index.php?rev=../../etc/passwd' signifie 
> « exécuter le script 'index.php' en lui passant la variable 
> 'rev' à '../../etc/passwd' ». Le script fait ce qu’il veut avec 
> son paramètre 'rev'. Un script moisi va s’en servir pour aller 
> ouvrir le fichier et l’inclure dans la réponse sans 
> vérification. Un script moins moisi va vérifier la valeur du 
> paramètre et ne pas s’en servir.
>   D’un point de vue réponse HTTP, ces deux scripts vont générer 
> un 200 de la part du serveur HTTP : le fichier 'index.php' a été 
> exécuté et renvoie un contenu.

Un script peut tout à fait retourner une réponse HTTP autre que 200.
C'est ce que je fais lorsqu'on demande une ressource qui n'existe pas
ou qui n'est pas autorisée pour la requête.

Quant aux scripts qui font des includes sur des fichiers dont
l'adresse est passée en paramètre et sans vérification...  ça me
laisse pantois.  Il y en a même qui laissent faire des includes sur
des URL...  Ce qui permet à un spameur de faire tourner un moulin à
spams chez vous avec votre bande passante et surtout votre
responsabilité.

Faire vraiment attention aux gentils scripts qui veulent vous rendre
mille services sans vous dire ce que fait le mille et unième.

dom

> 
>   La requête '/../../../etc/passwd', en général, n’est pas 
> valide, et va donc générer une réponse 404.
> (On peut avoir un serveur web qui renvoie toutes ou certaines 
> URL comme paramètre à l’exécution d’un script, lequel peut être 
> plus ou moins moisi, mais il faut lui demander.)
> 
>   Il est beaucoup plus fréquent de trouver un script PHP moisi 
> que de trouver un serveur web qui va aller chercher n’importe 
> quel fichier sur la machine, ne serait-ce que parce qu’il y a 
> beaucoup plus de scripts PHP que serveurs web…
> 
> -- 
>  Sylvain Sauvage
> 

-- 

Re: Tentatives possible réussies attaque serveur

[Sylvain L. Sauvage]

Le vendredi 9 octobre 2015, 14:47:01 andre_deb...@numericable.fr 
a écrit :
> Merci de la piqûre de rappel ci-dessous concernant les
> langages dynamiques Web.
> 
> Les documents sur la sécurité abondent en ce sens,
> dont surtout la réinjection de codes dans les pages Web.
> 
> La question initiale était :
> /index.php?rev=../../../../../../../../../etc/passwd
> HTTP Response 200, possible tentatives avec succès..."
> 
> Mais rien n'empêche de taper directement ceci :
> "www.monsite.com/../../../../... /etc/passwd
> 
> Le fait d'avoir une page d'index ou non,
> "/index.php?rev=../../../../../../../../../etc/passwd"
> ne doit pas changer grand chose...

  Ok, donc, malgré tout ce qui a été dit dans ce fil, tu n’as 
pas compris le protocole HTTP : ces requêtes ne sont pas 
équivalentes.

  Passer par un fichier PHP mal écrit qui va pouvoir lire 
n’importe quel fichier sur ta machine si on lui passe un chemin 
dans le bon paramètre n’est pas équivalent à faire une requête 
que le serveur va savoir refuser. À moins que celui qui a écrit 
le fichier PHP moisi soit aussi celui qui a écrit le serveur 
HTTP, ce dernier n’acceptera pas d’aller remonter plus haut que 
sa racine (p.ex. /var/www).

  La requête '/index.php?rev=../../etc/passwd' signifie 
« exécuter le script 'index.php' en lui passant la variable 
'rev' à '../../etc/passwd' ». Le script fait ce qu’il veut avec 
son paramètre 'rev'. Un script moisi va s’en servir pour aller 
ouvrir le fichier et l’inclure dans la réponse sans 
vérification. Un script moins moisi va vérifier la valeur du 
paramètre et ne pas s’en servir.
  D’un point de vue réponse HTTP, ces deux scripts vont générer 
un 200 de la part du serveur HTTP : le fichier 'index.php' a été 
exécuté et renvoie un contenu.

  La requête '/../../../etc/passwd', en général, n’est pas 
valide, et va donc générer une réponse 404.
(On peut avoir un serveur web qui renvoie toutes ou certaines 
URL comme paramètre à l’exécution d’un script, lequel peut être 
plus ou moins moisi, mais il faut lui demander.)

  Il est beaucoup plus fréquent de trouver un script PHP moisi 
que de trouver un serveur web qui va aller chercher n’importe 
quel fichier sur la machine, ne serait-ce que parce qu’il y a 
beaucoup plus de scripts PHP que serveurs web…

-- 
 Sylvain Sauvage

Re: Tentatives possible réussies attaque serveur

[Eric Degenetais]

> Mais rien n'empêche de taper directement ceci :
> "www.monsite.com/../../../../... /etc/passwd
> Le fait d'avoir une page d'index ou non,
> "/index.php?rev=../../../../../../../../../etc/passwd"
> ne doit pas changer grand chose...


bonjour,
En principe, le serveur est conçu pour limiter l’arborescence exposée.
Pour peu que le paramétrage par défaut soit correct et n'ai pas été
altéré imprudemment, il offre une bonne protection. Cependant les
pages PHP peuvent contourner cette protection si elles sont écrites
imprudemment, car le moteur d'exécution PHP a beaucoup plus de
latitude pour accéder à des fichiers que le serveur Web...d'où
l'apparition de failles qui n'existe pas dans les sites statiques.

cordialement

__
Éric Dégenètais
Henix


http://www.henix.com
http://www.squashtest.org



Le 9 octobre 2015 14:47,   a écrit :
> Merci de la piqûre de rappel ci-dessous concernant les
> langages dynamiques Web.
>
> Les documents sur la sécurité abondent en ce sens,
> dont surtout la réinjection de codes dans les pages Web.
>
> La question initiale était :
> /index.php?rev=../../../../../../../../../etc/passwd
> HTTP Response 200, possible tentatives avec succès..."
>
> Mais rien n'empêche de taper directement ceci :
> "www.monsite.com/../../../../... /etc/passwd
>
> Le fait d'avoir une page d'index ou non,
> "/index.php?rev=../../../../../../../../../etc/passwd"
> ne doit pas changer grand chose...
>
> André
>
> On Friday 09 October 2015 14:30:54 Sébastien NOBILI wrote:
>> Le vendredi 09 octobre 2015 à 13:27, andre_deb...@numericable.fr a écrit :
>> > Je ne sais plus qui, je ne sais plus quand (ça a été tronqué) a écrit :
>> > > 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 :
>> >
>> > Le PHP est un langage de sites dynamiques,
>> > comment faire autrement ?
>>
>> PHP a une très mauvaise réputation de nid à failles. Cette réputation n'est
> pas
>> forcément très objective mais parmi les arguments qui l'ont faite, on
> trouve :
>> - que l'API n'est pas très rigoureuse;
>> - qu'on peut développer un site en PHP sans trop de connaissances (et
> donc
>>   sans forcément trop de sécurité non plus).
>>
>> > "php.ini" traite les variables de formulaires,
>> > selon le mode "register_global = off",
>> > avec transmission de la variable à la page de traitement par :
>> > ...$_POST["name"]...
>> > Que peut-on faire de plus ?
>>
>> Ma réponse est indépendante du langage utilisé et vaut autant pour PHP que
> pour
>> tout autre langage utilisé pour créer des sites dynamiques (et même d'une
>> manière large des programmes client/serveur) :
>>
>> Ne _jamais_ faire confiance à ce qui arrive du client !
>>
>> Tu considères que tout est douteux et tu vérifies _scrupuleusement_ tout ce
> qui
>> arrive :
>> - est-ce que le nombre que tu attends est bien seulement un nombre;
>> - est-ce que la chaîne que tu attends ne contient pas de quoi faire de
>>   l'injection SQL;
>> - est-ce que la chaîne que tu attends ne contient pas de quoi faire du
> XSS;
>> - etc.
>>
>> Pour ça, les expressions rationnelles sont un très bon allié.
>>
>> Sébastien
>>
>>
>

Re: Tentatives possible réussies attaque serveur

[Dominique Asselineau]

Sylvain L. Sauvage wrote on Fri, Oct 09, 2015 at 05:03:48PM +0200
> Le vendredi 9 octobre 2015, 16:24:00 Dominique Asselineau a 
> écrit :
> >[???]
> > >   D???un point de vue réponse HTTP, ces deux scripts vont
> > > générer un 200 de la part du serveur HTTP : le fichier
> > > 'index.php' a été exécuté et renvoie un contenu.
> > 
> > Un script peut tout à fait retourner une réponse HTTP autre
> > que 200. C'est ce que je fais lorsqu'on demande une ressource
> > qui n'existe pas ou qui n'est pas autorisée pour la requête.
> 
>   Oui. Je donnais juste l???exemple de ces deux scripts : moisi et 
> moins-moisi.
>   On pourrait aller plus loin dans les détails et les 
> possibilités, p.ex. les redirections, les réécritures, ce que 
> veut dire « exécuter un script », etc. Mais bon, vu la longueur 
> du fil, les multiples explications, pour arriver à 
> « index.php?bla et /bla, c???est pareil », on se dit qu???il vaut 
> mieux rester simple???
> 
> > Quant aux scripts qui font des includes sur des fichiers dont
> > l'adresse est passée en paramètre et sans vérification...  ça
> > me laisse pantois.  Il y en a même qui laissent faire des
> > includes sur des URL...  Ce qui permet à un spameur de faire
> > tourner un moulin à spams chez vous avec votre bande passante
> > et surtout votre responsabilité.
> > 
> > Faire vraiment attention aux gentils scripts qui veulent vous
> > rendre mille services sans vous dire ce que fait le mille et
> > unième.
> 
>   J???aimais bien l???époque des premiers CGI, en shell, c???était si 
> facile de se pendre avec ;o)

Détrompe-toi Sylvain !  C'est arrivé il y a quelques années avec un
script PHP justement, trouvé sur le web bien que l'auteur du méfait
n'a jamais voulu le reconnaître.  Dans l'affaire il y a eu 2 pendus :
celui qui a récupéré le script, probablement à Troie... et celui qui a
configuré le php.ini en oubliant d'interdire l'inclusion d'URL car en
effet, ça peut se configurer au niveau de PHP.  Comme quoi il n'y a
pas besoin de remonter au siècle dernier avec des CGI en shell pour voir ça.

dom
-- 

Re: Tentatives possible réussies attaque serveur

[Philippe Gras]

Le 9 oct. 2015 à 16:46, Eric Degenetais  a écrit :

> Le 9 octobre 2015 16:24, Dominique Asselineau
>  a écrit :
>> Un script peut tout à fait retourner une réponse HTTP autre que 200.
>> C'est ce que je fais lorsqu'on demande une ressource qui n'existe pas
>> ou qui n'est pas autorisée pour la requête.
> 
> Certes...mais il y a des cas où il vaut mieux retourner 200 tout le
> temps. Après tout, index.php existe, l'URL est donc correcte, donc 404
> n'est pas tout à fait une réponse adaptée. Quand un robot fait du
> sondage en masse, lui retourner un code d'erreur sauf si ça tappe
> juste peut l'aider à trouver.

… et inversement !

> Par exemple, renvoyer un 200 uniquement en cas de succès de login est
> de nature à faciliter les attaques en force…

Ce n'est pas garanti. J'ai des milliers de requêtes en 403 sur mes pages de 
login, et cela

ne les dérange pas plus que ça.

Sur le principe, la page c'est "/index.php" ou 
"/index.php?login=machin=bidule" ?

Dans le premier cas, le serveur doit renvoyer un code 200 quels que soient les 
arguments

passés en variable.

Dans le deuxième cas, non et je suis d'accord avec Sylvain. Mais alors… il n'y 
aurait qu'un

login et un mot de passe ?

Bon, en fait quel que soit le code de réponse renvoyé, et vu que ça n'affecte 
pas les chieurs,

je crois que c'est un faux problème.

Les seuls qui vaillent la peine que l'on s'attarde de façon pratique, c'est de 
bien vérifier que

les variables demandées ne s'affichent pas sur la page et de créer un fichier 
dans Fail2Ban

pour envoyer les demandeurs aux pelotes.

> 
> __
> Éric Dégenètais
> Henix
> 
> 
> http://www.henix.com
> http://www.squashtest.org
> 

Re: Tentatives possible réussies attaque serveur

[Eric Degenetais]

Le 9 octobre 2015 16:24, Dominique Asselineau
 a écrit :
> Un script peut tout à fait retourner une réponse HTTP autre que 200.
> C'est ce que je fais lorsqu'on demande une ressource qui n'existe pas
> ou qui n'est pas autorisée pour la requête.

Certes...mais il y a des cas où il vaut mieux retourner 200 tout le
temps. Après tout, index.php existe, l'URL est donc correcte, donc 404
n'est pas tout à fait une réponse adaptée. Quand un robot fait du
sondage en masse, lui retourner un code d'erreur sauf si ça tappe
juste peut l'aider à trouver.
Par exemple, renvoyer un 200 uniquement en cas de succès de login est
de nature à faciliter les attaques en force...

__
Éric Dégenètais
Henix


http://www.henix.com
http://www.squashtest.org

Re: Tentatives possible réussies attaque serveur

[Sylvain L. Sauvage]

Le vendredi 9 octobre 2015, 16:24:00 Dominique Asselineau a 
écrit :
>[…]
> >   D’un point de vue réponse HTTP, ces deux scripts vont
> > générer un 200 de la part du serveur HTTP : le fichier
> > 'index.php' a été exécuté et renvoie un contenu.
> 
> Un script peut tout à fait retourner une réponse HTTP autre
> que 200. C'est ce que je fais lorsqu'on demande une ressource
> qui n'existe pas ou qui n'est pas autorisée pour la requête.

  Oui. Je donnais juste l’exemple de ces deux scripts : moisi et 
moins-moisi.
  On pourrait aller plus loin dans les détails et les 
possibilités, p.ex. les redirections, les réécritures, ce que 
veut dire « exécuter un script », etc. Mais bon, vu la longueur 
du fil, les multiples explications, pour arriver à 
« index.php?bla et /bla, c’est pareil », on se dit qu’il vaut 
mieux rester simple…

> Quant aux scripts qui font des includes sur des fichiers dont
> l'adresse est passée en paramètre et sans vérification...  ça
> me laisse pantois.  Il y en a même qui laissent faire des
> includes sur des URL...  Ce qui permet à un spameur de faire
> tourner un moulin à spams chez vous avec votre bande passante
> et surtout votre responsabilité.
> 
> Faire vraiment attention aux gentils scripts qui veulent vous
> rendre mille services sans vous dire ce que fait le mille et
> unième.

  J’aimais bien l’époque des premiers CGI, en shell, c’était si 
facile de se pendre avec ;o)

-- 
 Sylvain Sauvage

Re: Tentatives possible réussies attaque serveur

[Sylvain L. Sauvage]

Le vendredi 9 octobre 2015, 17:02:52 Philippe Gras a écrit :
>[… du “bon” code de retour …]
> Dans le deuxième cas, non et je suis d'accord avec Sylvain.

  Euh, j’ai rien dit là-dessus, moi. J’ai juste donné deux 
exemples de scripts, moisi et moins-moisi, qui renverraient 200 
(cas de la question initiale et pour rester simple).

  Mais si vous voulez mon avis, il n’y a pas de réponse 
générale. Un script qui renvoie une erreur, ça sert. Un script 
qui ne renvoie jamais d’erreur, ça sert aussi.

  Bon, le mieux, c’est un script qui renvoie un code tiré au 
hasard. Un coup ça marche, un coup ça marche pas. À bas REST !

(Eh, c’est vendredi !)
-- 
 Sylvain Sauvage

Re: Tentatives possible réussies attaque serveur

[Dominique Asselineau]

Eric Degenetais wrote on Fri, Oct 09, 2015 at 04:46:54PM +0200
> Le 9 octobre 2015 16:24, Dominique Asselineau
>  a écrit :
> > Un script peut tout à fait retourner une réponse HTTP autre que 200.
> > C'est ce que je fais lorsqu'on demande une ressource qui n'existe pas
> > ou qui n'est pas autorisée pour la requête.
> 
> Certes...mais il y a des cas où il vaut mieux retourner 200 tout le
> temps. Après tout, index.php existe, l'URL est donc correcte, donc 404
> n'est pas tout à fait une réponse adaptée. 

Si l'opération est de faire du téléchargement, la pertinence n'est pas
le script mais la ressource demandée.  Du coup, ça n'est pas du tout
absurde de répondre relativement à la ressource.

> Quand un robot fait du
> sondage en masse, lui retourner un code d'erreur sauf si ça tappe
> juste peut l'aider à trouver.
> Par exemple, renvoyer un 200 uniquement en cas de succès de login est
> de nature à faciliter les attaques en force...

Ah oui, enfin on parse la page et ça revient à peu près au même.
C'est comme souvent : tout dépend de l'enjeu.  Perso, je n'aime pas
que les mots de passe soient demandés au niveau des scripts, je
préfère que ce soit le serveur qui s'en charge.  Ça paraît plus
prudent.

dom

-- 

Re: Tentatives possible réussies attaque serveur

[Sébastien NOBILI]

Le vendredi 02 octobre 2015 à 12:33, BERTRAND Joël a écrit :
> andre_deb...@numericable.fr a écrit :
> >Y a t-il un danger que les mots de passe soient connus... ?
> 
>   Les mots de passe, non, mais les logins et les mots de passe chiffrés. 
> Sans
> indiscrétion, quel est ce index.php moisi ?

Les mots de passe chiffrés ne sont plus dans le fichier « /etc/passwd » depuis
un petit paquet d'années.

Ce fichier est devenu accessible à tous les utilisateurs car il ne contient plus
grand chose de vraiment sensible. Il peut cependant renseigner sur l'existence
ou non d'un compte utilisateur pour orienter des attaques type force brute, mais
rien de plus.

Sébastien

Re: Tentatives possible réussies attaque serveur

[BERBAR Florian]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/10/2015 15:13, andre_deb...@numericable.fr wrote:
> On Friday 02 October 2015 13:38:21 BERTRAND Joc3abl wrote:
>> andre_deb...@numericable.fr a écrit :
>>> On Friday 02 October 2015 12:34:49 yamo' wrote:
 andre_deb...@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.

>>> 

Re: Tentatives possible réussies attaque serveur

[Bernard Isambert]

Le 02/10/2015 13:38, BERTRAND Joël a écrit :


J'ai bien compris. 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.

Non. La réponse 200 indique qu'il y a bien un fichier /index.php et que 
celui-ci a répondu sans se planter, c'est tout. Si le fichier index.php 
ne s'occupe pas de la "query string", il n'y a absolument pas à s'inquiéter.


--
Bernard.
20 ans d'utilisation de Debian. Comme le temps passe...

Re: Tentatives possible réussies attaque serveur

[Philippe Gras]

Le 2 oct. 2015 à 12:33, BERTRAND Joël  a écrit :

> andre_deb...@numericable.fr a écrit :
>> Bonjour,
> 
>   Bonjour,
> 
>> 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... ?
>> 
>> André
>> 
> 
>   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

J'en ai tous les jours, ce n'est pas grave, en fait.

Pour vous rendre compte de ce que ça donne, vous devriez tester une de ces URL.

Normalement, ce qui passe dans la query string n'est pas pris en compte.
> 

Re: Tentatives possible réussies attaque serveur

[andre_debian]

On Friday 02 October 2015 13:38:21 BERTRAND Joc3abl wrote:
> andre_deb...@numericable.fr a écrit :
> > On Friday 02 October 2015 12:34:49 yamo' wrote:
> >> andre_deb...@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... ?
> >
> >> 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.

Comment faire autrement ?

André

Re: Tentatives possible réussies attaque serveur

[BERTRAND Joël]

andre_deb...@numericable.fr a écrit :

Bonjour,


Bonjour,


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... ?

André



	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

Re: Tentatives possible réussies attaque serveur

[yamo']

Salut,

andre_deb...@numericable.fr a écrit le 02/10/2015 11:10 :
> Bonjour,
> 
> 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... ?


As tu essayé toi même et regardé les réponses http vues par le
navigateur, par exemple avec l'extension httpheader sur firefox?


-- 
Stéphane

Tentatives possible réussies attaque serveur

[andre_debian]

Bonjour,

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... ?

André

Re: Tentatives possible réussies attaque serveur

[BERTRAND Joël]

andre_deb...@numericable.fr a écrit :

On Friday 02 October 2015 12:34:49 yamo' wrote:

andre_deb...@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... ?



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;


	J'ai bien compris. 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) ?


Cordialement,

JKB

Re: Tentatives possible réussies attaque serveur

[andre_debian]

On Friday 02 October 2015 12:34:49 yamo' wrote:
> andre_deb...@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... ?

>   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;
 
> As tu essayé toi même et regardé les réponses http vues par le
> navigateur, par exemple avec l'extension httpheader sur firefox?

Comment fait-on avec " l'extension httpheader" ?

André