responsabilite et decouverte de failles

Le
Professeur M
Bonjour à tous

Supposons la situation suivante, pas tout à fait inventée :

Dans une grande entreprise, un DRH exige de d'une partie des employés
qu'ils saisissent - via un logiciel maison - toutes sortes de données
(coordonnées des employés, données relatives à leurs emplois) ce
logiciel est manifestement destiné au flicage du travail des employés.

Ce logiciel envoie les données par une connexion FTP sur un serveur qui
centralise les dossiers.

Un employé du service informatique, agacé par ce logiciel de merde,
découvre qu'il est possible de récupérer les paramètres de connexion au
serveur simplement en sniffant la connexion : adresse, login et mot de
passe circulent en clair. Ceci permet à n'importe qui de récuperer les
fichiers de données.

La faille est signalée par le bricoleur à sa hiérarchie. Le bricoleur se
contente de vérifier par la lecture d'un fichier et l'écriture/effacement
d'un autre qu'il a bien un accès complet au serveur. RIEN n'a été modifié.

Le logiciel est téléchargeable sur le web (référencé par google), son
démarrage nécessite un mot de passe trivial communiqué par courrier aux
employés, inchangé depuis 3 ans et commun à tous les employés.
Bref, l'aspect sécurité à été totalement bâclée.


Quel est la responsabilité de chacun dans ce merdier ?

Peut-on reprocher quoi que ce soit au découvreur de la faille, même si son
intention était bien de mettre les pieds dans le plat et le nez dans le
caca de certains.

Pour le fun, j'ajoute qu'il n'y a vraisemblablement aucune déclaration à
la CNIL du bidule ;-)

Méphisto
--
C'est parce que la lumière est plus rapide que le son que certains
ont l'air brillants avant d'avoir l'air con
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Albert ARIBAUD
Le #14315031
Le Tue, 09 Oct 2007 14:04:56 +0000, Professeur Méphisto a écrit:

Bonjour à tous

Supposons la situation suivante, pas tout à fait inventée :

Dans une grande entreprise, un DRH exige de d'une partie des employés
qu'ils saisissent - via un logiciel maison - toutes sortes de données
(coordonnées des employés, données relatives à leurs emplois...) ce
logiciel est manifestement destiné au flicage du travail des employés.

Ce logiciel envoie les données par une connexion FTP sur un serveur qui
centralise les dossiers.

Un employé du service informatique, agacé par ce logiciel de merde,
découvre qu'il est possible de récupérer les paramètres de connexion au
serveur simplement en sniffant la connexion : adresse, login et mot de
passe circulent en clair. Ceci permet à n'importe qui de récuperer les
fichiers de données.

La faille est signalée par le bricoleur à sa hiérarchie. Le bricoleur se
contente de vérifier par la lecture d'un fichier et
l'écriture/effacement d'un autre qu'il a bien un accès complet au
serveur. RIEN n'a été modifié.

Le logiciel est téléchargeable sur le web (référencé par google), son
démarrage nécessite un mot de passe trivial communiqué par courrier aux
employés, inchangé depuis 3 ans et commun à tous les employés. Bref,
l'aspect sécurité à été totalement bâclée.


Quel est la responsabilité de chacun dans ce merdier ?

Peut-on reprocher quoi que ce soit au découvreur de la faille, même si
son intention était bien de mettre les pieds dans le plat et le nez dans
le caca de certains.

Pour le fun, j'ajoute qu'il n'y a vraisemblablement aucune déclaration à
la CNIL du bidule ;-)

Méphisto



A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer
pour intrusion dans un système informatique ; la facilité de la
manipulation n'y changera rien.

A contrario, la boîte peut effectivement faire l'objet d'une attention
particulière de la CNIL, mais il faut pour ça que cette dernière soit
saisie.

Amicalement,
--
Albert.
Professeur M
Le #14315021
Albert ARIBAUD a écrit :

A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer
pour intrusion dans un système informatique ;



D'accord, mais la manipulation qui a permis de découvrir la faille est
justifiable par la nécessité de faire fonctionner le logiciel client.
Le logiciel est totalement opaque, la documentation technique inexistante.

la facilité de la manipulation n'y changera rien.



Oui, mais le développeur et son commanditaire ne sont-ils pas tenus de
garantir, par ce que j'appellerai de bonnes pratiques de programmation,
la confidentialité des données dont certaines sont personnelles ?

Méph'

--
C'est parce que la lumière est plus rapide que le son que certains
ont l'air brillants avant d'avoir l'air con
Albert ARIBAUD
Le #14315011
Le Tue, 09 Oct 2007 14:40:25 +0000, Professeur Méphisto a écrit:

Albert ARIBAUD a écrit :

A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer
pour intrusion dans un système informatique ;



D'accord, mais la manipulation qui a permis de découvrir la faille est
justifiable par la nécessité de faire fonctionner le logiciel client. Le
logiciel est totalement opaque, la documentation technique inexistante.



Cela n'est pas une excuse : si la documentation est opaque, on ne bricole
pas des manips, on demande à son auteur d'en faire une meilleure (je
sais, ça ne donne rien de bon en termes de délais, mais là on parle de
droit).

la facilité de la manipulation n'y changera rien.



Oui, mais le développeur et son commanditaire ne sont-ils pas tenus de
garantir, par ce que j'appellerai de bonnes pratiques de programmation,
la confidentialité des données dont certaines sont personnelles ?



Si, c'est même pourquoi j'avais mentionné l'intérêt possible de la CNIL
pour la question. :)

Amicalement,
--
Albert.
patpro ~ Patrick Proniewski
Le #14315001
In article Albert ARIBAUD
Le Tue, 09 Oct 2007 14:40:25 +0000, Professeur Méphisto a écrit:

> Albert ARIBAUD a écrit :
>
>> A priori, je dirais que le bricoleur risque de voir la boîte l'attaquer
>> pour intrusion dans un système informatique ;
>
> D'accord, mais la manipulation qui a permis de découvrir la faille est
> justifiable par la nécessité de faire fonctionner le logiciel client. Le
> logiciel est totalement opaque, la documentation technique inexistante.

Cela n'est pas une excuse : si la documentation est opaque, on ne bricole
pas des manips, on demande à son auteur d'en faire une meilleure (je
sais, ça ne donne rien de bon en termes de délais, mais là on parle de
droit).



néanmoins, il a le droit de chercher les failles si il est responsable
de la sécurité et/ou du bon fonctionnement de l'infrastructure
informatique/réseau.

Il peut aussi sans problème dénoncer la politique de mot de passe de
l'application. D'ailleurs, peut être l'entreprise a-t-elle une charte
d'utilisation des outils informatiques qui prohibe le partage de mot de
passe, l'utilisation d'un même mot de passe au delà d'une durée données
... bref une raison valable aux yeux de la hiérarchie pour mettre le
logiciel en quarantaine.


>> la facilité de la manipulation n'y changera rien.
>
> Oui, mais le développeur et son commanditaire ne sont-ils pas tenus de
> garantir, par ce que j'appellerai de bonnes pratiques de programmation,
> la confidentialité des données dont certaines sont personnelles ?

Si, c'est même pourquoi j'avais mentionné l'intérêt possible de la CNIL
pour la question. :)




je pense que dans ce cas il y a obligation de moyen, pas de résultat (le
mot de passe est un moyen).

patpro

--
http://www.patpro.net/
Professeur M
Le #14314991
Albert ARIBAUD a écrit :

Cela n'est pas une excuse : si la documentation est opaque, on ne bricole
pas des manips, on demande à son auteur d'en faire une meilleure (je
sais, ça ne donne rien de bon en termes de délais,



Je pousse la parano un peu plus loin : on n'a donc pas le droit de
vérifier que les données transmises correspondent aux données saisies ?
Il est parfaitement possible techniquement que le logiciel client en
profite pour embarquer des fichiers autres que ceux souhaités.

Imagine que le DRH veuille, en complicité avec le programmeur, se faire
envoyer tous les fichiers lettre_motivation.doc trouvées sur les postes ?

Le «reverse engineering» n'est-il pas *parfois* légitime ?

mais là on parle de droit



C'est bien ce que j'attends des réponses à ma question.
La bidouille est faite, le signalement aussi mais je veux me blinder
complètement pour éviter les emmerdes. D'autant que je ne suis pas
toujours en odeur de sainteté, à force d'avoir la grande gueule ;-)

Méph'

--
C'est parce que la lumière est plus rapide que le son que certains
ont l'air brillants avant d'avoir l'air con
Professeur M
Le #14314981
patpro ~ Patrick Proniewski a écrit :

néanmoins, il a le droit de chercher les failles si il est responsable
de la sécurité et/ou du bon fonctionnement de l'infrastructure
informatique/réseau.



merci de ton soutien ;-)
Une référence de texte ou de jurisprudence ?

Cela dit, je ne suis pas responsable de la sécurité du serveur FTP, tout
juste d'une toute petite partie du réseau où est installé le client.
En plus ce n'est pas mon métier, juste une fonction, officielle quand
même, mais un peu annexe.

Il peut aussi sans problème dénoncer la politique de mot de passe de
l'application.



C'est fait, en plus d'un tas d'autres griefs

D'ailleurs, peut être l'entreprise a-t-elle une charte
d'utilisation des outils informatiques qui prohibe le partage de mot de
passe,



non

l'utilisation d'un même mot de passe au delà d'une durée données



T'es fou ? je vais avoir une émeute ;-)

... bref une raison valable aux yeux de la hiérarchie pour mettre le
logiciel en quarantaine.



« quarantaine » curieux nom pour la poubelle...

--
C'est parce que la lumière est plus rapide que le son que certains
ont l'air brillants avant d'avoir l'air con
patpro ~ Patrick Proniewski
Le #14314971
In article Professeur Méphisto
patpro ~ Patrick Proniewski a écrit :

> néanmoins, il a le droit de chercher les failles si il est responsable
> de la sécurité et/ou du bon fonctionnement de l'infrastructure
> informatique/réseau.

merci de ton soutien ;-)
Une référence de texte ou de jurisprudence ?



non, désolé :/

patpro

--
http://www.patpro.net/
Albert ARIBAUD
Le #14314961
Le Tue, 09 Oct 2007 16:51:23 +0200, patpro ~ Patrick Proniewski a écrit:

In article Albert ARIBAUD
Le Tue, 09 Oct 2007 14:40:25 +0000, Professeur Méphisto a écrit:

> Albert ARIBAUD a écrit :
>
>> A priori, je dirais que le bricoleur risque de voir la boîte
>> l'attaquer pour intrusion dans un système informatique ;
>
> D'accord, mais la manipulation qui a permis de découvrir la faille
> est justifiable par la nécessité de faire fonctionner le logiciel
> client. Le logiciel est totalement opaque, la documentation technique
> inexistante.

Cela n'est pas une excuse : si la documentation est opaque, on ne
bricole pas des manips, on demande à son auteur d'en faire une
meilleure (je sais, ça ne donne rien de bon en termes de délais, mais
là on parle de droit).



néanmoins, il a le droit de chercher les failles si il est responsable
de la sécurité et/ou du bon fonctionnement de l'infrastructure
informatique/réseau.



Le Code Pénal ne prévoit pas cette excuse dans ses articles 323-1 à 323-3.

Il peut aussi sans problème dénoncer la politique de mot de passe de
l'application. D'ailleurs, peut être l'entreprise a-t-elle une charte
d'utilisation des outils informatiques qui prohibe le partage de mot de
passe, l'utilisation d'un même mot de passe au delà d'une durée données
... bref une raison valable aux yeux de la hiérarchie pour mettre le
logiciel en quarantaine.



Il peut très bien faire tout ça, mais si en plus de décrire tout cela il
effectue les manipulations décrites, celles-ci risquent de se voir
retenues comme accès frauduleux à un système d'information automatisé,
aggravé éventuellement des actes de modification.

>> la facilité de la manipulation n'y changera rien.
>
> Oui, mais le développeur et son commanditaire ne sont-ils pas tenus
> de garantir, par ce que j'appellerai de bonnes pratiques de
> programmation, la confidentialité des données dont certaines sont
> personnelles ?

Si, c'est même pourquoi j'avais mentionné l'intérêt possible de la CNIL
pour la question. :)




je pense que dans ce cas il y a obligation de moyen, pas de résultat (le
mot de passe est un moyen).



Il ne me semble pas que la question du type d'obligation de pose ici ; je
viserais plutôt, à voir ce qui est décrit, le fait que les moyens mis en
oeuvre sont notoirement insuffisants au regard de l'état de l'art.

Amicalement,
--
Albert.
Albert ARIBAUD
Le #14314951
Le Tue, 09 Oct 2007 17:13:36 +0200, patpro ~ Patrick Proniewski a écrit:

In article Professeur Méphisto
patpro ~ Patrick Proniewski a écrit :

> néanmoins, il a le droit de chercher les failles si il est
> responsable de la sécurité et/ou du bon fonctionnement de
> l'infrastructure informatique/réseau.

merci de ton soutien ;-)
Une référence de texte ou de jurisprudence ?



non, désolé :/



Les textes de base sont le Code Pénal, articles 323-1 à 323-3.

En termes de jurisprudence, voir l'affaire Tati ou l'affaire Guillermito,
qui sans tomber pile sur le sujet doivent donner des pistes intéressantes.

Amicalement,
--
Albert.
Albert ARIBAUD
Le #14314941
Le Tue, 09 Oct 2007 14:52:23 +0000, Professeur Méphisto a écrit:

Albert ARIBAUD a écrit :

Cela n'est pas une excuse : si la documentation est opaque, on ne
bricole pas des manips, on demande à son auteur d'en faire une
meilleure (je sais, ça ne donne rien de bon en termes de délais,



Je pousse la parano un peu plus loin : on n'a donc pas le droit de
vérifier que les données transmises correspondent aux données saisies ?



Cela, si. Par contre, effectuer une session FTP peut être considéré comme
un accès frauduleux.

Il est parfaitement possible techniquement que le logiciel client en
profite pour embarquer des fichiers autres que ceux souhaités.

Imagine que le DRH veuille, en complicité avec le programmeur, se faire
envoyer tous les fichiers lettre_motivation.doc trouvées sur les postes
?



Ce serait une énorme connerie du DRH, qui engagerait de plus la
responsabilité du DSI et du patron, pour atteinte à la vie privée -- du
moins si le salarié a bien identifié comme personnel le dossier où se
trouvait ce fichier.

Mais bon, on dérive de la question initiale, là.

Le «reverse engineering» n'est-il pas *parfois* légitime ?



Parfois, oui : à des fins d'interopérabilité.

mais là on parle de droit



C'est bien ce que j'attends des réponses à ma question. La bidouille est
faite, le signalement aussi mais je veux me blinder complètement pour
éviter les emmerdes. D'autant que je ne suis pas toujours en odeur de
sainteté, à force d'avoir la grande gueule ;-)



Se limiter à l'observation passive, telle qu'elle peut être faite dans le
cadre du travail.

Ne pas mentionner les sessions FTP frauduleuses.

Ne pas présenter comme un cas d'école ce qui, en fin de compte, est un
cas réel. :)

Consulter un avocat.

Amicalement,
--
Albert.
Publicité
Poster une réponse
Anonyme