Exploit

Under Linux, setuid binaries is a well-known security topic since it allows users to run programs using the security context of their owner. Thus, if a program, whose owner is root, is executed by a non-privileged user, the binary will run under a privileged security context and will be able to perform actions that he normally wouldn’t be able to. Therefore, it is important to check that setuid binaries are well secured and that their behaviour can’t be altered.

Le caniche est insomniaque [1]

  Si vous suivez l'actualité vous avez constaté les différentes annonces sur le caniche voulant manger du TLS. Que l’on se rassure c’est «presque » normal et ce n’est pas TLS qui est remis en cause. Par contre ceux qui ont construit des implémentations de TLS basées sur des fonctions de chiffrement provenant de SSLv3 doivent sentir la morsure.

Les trois chercheurs Bodo Möller, Thai Duong, and Krzysztof Kotowicz viennent le 14 octobre de remettre le monde dans la torpeur des vulnérabilités du protocole SSL. En effet POODLE (pour Padding Oracle On Downgraded Legacy Encryption) est une vulnérabilité touchant le protocole SSLv3 et le moins que l'on puisse dire c'est qu'elle semble avoir enterré cette version du protocole pour de bon. Pourquoi pour de bon ? Eh bien parce que malgré l'effet de surprise généré par l’annonce, il faut rappeler que le protocole TLS qui a fait suite au SSLv3 est disponible depuis 1999 (RFC 2246). Et depuis, plusieurs dates ont marqué l'histoire du SSL. POODLE est donc une vulnérabilité, de plus, dans le protocole et non une erreur d'implémentation comme l'a été HEARTBLEED très récemment. Cette vulnérabilité a été rendu possible par deux choses :
  • Le fait de pouvoir réduire la sécurité d'un échange SSL entre un client et un serveur pour des besoins d’interopérabilité.
  • Une faiblesse cryptographique présente dans SSLv3.

Une nouvelle vulnérabilité critique CVE-2014-6271 a été publiée le 24/09 par Stéphane Chazelas dans le célèbre shell linux Bash. Cette dernière a été surnommée Shellshock et permet d'injecter des commandes systèmes à distance. Cet Interprète de commande est présent sur la grande majorité des distributions Linux et est le composant sous-jacent d'une large majorité de programme, notamment des programmes CGI beaucoup utilisés par les applications WEB. C'est pourquoi, bien souvent, il est possible d'éxécuter des commandes a distance ce qui est sûrement pour beaucoup responsable du score maximum dans la notation de l'impact et exploitabilité de la vulnérabilité.

Attardons nous quelques instants sur la vulnérabilité majeure découverte dans OpenSSL et qui occupe massivement le devant de la scène de la sécurité informatique depuis le début de la semaine. OpenSSL est une bibliothèque logicielle sur laquelle sont basés nombre de composants serveurs utilisant des communications sécurisées, c'est pourquoi toute faiblesse ou vulnérabilité trouvée sur celle-ci est lourd de conséquences... Découverte par Neel Mehta de Google Security et datée du 07 Apr 2014, cette vulnérabilité est estampillée CVE-2014-0160 et porte le nom de Heartbleed bug vulnerability.

heartbleed

Le shellcoding est un domaine déjà largement débattu depuis de nombreuses années (depuis le début des buffer overflows en fait), nous n’allons donc pas reprendre des choses dites et redites mais plutôt présenter un type de shellcode assez méconnu. Nous parlerons ici des shellcodes kernel sous Windows. Nous reprendrons dans un premier temps (très brièvement) les élévations classiques de droits sur cet OS, puis nous ferons une exploitation un peu plus sexy qui pourra être utilisée dans des cas plus complexes.

Windows 7 possède des sécurités en noyau assez solides, de nombreuses vérifications de tailles, contrôles d'intégrité ou restrictions d'accès sont présentes. Par exemple le "security_check" protège note pile si une chaine de caractères est utilisée, c'est également le cas quand nous utilisons une fonction dépréciée comme "strcpy()" (certaines ne sont même plus disponibles), ceci pour forcer les développeurs à programmer de façon sécurisée.

C'est pourquoi nous voyons beaucoup de débordements de tas en local (comme l'a démontré Tarjei Mandt) mais nous n'avons aucune (ou très peu) d'exploitation à distance comme à un moment avec SRV.SYS ou d'autres drivers.

Ce manque d'exploits est en parti du à la présence d'une ASLR (génération aléatoire des adresse en mémoire) en noyau. Résultat, si un Hacker n'a plus de moyen de sauter sur le code et exécuter la charge active (ROP, Jmp Eax, ...) l'exploitation du bug sera impossible. Nous n'aurons qu'un superbe BSOD dans la majorité des cas. Cet article explique comme contourner la protection à distance et relancera peut être les recherches sur ce domaine. Nous considérerons ici avoir un débordement de tampon à distance sur un driver.

Dans ce premier opus du blog nous allons parler kernel, déréférencements de pointeurs, de reverse engineering et un tout petit peu de système de fichier. Beaucoup de choses techniques mais rien de très compliqué. Notre cas d’étude sera l’outil de détection de rootkits GMER, il a la capacité de détecter de nombreux rootkits en noyau Windows et ce sans utiliser de signatures ! Un administrateur système utilisera donc cet outil pour détecter un possible virus d’ores et déjà installé sur sa machine. Nous avons voulu savoir si le fait d’utiliser cet outil (de protection à l’origine) ne peut pas ouvrir des axes d’attaques supplémentaires.