Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

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

27 réponses
Avatar
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\r\n";
$h .= "Content-type: text/html; charset=iso-8899-1\r\n";
$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; boundary=47b1ece617d073c62cc4160ab5112110
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
:-(((((((((((((((((((

7 réponses

1 2 3
Avatar
MIMATA
Fabien LE LEZ wrote:
On 20 Feb 2006 18:45:22 GMT, MIMATA :

existe-t-il un site qui permet de tester nos
formulaires ?


Je vois déjà trois problèmes :


1- Le problème légal.

La justice ne semble pas faire de différence entre quelqu'un qui
cherche des failles pour envoyer du spam, et quelqu'un qui cherche des
failles pour aider l'auteur à les réparer.
C'est qu'en général, les auteurs de ces "tests" ne demandent pas

l'autorisation avant d'agir, ils attaquent et disent ensuite : "vous voyez,
on a démontré que votre site était vulnérable..."

Donc, faire un tel site risquerait de s'avérer dangereux.
En tout cas, ne compte pas sur moi pour prendre le risque.
Comme je le disais dans un post précédent, je pensais à des scripts "non

destructeurs" qu'on mettrait soi même.

2- La compétence de l'auteur du site.

Imaginons qu'un gars crée un tel site. Qu'est-ce qui me prouve qu'il
est plus compétent que moi, et saura repérer des failles que je
n'aurais pas vues ?
Ben s'il en détecte au moins une partie, c'est déjà ça. En tout cas, il sera

plus compétent que moi...

3- La faisabilité technique.

Pour la faille dont on parle ici, c'est relativement simple : il
suffit d'essayer de rentrer
": é.com", et voir si ça marche.
Et ben voilà !



Ok, compris, merci


Avatar
Jeremy JUST
Le 19 Feb 2006 22:49:56 GMT,

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.


Pas sûr que ça ait un rapport direct, mais, bon.



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.


Ça me semble une drôle d'approche pour la sécurité. En gros, le
programme final ne saura résister qu'aux attaques que son développeur
a su réaliser. C'est un peu risqué, non?


Dans la vrai vie, ça voudrait dire se contenter d'une serrure type
Vachette à un point sur une porte en bois, parce que:
- je sais crocheter une serrure plus simple,
- je ne sais pas crocheter une serrure de ce type,
- je n'ai ni pied de biche ni vérin pour enfoncer la porte,
- je ne vais quand même pas mettre le feu à ma porte juste pour mes
tests.

Mais mes tests ne veulent pas dire que quelqu'un de plus compétent ou
résolu ne saura pas crocheter ma serrure de sécurité ou enfoncer/brûler
ma porte.



Pour avoir quelques grandes idées sur la sécurité des programmes, ce
document fait une bonne introduction:
http://www.dwheeler.com/secure-programs/

Si je me souviens bien, il évoque aussi quelques problèmes
spécifiques à PHP.


--
Jérémy JUST

Avatar
Nicob
On Tue, 21 Feb 2006 15:43:06 +0000, Vincent Bernat wrote:

Je ne connais malheureusement pas de framework pour les formulaires en
PHP, mais je pense qu'il en existe un certain nombre.


Certaines sociétés commercialisent des bibliothèques de fonctions
PHP/ASP/... filtrant ou vérifiant les entrées faites par un utilisateur.
Dans le monde du gratuit, il existe au moins ça :

http://www.owasp.org/software/validation.html
http://www.owasp.org/software/labs/phpfilters.html


Nicob

Avatar
Fabien LE LEZ
On 21 Feb 2006 15:43:06 GMT, MIMATA :

N'empêche, les RFC, c'est bien compliqué quand même non ?


Pas spécialement. Il faut juste faire l'effort d'en lire quelques-unes
pour s'habituer au style un peu particulier.

Avatar
Thierry Thomas
Mardi 21 février 2006 à 23:54 GMT, Nicob a écrit :

Je ne connais malheureusement pas de framework pour les formulaires en
PHP, mais je pense qu'il en existe un certain nombre.


Certaines sociétés commercialisent des bibliothèques de fonctions
PHP/ASP/... filtrant ou vérifiant les entrées faites par un utilisateur.
Dans le monde du gratuit, il existe au moins ça :

http://www.owasp.org/software/validation.html
http://www.owasp.org/software/labs/phpfilters.html


Voir aussi DB_Table et HTML_QuickForm chez PEAR :

<http://pear.php.net/package/DB_Table>.
--
Th. Thomas.


Avatar
R12y
Jeremy JUST :

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.


Ça me semble une drôle d'approche pour la sécurité. En gros, le
programme final ne saura résister qu'aux attaques que son développeur
a su réaliser. C'est un peu risqué, non?


Mais que tu fasses les tests avant ou après la conception, tu dois tester
quand même. autant que ce soit le plus tôt... tu pourras au moins te
vnter d'avoir fait de la sécurité un point important. Sans pour autant
être la méthode ultime, c'est à mon sens un moindre mal, au moins.

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


Avatar
Eric Razny
Le Thu, 23 Feb 2006 12:39:58 +0000, R12y a écrit :

Jeremy JUST :

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.


Ça me semble une drôle d'approche pour la sécurité. En gros, le
programme final ne saura résister qu'aux attaques que son développeur
a su réaliser. C'est un peu risqué, non?


Mais que tu fasses les tests avant ou après la conception, tu dois tester
quand même. autant que ce soit le plus tôt... tu pourras au moins te
vnter d'avoir fait de la sécurité un point important. Sans pour autant
être la méthode ultime, c'est à mon sens un moindre mal, au moins.


Ce qui me gêne dans cette façon de faire c'est que je ne vois pas
spécialement où est la sécurité.

Je m'explique.

Imaginons un développeur "faible" en ce qui concerne une
série de protocole dont smtp et qui doit envoyer des emails à partir de
données reçues sans un formulaire (c'est un cas vraiment pris au hazard,
n'est-ce pas? :) ).

Cette personne ne sait qu'utiliser des regexp, récupérer un champ de
manière "brute mais sure"[1], supprimer d'une chaine les caractères non
souhaités.

Si ce développeur qui ne comprends pas grand chose à l'email constitue
le sien en se basant sur un modèle connu (on se fout de savoir si From
peut supporter autre chose par exmple) :

============ From: <adresse email>
To: <adresse email>
Subject: <ascii limité en taille et à [A-Z][a-z][0-9][<quelques autres
symboles, espace..>]>
Content-Type: text/plain;
charset="iso-8859-15"
nn
<Son email>
============
il peut avoir une sécurité convenable en filtrant tous les champs puis
avec les regexp vérifier qu'on a bien *une* adresse email etc...

Reste pour <son email> que certains MUA débiles vont afficher du html
malgré le Content-Type si ça débute par <html> mais ça peut (doit)
aussi se filtrer.

Certe notre utilisateur limite fortement les possibilités des emails
mais il peut pondre un truc fonctionnel et simple. Il a simplement
demandé à quelqu'un que filtrer pour son besoin ( un ; peut être plus
gênant en SQL que pour un email par exemple ;) )

Maintenant il sera simplement incapable de pondre une série de tests
capable de vérifier la sécurité de son appli qui pourtant (voir le PS)
tient la route.

Inversement le testeur fou qui teste son développement en même temps a
toute les chances (risques, mais bon...) de biaiser ses tests en forçant
une attaque contre sa super-parade-qui-tue et en oubliant une attaque
simpliste.

Amha il est important d'avoir des notions de développement sur (ce que
l'OP semble rejeter, pour se contenter de recettes de cuisines qui vont
toujours foirer à un moment ou un autre) et de les appliquer en
comprenant pourquoi c'est important (buffer overflow, paramètre de
formatage foireux pour des printf-like, jeu de caractère limité pour
éviter le XSS et autre échapement en SQL, etc).

Eric

PS : je reste volontairement un peu caricatural pour indiquer ce que je
pense être le fond plus que la forme.

[1] ie si un formulaire web retourne un champ connu avec des données
"trafiquées" notre développeur va récupérer ces données, le côté
"sur" c'est pas de buffer overflow ou de gag de fin de chaine (genre pas
de 0x00 en C sur un char* qui va être traité avec un cmp derrière par
exemple :) )



1 2 3