Tutoriel LFI php://filter + Connexion Mysql + Dump Database

[Jajusa]

Bonjour je vais poster un petit tutoriel sur un méthode LFI très sympa, mais surtout très facile.
Nous parlons ici des wrappers.

Explication de cette faille :

PHP dispose de nombreux protocoles natifs, pour différents styles d’URL, à utiliser avec des fonctions de fichiers telles que fopen() et copy()

Pour avoir plus d'information je vous invite à lire le document PHP suivant :

http://php.net/manual/fr/wrappers.php.php

Donc, en résumé, le problème depuis PHP 5.0 est que certaines fonctions [...], et ici pour cette faille ce qui nous intéresse sont les flux d’entrée et de sortie.

En exemple, php://filter permet d’appliquer un filtre aux données qui transitent dans le flux d’entrée et de sortie. On peut illustrer cela avec la fonction readfile() au lieu de récupérer les données d’un fichier en clair, vous pouvez récupérer les données encodées en base64, en rot13, ou encore (dé)compresser en bzip2 le fichier.

Mais aussi, par exemple, si vous lancez un fopen() sur php://output dans votre script PHP, toutes les données que vous écrirez serons écrites dans la STDOUT ; il s’agit donc d’un équivalent aux fonctions echo ou print.

Exploitation :

Cherchons la vulnérabilité:

Donc en cherchant un peu dans les différentes pages de ce site cible, je remarque une chose qui me permet de penser qu'il est vulnérable au LFI wrapprers : les pages incluent des fichiers à l'extension .php



Donc je vais tester et voir si elle peut être vulnérable, avec un retour en arrière de répertoire, via un simple ../ à la place du page.php



Voilà, cette erreur me signifie qu'elle peut être vulnérable. De là, nous allons voir si l'on peut afficher le fichier /etc/passwd en modifiant notre URL en conséquence.



Voilà, cela confirme la présence d'une faille de type LFI.

Je pourrais tenter de faire une injection via le proc/self/environ ou bien via le /proc/self/fd ou du LFI log poisoning, mais cela fera l'objet d'un autre tutoriel.

L'exploitation :

Cette méthode est très facile à réaliser.

Nous allons utiliser php://filter pour lire les fichiers (Source) cryptés en BASE-64.
C'est utile quand nous voulons récupérer des informations MySQL ou pour tester n'importe quelle vulnérabilité mais le fichier doit obligatoirement être en .php

Nous aurons besoin d'un site (ou d'un soft) pour décrypter du BASE64 :

http://crypo.in.ua/tools/eng_base64d.php

Commençons :

Disons que je veux lire la page index.php, je vais modifier mon injection comme suit :

http://www.site.fr/index.php?page=ph...index.php&id=3

Et on va obtenir un code BASE64 sur la page :



Si on décode ce code en BASE64, ont obtient ceci :



On y voit 2 inclusions de fichier PHP :

cOnfig.php
connect_database.php

Je vais modifier l'URL pour inclure non plus index.php mais c0nfig.php



On décode ces informations :



On a récupéré les identifiants de connexion MySQL.

Maintenant que faire avec ça?

Eh bien je vais me connecter à leur base de données et la dump :

Lien informatif : https://dev.mysql.com/doc/refman/5.0/en/connecting.html

Donc les informations sont :

$dbhost = 'masqué les amis';
$dbuser = 'wse82094';
$dbpass = '4qa95hb235';
$dbname = 'wse82094';

Donc selon le protocole de connexion, nous allons faire :

mysql -h dbhost(masqué ici) -u wse82094 -p (puis entrée, puis mettre le password)



Pour voir les bases de données, nous allons utiliser SHOW DATABASES;



Je ne vais pas passer toutes les commandes MySQL, tel que USE nom_database, ou SHOW db_name, etc. À vous d'apprendre à vous en servir.

Maintenant je quitte avec exit

On a vu les Db suivantes :

• wse82094
• wse82094_1

Je vais juste dumper la premier DB : wse82094

Comment ? voici un petit lien utile :

http://hawkcreation.com/exporter-en-...vec-mysqldump/

Donc maintenant c'est easy

On va utiliser mysqldump :

mysqldump -h dbhost(masqué ici) -u wse82094 -p wse82094 > dump.sql

Note : wse82094 est le nom de la database que je dump.




Voilà c'est fini, j'espère que ce tutoriel vous a plu.

J'ai voulu poster un de mes vieux tutoriels, en espèrant voir d'autre membres suivre un peu, ce qui est le but d'un forum... le partage.

[fred]

Merci pour ce tutoriel, petite question :

Comment se défendre de cette faille ?

[DreAmuS]

Merci beaucoup, encore un très beau tutoriel.

J'apporte mon humble pierre avec ce script tout simple de 5 lignes qui permet de décoder du Base64 avec python.
https://docs.python.org/2/library/base64.html
C'est pour cela que je travaille du python et du Ruby intensément, c'est remarquable la facilité de l'emploi par rapport à d'autres langages :

#!/usr/bin/env python
# coding: utf-8 
import base64
code = input("Entrer le code Base64 :")
answer = base64.b64decode(code)
print (answer)

#!/usr/bin/env python
# coding: utf-8 
import codecs
code = input("Entrer le code ROT13 :")
answer = codecs.decode(code, 'rot_13')
print (answer)

[Jajusa]

Pour se prémunir des attaques LFI, il n’y a pas d’autre manière que de filtrer et valider les entrées utilisateurs. Il ne faut jamais inclure/exécuter directement une entrée utilisateur !

Pour le cas des RFI, il est possible de désactiver le support en passant la valeur des directives "allow_url_open" et "allow_url_include" à "Off".

Vous pouvez bloquer l’utilisation des wrappers en installant l’extension Suhosin pour PHP (sauf si "allow_url_include" = "On").

Les fonctions suivantes renverront "false" si un wrapper est utilisé dans le nom du fichier :
file_exists,is_file,filesize

Corriger la faille est très simple.
Il suffit de verifier chaque fichier inclue comme ceci, et d'agir en conséquence.
Par exemple :
Code:

 <?php

$page = strtolower($_GET['page']);

if (isset($page) && preg_match("/^[A-Z0-9]+$/i", $page)) {
    
    if (file_exists("pages/$page.php")) {
        include "pages/$page.php";
    }
    
    else {
        include "pages/include.php";
    }
}

else {
    include "pages/index.php";
}
?>

Source: un peu partout sur google, mais je laisserai les dev PHP du forum en donné une version plus détaillé.

[Creased]

Merci pour ce bon tutoriel, ça fait toujours du bien de revoir des notions qui sont en soi très simples, mais appliquées à un cas précis

[DreAmuS]

C'est le but, parfois travailler en situation réél car les VM et autres sites de challenge sont déjà tout trouvé et travailler sur de l'inconnue est le véritable challenge de l'apprentissage surtout dans de l'applicatif.

J'ai testé même si j'avais eu l'occasion déjà d'en faire et fonctionne à 100%. Le LFI log poisoning est aussi un bon sujet de tutoriel, merci si tu nous en fait part. Un autre très bon sujet aussi est Local File Inclusion to Remote Command Execution using SSH qui date depuis déjà de 5 ans.

Pour ma part le File inclusion est vraiment la faille de ces deux dernières années 2014/2015 et comme je l'avais souligné si tu t'en souvient, elle supplante largement la faille XSS persistante.

Beaucoup de site faillible ont perdus leurs ailes face à de jeunes hackers ayant appris à travailler dessus.
Je trouve qu'une redirection des attaques s'est vue depuis 3 ans, passant du travail sur le code lui-même, au navigateur puis sur l'application ou système en arrière.

Les mots de passe sont plus forts (ceci dû à un apprentissage par l'information)ce qui a provoqué une remise en question de la recherche de nouveaux protocoles comme vecteur d'attaque ainsi que de la recherche de compromission de l'applicatif.

Le pirate cherche la BDD à tout prix de nos jours :

De nombreux systèmes peuvent avoir des partages de fichiers. Ces partages peuvent être gérés via différents protocoles (FTP, NFS, SMB,…). Les restrictions sur ces partages sont en général trop faibles, voire inexistantes.

Aussi :

Fonctions PHP non protégées
Les sites web offrant la possibilité d’uploader du contenu (comme des images par exemple) utilisent les fonctionnalités d’upload de PHP. Si des contrôles stricts de ces fonctionnalités ne sont pas mis en place, il est possible d’uploader un web shell et d’obtenir des informations comme les condensés des mots de passe. Ainsi par rebond, il est possible de prendre la main sur le serveur en backoffice.

Donc, c'est bien d'avoir un aperçu de ces failles qui peuvent paraître bénigne et pourtant certains t'en trouvent à la moindre petite erreur.

Pour tout ceci je t'en remercie.

Pour ma part, je travaille sur l'apprentissage du codage, j'essais de reprendre mes marques en PHP que je pratique beaucoup moins depuis que j'avais fermé dle-template-fr.net avec Fred (pas celui d'ici^^) et Hells angels mon poto de longue date.

J'avais fermé aussi l'actu des pirates (et son journal) site que j'avais monté et coder pour chti demon, dont j'assurais la sécu (et la maintenance) en arrière plan avec Hell fire.

Ainsi, actuellement je travaille sur l'APT, les bots et les exploits pack, dont je bosse sur 2 projets un bots sur twitter en cop avec des vieux potos, et un exploit pack pour 2016 refresh.

Je sais tu va me dire hahahaha moi qui critiquer tout ça, mais l'espionnage est un monde qui me fascine depuis peu et je cherche à comprendre leurs techniques.

Je travaille aussi à côté la cryptographie avec à venir 2 gros tutoriels mais qui me prennent du temps car les Algo sont assez complexe. Bref, comme tu vois je n'arrête jamais d'apprendre. Le python aussi grâce à Fred (d'ici cette fois) qui m'a bien initié et je l'en remercierais jamais assez .

A bientôt et au plaisir de te relire .

[Jajusa]

Je pense qu'on peut allé plus loin avec cette faille.
Comme indiqué au début, je ne montre pas la finalité, car une fois connecté, à part dump la db, on peut joué un peu avec les requêtes, et obtenir une chose vraiment sympa--> un shell. Ce qui permet ensuite d'allé chercher le root du serveur.

PS: certe ma démarche n'est pas white, mais bon qu'est-ce qu'un white?
Le réel offre la joie d'être sur des situations non configuré, donc plus d'apprentissage.

[Creased]

Ce qui permet ensuite d'aller chercher le root du serveur.

PS: Certes ma démarche n'est pas white, mais bon qu'est-ce qu'un white?

Cela dépend en effet de la finalité pour laquelle tu vas récupérer le root dudit serveur...

Si tu cherches à démontrer au propriétaire de la plateforme (i.e. site web), l'importance de corriger et de se former au développement sécurisé en appliquant le principe du responsible disclosure, le cas échéant, ta démarche sera uniquement de donner plus de valeur à ton rapport

D'autant plus que tu as pris soin d'anonymiser les informations sur le site en question, je défends donc ta démarche white jusqu'ici, bien que cette notion soit sujette à controverse lorsqu'il s'agit de l'appliquer à l'éthique des membres de ce type de plateforme communautaire

[fred]

PS: certe ma démarche n'est pas white

Elle l'est depuis que je t'ai posé la question du "comment se prémunir de ..."

Bonne journée,

[DreAmuS]

Je connais Jajusa depuis un bout de temps, il apprends pour aider et comprendre, et il n'a jamais utiliser les connaissances ou compromission serveur contre ses administrateurs, c'est pour celà que je l'ai toujours soutenue sur les forums où ils partagent des tutoriels.

@ fred, tu a raison il est important de donner un exemple, de parler piratage mais aussi d'expliquer les contre mesures. Ensuite, certaines personnes vont utiliser ses techniques pas forcèment dans un sens éthique. Mais c'est comme ça, d'autres forums ont bloquer les accès justement à base de challenge pour remédier à un afflux de tristes personnages et ne partager leurs connaissance qu'avec ceux qui le méritent, bon entre nous ils n'ont pas rééinventer la roue non plus je vous rassure.

Mais Je pense que Jajusa partage une partie de son savoir avec nous et je suis sur que d'autres possèdent des connaissances qu'ils pourraient partager avec la communauté hackademics et ce serait vraiment sympas.

[Jajusa]

J'ai énormément de serveur sous contrôles, je n'en profite pas, bien au contraire,je corrige les failles moi même.
J'en garde un accès dans le but de tester des choses, des nouvelles vulnérabilités, car réellement beaucoup de serveur ne sont jamais maintenu niveau sécurité, 0 patch, 0 update rien, voir même abandonné.
C'est un peu comme le commerce, tu achète , puis y a pas de SAV
Je gagne ma vie honnêtement, et je vie ma passion dans la même vision.

[SAKAROV]

Ce qui fait que ce tuto est white, c'est que les info compromettantes ont été floutées. Ce tuto est en totale adéquation avec la Charte. J'ai de plus pleine confiance en le "jugement" de Dreamus.

[fred]

@ fred, tu a raison il est important de donner un exemple, de parler piratage mais aussi d'expliquer les contre mesures.

Tout à fait, le seul responsable est celui qui ne fait pas tout pour sécuriser, avec les ressources sur le net, il est possible de se mettre au courant mais aussi de s'en protéger, alors tant qu'à faire autant indiquer les solutions afin de pallier à ces failles.

[Jajusa]

J'ai indique un peu plus haut qu'il peut y avoir une suite à ce tutoriel.
Quelqu'un veut-il faire la continuité, ou proposer des idées de suite?

[_42_]

(...)

Corriger la faille est très simple.
Il suffit de verifier chaque fichier inclue comme ceci, et d'agir en conséquence.
Par exemple :
Code:

 <?php

$page = strtolower($_GET['page']);

if (isset($page) && preg_match("/^[A-Z0-9]+$/i", $page)) {
    
    if (file_exists("pages/$page.php")) {
        include "pages/$page.php";
    }
    
    else {
        include "pages/include.php";
    }
}

else {
    include "pages/index.php";
}
?>

(...)

Personnellement, je trouve ton code très minimaliste, voire trop ... J'explique !

Déjà, ta première ligne ne sécurise rien - strictement rien - et n'est intéressante que, et si seulement si, tous tes noms de scripts PHP sont écrits en minuscules.
C'est un prédicat de base, certes intéressant, mais qui dans certains contextes, est faux, voire nul et non advenu.

La deuxième ligne de code est, elle, plus intéressante ... mais au lieu de la fonction isset(), personnellement j'utilise !empty() ; ce que je ne comprends pas, par contre, c'est ton pattern de recherche dans la fonction preg_match ... étant donné que tu mets tout en minuscule, précédemment, il serait plutôt d'acabit de l'écrire ainsi : [a-z0-9], étant donné que tu n'auras jamais de lettre majuscule !

Rien à redire sur l'usage de file_exists, bien au-contraire, même si personnellement, je préfère utiliser la fonction require(), voire require_once()

Pour en revenir, à ta première ligne de code qui n'est en rien sécurisé, je partage ce bout de code que j'ai intégré dans mes anciens codes PHP - parce que, j'avoue cela commence à faire quelque temps, que je ne code plus PHP :

<?php
function securiseSuperGlobals() {

		// securise superglobals arrays...
		//if( !empty( $GLOBALS ) )	$this->securiseVariables( $GLOBALS );
		if( !empty( $_COOKIE ) )	$this->securiseVariables( $_COOKIE );
		if( !empty( $_ENV ) )	$this->securiseVariables( $_ENV );
		if( !empty( $_FILES ) ) 	$this->securiseVariables($_FILES);
		if( !empty( $_GET ) ) 	$this->securiseVariables($_GET);
		if( !empty( $_POST ) ) 	$this->securiseVariables($_POST);
		if( !empty( $_REQUEST ) ) 	unset($_REQUEST);
		if( !empty( $_SERVER ) ) 	$this->securiseVariables($_SERVER);
		if( !empty( $_SESSION ) ) 	$this->securiseVariables($_SESSION);

	}

    /*
     * @purpose: Securise variables
     *
     * */
	function securiseVariables($array) {

        if(!empty($array) && is_array($array)) {

        	foreach($array as $key => $value) {

        		# Si c'est un tableau, récursion de la fonction, sinon filtre tags
            	if(is_array($value)) {
                	$this->securiseVariables($array[$key]);
            	}
            // on peut très bien préférer l'usage de la fonction htmlentities(), par exemple, au lieu de strip_tags()...
            elseif(is_bool($value)) $array[$key] = filter_var(strip_tags($value), FILTER_VALIDATE_BOOLEAN);
            elseif(is_int($value)) $array[$key] = filter_var(strip_tags($value), FILTER_VALIDATE_INT);
            elseif(is_string($value)) $array[$key] = filter_var(strip_tags($value), FILTER_SANITIZE_STRING);

        	}
        	unset($key, $value);

        }

	}

securiseSuperGlobals();

if( !empty( $page ) ) {
	file_exists( "pages/$page.php" ) && require_once( "pages/$page.php" );
		}
else {
        require_once "pages/include.php";
    }
?>

Sachant que normalement, actuellement PHP convertit le type de la valeur obtenue automatiquement ... quelque soit la variable et sa valeur obtenue, dans les contextes des tableaux superglobaux.

Comme on le lit, dans le code securiseVariables() - ci-dessus -, l'usage immodéré des filtres PHP est fait - laissons faire à PHP ce qu'il sait mieux faire que nos propres mimines, voire notre cerval :
https://secure.php.net/manual/fr/fun...filter-var.php
Et, on peut assurément faire mieux.

Personnellement, avant l'usage de la fonction file_exists(), je m'assurerais aussi que le fichier appelé est bien un fichier, et surtout qu'il appartient bien au propriétaire des scripts PHP hébergés - vérification par exemple avec getOwner(), dans le cadre de l'usage des fonctions SPL. Ça me semble un strict minimal !

Allez zou ... bon code, à tous.