Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

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

Réalité du 0-day : la preuve par l'exemple
2008-07-312013-02-11sécurité applicativefr
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...
Publié le 31 Juillet 2008 par Olivier Rodier dans sécurité applicative

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.

OK, but .... ? Il se trouve qu’une vulnérabilité de type 0-day impactant le serveur d’application Oracle (BEA) WebLogic vient d’être découverte, la faille semble être liée au connecteur Apache (mod_wl). Cette mouture présente une sévérité maximum, un rating de 10, ce qui est suffisamment peu fréquent (sans être totalement exceptionnel) pour être souligné, surtout sur un produit aussi répandu.

Pourquoi un tel score ? Parce que cette vulnérabilité cumule plusieurs facteurs facilitant l’exploitation de la faille, avec un impact maximum :

  • l’attaque peut être menée à distance, l’exploit étant réalisé sur le protocole HTTP
  • l’attaque est dramatiquement simple à forge, il suffit simplement de surcharger la méthode HTTP POST afin de provoquer un buffer overflow sur le serveur cible
  • l’attaque peut aisément conduire à un déni de service par crash du système ou à une exécution de code arbitraire sur le serveur

Si on ajoute à cela le fait que l’exploit est disponible, qu’il n’y a pour le moment pas de fix validé par l’éditeur, que seul un workaround est proposé (modification d’un paramètre de la conf Apache pour limiter les URLs à 4000 bytes max) et on commence à percevoir toute la quintessence des vulnérabilités 0-day.

Anecdotique mais sympathique
Dans ces grands moments de solitude, on essaie toujours de trouver des solutions alternatives avec ce que l’on a sous la main, mais ces conseil peuvent malheureusement s’avérer pernicieux. On vous propose d’installer mod_security sur Apache, ce qui est un choix certes judicieux puisque ce mod se présente comme un Firewall applicatif travaillant essentiellement sur le contrôle des flux Web (OSI 7) .... mais ce type d’opération ne doit jamais être réalisée dans l’urgence, l’ajout d’une brique logique filtrante dans l’architecture pouvant créer plus de problème qu’elle n’en résout. On se retrouve donc de nouveau la tête prise entre le marteau et l’enclume, confronté à un cruel dilemme qui est de devoir choisir entre patcher son système/upgrader son architecture en urgence ou maintenir l’environnement de production en l’état afin d’en garantir la stabilité et donc la continuité du business. In fine, certaines recommandations n’apportent aucune réponse satisfaisante sur la problématique posée du 0-day puisque le composant à ajouter devra être initialement testé et validé avant d’être déployé sur le système cible en production.

On se surprend parfois à prier pour que son SI ne soit pas la cible d’une attaque massive dans les jours à venir.

2 Commentaires

  • 4 Avril 2015
    2015-04-04
    par
    Johnb963

    Very informative blog post.Really thank you! Keep writing. cbeaabdadkgk

  • 5 Août 2008
    2015-04-04
    par
    Oracle vient de mettre à disposition un patch (le WebLogic Server plug-in pour le frontal Apache) permettant de corriger la vulnérabilité critique.

    Il est disponible ici :
    https://support.bea.com/application_content/product_portlets/securityadv...

    Les recommandations usuelles de validation sont de rigueur, à savoir, sauvegarder votre ancien plug-in Apache, tester la mise à jour sur une plf de d'intégration, etc ...

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage