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.
nsp