La sécurité des logiciels de Cogilog pointée du doigt
Editeur de logiciels de comptabilité pour des PME, Cogilog n'a pas suffisamment sécurisé ses applications, explique Yoann Gini sur son blog (il est formateur, consultant agréé par Apple et auteur du guide sur OS X Server édité par nos soins). Il détaille les fautes de conception repérées dans cette application client-serveur.
Plusieurs décisions techniques sont pointées du doigt et sévèrement jugées au fil du billet. Cela démarre dès l'installation du logiciel.
Le service « serveur » de Cogilog est installé à un emplacement non standard du système et tourne avec le compte ayant permis l’installation, donc un compte administrateur. Aucun logiciel n’est censé travailler dans un dossier à la racine sous Mac. Si le logiciel est un service partagé, ses données vont dans /Library. Si les données sont propres à un utilisateur, cela va dans ~/Library. C’est ici la première erreur de Cogilog. Cela veut dire que si ce compte est supprimé, Cogilog ne marche plus. Et pour mettre à jour Cogilog, il faut être authentifié avec cet utilisateur…
Une base de données est installée sur chaque poste client, observe ensuite Gini. La logique du fonctionnement de l'application voudrait que ça ne soit le cas que sur la machine serveur : « Si le service PostgreSQL est vulnérable à une attaque, elle exposera ainsi tout le parc, y compris les postes clients qui n’ont techniquement pas besoin du serveur de base de donnée. »
Autre problème pointé, l'absence d'activation du chiffrement SSL pour les communications avec la base de données PostgreSQL utilisée par Cogilog. Un état inactif vecteur d'autres risques potentiels :
Le contenu échangé n’est pas chiffré, un attaquant avec une position privilégiée sur le réseau pourra accéder aux communications en clair. Et si le contenu échangé n’est pas authentifié, un attaquant avec une position privilégiée sur le réseau pourra falsifier vos données
D'autres faiblesses au niveau des mots de passe des comptes utilisateurs sont abordées : ce sésame est transmis en clair et modifié pour être véhiculé sous la forme uniquement de caractères en minuscules. De même que les risques de voir une installation Cogilog piratée depuis un accès extérieur et servir de passage pour installer des portes dérobées. L'éditeur a été contacté il y a une semaine mais les réponses fournies n'ont pas satisfait l'auteur de cette démonstration :
Sans briser le secret des correspondances privées, les réponses apportées ne sont que des contournements non mis en avant dans la documentation et des fausses excuses semblant justifier le fait que, pour eux, l’urgence n’était pas là.
Excellent article.
A ce niveau, parle-t-on encore de failles tellement il ne semble y avoir eu aucune réflexion en terme de sécurité ?
Je suis extrêmement partagé.
A la fois je loue l'effort fait par @ygini d'auditer la sécurité de cet excellent logiciel qu'est Cogilog, et de trouver des failles qui sont tout à fait réelles.
A la fois je ne les trouve que toutes relatives, car en fin de compte, les TPE, PME utilisatrice de la gamme Cogilog n'ouvrent pas des accès distants en client-serveur sur leur compta.
Non, ce qui me choque vraiment, c'est la manière de jeter en pâture de la sorte le travail d'une TPE, débuté à une époque où avoir du multitâche préemptif dans MacOS était un doux rêve. TPE qui à l'époque faisait face à des Météor, Sage ou déjà Ciel, et qui est encore là aujourd'hui.
Alors oui, il y a certainement de la poussière et des toiles d'araignée dans un code débuté il y a 20 ans, mais que je ne m'abuse, ce qui est démontré là ne date pas d'hier et aucun scandale n'est venu ébranler les clients de Cogilog à ce jour.
Plutôt que de mal prendre une réponse privée à un mail privé, après avoir twitté sa trouvaille sans pour autant affoler Twitter (17 nov - 0 retweet), peut-être qu'une proposition de rencontre à Toulouse (24 nov - il y faisait mauvais) aurait pu être plus productive, quitte à échanger une aide experte contre un témoignage dans un dossier sur la sécurité des logiciels client-serveur.
Un utilisateur parfaitement heureux de rémunérer le travail de Cogilog.
@yapafoto
J'approuve tout à fait ce commentaire. J'admire tout autant le travail de Monsieur Gini avec lequel j'ai eu affaire que celui non moins remarquable de COGILOG avec qui j'entretiens de cordiales et fructueuses relations. Mais effectivement la méthode devrait plutôt être de partager avec COGILOG les problèmes inventoriés puis essayer d'y remédier avec eux avant de balancer l'info sur le web. Changer tous ces aspects ne se fait pas en quelques jours dans des applications de plusieurs milliers (millions) de lignes de code. Pour info et contrairement à ses rivaux "de prestige" COGILOG réécrit ses soft de zéro à chaque changement important d'Apple.
Bonjour,
Je me permets de répondre aux remarques de yapafoto et tempest.
J'ai contacté Cogilog et, comme vous l'avez très certainement vu en analysant mon flux Twitter, je me suis posé la question de diffuser ou non l'information.
Le fait qu'il n'y ait pas eu de scandale à ce jour ne veut en aucun cas dire que la faille n'a pas été exploitée, mais que personne ne s'en est rendu compte.
La réponse privée de Cogilog est suffisamment claire pour moi. Les informations leur ont été partagées et leur position ne me laisse d'autre choix que d'informer les clients du produit des dispositions à adopter pour se protéger. C'est la seule option disponible lorsque l'on trouve une faille de sécurité et que l'éditeur de la ne prend pas en compte.
Contrairement à ce que vous avez l'air de penser, je n'ai pas mal pris la réponse de Cogilog, je m'y attendais simplement. Une réponse cohérente n'était pas possible au vu du code écrit.
Peu importe que la société existe depuis 20 ans. Ses choix architecturaux sont plus que discutables, l'application ne respecte aucune recommandation système d'Apple, et en plus elle met en danger les utilisateurs finaux.
Leur recommandation sur l'ouverture de port d'accès distant n'aidant pas.
À toutes fins utiles, je rappelle que je n'ai pas tout mis dans l'article. Seulement le nécessaire pour une prise de conscience. Entre autres, les points permettant d'exploiter ces failles pour sortir les documents du serveur et des postes clients ainsi que l'obtention d'un remote-shell ne sont qu'évoqué, mais sont bien réel.
Au-delà de votre gestion et compta, c'est l'ensemble de votre activité professionnelle qui est accessible ici.
Si vous êtes docteur, ce sont les dossiers médicaux de vos patients qui sont accessibles.
Si vous êtes une PME travaillant sur le secteur de la recherche, c'est votre avance potentielle qui est accessible à vos concurrents.
Je suis conscient qu'un tel article peut "choquer", mais c'est aujourd'hui la seule option disponible pour que les erreurs soient éventuellement corrigées.
Et pour information, cela demande très peu de changement de code.
Bof rien de bien dramatique quand même, faut arrêter la parano sur la sécurité. Installer inutilement postgres est idiot, mais de là à dire qu'il y a une grave faille de sécurité...
Et personne n'en a rien a foutre de voler la compta d'une TPE.
Un simple dba/admin sys incompétent (c'est pas difficile à trouver ds les grosses boîtes) peut faire 1000 fois plus de dégâts que n'importe quelle faille de sécurité au monde.
cybercooll
"Installer inutilement postgres est idiot, mais de là à dire qu'il y a une grave faille de sécurité..."
A moins de confier ça à un tiers qui s'occupe de vérifier qu'une màj ne foutra pas tout en l'air, ça reste un logiciel inutile qui peut cumuler les failles de sécurité... Comme celles qui garde de vieilles versions d'acrobat reader alors qu'une màj ne coute rien pour les 3 pauvres pdf qui sont concernés.
Super, je m'introduis dans ta base postgres vide car inutilisée (oui, je m'emmerde au boulot, je pirate le poste de mes collègues plutôt que d'attendre qu'ils partent pisser). Et alors?
Il faut lire la fin de mon article pour comprendre le risque réel…
La base en question permet d'obtenir un remote-shell. Même vide elle donne à l'attaquant la possibilité d'accéder à tous vos fichiers.
Je suis tout à fait d'accord avec l'auteur. C'est malheureux, mais les éditeurs ont souvent la flemme de corriger bugs et pb de sécurité. Tant que ce n'est pas sur la place publique, pourquoi passer du temps à corriger ? La seule manière de les y pousser, c'est malheureusement de publier.
Entre nous, concernant Cogilog, les bugs sont corrigés rapidement au contraire d'Apple ou d'Adobe par exemple. Pour la sécurité voir l'article plus bas ...
Ohoh !!!
Quelques commentaires ...
Tu dis : "Peu importe que la société existe depuis 20 ans. Ses choix architecturaux sont plus que discutables, l'application ne respecte aucune recommandation système d'Apple, et en plus elle met en danger les utilisateurs finaux."
Entre nous les recommandations d'Apple ... Bref, Je pense qu'en terme de sécurité, ils ont aucune leçon à donner à personne, de plus les failles que tu invoques; sont avant tout des failles de sécurité au niveau d'accès distant. Donc si l'accès distant n'est pas "protégé" soit par un VPN, soit par une autorisation scrupuleuse d'adresses IP connues, c'est une faille globale et non au niveau applicatif.
Ensuite tu parles de la position dans l'arborescence des fichiers de Cogilog, et de la possible suppression du compte sous lequel il est installé.
1 - En général tu as une sauvegarde mais bon çà ne règle pas le problème
2 - En général, c'est fait avec le compte admin, et c'est assez rare de le supprimer
3 - C'est peu pratique, certes mais en rien une faille
Concernant la fiabilité de PostGreSQL, je pense que tu exagères un peu, et encore on en revient à la protection au niveau de l'accès distant. De plus, bon nombre de site web utilise PostGreSQL.
Concernant SSL, vu les dernières failles trouvées en son sein, ce n’est pas aussi sûr que ça finalement. Voir POODLE.
Tu dis : "Le contenu échangé n’est pas chiffré, un attaquant avec une position privilégiée sur le réseau pourra accéder aux communications en clair. Et si le contenu échangé n’est pas authentifié, un attaquant avec une position privilégiée sur le réseau pourra falsifier vos données."
Encore une fois tu parles de position privilégié, genre man-in-the-middle, donc encore une fois c'est une faille de sécurité au niveau réseau et non au niveau applicatif.
Bref comme dans toute chose, tout est relatif.
Là, je te demanderais quelque précisions :
1 - As tu installé le logiciel en mode serveur et as tu essayé de craquer son accès ? Si oui as tu réussi ? En mode distant bien entendu ...
2 - As tu prévenu Cogilog de la mise en ligne de tes conclusions ? Si non, franchement ça m’inquiète.
Quelques réponses brèves vu que le commentaire part dans tous les sens :
- je parlais des recommandations d'organisation du file Systems d'Apple, ce point indique juste qu'ils n'ont pas lu la doc ;
- ce n'est pas rare de supprimer un compte admin et surtout de travailler avec plusieurs comptes admin personnel ;
- concernant PgSQL, je n'exagère en rien et c'est toute la démonstration de l'article, la faille n'est pas lié à une erreur cote Pg mais bien un mauvais usage de la part de Cogilog
- la sécurité informatique est une affaire de toute les zones et non juste de l'extérieur, on a appris depuis le temps de la ligne maginot ;
- oui je parle bien de la version Server de Cogilog, c'est écris dans l'article ;
- oui j'ai contacté l'éditeur, c'est écris dans l'article.
Sur une machine serveur, chez moi en tout cas, c'est rare d'avoir plusieurs compte admin et surtout de les supprimer.
Pour PostGreSQL, ce n'est possible que dans le cas ou tu as une position privilégié non ? Dans le cas, il n'y a pas de firewall te bloquant le passage de SSH par exemple ?
Je sais que tu as contacté Cogilog, je te demandais si tu lui avais précisé que tu allais publier tes conclusions ?
Plusieurs compte admin c'est un process standard quand on recherche la traçabilité.
Pour Pg, c'est valable à partir du moment où tu arrive à ouvrir la socket sur le serveur. L'évasion de firewall c'est assez simple à faire. C'est très rare qu'un serveur soit coupé du net a 100%.
J'ai bien entendu précisé à Cogilog que sans prise en compte du problème je publierais la News.
N'oubliez pas que la sécurité globale d'un SI est définie par la sécurité de l'élément le plus faible.
Si tu as prévenu alors c'est correct. Rien à dire.
Par contre, quand tu dis que "L'évasion de firewall c'est assez simple à faire." ... Je suis un peu expectatif ... Tu peux préciser comment tu vois la chose ?
C'est très simple. La plupart des firewall en TPE et PME ne font pas de DPI. Donc dans 99% des cas il suffit juste de trouver des ports ouvert en sorti.
Perso j'ai une machine de rebond sur le net avec un sshd qui écoute en 443. Je ne me suis jamais retrouvé bloqué même sur des réseau réellement secure. Car même sur les réseau avec DPI, on a encore un peu de mal à se dire qu'on fait du MitM institutionnel, ce qui demande de casser la connexion SSL avec des certificats maison.
Mais pour rester cohérent face à la clientèle standard de Cogilog, les firewall seront autorisé en sorti sans conditions.
Le fait également que Cogilog en mode client serveur ait une base qui tourne par défaut, tout le temps, sur tous les clients est génial. Il suffit de suivre un des employé et attendre qu'il se connecte depuis un hotspot pour l'infecter. Que l'accès distant soit par VPN ou non, les clients mobiles sont vulnérable.
OK On est d'accord encore faut-il avoir un accès du coté local du firewall non ?
C'est justement ce que permet le Pg mal configuré de Cogilog. "Bien" utilisé il permet de passer de l'autre côté de manière permanente. Et une fois en place, boucher la faille ne retirera pas l'accès distant.
C'est le point plus compliqué que je ne décris pas dans l'article car ça demande des connaissances propre à OS X.
De plus il y a plusieurs manière de faire cela, donc en expliciter une en prétextant défendre ne servirait à rien.
"Concernant SSL, vu les dernières failles trouvées en son sein, ce n’est pas aussi sûr que ça finalement. Voir POODLE."
SSL sous-entend actuellement SSL et TLS et non juste les versions vieille de 15-20 ans d'SSL. Après la citation entre "" dans l'article de n'en fait pas mention, ce nom étant propre à la partie du rédacteur de macg.
Sans déconner, J'ai rien compris à ton commentaire. On peut l'avoir en Français ? Enfin je veux dire cette partie là : "Après la citation entre "" dans l'article de n'en fait pas mention, ce nom étant propre à la partie du rédacteur de macg."
S'tu veux.
J'ai un peu de mal à comprendre bon nombre de commentaires.
Il me semble que Yoann a eu une démarche professionnelle. Comme l'indique l'article (et son post sur son blog), Cogilog a été averti des différents problèmes liés à leurs choix techniques et des conséquences qu'ils engendrent en terme de sécurité.
Bien entendu, si l'éditeur fait la sourde oreille, Yoann a raison de publier ces informations. C'est ce que fait n'importe quel (white-hat) hacker. D'une part pour prévenir les autres utilisateurs des risques encourus. Et d'autre part, pour mettre la pression à l'éditeur.
Sa démarche est avant tout constructive : personnellement, si j'étais éditeur d'un logiciel, je serais heureux que quelqu'un mette le doigt sur un potentiel problème. Il propose en plus des solutions simples à mettre en oeuvre pour corriger les quelques problèmes. C'est un input de grande valeur pour l'éditeur.
Enfin, l'article est intéressant à lire : il met en avant une démarche simple et intelligente, tout en présentant des petits outils que chaque sysadmin devrait maîtriser. Le tout sur un cas pratique et concret qui peut servir d'exemple.
Vraiment, je ne comprends pas les critiques :(
Tu n'es certainement pas sysadmin et encore moins éditeur. C'est une question de "philosophie" ... Si la volonté d'être constructif de Yoann est sans discussion possible, tout comme sa compétence, sa démarche peut avoir des effets indésirables. Là, il a donné un process permettant le hack de l'application ...
Etant moi-même sysadmin et mettant un point d'honneur à la sécurité, je peux dire que le problème est un soucis épineux ... On se retrouve toujours entre le marteau et l'enclume ... Pour des raisons financières, de simplicité pour les utilisateurs, ...
Tiens j'aimerais bien connaître les raisons qui te font penser que je ne suis ni sysadmin, ni éditeur. Ça m'intéresserait vraiment :)
Yoann a surtout donné aux gens qui utilisent ce logiciel les moyens de se protéger/prémunir contre un certain nombre de "failles" (ou points de vigilance, si vous préférez).
Ça devrait justement permettre aux sysadmins de ne pas se retrouver entre le marteau et l'enclume : en appliquant un certain nombre de mesures décrites par Yoann, ils éviteront justement d'être pris de court en évitant l'exploitation d'un de ces problèmes. Ils s'épargneront aussi le délicat moment où il faut donner des explications au client qui vient d'être piraté... Ces mesures sont censées être temporaires, le temps que l'éditeur fasse le nécessaire.
Je ne vois pas, dans ce cas précis en quoi les raisons financières et la simplicité pour les utilisateurs interviennent. Tu peux préciser ? :)
Les raisons sont claires, la manière dont tu t'exprimes, et le manque d'expérience en ce domaine sont criant dans tes propos ...
Si tu vois pas les raisons financières et la simplicité pour les utilisateurs, je suis désolé pour toi, mais j'ai pas le temps de te faire un cours, sur le comportement humain ...
Et arrête de cirer les pompes de Yohann il porte des baskets ;-) (Je rigole)
Dommage, quitte à ce qu'on me donne une leçon, j'aurais préféré l'avoir en entier.
n'oubli pas une chose, le process en question est élémentaire. N'importe qui ayant des compétences de base en sécu peut le faire.
Les parties spécifique au remote Shell OS X ne sont pas publié car elles sont plus spécifique.
Le seul effet de mon article est que tout le monde est informé. Pas simplement ceux qui cherchent.
J'entends bien là ta volonté de bien faire et ne t'en tiens pas rigueur ... Mais c'est un peu cavalier quand même. Tu leur as laissé une semaine, et je me doute que les réponses ne sont pas satisfaisantes. Mais c'est un petit éditeur. Et je crains que cela nuise aussi de sorte, que l'excellente qualité fonctionnelle des ses logiciels passent au second plan.
Mais concernant ton analyse, il n'y a rien à dire.
Par contre, je pense que pour les béotiens ca doit être la panique.
La didactique en ce domaine n'est pas une sinécure.
Le marketing des grandes marques informatiques (Apple en tête), ayant fait croire à tort que tout était safe et clic-bouton ... On a bien du mal aujourd'hui à sensibiliser à la sécurité.
Je ne leur demandait pas de résoudre le problème en une semaine. Juste de le reconnaître. La réponse que j'ai eu était totalement à coté de la plaque.