Vulnérabilités Web et XSS

Le firmware iPhone 3.1.3 de février 2010 a permis à Apple de corriger plusieurs vulnérabilités. La plus notable affectait le chargeur de démarrage iBoot et permettait de jailbreaker les iPhones 3GS. Une autre faille intéressante découverte par Tobias Klein a également été patchée, il s'agissait d'un stack buffer overflow dans la gestion des fichiers audio au format MP4 [CVE]. L'exploitation des failles de sécurité sur l'iPhone est rendue compliquée par l'utilisation du bit XN (eXecute Never) du CPU ARM, empêchant l'exécution de code sur la pile et le tas. Nous présentons ici comment utiliser le « return oriented programming » pour exploiter cette faille.

Les faux antivirus (Rogue AV) sont présents depuis de nombreuses années et tentent d'effrayer les utilisateurs en leur faisant croire que leurs machines sont infectées. Le FBI affirme que le montant des fraudes est supérieur à 150 Millions de dollars, et pour obtenir une telle somme, les cybercriminels sont sans cesse à la recherche de techniques alarmantes et effrayantes pour les utilisateurs.

Dans un environnement d'entreprise, il peut s'avérer bénéfique de restreindre les applications qu'il est possible d'exécuter sur un système Windows, que ce soit un poste de travail ou un serveur. Voyons si AppLocker, fonctionnalité disponible depuis Windows 7 et 2008 R2, répond à cette attente.

Le XSS (pour Cross Site Scripting) est à la fois connu et mal connu : connu parce qu'il est aussi vieux que le Web lui-même, ce qui fait qu'aucune personne s'intéressant même de loin à la sécurité informatique n'ignore ses grands principes, mal connu parce que comme tout ennemi familier que l'on a connu petit et chétif, il a grandi et s'est développé dans l'ombre de son grand frère, le Web, en n'attirant que peu les regards et en conservant aux yeux de beaucoup d'experts en sécurité l'image d'un parasite mineur, juste capable de provoquer l'affichage de messages d'avertissement inoffensifs ou de lancer des attaques reposant sur un minimum d'ingénierie sociale.

Résumé de l’épisode précédent : le XSS, en tirant notamment parti de l’API DOM, permet de réaliser des attaques si puissantes que Jeremiah Grossman sous-titrait son livre XSS Attacks paru en avril 2007 « XSS is the New Buffer Overflow, JavaScript Malware is the New Shell Code »2. Il est important d’examiner de plus près cette analogie entre XSS et attaques applicatives classiques afin de bien comprendre toute l’étendue des possibilités offertes par le XSS à un attaquant, notamment à travers l’injection de différents types de codes JavaScript malveillants. Dans la troisième partie de cet article, nous essaierons d’évaluer le risque réel de différents scénarios d’attaques, tirant notamment partie des trois erreurs les plus fréquemment commises à propos du XSS.

Résumé des épisodes précédents : le XSS tend à devenir une composante importante de scénarios d'infection massive exploitant des vecteurs d'attaques combinées visant, entre autres, à constituer des réseaux de machines zombies. La parenté du XSS avec des techniques d’attaques applicatives par débordement de tampon permet de bien comprendre la diversité et la puissance des attaques que le XSS rend possibles. Nous allons maintenant nous interroger sur les raisons susceptibles d’expliquer le relatif échec de la lutte anti-XSS aujourd’hui et illustrerons notre propos en essayant d’évaluer le risque réel de différents scénarios d’attaques, tirant notamment parti des trois erreurs les plus fréquemment commises à propos du XSS.

S’il est un sujet de trolls quasi quotidien sur la Toile, c’est bien de chercher à démontrer quel est le meilleur navigateur web. Ça tombe bien, ce qui suit a justement pour objectif d’alimenter ces trolls !Cet article effectue un tour d'horizon (non exhaustif) des outils de sécurité destinés à l’utilisateur, tels que les filtres anti-phishing, les protections contre les malwares ou contre ces attaques bizarres1 qui se terminent par « jack ». Seront aussi évoqués les mécanismes implémentés par les navigateurs afin de complexifier l’exploitation d’une vulnérabilité.

D’un point de vue théorique et pratique, où en est aujourd’hui la Chine en matière de guerre de l’information et de cyberguerre ? Nous pourrions voir dans la recrudescence des attaques imputées à la Chine (intrusions dans des systèmes d’information d’agences gouvernementales et de grandes entreprises, vol de données, espionnage, etc.), la démonstration de son implication de plus en plus marquée dans le champ de la guerre de l’information, le recours systématisé à des opérations agressives dans le cyberespace, dans le prolongement somme toute logique des théories et doctrines de GI affichées depuis près de 20 ans (§I). Toutefois les agressions recensées dans le monde ne sauraient résumer ni même refléter l’approche chinoise de la GI1 et de la cyberguerre : d’une part, les opérations ne peuvent lui être imputées assurément - pour des raisons techniques - et d’autre part, la doctrine chinoise ne saurait se limiter à ces intrusions. Pour tenter de répondre à la question, il nous a alors semblé intéressant de choisir un nouvel objet d’analyse. Nous avons ainsi analysé les émeutes du Xinjiang, qui au cours de l’été 2009 ont marqué l’histoire de la Chine et avons tenté d’identifier dans les épisodes de cette crise intérieure majeure et les modalités de sa gestion par les autorités (§II), des indices caractérisant l’approche chinoise de la GI (§III).

Cet article décrit la sécurité des différents modèles d’interconnexions entre les réseaux d’opérateurs afin de construire des réseaux virtuels privés (VPN). Après une brève introduction et un rappel sur les protocoles LDP et MP-BGP, quatre options d’interconnexions entre ces réseaux sont décrites, détaillant les avantages et inconvénients.

L'accès aux données d'un back-end SQL est souvent considéré comme le point final d'un pentest sur une application web, mais avec des back-end SQL de plus en plus riches en termes de fonctionnalités et l'essor des web services, les bases de données ne sont plus cantonnées au fond du SI dans une dmz isolée, mais sont devenues de véritables nœuds d'interconnexion entre SI. Il ne faut donc plus considérer l'accès au SGBD comme une fin en soi, mais comme un point d'appui pour pénétrer en profondeur dans les SI.Nous verrons comment un attaquant partant d'une simple injection SQL peut rapidement transformer une base de données Oracle en un proxy http, ainsi que les outils qui sont à sa disposition pour faciliter cette tâche. Nous terminerons par quelques recommandations pour pallier de tels risques.

Dans tout cours de cryptographie universitaire, la taille de la clé est souvent présentée comme une condition clé de la sécurité d’un crypto système. Pour les éditeurs de solutions sécurisées, la taille de la clé résume tout et devient une condition suffisante. Mais, si cela marche sur le papier, dans la pratique, il en est tout autrement. Les erreurs voire les trappes d’implémentation réduisent souvent la sécurité prétendue d’une application à une peau de chagrin. C’est également sans compter avec les erreurs propres aux utilisateurs : car si la cryptologie a été libéralisée, l’éducation des utilisateurs n’a jamais été faite et ces derniers se retrouvent avec des outils qui se retournent contre eux du fait de l’ignorance de règles de bases. Dans le cas d’un utilisateur lambda, c’est d’une gravité toute relative, cela peut être dramatique pour un usage professionnel. Dans cet article, nous montrons comment opérationnellement casser le chiffrement RC4 128 bits de la suite Office de Microsoft (jusqu'à la version 2003) et réfléchissons à comment dissimuler des trappes dans une application.