Publications


Pourquoi publions nous nos recherches en sécurité?

L'intégralité de l'équipe de consultants de Wargan Solutions consacre un cinquième de son temps de travail à l'auto-formation et à la R&D. Cette R&D est majoritairement consacrée à l'écriture d'exploits afin d'enrichir notre tool-suite utilisée lors des test d'intrusions. Nous consacrons donc un cinquième de notre temps à relire du code source ce qui nous confère une très grande expérience en la discipline mais aussi une méthodologie particulièrement pointue.

Les vulnérabilités et études que nous avons décidé de publier (nous ne publions qu'une très infime partie de nos découvertes) sont quasiment toutes exclusivement issues d'audits de code source et de production de concepts.

Liste de nos publications


13-05-2013 Critique IPB: Admin Account Takeover - Code Execution

IPB harbors a sanitization flaw in its registration form and user control panel (accessible once logged in). Incorrect e-mail address validation code allows an attacker to take over the admin account without prompting any alert but preventing the real admin to login afterwards. After a successful takeover, the attacker can plant a PHP backdoor using IPB's templating system. Thorough administrators will inspect total file system after they recover their hacked account, while other administrators might assume they are dealing with a bug, receive their new password using "Password recovery" system and leave the backdoor intact. Attacker may also use the "Retrieve password" process to mislead the admin into thinking their account was locked due to unsuccessful login attempts and not investigating further, thus preserving the backdoor.


23-11-2012 Etude Implémentation d'une hashtable

Une table de hachage est une structure de données généralement utilisée pour implémenter tableaux associatifs, caches, ou plus généralement associer une clé à une valeur. Dans le cadre de notre projet, nous avons choisi de réaliser un cache de données reposant sur cette structure, particulièrement intéressante dans notre cas pour ses temps d'accès relativement constants par rapport au nombre d'entrées dans la table. Cependant, la majorité des implémentations libres ne sont pas optimisées pour une utilisation parallèle. Nous avons donc décidé de programmer cette structure nous-mêmes, en nous basant sur les travaux publiés sur le sujet. Nous décrirons dans cet article le cheminement que nous avons suivi afin de mener à bien cette implémentation. Une table de hachage n'est pas une structure complexe: c'est en réalité un vulgaire tableau. Tout l'art et la difficulté de son implémentation se résume à deux problèmes principaux:

  • Le premier consiste à trouver une fonction injective (fonction de hachage) associant efficacement à toute clé un emplacement quelconque dans le tableau.
  • Le second est plus subtil et procède directement du premier: notre tableau ne disposant que d'un nombre fini d'emplacements, il est nécessaire de gérer le cas où la fonction de hachage attribue le même emplacement à plusieurs clés différentes (collision). C'est le problème de la gestion de ces collisions qui est le plus ardu, et il existe de nombreuses façons de le traiter. Nous allons les passer en revue concisément dans les paragraphes suivants.



15-03-2012 Etude Allocation mémoire avec le TLS

Les allocations mémoire sont généralement plus coûteuses que d'ordinaire en environnement multi-thread. En effet, la majorité des algorithmes d'allocation en usage dans les systèmes d'exploitation actuels implémentent le tas à l'aide d'un ou plusieurs pool de mémoire protégés par des mécanismes de synchronisation à exclusion mutuelle. Cela induit de la contention lorsque plusieurs threads ont besoin de mémoire simultanément. De plus, les primitives de verrouillage introduisent bien souvent une perte de performance même lorsqu'un seul processus les utilise.

A cela s'ajoute l'éventualité plus fourbe d'obtenir dans deux threads différents des blocs mémoire partageant la même ligne de cache processeur. Dans un tel cas de figure, si deux processeurs utilisent ces blocs mémoire indépendants simultanément, le mécanisme de cohérence du cache provoquera une importante perte de performance en le rafraîchissant à chaque accès. Nous avons donc étudié la possibilité de limiter le nombre d'allocations concurrentes pour augmenter les performances tout en continuant d'utiliser l'allocateur du système à l'aide du mécanisme de Thread Local Storage (TLS).


05-10-2011 Critique Facebook: Multiples vulnérabiliés (CSRF/XSS)

Facebook utilise un système anti-CSRF basé sur deux jetons respectivement nommés post_form_id et fb_dtsg. Ces jetons change fréquemment, et sont certainement construits à partir de paramètres aussi divers que la date du jour, l’heure de création du compte, l’id de l’utilisateur, et sûrement beaucoup d’autres. Déterminer les valeurs de ces jetons pour un utilisateur précis est, à notre avis, chose impossible.


04-10-2011 Critique Facebook: Multiple vulnerabilities (CSRF/XSS)

Facebook comes with an anti-CSRF system based on two tokens, respectively called post_form_id and fb_dtsg. These tokens change frequently, and are certainly built upon several parameters including time of day, time of account creation, user id, and many others. Determining the values of these tokens for a specific user is, to our view, impossible.


Oldies Critique PunBB < = 1.2.13 Multiple Vulnerabilities

PunBB is prone to an SQL injection in the search module, because of an unitialized variable which is undirectly passed into an SQL query without any check. Using this vulnerability, a visitor can perform blind SQL injections, which can lead to the content disclosure of any data stored in the database. The exploitation of this flaw uses the PHP Zend_Hash_Del_Key_Or_Index vulnerability, and thus requires register_globals enabled and PHP <= 4.4.2 or PHP <= 5.1.3 on the server where PunBB is installed.