Michael VERGOZ - Apache

Tomcat : Problème d'encodage UTF-8

Michael Vergoz — Tue, 12 Aug 2008 12:13:00 +0000

Une faille de sécurité a été découverte par Simon Ryeo dans Apache Tomcat. Cette faille permet à un attaquant de recupère des fichiers important (comme /etc/passwd ou un fichier .htpasswd) sur le serveur visé.

En fait il est possible d'effectuer un Directory Traversal. Toute les versions de Tomcat inférieur à la version 6.0.18 sont touché.

Les conditions sont simples : Si allowLinking et URIencoding autorise l'UTF-8 dans votre context.xml ou votre server.xml alors il est possible de recupèrer des fichiers.

Exploit
If your webroot directory has three depth(e.g /usr/local/wwwroot), An
attacker can access arbitrary files as below. (Proof-of-concept)

http://www.target.com/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/foo/bar

Solutions :

Désactiver allowLinking ou ne pas utiliser l'UTF-8 dans URIencoding.
Utiliser BinarySEC :)

Références :

http://www.securityfocus.com/bid/30633/info

Faille sur faille : La bombe du web est là

Michael Vergoz — Sun, 02 Mar 2008 21:39:00 +0000

On dit souvent que c'est en passant le mot que les choses avancent. C'est la raison pour laquelle j'écris cette petite brève. Il faut comprendre une chose avant tout, le niveau critique de sécurité (ou d'insécurité) que nous avons atteint est rare / grave et c'est ce que je vais tenter d'expliquer rapidement.

Précédemment je parlais des failles dans Wordpress, Joomla et PHP-NUKE. Je ne sais pas dire combien de sites exactement utilisent ces Applications mais je connais un certain nombre de groupes d'utilisation. Par exemple, Joomla est reconnu pour être utilisé par les administrations et les sites d'informations. Wordpress est réputé pour être utilisé dans le domaines de l'édition sur le web (un peu comme Joomla) et crawler web. Et pour finir PHP-NUKE que je sais massivement utilisé par les "clans" de Joueurs.

Ensuite il faut prendre en considération trois autres choses :

La première est que ces sites sont, dans pratiquement tous les cas, hébergés sur des serveurs Apache / Linux sauf pour Wordpress qui peut se retrouver à tourner sous Windows et ces applications contiennent des failles connues et facilement exploitables.

La seconde est qu'il y a un nombre très important de failles LOCALES (nécessitant une authentification pour être exploitées) dans le noyau Linux. Vous me direz que ce ne sont que des failles locales. Il faut un contexte utilisateur à l'attaquant sur la machine et le serveur Web Apache qui héberge ces applications vulnérables est considéré comme un utilisateur simple au vu du noyau. Quand un attaquant pénètre le premier niveau - l'application web - il peut exécuter des programmes sur le serveur dans l'environnement de l'utilisateur Apache (www-data en général). A ce moment, les dégâts peuvent être limités MAIS il y a des failles LOCALES qui permettent à l'utilisateur d'élever ses privilèges ! L'attaquant va faire télécharger un petit code par le serveur puis ce dernier va le compiler et l'exécuter et l'utilisateur va finalement se retrouver directement root (administrateur) sur le serveur.

La troisième chose à considérer est les réseaux de Botnet. Quatre heures après la publication d'une faille d'escape shell dans PHP-NUKE je commençais déjà à recevoir des attaques de machine déjà piratées par cette même faille. Les hommes qui sont derrière ces Botnet sont comme des veilleurs et sont très opportunistes. Par la suite j'ai placé quelques pots de miel et je commençais déjà à recevoir des sources d'exploits publiés sur le site de milw0rm. En passant, j'ai un ami qui exécutait des vm complètes et se faisait pirater entièrement son serveur par des robots et des fois par des exploits (source d'un programme malveillant) inconnus.!?!!

La réalité du terrain est catastrophique. Les botnets se sont largement spécialisés et leur techniques sont issu es des White Hat voulant du full disclosure à tout prix. Qui sera capable d'en mesurer les conséquences ? Et qui serait capable de déterminer l'ampleur des dégâts ? La bombe atomique du web est là.

Quelques liens qui font peur :

milw0rm d0ng L!Nux !!HOT!!

Linux Kernel Prior to 2.6.24.1 'copy_from_user_mmap_sem()' Memory Access Vulnerability (Vulnerabilities)

Linux Kernel Prior to 2.6.24.1 '/proc' Local Memory Access Vulnerability

Linux Kernel Prior to 2.6.24.1 'vmsplice_to_user()' Local Memory Access

Linux Kernel Prior to 2.6.24.1 'vmsplice_to_pipe()' Local Privilege Escalation Vulnerability

Compiler Apache sans SSP

Michael Vergoz — Sun, 16 Sep 2007 10:44:00 +0000

Un autre petit tip pour compiler Apache 1.3 sans SSP.

$ ./configure --prefix=/je/sais/pas --exec-prefix=/je/sais/pas --enable-module=so
$ make CC="gcc -fno-stack-protector -DEAPI" LD="ld -fno-stack-protector"
$ readelf -a src/httpd | grep stack_chk

Et voila plus de SSP dans Apache :)

Pour Apache > 2.0 et pour APR il ne faut pas utiliser CC et LD mais CFLAGS, et LDFLAGS. En fait à l'époque Apache 1.3 ne gérait pas ces deux dernières variables.

$ make CFLAGS='-fno-stack-protector' LDFLAGS='-fno-stack-protector'

Carton rouge pour Gentoo

Michael Vergoz — Sun, 16 Sep 2007 10:10:00 +0000

Gentoo farci Gentoo farça!

Bon je suis un peut dégouté de Gentoo car au départ, je m'attendais à un système de versionning fiable au niveau du portage et en fait rien, non seulement les références des packages sont perdues mais les sources finissent par disparaitre des mirrors Gentoo. En gros, impossible de faire tourner une vieille gentoo.

Autre chose pas cool, impossible d'emergeR une vieille version d'autoconf genre la 2.53 ou 2.13 nécessaire pour compiler différentes versions d'Apache. Comme dit un pote, comment on peut faire tourner des Gentoo en production ? :(

On est loin des Ports de FreeBSD.