Victime d'un hack de type "relais" : j'aimerais comprendre

Le
SvS
[Moderation]
Attention, cet article est posté dans deux groupes et le FU2
n'etait pas positionné.

J'ai pris sur moi de le positionner sur fr.comp.securite car :

- amha le problème est bien plus général que le php
(vérif des entrées, toussa :) )

- il vaut mieux éviter des réponses à droite et à gauche dans ce cas
Si vous n'êtes pas d'accord avec ce FU2 merci de le repositionner

Eric Razny.
Co-modérateur de fr.comp.securite
[fin de modération]


Bonjour,

j'ai très honte de moi, je pensais avoir bien sécurisé mes pages web, mais
j'ai été victime d'un hack monstrueux sur une page qui était censée
m'envoyer un email.

Je m'explique :
1) une page html classique, qui contient quatre champs : un nom d'émeteur,
un email d'émeteur, un sujet, et un message, en utilisant les champs FORM et
la méthode POST.

2) ces données sont envoyées à une page php qui les récupère, et qui
contient une commande mail qui contient en dur mon adresse email. Extrait de
la feuille php
_____________________________________________
$too = "moi@monadresse.org";
/* Ce qui vient du post */
$subject = $_POST['title'];
$from_n = $_POST['realname'];
$from_e = $_POST['emaille'];
$message = $_POST['comments'];
if ($from_n<>"") $mister = $from_n; else $mister = $from_e;

/* divers tests */
if ($from_e=='') { errmess("Vous n'avez pas mis votre
email",$url_from,$css_f); }
if ($message=='' & $subject=='') { errmess("Vous avez oubli&eacute; le
sujet et le petit message",$url_from,$css_f); }

$h = "MIME-version: 1.0";
$h .= "Content-type: text/html; charset=iso-8899-1";
$h .= "From: ".$from_n.'<'.$from_e.'>';
$sbj = stripcslashes($subject);
$message = stripcslashes($message);

mail($too, $sbj, $message, $h);
______________________________________


3) en l'espace de 24h, je reçois plus de 600 emails venant de cette page. Je
regarde mon log, effectivement, je vois les lignes qui contiennent les POST,
venant de diverses adresses email. Dans l'urgence je bloque mon site, puis
j'efface la feuille htm et la feuille php

Bon, je me dis "ce n'est pas grave", il n'y a que moi qui a reçu ce spam

4) M j'ai servi de relais, car les emails de spam ont bien été
redistribués à des centaines de personnes Je le sais, car sur mon adresse
de retour (celle de mon serveur apache), j'ai reçu plus de 800 avis de non
délivrance.

5) je regarde les emails qui m'ont été envoyé sur moi@monadresse.org, et
effectivement, je vois pour la plupart des emails de spam une liste
d'adresses dans un deuxième champ "subject". Extrait de l'une d'entre elle :
________________________________________________
Date: Tue, 14 Feb 2006 16:46:43 +0100
Subject: Callorhynchus@monadresse.org
To: moi@monadresse.org
MIME-version: 1.0
Content-type: text/html; charset=iso-8899-1
From: Callorhynchus@monadresse.org<Callorhynchus
Content-Type: multipart/mixed; boundaryGb1ece617d073c62cc4160ab5112110
MIME-Version: 1.0
From: Callorhynchus@monadresse.org
Subject: hmm
,missamys@aol.com,ionacar@aol.com,mlmartin11@aol.com,johnonel@aol.com

-- Suit alors une longue liste d'emails, qui se termine par

Message-Id: <20060214154643.8239C1C0009B@mwinf1209.wanadoo.fr>
X-me-spamlevel: low
X-me-spamrating: 60.253081
__________________________

Questions :

A) est-ce normal que la méthode post puisse être simulée?
B) pourquoi, alors que l'adresse de la fonction mail dans la feuille php ne
contenait qu'un seul destinateur, cet email a été envoyé à d'autres???
C) Pourquoi y a -t-il deux champs subjects dans les entêtes?
D) que faire pour se protéger de ça? A part bien sûr ce que j'ai déjà
effectué, à savoir effacer les deux feuilles??
E) est-ce moi qui suis un sombre crétin?????

Pour info : serveur apache 2.0.55
Php 5.1.2

Merci pour vos réponses, et mes excuses à la communauté pour avoir servi,
contre ma volonté, la très mauvaise cause des spammeurs
:-(((((((((((((((((((
Vos réponses Page 1 / 3
Trier par : date / pertinence
Xavier Roche
Le #831489
SvS wrote:
Je m'explique :
1) une page html classique, qui contient quatre champs : un nom d'émeteur,
un email d'émeteur, un sujet, et un message, en utilisant les champs FORM et
la méthode POST.


C'est le grand classique du cgi non protégé et détourné de son
utilisation. Une technique fameuse, tout comme celle de l'inclusion de
page à partir d'un paramètre de la query permettant l'injection de code
hostile sur le serveyr.

Trois grosses erreurs a mon avis ont été commises ici:
- la première, c'est d'avoir laissé un cgi buggé en ligne :p
- la deuxième, c'est de ne pas garder une trace (Date: + X-IP: par
exemple) dans les en têtes du message envoyé, histoire de pouvoir
remonter en cas de problème
- la troisième, c'est de ne pas avoir réagi au quart de tour dès que des
choses suspectes se sont produites sur le serveur (notamment ne pas
avoir tout coupé et prévenu qui de droit)

Regardons maintenant d'où provient la faille.

$too = "";
$from_e = $_POST['emaille'];
..

$h = "MIME-version: 1.0rn";
$h .= "Content-type: text/html; charset=iso-8899-1rn";
$h .= "From: ".$from_n.' ..

mail($too, $sbj, $message, $h);


Perdu! La commande mail() ci-dessous prend comme 4è paramètre
"additional headers". Ce paramètres est très dangereux car il est
interprété par le système de livraison, notamment sur d'éventuels
en-têtes CC ou BCC.

mail($too, $sbj, $message, $h);


Exemple:
mail("", "Salut!", "Bonjour", "CC: :
");

Va non seulement envoyer vers , mais aussi vers
et

Or, votre script comporte l'intégration de données du POST non échappées
et non contrôllées directement dans les en-têtes:

$from_e = $_POST['emaille'];
$h .= "From: ".$from_n.'
Donc si from_e contient un retour chariot, vous êtes cuits ; comme part
exemple avec $from_e="rnCC:
fermant apres" ; qui enverra le mail également à


3) en l'espace de 24h, je reçois plus de 600 emails venant de cette page. Je
regarde mon log, effectivement, je vois les lignes qui contiennent les POST,


Prévenez tout d'abord votre FAI immédiatement en lui expliquant la
situation (éventuellement avec un courrier), car il va probablement
recevoir des plaintes très rapidement et peut être susceptible de fermer
votre compte. Donnez-lui les logs de connexion éventuellement (IP et
date du petit malin)

5) je regarde les emails qui m'ont été envoyé sur , et
effectivement, je vois pour la plupart des emails de spam une liste
d'adresses dans un deuxième champ "subject". Extrait de l'une d'entre elle :

From: <Callorhynchus
Content-Type: multipart/mixed; boundaryGb1ece617d073c62cc4160ab5112110
MIME-Version: 1.0
From:
Subject: hmm


Ah, ce crétin n'a même pas fait ça de manière propre! En gros il a
injecté $from_e="<CallorhynchusrnContent-Type: multipart/mixed;
boundaryGb1ece617d073c62cc4160ab5112110rnMIME-Version: 1.0rnFrom:
: hmmrnCC:...".

A) est-ce normal que la méthode post puisse être simulée?


Il n'y a pas de simulation. Le spammeur a injecté les données du post
comme le ferait un navigateur. Il n'y a aucune différence.

Il a peut être même utilisé une page web locale, avec un POST sur votre
cgi, et un TEXTAREA en avec comme nom de champ from_e (vu le niveau
minable de la bidouille, c'est probable)

B) pourquoi, alors que l'adresse de la fonction mail dans la feuille php ne
contenait qu'un seul destinateur, cet email a été envoyé à d'autres???


La fonction mail() est décidément bien dangereuse!

D) que faire pour se protéger de ça? A part bien sûr ce que j'ai déjà
effectué, à savoir effacer les deux feuilles??


Echapper systématiquement tout ce qui peut être injecté dans les
en-têtes. Notamment, filtrer tout retour chariot, ou même envoyer une
erreur 500 dès qu'il est détecté ; par exemple:

if (strpos($from_e, 'n') !== false) {
header("HTTP/1.0 500 Go to hell and die!");
exit(1);
}

E) est-ce moi qui suis un sombre crétin?????


Je n'aurais pas dit cela en ces termes :p

Pour info : serveur apache 2.0.55
Php 5.1.2


Pour info, c'est amha pour cette raison que certains hébergeurs comme
online ont retiré la fonction mail(), pour une fonction customizée, mais
"sécurisée".

Jean-Francois Ortolo
Le #831490
SvS wrote:
[Moderation]
Attention, cet article est posté dans deux groupes et le FU2
n'etait pas positionné.

J'ai pris sur moi de le positionner sur fr.comp.securite car :

- amha le problème est bien plus général que le php
(vérif des entrées, toussa :) )

- il vaut mieux éviter des réponses à droite et à gauche dans ce cas
Si vous n'êtes pas d'accord avec ce FU2 merci de le repositionner

Eric Razny.
Co-modérateur de fr.comp.securite
[fin de modération]


Bonjour,

j'ai très honte de moi, je pensais avoir bien sécurisé mes pages web, mais
j'ai été victime d'un hack monstrueux sur une page qui était censée
m'envoyer un email.

Je m'explique :
1) une page html classique, qui contient quatre champs : un nom d'émeteur,
un email d'émeteur, un sujet, et un message, en utilisant les champs FORM et
la méthode POST.

2) ces données sont envoyées à une page php qui les récupère, et qui
contient une commande mail qui contient en dur mon adresse email. Extrait de
la feuille php
_____________________________________________
$too = "";
/* Ce qui vient du post */
$subject = $_POST['title'];
$from_n = $_POST['realname'];
$from_e = $_POST['emaille'];
$message = $_POST['comments'];
if ($from_n<>"") $mister = $from_n; else $mister = $from_e;

/* divers tests */
if ($from_e=='') { errmess("Vous n'avez pas mis votre
email...",$url_from,$css_f); }
if ($message=='' & $subject=='') { errmess("Vous avez oubli&eacute; le
sujet et le petit message...",$url_from,$css_f); }

$h = "MIME-version: 1.0rn";
$h .= "Content-type: text/html; charset=iso-8899-1rn";
$h .= "From: ".$from_n.' $sbj = stripcslashes($subject);
$message = stripcslashes($message);

mail($too, $sbj, $message, $h);
______________________________________


3) en l'espace de 24h, je reçois plus de 600 emails venant de cette page. Je
regarde mon log, effectivement, je vois les lignes qui contiennent les POST,
venant de diverses adresses email. Dans l'urgence je bloque mon site, puis
j'efface la feuille htm et la feuille php

Bon, je me dis "ce n'est pas grave", il n'y a que moi qui a reçu ce spam

4) M...... j'ai servi de relais, car les emails de spam ont bien été
redistribués à des centaines de personnes... Je le sais, car sur mon adresse
de retour (celle de mon serveur apache), j'ai reçu plus de 800 avis de non
délivrance....

5) je regarde les emails qui m'ont été envoyé sur , et
effectivement, je vois pour la plupart des emails de spam une liste
d'adresses dans un deuxième champ "subject". Extrait de l'une d'entre elle :
________________________________________________
Date: Tue, 14 Feb 2006 16:46:43 +0100
Subject:
To:
MIME-version: 1.0
Content-type: text/html; charset=iso-8899-1
From: <Callorhynchus
Content-Type: multipart/mixed; boundaryGb1ece617d073c62cc4160ab5112110
MIME-Version: 1.0
From:
Subject: hmm
,,,,

-------------- Suit alors une longue liste d'emails, qui se termine par

Message-Id: X-me-spamlevel: low
X-me-spamrating: 60.253081
__________________________

Questions :

A) est-ce normal que la méthode post puisse être simulée?
B) pourquoi, alors que l'adresse de la fonction mail dans la feuille php ne
contenait qu'un seul destinateur, cet email a été envoyé à d'autres???
C) Pourquoi y a -t-il deux champs subjects dans les entêtes?
D) que faire pour se protéger de ça? A part bien sûr ce que j'ai déjà
effectué, à savoir effacer les deux feuilles??
E) est-ce moi qui suis un sombre crétin?????

Pour info : serveur apache 2.0.55
Php 5.1.2

Merci pour vos réponses, et mes excuses à la communauté pour avoir servi,
contre ma volonté, la très mauvaise cause des spammeurs
:-(((((((((((((((((((


Certes

La "feuille" php qui reçoit les données du formulaire en POST, a
servi directement au hackeur.

Et, oui, dès lors que le hacker a visualisé la source de la page html
contenant le formulaire, il est très facile, de simuler un envoi en
POST, à ta feuille php, de toutes les données imaginables pour envoyer
n'imoorte quel nombre d'emails. Ceci même de façon rapide, répétée, et
automatique.

La parade: Peut-être un filtrage sur les adresses emails à envoyer et
lerus nombres, associé à une mémorisation du nombre d'emails envoyés à
chaque adresses emails, avec une limite maxi de ce nombre, codée en dur
dans le feuille php.

D'autre que moi pourraient donner plus de précisions pour la parade,
moi je ne fais jamais d'envois d'email par PHP... D'ailleurs ton script
est un excellent example pour moi... ;)

Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com

Christophe Meresse
Le #831487

Questions :

A) est-ce normal que la méthode post puisse être simulée?


Oui, Il suffit de se créer sa propre page locale qui post vers ta
page.
Ca peut-être évité par certaines techiques du style texte sous forme
d'image générée déformée que l'utilisateur doit re-écrire
(L'inconvenient est que cela rend le service inaccessible aux
malvoyants). Il existe d'autres solutions mais je ne les ai plus en
tête.

B) pourquoi, alors que l'adresse de la fonction mail dans la feuille php ne
contenait qu'un seul destinateur, cet email a été envoyé à d'autres???
C) Pourquoi y a -t-il deux champs subjects dans les entêtes?


Mon avis sans y regarder de près c'est que le hacker s'est servi d'un
de tes champs pour y inserrer l'ensemble des champs d'un mail à
envoyer, un peu comme on fait de l'insertion de SQL dans un champs pour
une base de donnée. C'est pour ca qu'on retrouve deux champs Subject
mais aussi deux champs From, etc...

Il faut que tu testes plus le contenu des champs que ton formulaire
t'envoies.

D) que faire pour se protéger de ça? A part bien sûr ce que j'ai déjà
effectué, à savoir effacer les deux feuilles??


Voir ma réponse à A

E) est-ce moi qui suis un sombre crétin?????


Béh non... je suis certain que tu y penseras à chaque fois que tu
feras un formulaire maintenant :) (De la même manière on peut remplir
un bdd comme ca...)

Bonne journée
Christophe

MIMATA
Le #831485
est-ce moi qui suis un sombre crétin?????


Bonjour,

De crainte d'être le prochain "sombre crétin" sans que ce soit dit en ces
termes :-D je voudrais savoir s'il existe un site ou autre qui permet de
tester nos propres formulaires et simuler des attaques afin de savoir si
nous sommes vulnérables et ainsi nous aider à détecter les points faibles de
nos scripts...parfois réccupérés ici ou là sans beaucoup de précautions... ?
En gros, je voudrais hacker mes propres formulaires pour les tester en
live...

Merci pour les infos

R12y
Le #836069
MIMATA :

En gros, je voudrais hacker mes propres formulaires pour les tester en
live...


C'est bof bof comme principe.
Pourquoi?
Imagine que tu aies réussi à trouver un site vulnérabe, comme celui du
posteur original, alors pour l'embeter il te suffirait de te servir d'un
tel site.
Le souci c'est que c'est le webmaster dudit site qui s'en prendra plein la
bouche en cas de procès, parceque les tentatives viennent de sont système.
Parceque rien ne prouve que tu va te servir de cet outil _que_ pour ton
site.

--
Debian/apt Repo: http://locataire-serveur.info/sections/liens/debian-repository
Fedora/yum Repo: http://locataire-serveur.info/sections/liens/fedora-core-yum

Nicob
Le #836070
On Sat, 18 Feb 2006 14:59:01 +0000, MIMATA wrote:

En gros, je voudrais hacker mes propres formulaires pour les tester en
live...


Soit tu te formes toi-même, grâce à l'abondante documentation disponible
sur le Net (par exemple chez l'Owasp), soit tu soumets ici un lien vers
les scripts en question, avec le code source et tout, afin que de gentils
bénévoles y jettent un oeil et te fassent un retour sur la sécurité
apparente de la chose ...


Nicob

MIMATA
Le #836066
Nicob wrote:
On Sat, 18 Feb 2006 14:59:01 +0000, MIMATA wrote:

En gros, je voudrais hacker mes propres formulaires pour les tester
en live...
J'aurais pas du ajouter cette phrase... :-/



Soit tu te formes toi-même, grâce à l'abondante documentation
disponible sur le Net (par exemple chez l'Owasp),
C'est ce que je suis en train de faire mais au regard de ce qui se dit sur

le sujet et au vu des explications parfois très techniques de spécialistes
du PHP (ce que j'espère devenir un jour...), j'ai bien peur d'avoir encore
beaucoup de chemin à parcourir avant d'arriver à maîtriser tous les aspects
de la sécurisation d'un formulaire.

soit tu soumets ici
un lien vers les scripts en question, avec le code source et tout,
afin que de gentils bénévoles y jettent un oeil et te fassent un
retour sur la sécurité apparente de la chose ...
Je comprends mais un peu pour les mêmes raisons que celles qu'avance R12y je

préfèrerais faire les tests moi même parce qu'un petit malin pourrait
trouver une faille et m'exploser mon site pour enfin conclure : GAME OVER,
ton site n'était pas bien sécurisé, quel dommage sombre crétin !!!
J'imagine que les gens qui s'amusent à hacker des sites sont déjà bien
formés et qu'ils maitrise bien toutes ces questions de sécurité...de plus,
ils sont peut-être parmi nous... :-$


MIMATA
Le #836067
R12y wrote:
MIMATA :

En gros, je voudrais hacker mes propres formulaires pour les tester
en live...
J'aurais vraiment pas du ajouter cette phrase... :-/



C'est bof bof comme principe.
Pourquoi?
Imagine que tu aies réussi à trouver un site vulnérable, comme celui du
posteur original, alors pour l'embêter il te suffirait de te servir
d'un tel site.
Ma demande n'avait pas ce but mais il est tout à fait exact que rien ne le

prouve. Ceci dit, je demandais des scripts inoffensifs et tu me diras que
avec un script de base, on peut tout à fait le transformer pour en faire un
script agressif. Le problème avec ces questions de sécurité, c'est que tout
est théorique et
les neuneus comme moi, qui se forment sur le tas, qui n'ont pas une
formation de programmation pointue, ne peuvent que lire des explications qui
sont la plupart du temps très techniques et dont on ne saisi pas tout les
aspects (c'est peu dire...).
Faute d'exemples précis, la majorité d'entre nous ne peuvent que constater
les
dégâts et un beau jour on se réveille en disant : "tiens, mon formulaire à
envoyé des milliers de spams pendant mon WE, mon site à disparu, mon
hébergeur m'a foutu dehors et maintenant je reçois des centaines de mails
d'insultes..." et ce jour là, c'est trop tard.
C'est un cercle vicieux : pour ne pas encourager ces pratiques, on bloque
l'information aux amateurs, du coup ils ne savent pas bien se protéger et
les mecs qui savent déjà peuvent tranquillement utiliser des milliers de
sites pour commettre leurs forfaits. Et si on donne les clés facilement,
plein de petits cons vont se prendre pour Néo et s'amuser à essayer de
foutre en l'air des sites "concurrents" ou celui du mec qui nous à un peu
énervé sur un forum. C'est un peu un dilemme que je conçois très bien mais
en même temps, le problème reste le même : beaucoup de sites ne sont pas
protégés, beaucoup de personnes ne savent pas comment se protéger et ne le
saurons probablement jamais et beaucoup de sites continuerons à servir de
relais pour polluer le réseau.


Le souci c'est que c'est le webmaster dudit site qui s'en prendra
plein la bouche en cas de procès, parce que les tentatives viennent de
sont système. Parce que rien ne prouve que tu va te servir de cet
outil _que_ pour ton site.
En fait je pensais à un site qui proposerait des scripts inoffensifs ayant

pour seul but de tester, le site en lui même ne ferait pas d'attaque, il
proposerait juste des scripts que je pourrais moi même coller dans mes
champs et qui serait conçus pour déceler les failles, pas pour tout niquer.


R12y
Le #836064
MIMATA :
le sujet et au vu des explications parfois très techniques de spécialistes
du PHP (ce que j'espère devenir un jour...),


Je t'arrete tout de suite:
La sécurisation d'un script ou programme quelconque passe d'aord par une
bonne conception.
Ce que je veux dire par là c'est qu'avant de maîtriser PHP ce que tu
devrait rechercher c'est avoir de bonnes bases d'algorithmique.
Juste pour information, il y a un groupe consacré à l'algorithmique:
fr.comp.algorithmes.

Je comprends mais un peu pour les mêmes raisons que celles qu'avance
R12y je préfèrerais faire les tests moi même


Ca me fais penser à un truc.... :-)
Il y a une nouvelle mode de nos jours, la programmation dirigée par les
tests.
En gros, tu programme d'abord les tests que ton programme doit passer et
ensuite du fait le programme.

Tu pourais donc t'en inspirer... Ca t'interesse d'avoir un peu de détails
sur la manière de mener les choses sous cet angle?

--
Debian/apt Repo: http://locataire-serveur.info/sections/liens/debian-repository
Fedora/yum Repo: http://locataire-serveur.info/sections/liens/fedora-core-yum

MIMATA
Le #835810
R12y wrote:
La sécurisation d'un script ou programme quelconque passe d'abord par
une bonne conception.
Le truc c'est que je voudrais tester les scripts que j'ai intégré sur mes

sites mais que d'autres personnes ont programmé, il s'agit d'un test a
posteriori. Je ne suis pas encore assez au point pour pouvoir juger de la
sécurité d'un prog juste en lisant le code.

Il y a une nouvelle mode de nos jours, la programmation dirigée par
les tests.
En gros, tu programme d'abord les tests que ton programme doit passer
et ensuite tu fais le programme.
Tu pourais donc t'en inspirer... Ca t'interesse d'avoir un peu de
détails sur la manière de mener les choses sous cet angle?
Bien sûr !


Publicité
Poster une réponse
Anonyme