21 déc. 2007

Programmation bluetooth sous Gnu/Linux

Fiou! Voici enfin terminé le premier semestre (et sa fin pour le moins chaotique). Nous voila donc à quelques jours des traditionnelles fêtes de fin d'année. Fêtes au cours desquelles des millions de personnes vont s'adonner au "plaisir d'offrir, joie de recevoir". Et parmis les présents échangés se trouveront une foule d'objets high-tech, autement communicants, et sans fils, il s'entend!

Depuis quelques jours une idée me trotte donc dans la tête (au détriment de mes examens :'(), celle de l'écriture d'un petit framework d'exploration des réseaux bluetooth environnants. Je ne parle pas ici de sniffers (même si me connaissant j'y reviendrais, hcidump est déjà installé!). Mais plutôt d'une exploration active.

En effet le protocole bluetooth spécifie que les appareils, en plus de contenir un code spécifique à leur constructeur, renferment et peuvent communiquer leur complète description (les services qu'ils hébergent, des détails sur leur mode de communication etc...)
Hmm, appétissant non? Alors imaginez qu'en plus j'apprends que la pile bluetooth de linux (bluez) est la plus solide et la meilleure implémentation (en ce qu'elle permet au programmeur un accès aux couches bas niveau du protocole) comment pourrais-je me détourner d'un tel projet?!!


Je ne suis qu'au début de mes investigations dans ce domaine, mais les nouvelles sont bonnes, toutes les sources font l'apologie de la lib bluez, la programmation client et serveur se fait via les primitives socket() et bind().

J'ai donc commencé mon apprentissage via un code établissant une liaison série entre deux périphériques. Je ne le copie pas en entier, il est relativement classique pour tout ce qui est des parties qui prennent de la place...

Je conserve :


#include <rfcomm.h> /* définition des adresses bluetooth */

fd = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);


/* CLIENT */
connect(fd, (struct sockaddr *)&sa_rfcomm,
\ sizeof(struct sockaddr_rc));

/* SERVEUR */
bind(fd, (struct sockaddr *)&sa_rfcomm,
\ sizeof(struct sockaddr_rc));
listen(fd, MAX_CONN);


Rien de spécial pour l'appel à socket() à part que c'est beau. sa_rfcomm est une structure contenant l'adresse du serveur et le canal employé pour communiquer, via send() et recv().

Pour les plus pressés, l'accès bas niveau se fait en spécifiant les protocoles BTPROTO_HCI ou BTPROTO_L2CAP lors de la création du descripteur de fichier, mais ceci est une autre histoire.

Histoire qui s'annonce passionnante, au vu de la convergence des menaces et des protections vers l'informatique mobile (j'inclus là téléphones, PDA et consoles de jeu). On peut légitimement penser que cette convergence risque fort de s'accélérer lorsque l'on observe les comportements actuels relatifs à la sécurité. Un Buffer Overflow sur l'iphone, permettant d'executer du code noyau devient quasiment un élément de publicité ("installez ce que vous voulez sur votre Iphone!!"). Ou ces hotspots wifi un peu partout, les logiciels de gestion de finance sur téléphone portable... Toutes ces aberrations sont monnaies courantes. Contrairement aux logiciels antiviraux pour systèmes, tellement rares qu'on peut les considérer comme inexistant!
La lecture des 1200 pages de spécifications du protocole constitue une bonne explication quant à l'existence de nombreuses implémentations buggées.

Bref, de là à voir le bluetooth fricoter avec le metasploit framework comme le fait le wifi depuis la V3.0 il n'y a qu'un pas, qui sera sans doute franchi relativement rapidement...

Je releaserais mes codes ici au fur et à mesure de l'avancement du projet.

8 déc. 2007

Steganographie -=] part 2 [=-

Toujours dans le cadre de nos travaux sur la steganographie, je me suis attaquée à l'écriture d'une implémentation "deux-en-un" de canaux de communication, en local cette fois-ci.

Ici, l'objectif est de faire communiquer deux applications de manière furtive sur un même ordinateur. Les deux applications ne nécessitant ni des privilèges égaux, ni des privilèges équivalents.

Le premier type de canal est un "covert storage channel" (je ne connais aucune traduction officielle du terme en français). Cela consiste en le placement d'un verrou posix sur un fichier par une première application. La seconde teste la
présence de ce verrou à intervalle régulier et considère selon les résultats qu'un bit 0 ou 1 lui a été transmis.

La difficulté réside ici dans la synchronisation des deux processus. Il est possible de la faire via le timestamp, en mettant le processus en sommeil tant que le timestamp n'est pas congru à 0 (mod 5) par exemple...

Le second canal est un "probalistic channel", il consiste en la mesure d'un phénomène par le processus récepteur, et la modification de la probabilité de réalisation de celui-ci par le processus émetteur.

Ici, la mesure se fera donc sur le taux de présence du verrou sur un fichier pour 100 tentatives d'accès par exemple. Si celui-ci dépasse un certain seuil (95% par exemple), on considère la réception d'un bit 1, sinon 0.

L'implémentation utilisera donc la fonction lockf dont voici un extrait de la page de man:


#include int lockf(int fd, int cmd, off_t len);
[...]

F_TLOCK
Comme F_LOCK mais l'appel n'est pas bloquant,
il renvoie une erreur si le fichier est déjà verrouillé.

F_ULOCK
Déverrouiller la section indiquée du fichier.
Ceci peut conduire une section verrouillée à
être découpée en deux sections.

F_TEST
Verifier s'il y a un verrou : l'appel renvoie 0
si la section indiquée est libre ou verrouillée
par le processus appelant, et -1 avec EACCES dans
errno si un autre processus possède le verrou.

J'ai entrepris la rédaction d'un code, ce dernier est plutôt simple, mais il s'avère très difficile de synchroniser correctement les deux processus. Les examens ayant grignotés mon temps libre, je suis forcé de remettre à plus tard la release du code...

3 déc. 2007

Je te dis base vulnérable et tu me réponds...

...que tu as 2 500 000 résultats en poche!
Car tu t'appelles Google et que tu as indexé une foultitude de pages d'erreurs MYSQL, mettant ainsi à disposition de tous des sites vulnérables avec le nom des tables, la requête erronée, le point d'injection etc...


Googlez donc ceci pour voir:

You have an error in your SQL syntax;
check the manual that corresponds to your
MySQL server version for the right syntax to use


Bien sûr les grincheux m'objecteront qu'il y a parmis ces pages recencées pas mal de bruit, de personne qui cherchent à résoudre des problèmes dans leur script ou des manuels de SQL. Néanmoins la proportion de véritables pages d'erreurs, vulnérables, est impressionnante.

Les plus chanceux font du tout en un en présentant des dizaines d'erreurs sur la même page, dans différentes bases de données. Au cas où le besoin s'en ferait sentir ces erreurs sont recyclables en jolies failles XSS...

Il n'y a qu'à injecter du javascript dans la requête, lors de l'affichage du message d'erreur le code est inclus dans la page!

Lancé, il est également possible de rechercher des avertissements de la fonction "include". En scriptant la chose, et en comparant l'URL proposée et la page, on peut trouver, sisi, des failles includes. La même que tout le monde croyait morte et enterrée semble se porter bien...


Convergence vers moi de regards noirs: "pourquoi rechercher des failles ainsi? N'as tu jamais fait d'erreur en programmant? et tout et tout..."
Cette recherche avait deux objectifs, le premier était de tester le comportement de google face à la recherche de pages "d'erreurs dangereuses", et bien il ne réagit pas, contrairement à des recherches de types


inurl:"machin_truc.php?var_vuln=" nom_de_l'app_vulnérable


Là Google mettrait brusquement fin à la recherche avec un message d'alerte (notamment pour lutter contre les malwares exploitant des failles connues comme "zero day").
Ici donc rien...
Le second objectif était de démontrer la terrible dangerosité des applications, surtout sur le web, un peu trop bavardes. Il y a quelques jours, un mode Verbose/Debug zêlé sur Dailymotion a révélé au grand public tout un fichier header, avec IP, logins et passwords internes!

Même si cacher les sorties d'erreur de ses scripts ne constitue pas une protection en soit, c'est tout de même un minimum, histoire de ne pas hurler à qui voudrait le savoir, que votre site est vulnérable...