Sécurité, Réseaux et SI - Orange Business Services

Réalité du 0-day : la preuve par l'exemple

De nos jours, une grande majorité des applications dites Web s'appuie sur un modèle d'architecture de type n-tiers. Dans sa définition la plus basique, ce modèle met principalement en œuvre 3 composants logiques : un frontal Web, un serveur d'application et une base de données. Ces 3 éléments peuvent se retrouver physiquement sur un même serveur, ou être déployés sur des machines indépendantes avec gestion des modes clustering (applicatif, physique, ...), load-balancing et failover.

Il ne se passe malheureusement pas une journée sans son lot de nouvelles vulnérabilités, fraichement découvertes. Veille, validations et déploiements des patchs sécurité sur les environnement de production sont désormais devenus le triste quotidien de toutes équipes opérationnelles en charge du SI. Sur ce point, il est intéressant de noter que deux mondes s'affrontent : d'un coté, une course effrénée au patch sécurité  cherchant à implémenter les correctifs "le plus rapidement possible" tout en essayant de garantir la continuité du service, et de l'autre, face aux contraintes d'exploitation, on privilégie la stabilité de l'environnement de production, même si les versions logicielles installées ont plusieurs wagons de retard.

DNS Poisoning : Premières attaques

Les attaques exploitant les serveurs DNS vulnérables à faille de "DNS Poisoning" ont démarrées.

Si vous n'est pas encore protégés, il est temps de le faire : Même si la période actuelle de congés n'est pas propice pour mobiliser les personnes, remontez le problème au niveau de votre direction générale. Rester inactif ne vous apportera que des problèmes : L'été devrait être chaud, les semaines à venir particulièrement.

Journal d'un pirate. Feuilleton d'été. Saison 1 Episode 4

Lundi 8 Septembre 2045:

J’ai passé de bonnes vacances. Profitons que je suis en forme pour faire quelques piratages. Tiens, pour me chauffer, je vais aller revoir Tartempion. Ils ont installés un nouveau serveur, SEM qu’il l’appelle, pourquoi pas. Mais mes chevaux de Troie ne fonctionnent plus, ils ont dû changer les stations. Ce n’est pas grave, je vais les réinstaller. Bizarre, je ne peux pas sur certaines. Il est temps que je récupère des données, que j’efface les fichier journaux (logs), et que je m’en aille.

Même jour, cahier d’exploitation de monsieur Machin Responsable de la sécurité de la société Tartempion SA :

Tout pour la sécurité m’a dit qu’il fallait regarder mes logs tous les jours, comment pouvais je savoir ? Il y a tellement de choses dans ces journaux que je n’arrive pas à tenir le coup. Heureusement Tout pour la Sécurité m’a installé l’arme absolue. Tiens, tiens, quelqu’un s’est introduit dans mes réseaux ? Tiens, le voilà qui essaie d’effacer ses traces, il ne sait pas qu’il ne pourra pas toutes les effacer en même temps. Je te vois… Je te tiens. Appelons le bureau privé de répression de la criminalité informatique.

Le site Internet du président de la Géorgie attaqué en DDoS

Le site Internet (www.president.gov.ge) de Mikhail Saakashvili, président de la Géorgie, a été attaqué en déni de service (DDoS) le week-end dernier. Les attaques auraient commencées le Samedi 19 Juillet et se seraient poursuivies le Dimanche 20 Juillet.

L'information a été initialement communiquée sur le site de ShadowServer "The Website for the President of Georgia Under Attack - Politically Motivated? July 20, 2008".

On y retrouve un petit cocktail intéressant de technologie russe (MachBot) et un centre de commande du botnet localisé aux états-unis.

Sécurité et modèle SaaS

Simple évolution du désormais traditionnel modèle ASP (Application Service Provider) pour certains, nouveau modèle de consommation des services IT s’appuyant sur les caractéristiques du Cloud-Computing et du Web 2.0 pour les autres, la réalité business associée à la vague SaaS (Software as a Service) n’est plus à démontrer et va modifier la donne sur les futures évolutions des Systèmes d’Information des entreprises.

Faille DNS : Les outils d'exploitation sont disponibles dans Metasploit

Les cartes viennent d'être quelque peu re-distribuées : Comme évoqué dans mon bulletin d'hier, le framework Metasploit intègre désormais le module permettant d'exploiter les serveurs DNS vulnérables à la faille  de poisoning.

Il n'est pas (jamais) trop tard pour bien faire : Patchez vos serveurs DNS ou re-configurez les pour forwarder les demandes de résolution vers des serveurs DNS sécurisés.

Les cibles d'attaques sur internet étant très nombreuses, un attaquant "opportuniste" aura tendance à se tourner sur les "quick wins" en priorité (et je ne parle pas des "scripts kiddies").

C'est pourquoi je vous propose 4 recommandations supplémentaires (certaines très classiques, pas de "breaking news" je vous rassure).

Lord of the Keyring

   L'ensemble des équipements IT (switch, routeurs, serveurs, postes de travail...) dispose de comptes privilégiés. Ces comptes aussi appelés comptes d'administration sont utilisés par des spécialistes afin de contrôler l'ensemble des paramètres de ces équipements. Il paraît évident d'apporter un soin tout particulier à la sécurité de ces comptes (mots de passe robuste, renouvelés périodiquement, communiqués aux seules personnes ayant le besoin d'en connaître...) Mais que se passerait-il si ces comptes n'étaient détenus que par une seule et même personne au sein d'une organisation?
   C'est ce qui semble s'être produit il y a peu à San Francisco. En effet, l'administrateur IT de la ville a été arrêté le 13 Juillet. Il a ensuite refusé de communiquer les mots de passe des switchs et routeurs Cisco utilisés par le réseau WAN en fibre optique de la ville (ce réseau transporte à lui seul près de 60% du trafic de l'administration de la ville).
   Les conséquences immédiates sont mineures car, sans les mots de passe, le réseau continue de fonctionner. Toutefois, il est impossible de reconfigurer les équipements. Le seul moyen pour les équipes IT d'en reprendre le contrôle serait de les arrêter et de les reconfigurer. Une tâche qui pourrait prendre plusieurs mois, perturberait le trafic et coûterait quelques millions de dollars à la ville.
   Ce n'est qu'après s'être entretenu personnellement ce jour, avec le maire de San Francisco, que l'administrateur a consenti à lui donner non pas les clés de la ville, mais bien celles de son réseau. Mais que se serait-il passé si cet administrateur avait été victime d'un grave accident et soit dans l'incapacité de révéler ces précieux mots de passe à quiconque?
   Des mesures organisationnelles tel que la mise au coffre des codes d'accès auraient pu permettre d'éviter une telle situation. Encore faut-il que les codes qui sont conservés dans le coffre soient les bons... D'autre part, on peut noter qu'environ 80% des sinistres d'origine interne sont imputables à des utilisateurs privilégiés. Il convient donc de pouvoir imputer les actions d'administration au delà du simple compte 'root' ou 'admin'. Loin d'être la solution ultime, une application de Single Sign-On peut ici apporter une réelle valeur ajoutée, assurant une traçabilité des actions d'administration (même s'il y a plusieurs utilisateurs pour un seul compte 'Administrateur') et garantissant l'accès aux applications, systèmes, équipements... dont il se fait l'interface.

Faille DNS Poisoning : Il n'est pas encore trop tard pour se protéger

Comme précisé dans mon post d'hier, les détails sur la faille de DNS poisoning sont désormais connus. Des experts dans le domaine de la sécurité comme Dave Aitel d'Immunity ou de HD Moore estiment [1] que le développement d'un outil est une tâche peu complexe et son temps de mise au point de l'ordre de la journée.

Le SANS Internet Storm Center (SANS ISC) recommande un "PATCH NOW" dans son bulletin d'information intitulé "SANS ISC, Dan Kaminsky's DNS bug: revealed? - Patch!".

Dans ce contexte, comment réagir rapidement pour protéger votre organisation et ses activités ?

Votre fournisseur d'accès Internet (ISP) peut-il vous aider ?

Faille DNS Poisoning : Détails publiés en avance

Afin de laisser le temps aux opérateurs de sécuriser leurs systèmes ; le chercheur en sécurité Dan Kaminsky avait précisé sur son Blog DoxPara.com qu'il n'en dévoilerait les détails que le 6 Aout 2008 lors de la prochaine conférence "Black Hat Briefings 2008".

Cepandant, au vu du "buzz" planétaire autour de cette faille, la situation a pris un tournant quelque peu différent : D'autres chercheurs en sécurité ont publié sur leurs blogs des détails sur ladite vulnérabilité. Le post original a été publié sur le Blog de Matasano mais a été retiré (Matasano, Regarding The Post On Chargen Earlier Today, July 21, 2008) quelque temps après.

A la lecture de l'analyse qui en est faite, mais qui reste cependant à valider "in-situ", le risque semble bien réel : Il est annoncé que 10 secondes suffisent pour "empoisonner" le cache d'un serveur DNS vulnérable.... Damned...

Des copies du post d'origine sont disponibles sur d'autres Blogs:

• Beezari, LiveJournal, DNS bug leaks by matasano, July 22, 2008
• Buanzolandia, Matasano - Kaminsky - DNS Forgery, July 21, 2008

Une analyse a été rédigée sur le Blog Invisible Denizen : Kaminsky's DNS Issue Accidentally Leaked ?, July 21, 2008.

Mon avis sur la question ? A la lecture de ces informations, la menace serait plutôt bien réelle...

Faille DNS Poisoning et NAT : Un cocktail à manipuler avec précaution

Comme recommandé dans la note Faille DNS : Le grand "buzz" de ces derniers jours la mise à jour des serveurs DNS de type "resolver/cache" est une action devant etre  menée à bien si pas déjà effectuée depuis.

Votre serveur DNS est donc protégé, tout retourne à la normale..... Sauf que NON.... Celui-ci est toujours marqué comme étant vulnérable via un outil comme "DNS Checker" proposé sur le site http://www.doxpara.com : Les ports sources sont toujours aussi statiques qu'avant....

D'où vient le problème ? Une erreur lors du déploiement du correctif ? Un problème de configuration de la nouvelle version du DNS ? Des yeux embrumés ? Une erreur de l'outil DNS Checker ?

Non, c'est tout simplement que votre serveur DNS est derrière un equipement qui fait de la translation d'adresse (NAT), comme par exemple un équilibreur de charge, un firewall, un routeur, etc... Comment aborder le sujet ? Quels principes adopter ? .....