Lors de la publication de son dernier patch, Oracle a déclaré qu'une faille de sécurité critique de sa base de données avait été corrigée. La personne qui a découvert cette vulnérabilité a mis en avant la procédure et a publié les détails de cette vulnérabilité. Bien que la vulnérabilité affecte presque toutes les installations en production d'Oracle en cours d'utilisation, il n'y a pas réellement de patch pour ces versions. Les administrateurs de base de données Oracle devront donc prendre des mesures immédiates pour protéger leurs systèmes...
Dans son Credit Statement, qui apparaît dans le Critical Patch Update du mois d'Avril 2012 (CPU), Oracle nous parle de Joxean Koret. Quand cet expert en sécurité a demandé à la compagnie pourquoi il avait été cité, celle-ci a répondu que c'était en rapport avec une faille qu'il avait découvert en 2008 et que celle-ci avait dorénavant été corrigée. Koret a donc publié les détails au sujet de cette vulnérabilité, a expliqué comment l'exploiter et a recommandé aux utilisateurs d'installer les derniers correctifs du CPU pour protéger leurs systèmes.
Toutefois, il s'est avéré ensuite qu'il n'y a pas réellement tous les correctifs pour les versions actuellement disponibles de base de données Oracle... Les mises à jour de sécurité qui ont été décrites par Oracle se réfèrent seulement au "main code line", qui est la version non publiée d'Oracle 12.
Et comme presque toutes les installations dans une utilisation en production sont touchées, la majorité des administrateurs d'Oracle ont été laissés sur la touche et doivent donc eux-même prendre des mesures pour protéger leur système... Merci Oracle...
Fonctionnement de cette vulnérabilité
Je vais maintenant vous expliquer comment fonctionne cette faille et comment tenter de la combler sur votre système. Le serveur de base de données Oracle dispose d'un processus de connexion réseau distinct qui opère habituellement sur le port TCP 1521. La base de données s'inscrit comme listener avec ce processus et ce processus met en avant les demandes des clients sur le système de base de données qui elle-même gère une instance de base de données.
Des pirates peuvent enregistrer leur propre proxy d'espionnage comme nœud de load balancing
Depuis la version 8i, ces processus de connexion au réseau peuvent enregistrer des listeners supplémentaires. Un tel listener peut même être enregistré pour une instance de base de données existante. Le listener actif interprète cela comme un nouveau nœud de type cluster (Oracle Real Application Clusters ou RAC) et utilise le nouveau listener pour mettre en œuvre l'équilibrage de charge (load balancing). En d'autres termes, chaque connexion secondaire sera routée vers le nouveau listener.
Alexander Kornbrust, un expert en sécurité Oracle de Red Database Security, pense que cette faille de sécurité est particulièrement grave car "elle permet à des pirates des attaques distantes et non-authentifiées pour rediriger le trafic réseau sur le serveur de base de données vers un serveur arbitraire...". Tout ce que les pirates ont besoin de savoir est le SID Oracle ou le nom du service si vous préférez.
Combler cette faille pour protéger son système
Tout le monde espère un patch prochainement mais comme le dit Kornbrust, il ne faut pas s'attendre à un patch avant au moins 3 mois... La politique de publication des patchs chez Oracle stipule que le patch pour la version 11.2.0.4 qui n'ait pas encore publiée, le sera avant les correctifs de sécurité... Encore une fois bravo Oracle...
Et comme se plaint le plus grand spécialiste en sécurité Oracle : "Pour cette raison, il faut souvent attendre entre un et deux ans..."
Les administrateurs Oracle devraient dont prendre des mesures immédiates pour protéger leurs installations. Pour ceux qui n'utilisent pas de clustering, ce sera relativement facile. En allant dans le fichier de configuration listener.ora, il faudra désactiver cette fonctionnalité inutile :
dynamic_registration = off
Par contre pour ceux dans un environnement de clustering ça se complique. Une option consiste à restreindre l'accès au listener de telle façon que le listener est inaccessible à partir d'Internet et les réseaux locaux. Dans certaines configurations, l'option TCP.VALIDNODE_CHECKING peut être utilisée pour limiter les systèmes qui peuvent parler au listener à partir de ceux inclus dans la liste TCP.INVITED_NODE.
En ce qui concerne les SIDs et noms de services, vous mettez probablement en place des noms longs et aléatoires afin de limiter les attaques. Si c'est le cas c'est bien mais ça n'empêche généralement pas les attaques. Une protection plus efficace du SID peut être réalisée en faisant en sorte que les communications soient cryptées via SSL/TLS. Toutefois, et je comprends les administrateurs, cela n'est pas vraiment une option car Oracle facture une taxe significative supplémentaire pour cette fonctionnalité. Et comme il n'y a jamais deux sans trois : merci Oracle...
Voilà je pense avoir tout dit et pour ceux qui veulent des informations supplémentaires sur cette vulnérabilité, vous pouvez vous rendre sur l'article de Joxean Koret intitulé : "The history of a -probably- 13 years old Oracle bug: TNS Poison."
