Tentatives possible réussies attaque serveur

Eric Degenetais wrote on Fri, Oct 09, 2015 at 04:46:54PM +0200

Le 9 octobre 2015 16:24, Dominique Asselineau
<asseline@telecom-paristech.fr> 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

--

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

On Friday 09 October 2015 15:39:57 Sylvain L. Sauvage wrote:

Le vendredi 9 octobre 2015, 14:47:01 andre_debian@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 ha ut 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écu rité.
Il m'annonce "qu'une tentative d'intrusion" a eu lieu à 03h40, code 20 0.
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 m oisie,
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é

Le vendredi 9 octobre 2015, 23:07:45 andre_debian@numericable.fr
a écrit :

[…]
ça veut dire quoi "écrire le serveur HTTP" ?

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

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 l a
réponse « 200 OK » ne donne aucun indice autre que le sc ript a
bien été exécuté et a renvoyé « quelque c hose ».
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 e ssayer de
comprendre les réponses qui te sont faites.
Est-ce que tu as même seulement essayé les URL suspectes to i-
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

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 scri pt» :

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é

Le mardi 13 octobre 2015, 19:41:51 andre_debian@numericable.fr a
écrit :

[…]
> > ça veut dire quoi "écrire le serveur HTTP" ?
> >
> Concevoir, programmer. La même chose que «écrire u n
> 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 pou r HTTP », « un
serveur qui donne des réponses à des requêtes selon le p rotocole
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 fout u 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 gar s
qui était devant ta porte » pour voir si « tu peux entre r 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

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 qu i propose un
service à d’autres programmes » et « serveur pour HTTP », « un
serveur qui donne des réponses à des requêtes selon le pro tocole
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 de vant 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, da ns 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é

Le 13 oct. 2015 à 21:54, andre_debian@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.=

@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 p artie
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 <ph.gras@worldonline.fr> a écr it :

Le 13 oct. 2015 à 21:54, andre_debian@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 mon tagne.

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 do nc 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 qu estion.

Bis repetita placent.

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êt es
relevées, tente ce qui t'a été suggéré:
fais la même requête depuis ton navigateur, et vois si tu obtie ns 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 valeu r 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écuri té 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é