Piratage informatique : la justice précise le champ de l'infraction de fourniture de moyens

Piratage informatique : la justice précise le champ de l’infraction de fourniture de moyens

Pas de piratage faute de piratage

Avatar de l'auteur
Marc Rees

Publié dans

Droit

08/01/2020 3 minutes
30

Piratage informatique : la justice précise le champ de l'infraction de fourniture de moyens

La Cour de cassation souligne que l’éditeur d’un logiciel de caisse permettant de truquer le chiffre d’affaires ne peut faire l’objet d’une condamnation lorsque ces manipulations sont le fait de l’utilisateur autorisé.

Le 7 décembre 2010, l’administration fiscale porte plainte contre Alliance software et Alliadis. La première a développé un logiciel de gestion pour les pharmaciens et la seconde a assuré sa commercialisation. Elle reproche surtout aux deux entités d’avoir proposé « sans motif légitime des moyens spécialement adaptés pour commettre une atteinte frauduleuse à un système de traitement automatisé de données ».

Selon l’administration fiscale, le logiciel permettait, après saisie d’un mot de passe administrateur, d’annuler des recettes, sans trace informatique, pourvues qu’elles ne soient pas liées à une prescription médicale, et avant qu’elles ne soient arrêtées comptablement.

Le 11 janvier 2014, le procureur de la République ouvre une information judiciaire contre personne non dénommée. Elle s’appuie sur deux dispositions de la loi Godfrain sur le piratage informatique, les articles 323-3-1 et 323-3 du Code pénal. Ils répriment en substance la fourniture d’un programme calibré pour effectuer un piratage informatique tout en réprimant le fait d’introduire frauduleusement des données dans le système de traitement.

Pas de piratage en cas de droits d'accès et de modification de données

Après un échec en appel, l’administration fiscale a formé un pourvoi en cassation. En vain, la Cour de cassation a elle aussi rejeté leur recours, comme l’a relevé Me Bernard Lamon. Pourquoi ? Le logiciel permettait finalement à son propriétaire de faire disparaître des données relatives à des paiements en espèces.

Or, « les atteintes aux systèmes de traitement automatisé de données prévues aux articles 323-1 à 323-3 du Code pénal ne sauraient être reprochées à la personne qui, bénéficiant des droits d’accès et de modification des données, procède à des suppressions de données, sans les dissimuler à d’éventuels autres utilisateurs du système ».

Dit autrement, il n’était pas possible de reprocher à Alliance software et Alliadis l’une des infractions en cause, puisque le fait de piratage informatique n’a pu être caractérisé, l’introduction des données étant effectuée par les propriétaires du logiciel.

Écrit par Marc Rees

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Pas de piratage en cas de droits d'accès et de modification de données

Fermer

Commentaires (30)


Et quid de la certification du logiciel de caisse qui ne doit permettre aucune altération ? (Tout en étant bien sûr backupable)


Il a vraiment fallu aller jusqu’en cassation pour comprendre qu’utiliser des droits d’administration quand on est administrateur, ce n’est pas du piratage ?!


C’est surtout l’administration qui n’a rien voulu lacher et qui a tenter tous les recours en vain d’ailleurs.


Je ne sais plus s’il y avait de la jurisprudence, mais la doctrine a toujours défini le motif légitime permettant d’intervenir sur le STAD (système de traitement automatisé de données) comme étant la volonté ou l’autorisation du propriétaire du STAD, outre naturellement l’ordre de la Loi ou afin de respecter un demande de la Justice.  Certains envisagent encore le fait d’intervenir pour colmater une faille dans l’urgence même en cas d’absence d’autorisation du propriétaire (mais je n’ai pas souvenir que ça a été reconnu pas la jurisprudence).

 

Curieux que l’administration fiscale monte jusqu’à la Cour de cassation pour se l’entendre dire, elle ne pouvait que finir “fanny sous le baby”.



C’est plus curieux encore en sachant que les dits propriétaires pouvaient être poursuivis au titre de la fraude dont ils se rendaient coupables.


Donc si demain un quidam supprime des dossiers sensibles sur le réseau via ses propres accès, il ne peut être tenu pour piratage de données.



effectivement … donc la raison de la plainte est ko.


si ce sont ses accès, c’est une faute professionnelle, pas un piratage …

si c’est un accès frauduleux ben … c’est là qu’est le piratage “source”








refuznik a écrit :



C’est surtout l’administration qui n’a rien voulu lacher et qui a tenter tous les recours en vain d’ailleurs.





C’est un beau gâchis d’argent public et de temps de l’appareil judiciaire, deux ressources pourtant bien rares…









crocodudule a écrit :



C’est plus curieux encore en sachant que les dits propriétaires pouvaient être poursuivis au titre de la fraude dont ils se rendaient coupables. 





 

 A mon sens, la DGFiP a souhaité manier la lourde lame du droit pénal  (contre l’éditeur et le distributeur) plutôt que celle plus frêle du droit fiscal à l’encontre d’innombrables officines. Visiblement, cette lame est à double tranchant. 



 Il était évident que l’éditeur du STAD n’a pas “frauduleusement” tenté d’accéder, de se maintenir, d’entraver le fonctionnement du logiciel ou de supprimer des données à l’égard du seul utilisateur légitime soit l’officine  (cf. considérant 16 de l’arrêt). A l’égard de l’administration fiscal, cela est autre chose.



Mais qui ne tente rien ; n’a rien. Comme en attestent les nombreux recours, souvent dilatoires, des banques contre leurs clients en matière de piratage de comptes bancaires.



Une collègue a été formatrice sur un logiciel de pharmacie il y a des années…. elle m’expliquait qu’à l’époque :





  • tous les logiciels pour pharmacie avait un “bouton caché” pour ce genre d’opérations (d’ailleurs, si t’en mettait pas un dans ton logiciel, il ne se vendait pas!)

  • que l’usage de ce “bouton” faisait partie de la formation



    Bref….


Un avocat fiscaliste m’avait dit que l’administration fiscale avait attaqué des pharmaciens pour fraude à la suite de cette affaire.

Le fisc avait beaucoup spéculé sur le montant de la fraude mais cet avocat me disait que le résultat avait été bien moindre qu’espéré.








Soriatane a écrit :



Un avocat fiscaliste m’avait dit que l’administration fiscale avait attaqué des pharmaciens pour fraude à la suite de cette affaire.

Le fisc avait beaucoup spéculé sur le montant de la fraude mais cet avocat me disait que le résultat avait été bien moindre qu’espéré.





Curieux car si la fraude est prouvée après ça tabasse très vite à coup d’évaluation forfaitaire et de majoration etc… L’administration devait avoir la preuve que la “fonctionnalité cachée” existait bien sur le logiciel de caisse mais pas de son utilisation.









nicopelle a écrit :



Une collègue a été formatrice sur un logiciel de pharmacie il y a des années…. elle m’expliquait qu’à l’époque :

tous les logiciels pour pharmacie avait un “bouton caché” pour ce genre d’opérations (d’ailleurs, si t’en mettait pas un dans ton logiciel, il ne se vendait pas!)que l’usage de ce “bouton” faisait partie de la formationBref….





C’est aussi vrai (ou du moins ça l’était il y a quelques années) sur les logiciels de caisse de restaurant.



Il y a gros à parier que les logiciels de caisse d’autres corporations permettent aussi ce genre de bidouillage.



 J’ai même vu un outil permettant de sortir quelles étaient les paiements à supprimer. Ça affichait le total reçu en liquide, on entrait le pourcentage qu’on voulait prélever et ça listait les entrées à faire disparaître et vous disait combien vous pouviez récupérer précisément dans la caisse…



Tant que le stockage des informations n’est pas implémenté en mode blockchain (ce qui reste assez récent), où toute altération du passé est impossible sans se faire remarquer, de tels changements peuvent être faits en trafiquant la base de données (directement, ou indirectement si elle est juste en mode INSERT sans UPDATE).



Si l'administration voulait à ce point se rendre utile elle pousserait à ce qu'une telle techno soit nécessaire à la certification de ce type de logiciels.

Je suppose que l’administration voulait d’une part traiter le cas des pharmaciens fraudeurs via les lois fiscales, mais voulait d’autre part mener une action pour dissuader les fournisseurs de logiciels de fournir les fonctionnalités de fraude, ce qui il faut le reconnaitre n’est pas très respectueux de l’esprit de la loi fiscale.



L’angle d’attaque de piratage est surprenant, j’aurais plus imaginé qu’on les accuse de complicité de fraude fiscale ou quelque-chose du genre. Mais ce n’est peut-être pas possible juridiquement.

Je suppose que l’étape suivante sera d’ajouter un article de loi punissant sévèrement la fourniture de logiciels comptable fournissant des fonctions de ce type, afin que les suivants ne passent pas entre les gouttes.








Zerdligham a écrit :



Je suppose que l’étape suivante sera d’ajouter un article de loi punissant sévèrement la fourniture de logiciels comptable fournissant des fonctions de ce type, afin que les suivants ne passent pas entre les gouttes.





La loi a changé. Depuis le 1er janvier 2018, les caisses enregistreuses doivent être certifiées afin d’empêcher les fraudes.



Des développements sur le sujet ont déjà lieu, un ami avait lancé une startup sur le sujet il y a 2-3 ans avant de se faire doubler par son associé.


C’est pas avant tout pour pouvoir virer les entrées faites par erreur que cette fonction existe ? C’est suffisant pour justifier son existence… d’ailleurs, dans les magasins, il faut une clef physique souvent pour faire ça, justement pour éviter d’en abuser.


Une correction d’erreur honnête devrait laisser des traces (action erronée + correction), pas effacer toute trace de l’action initiale.


Le souci c’est que c’est programmé pour ne laisser aucune trace.








Zerdligham a écrit :



Je suppose que l’administration voulait d’une part traiter le cas des pharmaciens fraudeurs via les lois fiscales, mais voulait d’autre part mener une action pour dissuader les fournisseurs de logiciels de fournir les fonctionnalités de fraude, ce qui il faut le reconnaitre n’est pas très respectueux de l’esprit de la loi fiscale.



L’angle d’attaque de piratage est surprenant, j’aurais plus imaginé qu’on les accuse de complicité de fraude fiscale ou quelque-chose du genre. Mais ce n’est peut-être pas possible juridiquement.

Je suppose que l’étape suivante sera d’ajouter un article de loi punissant sévèrement la fourniture de logiciels comptable fournissant des fonctions de ce type, afin que les suivants ne passent pas entre les gouttes.





Je ne connais pas la fonctionnalité, mais de ce que j’ai compris elle ne permet pas en elle-même de frauder mais de rectifier corriger annuler sans laisser de trace. Il s’agirait donc du détournement d’une fonctionnalité légitime.



Au passage le truc de la certification des logiciels comptables et de facturation m’a toujours parue louche: sauf réalisation d’empreintes ou snapshot depuis l’extérieur de la base par un tiers de confiance et régulier, je vois pas comment on peut empêcher l’administrateur de la base de faire ce qu’il veut sur celle-ci.



Tous les logiciels métiers que je connais (proprio) ne laissent pas accès à la base de données. L’administrateur de cette base est l’éditeur et y faire des requêtes est payant.

J’ai même vu un éditeur avoir la main sur les sauvegardes et sur le matériel. Donc impossibilité pour le client de quitter l’éditeur de quelques manières que se soit.



Bref, devant la tendance du marché à la location des logiciels, une certification est bien suffissante. Si tous les utilisateurs avaient le code source, cela serait autre chose.


Non c’est faux, tu peux parfaitement implémenter un hash pour contrôler que les entrées n’ont pas été altérées.

Ex:




  • une table stocke le total (montant ou nombre de lignes) par jour,

  • une autre le détail de chaque ticket.



    Si chaque ligne contient un HASH de son propre contenu, tu ne pourras pas frauder (en tout cas facilement) :

  • Tu peux supprimer des lignes de détails,

  • Quand tu vas modifier les totaux de la journée le hash ne correspondra plus prouvant la modification de la ligne.



    C’est une solution parmi tant d’autres, une autre piste est de stocker toute insertion à distance: les modifs local ne correspondent plus à l’état distant.



    Bref il y’a de nombreuses façon de faire un soft sécurisé, et rien n’est complètement fiable (même une blockchain peut-être falsifiée il “suffit” de contrôler plus de la moitié des nœuds pour pouvoir invalider des transactions )


Quand je parle de blockchain c’est davantage dans l’esprit d’un dépôt Git, où chaque opération sur le contenu est identifiée par un hash en partie basé sur l’opération précédente, permettant d’avoir à un seul endroit les données et ce qui les vérifie (pas “les certifie”, ce qui serait sans doute nécessaire à terme, mais qui gèrerait les clés ?).

Certes dans l’exemple que je cite il est possible d’altérer le passé d’un dépôt, au prix de la perte d’intégrité des références (un commit intact situé après le point de modification, référencé par son hash dans du ticketing, n’existera plus sous le même hash et donc le lien sera pété) et de la synchronisation des différentes instances, mais ça reste plus difficilement falsifiable que de modifier un hash dans une autre table.


Je me souviens juste que la plus grande crainte des pharmaciens était une condamnation touchant leur casier judiciaire et entrainant de facto une inderdiction d’excercer. Les pharmaciens doivent un casier judicaire vierge.


Je n’y connais rien en BDD mais en pharmacie les éditeurs savent récupérer la BDD d’un logiciel concurrent, et ça ne pose aucun problème pratique. J’imagine donc que ces BDD sont dans des formats standards. Légalement les données de l’officine appartiennent à l’officine, et si la sauvegarde est délocalisée chez l’éditeur, alors celui-ci doit avoir le statut d’hébergeur de données de santé.


Tu as raison.

Ce verrouillage de la base de données n’existent dans les logiciels de gestions d’officine, ce sont souvent des base SQL +/- accessibles.

Source:https://tel.archives-ouvertes.fr/tel-01078999


Enfin, une escroquerie ou un vol peuvent être supprimés du bulletin B2 du casier judiciaire. Et comme l’impossibilité d’exercice de la profession de pharmacien nécessite la consultation du bulletin B2, il suffit de motiver la demande auprès du juge avant la prononciation de la peine ou de le contacter une fois la peine établie. Cela n’empêchera pas que la condamnation figurera toujours au B1 mais elle ne sera plus/pas présente au B2 et donc également au B3


Par contre, ce que j’aime bien dans la décision de la cour de cassation, c’est que les éditeurs de logiciels ne sont pas responsables des manipulations effectuées par l’utilisateur autorisé, mais qui a montré la procédure à ces utilisateurs enregistrés et qui ne bloque pas ce genre de pratique ou tout au moins pourrait permettre de conserver une trace de ces changements ? C’est bien le concepteur du logiciel.



Donc au final, le logiciel peut être modifié, tout le monde sait que c’est possible, les clients de ces sociétés de logiciel demandent aux commerciaux les procédures pour enlever certaines opérations et s’ils ne s’exécutent pas, les clients vont voir ailleurs mais au final, il n’y a pas de responsabilité du concepteur de logiciel.



De toutes façons, je ne comprends pas l’attitude de l’administration fiscale contre les pharmacies, mis à part vouloir faire jurisprudence pour ainsi s’en prendre aux boulangeries, bars, etc. car les pharmacies doivent obligatoirement acheter leurs médicaments auprès de répartiteurs et il est donc facile de connaitre les quantités de médicaments qui ont été livrés à la pharmacie








willy40 a écrit :



De toutes façons, je ne comprends pas l’attitude de l’administration fiscale contre les pharmacies, mis à part vouloir faire jurisprudence pour ainsi s’en prendre aux boulangeries, bars, etc. car les pharmacies doivent obligatoirement acheter leurs médicaments auprès de répartiteurs et il est donc facile de connaitre les quantités de médicaments qui ont été livrés à la pharmacie





Non non dans ce domaine il y a beaucoup d’habitudes plutôt “shady”

Notamment dans le sujet qui nous intéresse, les labos aiment bien remercier (pour bons chiffres de vente, garantie d’avoir un bon spot, etc.) les pharmacies à coup de dons de palettes de produits non facturés et non déclarés



Dans le domaine, ce n’est pas vraiment des palettes de médocs qui sont offertes mais des voyages tout frais payés, des prêts financiers pour rénover la boutique mais rarement des médicaments