devloop :: blog

Comme je suis de près les différentes build de la version d'Opera 10 à venir, je ne pouvais pas échapper au buzz concernant Opera Unite.

J'ai donc mis en service ma page depuis quelques temps déjà et ait eu l'occasion de tester les différents services proposés en standard.

J'ai d'abord rencontré des problèmes pour que la page soit accessible. Bien que l'utilisation de UPnP soit activée dans Opera et sur le routeur, ce dernier ne semblait pas recevoir la moindre demande de port. J'ai donc du NATer moi même le port 8840 pour recevoir les connexions. Il est possible que cela soit corrigé depuis, je n'ai pas réessayé la configuration depuis la première build.

Le Fridge qui permet de laisser des mémos affichés sous la forme de post-it et le Lounge qui est un salon de discussion très sommaire sont plus des gadgets à mes yeux et je les ais désactivé assez tôt. A noter que pour le Loundge je n'ai pas retrouvé dans les dossiers de cache Opera les conversations ce qui est un bon point question vie privée ("privacy"). Bien sûr les données sont transférées en clair sur le réseau et non protégées par SSl/TLS.

Le système de galerie photo et le service faisant office de serveur web sont plutôt sympathiques et permettent à des personnes souhaitant créer un site Internet de le faire facilement et de disposer d'un nom de domaine pour pas un rond
Evidemment on se limite à des pages statiques, il n'est pas question de faire exécuter du PHP ou CGI.

Pour le peu que j'ai regardé niveau sécurité, je n'ai rien remarqué de mauvais. Les cookies ne sont pas définis sur un sous-domaine global mais bien le domaine exact pour la "domiciliation" de l'utilisateur (home, work etc) et l'administration se fait par le protocole spécial unite:// (donc pas d'attaques du type CSRF)

J'ai eu plus de difficultés à faire fonctionner le Media Player mais le problème venait en fait de FlashBlock pour Opera qui cassait l'affichage des pages
Une fois corrigé, les flux passent bien et on ne sent pas les connexions passer depuis la navigateur (évidemment c'est selon le nombre de personnes connectées).

Quand au système File Sharing, il permet à chacun de mettre très simplement à disposition des fichiers. On regrette bien sûr de ne pas pouvoir spécifier plusieurs dossiers de partage.
Les transferts semblent se faire sans problème. Lors d'un test on a même pû transférer un fichier d'environ 700Mo... en revanche ce transfert utilisait la totalité de la bande passsante en upload Opera semble avoir rectifié le coup avec la dernière build en date.

Pour ce qui est des autorisations d'accès, c'est pour le moins simple : ressources publiques, protégées par un mot de passe ou privées (seul vous y accèder).
Un système permettant d'uploader des fichiers vers son ordinateur pourrait aussi être sympathique (transfert de fichier dans les deux sens)

En revanche le système dans sa totalité n'est par parfait et il arrive que l'on doive relancer Opera pour refaire fonctionner les services qui ne répondent plus.
J'aime vraiment la possibilité que le service offre à chacun (même des "non-initiés") de pouvoir mettre en place et gérer soit même un petit espace sur Internet

Voici un site totalement inutile... donc indispensable qui ravira les fanboys de la distribution Linux openSUSE :

Geeko Builder

Ce site vous permet de créer vous même votre fond d'écran openSUSE en sélectionnant les différents éléments (décor, vétements, outils) à incorporer.
Par exemple j'ai fait une version Geeko Ninja dans une salle de serveurs

Mieux vaut tard que jamais, j'ai découvert FlashBlock pour Opera. Je l'utilise depuis une semaine et j'en suis très content.
Il est composé d'un UserJS et d'un feuillet de style. Une fois les fichiers copiés dans leurs dossiers Opera, il suffit d'aller dans Afficher > Style et de sélectionner "Flash Blocker" pour l'activer.
L'utilisation est exactement la même que celle du plugin Firefox et en plus c'est compatible avec les dernières build béta d'Opera 10

FlashBlock pour Opera

Alors que Wapiti a dépassé doucement mais surement la barre des 16200 téléchargements sur SourceForge, les plus observateurs auront remarqué la sortie d'une version 2.0.0 béta avant-hier soir.

La question que vous vous posez certainement c'est comment l'on peut passer d'une version 1.1.7-alpha à une version 2.0.0-béta...
Tout simplement avec beaucoup de changements !! Et il s'en est passé des choses depuis la sortie de la précédente version.

Premièrement, le nombre de développeurs est passé de 1 à 3 grace à l'aide de 2 développeurs espagnols de ICT-Romulus.
Leur souhait était de pouvoir apporter des nouvelles fonctionnalités à Wapiti, notamment pour faciliter son intégration dans un projet de framework J2EE basé sur Maven (si j'ai tout compris lol).
Dans tous les cas ils ont proposé de participer au développement de Wapiti afin que tout les utilisateurs puissent profiter de leurs idées et de leurs modifications Cela est passé par la mise en place d'un espace SVN pour le projet pour faciliter le développement.

Leur objectif principal était de travailler sur le rendu final fournit par Wapiti. Ainsi il est possible d'obtenir un compte rendu des vulnérabilités dans 3 formats différents : XML, HTML et texte simple. Pour cela les options -f (format) et -o (output) ont été rajoutés.
Ils ont aussi réussi à séparer les payloads du code, ce qui rend plus simple leur ajout. Le code a été aussi revu et est plus modulaire.
Des règles de détection pour les failles SQL ont aussi été rajoutées.

De mon côté j'ai pû enfin résoudre le problème des boucles sans fin lors du scan d'urls en ajoutant l'option -n (ou --nice) qui permet de définir un "seuil de tolérance" au niveau des urls du même type.
Ainsi si les pages suivantes ont déjà été scannées :
http://server/p?a=x&b=1&c=x
http://server/p?a=x&b=2&c=x
http://server/p?a=x&b=2&c=y

Avec un seuil de 2, quand l'url "http://server/p?a=x&b=3&c=x" sera trouvée, elle sera exclue car déjà 2 urls du même pattern ont déjà été trouvées (http://server/p?a=x&b=*&c=x).
Même chose avec l'url http://server/p?a=x&b=2&c=z.
Par défaut aucun seuil n'est spécifié (ce qui revient à le fixer à 0). A vous de voir la valeur qui vous semble juste (10 me parait en bon compromis pour faire beaucoup de possibilités sans tourner en boucle).

J'ai aussi réussi à faire fonctionner l'authentification HTTP (option -a) en pompant sur le code de sqlmap. Même si les instructions sont sensiblement différentes par rapport à ce que Wapiti faisait, le principe est le même et je ne saurais pas dire pourquoi ça ne fonctionnait pas auparavant (alors que proxies et cookies fonctionnaient)... un des mystères de Python
Malheureusement, étant donné la façon dont les modules urllib2 fonctionnent, il est préférable de retirer l'authentification sur le serveur et d'utiliser Wapiti simplement. En effet pour chaque url, si l'authentification est présente, Python va émettre deux requêtes : une première sans authentification qui va renvoyer une erreur 401. Et une seconde avec les identifiants pour passer la vérification

Enfin la nouvelle méthode de scan XSS est complètement implémentée et la librairie Beautiful Soup a été mis à jour.

Pour la prochaine version, différents changements sont à faire comme pouvoir gérer les erreurs HTTP 500 (nouveau bug), améliorer la qualité des rapports de scan, limiter le nombre de plantages liés au décodage Unicode et enfin travailler sur la vitesse de scan de Wapiti.
En effet lors de certains tests, on s'apperçoit que Wapiti peut avoir un effet DoS sur le serveur web (voir que les 152 process lancés par Apache pour répondre aux requêtes sont tous occupés c'est pas top...) Il faut donc essayer d'envoyer le plus de requêtes possibles par connexion (ou trouver la juste proportion entre les deux)

Dans tous les cas, je ne peux que vous conseiller de passer à cette nouvelle version qui apporte des fonctionnalités importantes

Télécharger Wapiti-2.0.0-béta.

Il y a presque un an maintenant j'avais testé Anywhere.FM, un site permettant d'uploader sa musique en ligne pour pouvoir ensuite la réécouter depuis n'importe quel poste connecté à Internet et disposant du plugin Flash d'Adobe.
C'est très pratique et agréable... quand cela fonctionne. Et malheureusement sous Linux, ça ne fonctionne pas souvent. Premièrement la fonction d'upload ne fonctionne pas sous Linux avec Flash9 (je n'ai pas testé avec la version béta 10), la faute à Adobe qui semble moins pressé quand il s'agit de systèmes libres. Deuxièmement la lecture des titres (et c'est quand même l'utilité principale du site) semble fonctionner uniquement quand ça lui chante... et de toute évidence depuis des mois le site a décidé qu'il ne voulait pas lire les musiques sous Linux. Ainsi l'animation Flash reste bloquée sur "Loading..." mais ne charge rien du tout.

Bref dans mon raz-le-bol général j'ai décidé d'analyser le fonctionnement du site et de voir s'il est possible de développer un petit quelque chose qui me permettrait de pouvoir lire ma musique en ligne directement sur les serveurs sans avoir à passer par l'interface pompeuse existante
A l'heure actuelle il n'y a pas encore de code, seulement mon analyse qui dévoile la grosse partie du fonctionnement du site.

Identification
Si vous rendez sur une des urls du site, vous serez redirigés automatiquement vers http://www.anywhere.fm/player/. Cette page est chargée dynamiquement et en fonction de la page que vous avez demandé en premier, différentes variables seront passées à l'animation Flash chargée dans le navigateur (par exemple pour indiquer qu'il faut aller chercher la librairie de tel utilisateur).
Durant ce premier contact avec le site, un identifiant de session PHP (variable PHPSESSID) vous sera attribué et vous n'en changerez normalement pas même si vous fermez/ouvrez une session sur le site.
Cette variable de session définie comme cookie est spécifique à l'hôte www du domaine anywhere.fm (d'autres hôtes entrent en jeu comme on le verra plus tard).

Tracking
La page chargée fait appel à différents scripts JavaScript dont un qui a sans doute un rôle de tracking (analyse pour étude commerciale etc) mais à l'heure de ces lignes je ne le jurerais pas.
Le script en question se situe à l'adresse http://edge.quantserve.com/quant.js et il déclare une variable nommée "dc" qui est générée aléatoirement par le serveur.
La fonction principale nommée quantserve() récupère différentes informations sur la configuration de l'internaute et construit une url vers un "pixel traqueur" qui est ensuite chargée par le client pour envoyer les données au serveur pixel.quantserve.com.

La partie qui nous intéresse dans ce script (mais qui est peut-être optionnelle) est la modification des cookies.
La variable dc qui était définie se retrouve dans les cookies sous le nom "__qca".
Une autre variable, générée aléatoirement en JavaScript (code : Math.round(Math.random()*2147483647) ) est aussi ajoutée au cookie et se nomme "__qcb".

Contrairement à PHPSESSID qui est propre à www, __qca et __qcb sont propres à l'ensemble du domaine.

Crossdomain
L'animation Flash étant chargée, elle a besoin de vérifier qu'elle a bien la permission de communiquer avec certains serveurs. Pour cela elle va demander pour chacun un fichier crossdomain.xml qui définie les règles d'accès.
Parmis les serveurs on trouve music, upload-XX (XX étant un nombre multiple de 5) et upload-full.

Authentification
L'animation ayant déterminée qu'elle pouvait dialoguer avec music.anywhere.fm, elle effectue une requête GET sur la page /account/get_current_user?_unique_request_id_=XXXXXXXXXXXXXX.
L'argument _unique_request_id_ a pour valeur un nombre probablement aléatoire mais toujours très grand. Cet "identifiant unique de requête" est incrémenté à chaque communication avec le serveur music.

Le serveur music donne ses réponses sous le format XML. En l'absence de la saisie de vos identifiants, les données renvoyées sont celles de l'utilisateur par défaut (user_id = 89, login = demo, fullname = Lux)

La page en profite pour définir trois nouvelles variables de cookie :

• auth_token et auth_session_id ont pour restriction l'hôte music
  
• _HotPot_session_id est défini sur tout le domaine anywhere.fm
  

Ces trois variables sont typiques des variables de session : 32 caractères sous l'alphabet hexadécimal.
Malgré leur nom différents, auth_session_id et _HotPot_session_id ont la même valeur.

L'opération suivante est un POST à l'adresse /account/create_login_tracker?_unique_request_id_=XXXXXXXXXXXXXX.
Les variables vues précédemment et concernant l'hôte music ou tout le domaine sont bien sûr renvoyés à nouveau au serveur.
Les données passées dans le corps de la requêtes sont session_id (correspondant à auth_session_id de tout à l'heure) et user_id (correspondant à celui renvoyé par la requête précédente soit 89 ici).
Cela renvoit une information très courte de la forme : <tracker_id>XXXXXXXXXX</tracker_id>

Introduction à AMF
Débutent alors les communications AMF avec le serveur www. Action Message Format est un format de données créé à l'origine par Macromedia puis conservé par Adobe.
Il est utilisé principalement par Flash pour des communications RPC.
L'avantage par rapport à un formatage XML sont son format binaire (on n'est pas resteint à des caractères imprimables) et son gain de place. Il utilise notemment un système de références qui permet de ne pas avoir à redéfinir des données déjà envoyées (pour le moment je n'ai pas étudié en détails ce sujet).
On pourrait comparer ce format au bencodage de BitTorrent mais en réalité il est bien plus complexe, voire carrément prise de tête (rien que le codage d'entiers sur 29 bits donne un aperçu)
De plus deux versions existent : AMF0 et AMF3. Il peut possible d'intégrer des données AMF3 dans du AMF0 par le biais d'un type particulier (0x11)
Les requêtes HTTP transportant des données AMF ont l'entête "Content-Type: application/x-amf"

Ce format n'étant pas le sujet de l'article, je n'en dirais pas plus pour le moment.

Connexion
Passons pour l'instant sur les échanges RPC qui ont été faits, et rentrons nos identifiants de connexion sur le site.
Cela génère une requête POST sur /account/login?_unique_request_id_=XXXXXXXXXXXXXX sur le serveur music. L'identifiant de requête a (ne l'oublions pas) été incrémenté à plusieurs reprises et cela ne changera pas.
Les données envoyées sont :

• dans le header Cookie : __qca, __qcb, auth_token, auth_session_id et _HotPot_session_id
  
• dans le body : "login" et "password"
  

auth_session_id et _HotPot_session_id ont toujours la même valeur.
La réponse du serveur nous informe d'une nouvelle valeur pour auth_token (qui définie donc notre session utilisateur sur le serveur music)
Sur le serveur www, aucun changement n'est à prendre en compte, les données du cookies n'ont pas changées.

Les deux requêtes effectuées avant connexion sont répétées sauf que get_current_user renverra notre user_id et create_login_tracker renverra une nouvelle valeur.

RPC et Flex
Les échanges RPC sont effectués uniquement avec le serveur www et à destination de la page
/amfphp/gateway.php?_unique_request_id_=XXXXXXXXXXXXXX
Les requêtes RPC sont toujours groupées par deux et ont le même _unique_request_id_. Anywhere.FM utilise les librairies Flex dans ses échanges.
On trouve ainsi deux types de messages :

• flex.messaging.messages.CommandMessage : permet de faire un "ping" du serveur. C'est toujours la première requête du groupe
  
• flex.messaging.messages.RemotingMessage : permet d'appeler une fonction RPC sur le serveur. C'est toujours la seconde requête
  

Ces fonctions Flex se basent toujours sur les mêmes arguments.
Concernant les fonctions RPC, l'argument source sera toujours fixé à "BlazingFast.DBQueries". L'argument operation contient le nom de la fonction à appeler sur le serveur et body est un tableau contenant les arguments à y passer.

Fonctions
Le premier argument de chacune des fonctions existante correspont au auth_session_id, permettant ainsi au serveur de vérifier les permissions d'accès aux données.

La première fonction qui nous intéresse est get_complete_profiles. Elle prend deux argument : le premier est (bien entendu) l'identifiant de session et le second est un tableau contenant une liste d'identifiants utilisateur.
Le résultat retourné est un tableau contenant des informations diverses sur les utilisateurs correspondant, notemment les liste de titres dont ils disposent.
Trois données importantes permettent de définir une playlist : playlist_type, playlist_id et playlist_name.
Le type d'une playlist aura la valeur 200 s'il s'agit de la collection entière de l'utilisateur et 300 s'il s'agit d'une librairie personnalisée.

La fonction get_songs_for_user_playlists pourrait se définir de cette façon :
get_songs_for_user_playlists(session_id, user_id, bool, [playlist_id], [playlist_type], ['0','0'...])
Le rôle du booléen en troisième argument m'échappe pour le moment ainsi que le tableau de chaines de caractères définie à '0'.
Cette fonction retourne un tableau qui peut être imposant définissant chaque titre d'une liste de lecture. En dehors des données "classiques" (name, artist, album), on trouve les données "master_id" et "song_ressource_id" qui permettent de récupérer une adresse valide pour un titre donné.

C'est la fonction get_song_url qui nous donne le sésame. On pourrait la déclarer de cette façon :
get_song_url(session_id, user_id, master_id, song_ressource_id)
Elle retourne une chaine de caractères correspondant à une url HTTP vers le fichier MP3
Cette url dispose d'une clé d'accès ainsi qu'un temps de validation. Par conséquent il ne doit pas être possible d'utiliser deux fois la même url.

Conlusion
Il reste de nombreux points à éclaircir qui doivent pouvoir être déterminés par expérimentation comme :

• _unique_request_id_ est-il généré aléatoirement au début ?
  
• Les variables définies par quantserve() ont-elle une utilité autre que le tracking ?
  
• Quelle utilité a la valeur tracker_id ?
  
• A quoi sert le booléen et le tableau de chaines passé à get_songs_for_user_playlists ?
  

Netographie
Open Source Flash documentation
PyAMF (les codes sources m'ont bien aidé)
Charles Web Debugging Proxy : Un proxy qui comprend l'AMF Malheureusement en shareware

Ping Flex
Pour terminer un petit exemple de code utilisant l'API PyAMF qui réalisé un ping en Flex (merci aux développeurs de l'API pour leur aide ;-) ) :

import pyamf
from pyamf.remoting import client
from pyamf.flex import messaging
from pyamf import remoting

gw = client.RemotingService('http://127.0.0.1/',pyamf.AMF0,pyamf.ClientTypes.Flash9)
message = messaging.CommandMessage(body={},
    timestamp=0,
    destination='',
    clientId=None,
    headers={'DSId': u'nil'},
    timeToLive=0,
    messageId='7478D81C-65B4-EA4B-B52E-4689507A7241',
    operation=5,correlationId='',
    messageRefType='flex.messaging.messages.CommandMessage')
gw.addRequest('null', message)
gw.execute()