reponses a une intrusion

LaDDL nous disait récement dans fr.comp.securite
<news:3f5e45c8$0$9224$79c14f64@nan-newsreader-03.noos.net> :

[En préambule, où sont les modérateurs ici ?!

Ils sont là, ils sont las...

Que vient faire ce post ici ?

Il répond aux critères de modération, qui impliquent une approbation
par défaut "sauf quand..."

Apporte-t-il un complément d'information à la discussion ?

Oui, même si ces arguments sont parfois proches de l'ad hominem.
C'est moi qui l'ai approuvé, après l'avoir laissé trainé une petite
heure dans la file d'attente, le temps de me décider sur son sort.
Peut-être n'aurais-je pas dû, peut-être pas. Toujours est-il que je
l'ai trouvé bien plus pertinant qu'il n'y parait à première vue, et
cela malgré son ton assez léger.

Je me pose la question car en général vous refusez ce genre de post.

Non, ce n'est pas pour cela que tu te poses la question, et tu le sais
parfaitement.

Donc pourquoi cette exception ?]

Sans doute parce que cela fait deux semaines que l'on approuve tes
messages, non parce qu'ils ont un sens ou un fond en eux-mêmes, mais
parce que les réponses qu'ils génèrent en ont un et abordent un aspect
de la sécurité informatique qui est parfois oublié et/ou négligé. Nous
sommes déjà deux modérateurs à te l'avoir dit à demi-mot dans nos
réponses à tes messages.

Cependant, j'estime pour ma part que les différents intervenants ont
maintenant fait le tour du sujet. Par conséquent, les vacances sont
finies aussi pour les-dits intervenants et, à moins d'arguments chocs
ou de réponse concernant explicitement le sujet initial de la
discussion, tous les messages intitulés "Re: reponse a une intrusion"
seront renvoyés à leur auteur.
Pour l'instant, je laisse une chance aux discussions dérivées, à leurs
intervenants de faire preuve de maturité dans leur argumentation.


Fu2 (Suivi de la discussion) sur la mailing-list de modération
--
Stéphane Catteau Co-modérateur de fr.comp.securite
Pour joindre l'équipe de modération <mailto:fcs-mods@lists.freenix.org>
Les conseils d'utilisation <http://fr.comp.securite.free.fr/cu.htm>

Dans sa prose, LaDDL nous ecrivait :

Cedric Blancher wrote:

Si tu veux que ton malware reste dans l'espace de confiance, il faut que
tu en contrôle la diffusion, non ?
Précision : je ne dit pas que le malware doit rester dans l'espace de

confiance.

L'espace de confiance comprends aussi, pour moi, les gens, et donc leurs
systèmes, qui ont accès au système de diffusion.

Sinon bien sûr on peut contrôler, suivre sa diffusion.

On peut la suivre sa diffusion ou pas ? Je pense venir de te donner un
exemple où la diffusion d'un code source ne peut être suivie, fait avec
lequel tu sembles d'accord.

Oui, je lui ai répondu la mm chose qu'à toi (avec d'autres termes).

J'ai pas dû lire le bon post.

Lesquelles ?
Par exemple la signature du code ou de l'application.

Ah ouais. Parce que le mec, il va laisser la signature. Ils sont sympas
les pirates dans ton monde.

On peut voir bien entendu toutes les possibilités d'erreurs, de
malveillances, etc... mais la technologie de signature numérique
utilisée et très complexe (cf l'url en bas de mon post du Date: Sun,
07 Sep 2003 20:14:22 +0200 pour plus de détails sur la technologie)

Juste une remarque : pour trouver les articles, c'est plus simple avec le
message-id... Parce que là, j'ai du mal à trouver quelquechose de
précis autre que "certification, signature".

Je n'ai pu être présent à la conférence. Sinon y a t il un CR en
ligne sur le site ?

Sur le site web, suffit de suivre les liens, il y a tous les supports de
conférence (articles et slides). Suffit d'ouvrir son navigateur.

--
BOFH excuse #35:

working as designed

Dans sa prose, LaDDL nous ecrivait :

Signer du code binaire puis le binder ne change pas le problème de la
signature numérique même si elle est compressée ou encryptée. On
pourra toujours la décrypter.

Ou la supprimer...

--

Subject: pb fvwm95-2 comment l'installer le compiler???
Merci d'avance
je te conseille d'être un peu plus précis dans l'exposé de ton pb...

-+- EJ in guide du linuxien pervers :"Les modéros sont sympas !" -+-

"LaDDL" <alamaison@noos.fr> a écrit dans le message de
news:3f5e4dd6$0$20315$79c14f64@nan-newsreader-01.noos.net...

Cedric Blancher wrote:

En outre dans ton exemple s'il y a délit ou infraction on dispose d'un
certain nombre d'informations qui permettront de remonter jusqu'au
diffuseur.

Lesquelles ?
Par exemple la signature du code ou de l'application.

Une fois de plus ça ne répond pas à la question.
L'immense majorité des tests de vulnérabilités sont des codes sources[1]. Tu
as reconnu toi même (implicitement) que l'on ne pouvait marquer efficacement
un tel code.
De plus ta réponse implique que la diffusion des exploits est marqué au vol
en fonction de l'id du downloader[2]. Or :
a) dans le cas d'un doc ascii ce genre de marquage ne sera pas discret!
b) dans le cas d'un prog "fermé", outre qu'un desassemblage permet de
récupérer l'algo raisonnablement facilement quand il s'agit de petits progs
de ce type, une simple vérification de la différence entre les progs reçus
par deux utilisateurs légitimes va commencer à donner des infos
interressantes sur le processus[3]

En tant que professionnel tu dois savoir[4] que si l'obscurité peut aider
(changement de bannières par exemple) il est illusoire et dangereux de baser
la sécurité sur ce seul principe. Il s'ensuit que la façon de signer le code
sera probablement à un moment ou un autre publique. Or le but du
"malfaisant" ici n'est pas de faire croire qu'un exploit est signé mais
simplement de se débarrasser de la signature.

Il est bien entendu que même du code crypté doit être à un moment ou un
autre décrypté. Pour un petit exploit la déportation de l'exécution d'une
partie du code (fonction excécutée en externe, paramètre récupérés à
distance à l'exécution) est peu envisageable. Sans compter qu'un admin sécu
ou réseau sensé ne va pas permettre à une appli de balancer n'importe
quoi[5] sur son réseau interne.

Si tu as un contre exemple je suis curieux de le connaitre.

La seule infraction que je vois est le non respect du contrat
qui régit l'accès au système de diffusion de la personne source de la
fuite (celle qui a mis l'objet sur disquette). Pour un peu qu'elle soit
root sur son système, tu auras du mal à tracer le fait que tel fichier
ait été copié sur tel support, en particulier si celui-ci est un
support genre clé USB (pas de trace spécifique au périphérique
d'écriture, celui-ci est intégré au médium).
On peut voir bien entendu toutes les possibilités d'erreurs, de

malveillances, etc... mais la technologie de signature numérique
utilisée et très complexe (cf l'url en bas de mon post du Date: Sun, 07
Sep 2003 20:14:22 +0200 pour plus de détails sur la technologie)

Elle n'a pas besoin d'être très complexe (complexité d'ailleurs signifie
souvent problème d'implémentation et de maintenance :) ). Les systèmes
actuels sont largement suffisant et se fondent généralement sur la
difficulté de résolution de problèmes connus. Pour plus de précaution on
peut envisager de doubler la signature en utilisant deux problèmes qui ne
sont (sauf découverte) pas liés, de telle sorte que le cassage de l'un ne
compromette pas le système global de signature. Un petit tour sur
fr.misc.cryptologie suffit pour s'en rendre compte (tiens ils ont un
lheureux la bas, qui me rappelle quelqu'un :) )

Eric.

[1] directement ou indirectement, comme des paquets à envoyer sur un port
via un soft quelconque.
[2] sinon plusieurs utilisateurs vont avoir le même code, ce qui implique
qu'on ne peut plus trouver l'origine de la fuite.
[3] suivant la complexité du système plusieurs essais ou un plus grand
nombre de participants peuvent être "utiles".
[4] <mode gag> c'est volontairement ici que j'utilise une des formules que
je dénonce "il est évident que, tout le monde sait que..."
[5] puisque les paquets auraient pu être composés en externe.

Cedric Blancher wrote:

L'espace de confiance comprends aussi, pour moi, les gens, et donc leurs
systèmes, qui ont accès au système de diffusion.
Cela va sans dire.

On peut la suivre sa diffusion ou pas ?
Oui.

Je pense venir de te donner un
exemple où la diffusion d'un code source ne peut être suivie, fait avec
lequel tu sembles d'accord.
Oui dans ton exemple.

Non dans notre environnement. Mais bis repetita on en reparle dans qq
mois.

Ah ouais. Parce que le mec, il va laisser la signature. Ils sont sympas
les pirates dans ton monde.
lol

Il est difficile de l'effacer ou de la falsifier.

Juste une remarque : pour trouver les articles, c'est plus simple avec le
message-id... Parce que là, j'ai du mal à trouver quelquechose de
précis autre que "certification, signature".
Bon comme avec Eric je communique à nouveau l'url + 2 autres afin que tu

puisses comprendre d'où nous sommes partis.
- http://www.cyber.ee/
- http://www.timestamp.cyber.ee/
- http://www.openevidence.org/

Cedric Blancher wrote:

Dans sa prose, LaDDL nous ecrivait :

Signer du code binaire puis le binder ne change pas le problème de la
signature numérique même si elle est compressée ou encryptée. On
pourra toujours la décrypter.

Ou la supprimer...
Oui et/ou la falsifier sur la base de ton exemple en tout cas.

Eric Razny wrote:

Une fois de plus ça ne répond pas à la question.
Bonjour Eric, fouilles un peu sur le site que je t'ai communiqué et tu

finiras par trouver des réponses à cette fameuse question.

Allez je vais être sympa, je communique une nvlle fois l'url du site et
les liens directs vers ce qui vous interesse :
- http://www.cyber.ee/
- http://www.timestamp.cyber.ee/
- http://www.openevidence.org/

L'immense majorité des tests de vulnérabilités sont des codes sources[1]. Tu
as reconnu toi même (implicitement) que l'on ne pouvait marquer efficacement
un tel code.
Oui. (cf infos communiquées ultérieurement + ci-dessus)

De plus ta réponse implique que la diffusion des exploits est marqué au vol
en fonction de l'id du downloader[2].
Même si ce que tu dis est de l'ordre du possible, vraisemblable. On en

reparlera dans qq mois qd on publiera nos travaux.

Or :
a) dans le cas d'un doc ascii ce genre de marquage ne sera pas discret!
Cela dépend du langage utilisé.

b) dans le cas d'un prog "fermé", outre qu'un desassemblage permet de
récupérer l'algo raisonnablement facilement quand il s'agit de petits progs
de ce type, une simple vérification de la différence entre les progs reçus
par deux utilisateurs légitimes va commencer à donner des infos
interressantes sur le processus[3]

En tant que professionnel tu dois savoir[4] que si l'obscurité peut aider
(changement de bannières par exemple) il est illusoire et dangereux de baser
la sécurité sur ce seul principe.
Ce n'est pas le principe retenu dans notre démarche.

Il s'ensuit que la façon de signer le code
sera probablement à un moment ou un autre publique.
Peux-tu expliciter je ne comprends pas bien ce que tu entends par rendu

"public".

Or le but du
"malfaisant" ici n'est pas de faire croire qu'un exploit est signé mais
simplement de se débarrasser de la signature.
Oui ce pourrait être son objectif. Comme de la falsifier aussi.

Dans sa prose, LaDDL nous ecrivait :

Oui dans ton exemple.
Non dans notre environnement. Mais bis repetita on en reparle dans qq
mois.

OK, donc je peux considérer que ton environnement ne diffuse pas de code
source, mais uniquement des formats binaires.
Quid de la documentation, type Phrack par exemple ?

Il est difficile de l'effacer ou de la falsifier.

Dans mon exemple, il ne sera pas vraiment difficile de l'effacer. La
falsifier, c'est un autre problème.

Bon comme avec Eric je communique à nouveau l'url + 2 autres afin que
tu puisses comprendre d'où nous sommes partis.
- http://www.cyber.ee/
- http://www.timestamp.cyber.ee/
- http://www.openevidence.org/

c'est pas d'où tu pars mon problème, c'est où tu arrives ;)))
Mais j'y cours quand même.

--
j ai ete sur le site et j ai decouvert le programme. a quel niveau y a
til un probleme? Merci d eclairer ma lanterne. si je pouvais ne pas
etre traiter de gugusse, ce serait tres gentil de votre part...
-+- phjl in GNU : S'il te plait monsieur, dessine moi un neuneu -+-

Dans sa prose, LaDDL nous ecrivait :

Ou la supprimer...
[La signature]

Oui et/ou la falsifier sur la base de ton exemple en tout cas.

Je ne vais pas t'apprendre que même dans l'exemple que je te cite, la
falsification de la signature n'est pas possible sans que te vole ta clé
privée (ou alors, tu utilises un bien piètre système de signature) ? Et
si j'ai en ma possession ta clé privée, l'impact sur ton système ne se
limitera plus à ce bête exemple...

--
« Excusez-moi, je n'ai pas pu m'en empêcher... »
-+- CF in GNU - fufe, c'est plus fort que toi -+-

Cedric Blancher wrote:

OK, donc je peux considérer que ton environnement ne diffuse pas de code
source, mais uniquement des formats binaires.
Quid de la documentation, type Phrack par exemple ?
lol

Ok on va résumer et reprendre depuis le début.

Nous avons imaginé un système de trading/espace de confiance pour les
malwares (tous types de codes, applications, etc).

Projet orienté Open Source. Accessible en ligne d'ici qq mois.

Notre constat : trop de malwares [malicious software] sont en libre
service et accessibles par des inconscients ou des personnes
malintentionnées.

Notre objectif : améliorer le travail collaboratif sur tous types de
codes, security tools, etc. Encadrer et sécuriser les échanges.
Contrôler les dérives, dérapages, etc.

Inspirés par des projets de certification de documents et de réseau
distribué nous travaillons dessus depuis six mois en parallèle de nos
activités professionnelles.

Donc pour le détail des technologies employées on aura l'occasion d'en
reparler. ;)

Dans mon exemple, il ne sera pas vraiment difficile de l'effacer.
On est d'accord.

La
falsifier, c'est un autre problème.
J'en conviens.

c'est pas d'où tu pars mon problème, c'est où tu arrives ;)))
J'espère que l'explication fournie ci-dessus t'apportera des

éclaircissements.

Mais j'y cours quand même.
Pas trop vite ;)