WEB

sony-hacked                 Ces derniers jours une filiale de la société Sony (Sony Pictures Entertainment) fait le buzz (bad buzz) suite à une nouvelle intrusion d’un groupe de « hackers » qui se fait appeler « Guardians of Peace » [#GOP].

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.

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

Dans notre article précédent (https://www.nes.fr/securitylab/?p=487), nous avons vu comment créer un web shell PHP quasi-indétectable au niveau des logs des requêtes Apache en utilisant les fonctionnalités du mod_rewrite.

Nous allons reprendre ce web shell et lui ajouter un peu de d’obfuscation pour qu’il devienne encore moins traçable, à savoir : - Encodage en base64 des requêtes - Padding du payload : ajout de caractères ne servant à rien dans les requêtes afin d’empêcher le décodage automatique des payloads base64 par les WAF (Web Application Firewall) - Envoi de contenu de taille variable en retour, afin de ne pas alerter les WAF avec une page de 0 octet) - Manipulation des lettres dans les noms des fonctions PHP à base de str_replace : afin d’empêcher la détection de fonctions PHP (exemple : exec, base64_decode, base64_encode…) - Changement de la page requêtée à chaque envoi de commande afin qu’il n’y ait pas plusieurs requêtes sur la même page qui se suivent dans les logs

Lors d’un test d’intrusion web, il arrive de découvrir une vulnérabilité d’upload de fichiers permettant d’envoyer des fichiers PHP.

Afin d’exploiter cette vulnérabilité, on envoie un Web Shell PHP classique ou un peu plus évolué (c99, c100, r57, 12309…) permettant d’exécuter des commandes à distance sur le serveur attaqué.

Malheureusement ce type d'attaque est souvent très peu discrète et un admin système consciencieux peut vite repérer le webshell.

Nous allons ici vous expliquer une méthode pour rendre cette attaque quasi-indétectable