Lors de la conférence DerbyCon 2.0, les experts en sécurité Laszlo Toth et Ferenc Spala ont présenté une série d'attaques, dont certaines étaient auparavant inconnues, sur des bases de données Oracle et des serveurs SQL et ils ont même publié les outils appropriés pour les exploiter.

Dans le "piratage du client Oracle", Laszlo Toth a démontré que, bien qu'Oracle enregistre le nom d'utilisateur et le mot de passe de façon chiffrée en mémoire, ces données restent en mémoire à la fin de la session et peut facilement être déchiffrée. Un trojan, par exemple, pourrait exploiter ceci pour récolter les mots de passe en clair du client et c'est ce qui a été remarquablement démontré par l'extension Meterpreter : ocioralog.

Think differently (rien à voir avec la pomme) pour pirater une base de données

Ils ont également démontré comment les connexions Oracle peuvent être détournées et exploitées. En raison de la vulnérabilité TNS listener poisoning qu'Oracle ne veut pas corriger, leur approche fonctionne avec n'importe quelles bases de données Oracle standard, à moins que des mesures spéciales de sécurité pour le listener TNS aient été mises en place. Le TNS proxy appelé pytnsproxy combiné à un module Metasploit approprié appelé tnspoison, permet à des pirates non-authentifiés de sniffer ou modifier les connexions à la base de données. Des commandes SQL peuvent même être envoyées en utilisant le proxy TNS.

Enfin, ils ont utilisé une extension Meterpreter appelée oralog. Cette extension est une sorte de sniffer de mot de passe qui écrit les mots de passe de bases de données de tous les utilisateurs qui se connectent au serveur dans un fichier non chiffré.

Nouveau projet proposé par Oracle et AMD sur la mailing list OpenJDK afin de savoir s'il est possible d'améliorer de façon de transparente les applications Java en permettant à la JVM de tirer avantage du GPU.

Le projet, qui sera parrainé par le groupe HotSpot chez Oracle, se penchera sur les moyens de démontrer les avantages de passer au moins une partie des calculs d'exécution de Java du CPU vers le GPU. L'idée est d'utiliser l'implémentation de JVM HotSpot, qui a une analyse d'exécution avancée sur la performance du code, en tant que base pour le projet. L'objectif est d'améliorer les performances sans toucher à la phase de compilation, à la consommation mémoire et à la qualité du code généré.

Les développeurs veulent commencer leur travail à partir de Java 8 Lambda mais ils s'attendent déjà à de sérieux défis avec l'API Java. Cela conduirait probablement à un nouveau langage ou des extensions pour la machine virtuelle Java.

Ce projet a des objectifs commun avec l'annonce récente du projet Rootbeer GPU compiler et il est possible que les développeurs des deux projets puissent travailler ensemble. Gary Frost de chez AMD, a confirmé que ses ingénieurs sont également prêts à s'y mettre.

Oracle a décidé ne pas fournir de patch pour une vulnérabilité critique dans ses bases de données 10g et 11g. Au lieu de cela, les utilisateurs sont censés corriger le problème avec un workaround.

Selon Oracle, une grande quantité de code aurait besoin d'être changé et il y aurait un risque important de régressions possibles. Ils citent également l'impossibilité d'automatiser l'installation d'un patch pour le problème. Les utilisateurs d'Oracle ont donc une seul option, utiliser une méthode de contournement qui consiste essentiellement à assurer l'administration du cluster en utilisant la "Class of Secure Transport" (COST). Ils n'ont donc pas l'intention de corriger cette vulnérabilité avant la sortie de la version 12.

Le serveur de base de données est vulnérable à une attaque connue sous le nom de TNS listener poisoning, avec laquelle un pirate est en mesure d'écouter la communication d'un serveur de base de données via un nœud de cluster injecté. Des détails de l'attaque ont d'abord été publié en Avril par Oracle. La personne ayant découvert cette vulnérabilité l'avait déjà reportée il y a 4 ans et depuis Oracle a publié une nouvelle version majeure dans laquelle cette faille a été tout simplement ignorée...

Pour ceux qui me lisent assez régulièrement, vous allez me dire : "Mais quelle rigolade!".
Pour mes nouveaux/récents lecteurs qui n'ont pas tout compris, Oracle a connu récemment une vulnérabilité sur son système de bases de données et suite à ça, Oracle a fait une annonce dans laquelle il offre le support SSL pour ses clients.

Un article sur leur blog explique pourquoi la société a fait cette annonce, Oracle Security Alert for CVE-2012-1675 distingue deux types supports. L'un pour les clients sans Oracle Real Application Clusters et un pour ceux avec Oracle RAC.

Pour ceux sans RAC, Oracle recommande de limiter les inscriptions de nouveaux listeners et des protocoles IPC. Toutes les instructions sont fournies dans l'annonce d'Oracle : Using Class of Secure Transport (COST) to Restrict Instance Registration.

Pour ceux avec RAC ou Exadata, le problème est un peu plus complexe et l'utilisation de COST signifie dans ce cas la mise en place du SSL/TLS comme indiqué dans Using Class of Secure Transport (COST) to Restrict Instance Registration in Oracle RAC. Le problème est que l'utilisation de SSL/TLS est vendu pour un coût supplémentaire non négligeable. Mais maintenant (et ça aurait dû être le cas dés le début...), Oracle a mis à jour sa licence afin que les clients puissent utiliser le SSL/TLS afin de se protéger contre cette vulnérabilité.

Avec le changement de licence et la disponibilité du workaround (solution de contournement) efficace, il est peu probable qu'Oracle mette en place un patch pour ses base de données d'ici peu de temps. Le problème affecte actuellement les base de données Oracle 11gR2 11.2.0.2 et 11.2.0.3, 11.1.0.7 11gR1, et 10g 10.2.0.3, 10.2.0.4 et 10.2.0.5. Les utilisateurs de Oracle Fusion Middleware, Enterprise Manager ou E-Business Suite devraient également prendre note de cette vulnérabilité, car ces produits incluent le système de base de données d'Oracle.

De retour sur notre bon vieux dossier Flashback avec aujourd'hui un rapport de la firme Russe Dr.Web qui indique que le malware s'est mis à son aise sur les systèmes exécutant Mac OS X 10.6 Snow Leopard. Le spécialiste en antivirus qui a découvert la variante courante de Flashback a enregistré et évalué les communications du botnet comme vous pouvez le voir sur le graphique ci-dessous.

Dr.Web dit que les ordinateurs d'Apple, prédécesseurs de la 10.7 Lion et en particulier la 10.6 Snow Leopard sont particulièrement touchés. Prés de 63% des Mac infectés exécutent Snow Leopard, et un autre quart la 10.5 Leopard. Seulement 11% des systèmes infectés par le botnet Flashback sont des machines non patchées Lion.

Les utilisateurs de Leopard n'ont actuellement aucun moyen officiel de se protéger contre le trojan car Apple ne fournit les mises à jour de sécurité que pour Snow Leopard et Lion. C'est pas beau ça?! Et pour rendre les choses encore plus chaotiques pour les utilisateurs, l'outil de suppression de Flashback ne fonctionne que sous Mac OS X 10.7. Mouahahahah!

Une des raisons pour lesquelles les systèmes Lion ont été nettement moins touchés, c'est que Java n'est plus un composant par défaut du système d'exploitation Mac et que celui-ci doit être installé manuellement. Le futur plan d'Apple est de complètement abandonner le propre développement de Java et laisser tout le soin à Oracle qui a publié la première release de Java pour Mac OS X. Quand on voit ce que fait Oracle en ce moment, les utilisateurs ont intérêt à avoir un pommier résistant à n'importe quelle intempérie!