L'envers du décor
Quand j'étais petit, je pensais que le problème de la sécurité était résolu (c'était plus facile à l'époque, il faut dire).
Je mettais à jour ma machine dès que possible, je n'avais aucun port ouvert sur Internet, des mots de passe robustes, et un antivirus (déjà !). A l'époque les navigateurs ne posaient pas problème: l'historique de sécurité de NCSA Mosaic est pour ainsi dire vierge :)
Plus grand, je suis sorti d'école sans savoir rien faire et je suis donc devenu consultant en SSII (comme beaucoup de jeunes diplômés). J'ai ainsi pu distribuer des conseils à des gens qui semblaient persuadés que j'en savais plus qu'eux - ce qui était malheureusement probablement vrai (note: j'ai un billet sur le jeunisme dans l'informatique en préparation :).
Plus tard, j'ai pris en charge bénévolement l'administration du réseau informatique dans la TPE de ma femme. Avec de vrais utilisateurs complètement étrangers à l'informatique (sauf le commercial, qui a un Mac). Et là, j'ai commencé à voir l'envers du décor ...
Maintenir en sécurité - et donc à jour - un parc logiciel de taille même modeste relève de la gageure avec les outils logiciels qui nous sont proposés aujourd'hui par les éditeurs.
Microsoft facilite vraiment la tâche des administrateurs avec l'installation automatique des correctifs pour tous leurs logiciels, avec ou sans WSUS, et le déploiement centralisé d'applications.
De mon point de vue, la palme de l'horreur dans le domaine revient sans conteste aux logiciels Adobe (Acrobat Reader et Flash particulièrement, ainsi que ShockWave récemment). Ces logiciels sont victimes de la combinaison des facteurs suivants:
- Ils sont incontournables (Flash, toutes versions confondues, dépasse les 99% de déploiement dans le monde).
- Ils font l'objet de problèmes de sécurité récurrents.
- Ils sont accessibles via un navigateur.
- En conséquence ... ils sont ciblés par de vraies attaques provenant d'Internet.
Se protéger nécessite au minimum de mettre à jour et de diminuer la surface d'attaque de ces logiciels.
En ce qui concerne la mise à jour, c'est la croix et la bannière. Le système de mise à jour automatique (intégré) nécessite d'être administrateur local du poste. Et l'utilisateur final doit prendre la décision de mise à jour, au travers d'une boite de dialogue - échec.
En ce qui concerne Flash, un fichier d'installation ".msi" est disponible, ce qui permet d'utiliser les fonctions natives de distribution logicielle dans Windows et de contourner les problèmes précédents.
Ce qu'on sait moins, c'est que la distribution de ce fichier ".msi", même en entreprise, est soumise à accord préalable et discrétionnaire de la part d'Adobe !
En ce qui concerne Acrobat Reader, c'est l'enfer.
Les seules versions téléchargeables en format ".msi" sont les versions 9.1.0 et 8.1.3. Enfin je crois, car l'ergonomie du site Web d'Adobe laisse à désirer ... On peut passer par ici ou par là pour récupérer ces versions mais il existe peut-être des portes dérobées.
Quand je dis ".msi", il faut comprendre une version compressée avec NOSSO dans laquelle il est possible de trouver le ".msi" après quelques manipulations (notez que la documentation d'installation d'Acrobat Reader est elle-même au format PDF :) ... Sans parler de la version anglaise d'Acrobat Reader, qui installe également AIR si l'on n'y prend garde.
Quand je dis ".msi", il faut comprendre une version compressée avec NOSSO dans laquelle il est possible de trouver le ".msi" après quelques manipulations (notez que la documentation d'installation d'Acrobat Reader est elle-même au format PDF :) ... Sans parler de la version anglaise d'Acrobat Reader, qui installe également AIR si l'on n'y prend garde.
Au jour où j'écris ces lignes, les seules versions d'Acrobat Reader sans bogue connu et publié sont les versions 9.1.3 et 8.1.6. Pour arriver à ces versions, il faut télécharger des correctifs au format ".msp". Passons sur le sans-débit (<= 56K) qui a récupéré une version d'Acrobat Reader sur un CD AOL: il ne peut pas être à jour sans télécharger presque 100 Mo de correctifs.
L'organigramme d'application des susdits correctifs ne suit aucune logique. Certains correctifs nécessitent de disposer de la version N-1, d'autres peuvent être appliqués sur les versions N-1, N-2 ou N-3. Ce qui cause visiblement des problèmes.
Après avoir appliqué tous les correctifs et redéployé entièrement l'application, reste le problème de la défense en profondeur: la désactivation de JavaScript dans Acrobat Reader (mesure conservatoire nécessaire mais non suffisante par les temps qui courent).
Cette opération s'effectue dans la base de registre au travers de la clé bEnableJS, dont l'emplacement exact varie d'une version d'Acrobat Reader à l'autre.
Vous trouverez des modèles d'administration (fichiers ".adm) "tout fait" sur Internet vous permettant de régler ce paramètre. Seul problème: une fois le fichier ".adm" chargé dans la console de gestion des stratégies de groupe, aucun paramètre n'est visible ...
Je vous donne les trucs que personne ne documente (applicables au moins à Windows 2003 R2):
- Le parser de fichiers ".adm" étant ce qu'il est, il faut obligatoirement terminer par un retour à la ligne (sinon le dernier caractère de la dernière ligne est omis).
- Les clés de base de registre n'étant pas des sous-clés de "Software\Policies" ne sont pas affichées par défaut. Il faut changer le filtre d'affichage dans la GPMC.
Ce dernier comportement s'explique par le fait que les modifications apportées ailleurs que dans "Software\Policies" sont permanentes (ce que Microsoft appelle le "tatouage" de la base de registre). A contrario, les paramètres gérés par une politique sont appliqués dynamiquement.
Tout ça pour qu'à l'ouverture d'un fichier PDF contenant un JavaScript, l'utilisateur se voie proposé de le réactiver "afin de bénéficier de toutes les fonctionnalités du document" ...
Mais au moins, Acrobat Reader a l'avantage sur Flash (et sur FireFox, accessoirement) d'être configurable par la base de registre, et non par une saleté de fichier binaire ".sol" configurable uniquement en passant par le site d'Adobe !
Si j'avais un seul message à faire passer à Adobe, cela serait probablement "with great power comes great responsibility" ...
Quant à moi j'en tire les conclusions suivantes:
- La sécurité est un échec.
- Il est impossible d'être un bon auditeur sans être un excellent administrateur.
- Personnellement, je désinstalle Flash à chaque annonce de faille pour être sûr de toujours récupérer la dernière version au moment où j'en ai vraiment besoin.
- Et enfin, le réseau de ma femme est probablement plus sûr que celui des entreprises du CAC40 ... la sécurité est un échec, à nouveau !
8 commentaires:
News0ft: Personnellement, je désinstalle Flash à chaque annonce de faille pour être sûr de toujours récupérer la dernière version au moment où j'en ai vraiment besoin.
Tout est troué, et patcher tous les 5 matins ne fait que confirmer l'évidence.
Pourquoi se faire chier avec des process aussi compliqués et limitants ? Prend sur toi et place tes pions un peu plus loin :) (puis Möbius/DiD c'est 'achement plus hype).
De plus le cas "Adobe" est loin d'être compliqué à résoudre, j'espère que tu ne chiffres pas tes mails avec une appli AIR :).
J'ai aussi remarque que Acrobat Reader se met a jour automatiquement uniquement si tu le lances et apres avoir ouvert le fichier (ou bien leur tache de mise a jour automatique est trop lente par rapport au nombre de patch).
C'est un peu "tu viens de te faire infecter, veux tu maintenant mettre a jour ta version ?". J'adore ! :)
J'ai bien essayé de mettre à jour acrobat reader, mais adobe updater ne gère pas les proxy http avec authentification AD...
Il est impossible d'être un bon auditeur sans être un excellent administrateur.
Mais si, il suffit d'être certifié ISO27001. Et le blog de Sid le dit si bien, pour être certifié ISO27001, il suffit de savoir cocher les cases sans dépasser, et de se débrouiller pour qu'à la fin la société soit certifiée et ainsi te paye.
Pour la sécurité des parcs, j'entends souvent aussi ces histoires de normes, de mécanisme 'up-to-date', de bonnes pratiques etc..
L'ennuyeux, c'est surtout le suivi au cours du temps. Chez soi, ça va. On dispose d'un admin à temps (quasi) plein, qui connaît en plus bien la machine, les habitudes d'utilisation etc..
Dans une grosse boîte, c'est déjà plus compliqué. Comment gérer le socle hardware, puis le socle système, puis le socle applicatif, puis la compatibilité avec l'existant (genre l'appli hypra mal codée qui n'accepte que IE5.5 après tripotage de la BdR, mais qui est essentielle) de plus sur trois continents, avec des consultants qui ont besoin d'un poste et d'accès pour des durées très courtes, avec d'autres machines qui se connectent une fois tous les 6mois à un réseau, avec la dépérimétrisation, etc etc..
Quelque fois je me demande au contraire comment se fait il qu'il n'y ait pas plus de compromissions...
Je suis allé faire une presta chez un client. Il avait une techno de sécurité absolument fiable, basée sur de la PKI costaud, le truc installé par un gus de la boîte elle même qui codait tout ça. Bref, la Graal de la sécurité informatique.
Et là, pas de bol, ils perdent le mot de passe principal (ce qui ne les empeche pas de bosser ceci dit, avec leurs mots de passe qui donnent des droits réduits). Bref.
Ils sont toutefois bien ennuyés de ne plus avoir ce mot de passe principal.
Deux solutions:
1/ repartir de zéro en tentant de recréer au mieux l'existant puis supprimer lancien système.
2/ demander le classeur de formation initiale, lire le mot de passe du formateur dans la copie d'écran, (si si juste au dessus de la grosse case rouge: "ce mot de passe doit être conservé de façon sécurisé et ne doit jamais être divulgué"), lire ce mot de passe, rentrer dans le super système avec.
Presta terminée. 5mn (facturée une journée, faut pas déconner non plus, hein). Client content.
Rapport pondu qui préconise de changer malgré tout ce mot de passe. Je parie que ce rapport doit prendre la poussière en haut d'une armoire, en ce moment :)
En bref, une société avec un truc hyper béton dont le mot de passe était quasi connu de tout le monde. Mais bon, puisque personne ne le sait, ça n'est pas très grave :)
La sécurité, c'est un truc chiant comme la mort, très pénible, qui coûte cher et qui t'empêche d'accéder à tes données quand tu en as besoin..
Je réagis (je troll?) sur la remarque d'Anonyme :
Quelque fois je me demande au contraire comment se fait il qu'il n'y ait pas plus de compromissions...
Je suis encore plus étonné quand je vois :
- la quantité d'exploits disponible et de plateforme pour les utiliser comme metasploit ou canvas (vive les francais ;-) ),
- le nombre d'entreprise en retard sur les patch ou qui ne patch pas du tout (j'ai travaillé pour de grandes "entités" où la mise à jour unix est une légende urbaine : quand ca marche on ne touche pas),
- la confiance que l'on donne à des prestats qui changent tous les 6 mois (dans une banque où, sans status particulier, j'avais accès aux DAB en RDP je m'étonnais de mon honnêteté => oui, je sais, chui grillé ;-) ),
- le nombre de bdd avec numéros de cartes bleues+cryptogrammes à 1 ou 2 zones du net (fnac, amazone, ...),
- le nombre d'entreprises qui se croient protégées avec un proxy http (vous connaissez beaucoup d'entreprise qui déchiffrent le HTTPS pour en scanner le contenu? Réellement : qui déploient un certificat autosigné sur les postes utilisateurs pour générer dynamiquement, sur le proxy, des pseudos faux certificats des sites accédés, comme le font les ironports par exemple ),
- le nombre de PME/PMI qui n'ont pas de proxy ou peu/pas de sécu, mais ont une liaison directe avec leur coeur de réseau d'une entreprise internationale,
- bon, j'arrête là ;-)
J'en suis à me demander si en fait il n'y a pas énormément de victimes mais qu'elles en ont honte et n'en parlent pas.
La sécurité est-elle un échec? Elle est relative et elle doit rester économique.
Si échec il y a, c'est de sacrifier le moyen terme à des économies de bout de chandelle sur le court terme. Mais ceci est valable dans bien des domaines, non?
@anonyme: un audit de sécurité technique et un audit 27001 n'ont absolument rien a voir.
Quand a ceux qui soient disant perdent leurs mots de passe, ils sont toujours étonnés de voir, après un audit ou un pentest, que les mots de passe n'étaient pas si perdus que ca.
Pour les contrats de maintenance bidons qui imposent de ne pas changer les passwords par défaut... il faut savoir que ca existe et que les audits securite servent a montrer ces aberations. bref...
Ah bah une petite série de FAIL encore:
http://www.failblog.org qui redirige sur OVH, et http://failblog.org qui est entièrement vide
Failblog.fr, welcome in FAIL :)
Enregistrer un commentaire