dimanche 29 décembre 2013

NSA Catalog : petit papa Snowden

Les révélations faites par Edward Snowden continuent.
Le spiegel vient de publier un article sur le catalogue NSA. Edit 30/12/2013: Un lien avec un grand nombre de pages du catalogue /Edit. Il s'agit de tout ce que peut faire la NSA concernant les attaques sur le matériel. Et la liste est encore une fois longue. Les disques durs? Backdoorés. Les BIOS? Backdoorés. Les firewalls Juniper/Cisco? Backdoorés. Les cordons USB? Backdoorés. Le crash reporter de windows? Backdooré. Les communications mobiles? Ecoutées. Etc, etc, etc.. Inutile de reprendre l'article du spiegel, je vous laisse le lire.

Voici par exemple une image d'un cordon USB backdooré:
Cela permet la persistance de l'infection, de la communication over-the-air grâce à une antenne RF, etc...

Je serais curieux de lire le catalogue complet.

A part ça, joyeux noël :-)

Edit: De plus en plus d'articles mentionnent le fait que le crash reporter de windows envoie les données en clair. Le crash reporter de mac utilise SSL/TLS mais si vous avez accès à un cerificat SSL, ça se casse facilement aussi.

mardi 19 novembre 2013

Grehack 2013 writeup - 1337

Un des challenges de la grehack 2013 était du reverse linux.
Le binaire s'appelait 1337 (et les orgas avaient prévenus qu'ils aimaient le l33tsp34k). En attendant que l'orga mette les fichiers en libre-accès, je le pose sur un site de dl.

Writeup, première phase de découverte:
kevin@slack:~/chall/grehack$ file 1337
1337: ELF 32-bit LSB executable, Intel 80386,, statically linked, stripped
kevin@slack:~/chall/grehack$ readelf -s 1337
readelf: Error: Unable to read in 0x28 bytes of section headers
readelf: Error: Unable to read in 0x488 bytes of section headers
readelf: Error: Unable to read in 0x100 bytes of program headers

WUT? Un ELF illisible?

Bon, premier exercice, réparer le binaire:
kevin@slack:~/chall/grehack$ hexdump -C 1337 | head -2
00000000  7f 45 4c 46 01 01 01 13  37 13 37 13 37 13 37 00  |.ELF....7.7.7.7.|
00000010  02 00 03 00 01 13 37 00  90 84 04 08 34 13 37 00  |......7.....4.7.|
kevin@slack:~/chall/grehack$ hexdump -C /bin/ls | head -2
00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 03 00 01 00 00 00  b4 c1 04 08 34 00 00 00  |............4...|

Il y a quand même beaucoup de 1337 dans ce binaire. On tente une approche basique: tous les 0000 sont remplacés par des 1337:
kevin@slack:~/chall/grehack$ cp 1337 wip
kevin@slack:~/chall/grehack$ sed -i 's/\x13\x37/\x00\x00/g' wip
kevin@slack:~/chall/grehack$ readelf -s wip

Symbol table '.dynsym' contains 12 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.0 (2)
     2: 00000000     0 FUNC    GLOBAL DEFAULT  UND free@GLIBC_2.0 (2)
     3: 00000000     0 FUNC    GLOBAL DEFAULT  UND fgets@GLIBC_2.0 (2)
     4: 00000000     0 FUNC    GLOBAL DEFAULT  UND malloc@GLIBC_2.0 (2)
     5: 00000000     0 FUNC    GLOBAL DEFAULT  UND puts@GLIBC_2.0 (2)
     6: 00000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     7: 00000000     0 FUNC    GLOBAL DEFAULT  UND exit@GLIBC_2.0 (2)
     8: 00000000     0 FUNC    GLOBAL DEFAULT  UND strlen@GLIBC_2.0 (2)
     9: 00000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.0 (2)
    10: 0804889c     4 OBJECT  GLOBAL DEFAULT   16 _IO_stdin_used
    11: 08049aa0     4 OBJECT  GLOBAL DEFAULT   26 stdin@GLIBC_2.0 (2)
kevin@slack:~/chall/grehack$

Ok, ça semble bon.

kevin@slack:~/chall/grehack$ ./wip
Ready to become 1337?
yes
fail

Ok. Il est temps de regarder un peu à quoi ressemble ce challenge, pour une approche rapide, je prends metasm. Je démarre par l'entrypoint (0x8048490) et je navigue un peu jusqu'à 0x0804857c qui semble intéressant.
Et ce qui est à l'adresse 0x080488a0 est encore plus intéressant: on découvre trois manières d'écrire FAIL, puis un message de félicitations.

Si je regarde une vue d'avion du programme, on se rend compte que l'on peut dérouler l'exécution en plusieurs phases:
Pour ne pas alourdir le post, je ne met pas l'ensemble des vérifications, mais on voit deux boucles qui semblent faire des choses, puis des séries de checks qui mènent aux trois différents FAIL. C'est sympathique, car selon le message, on peut tout de suite savoir si on a passé l'étape. Analysons la Boucle1 et sa condition en sortie:

suite au strlen, on met la taille dans esp+0x10, on met 0 dans esp+0x1c, et on itère jusqu’à ce que le second égale le premier (autrement dit, on parse la chaîne). Pendant l'itération, on prend caractère par caractère du mot de passe, et on additionne en hexa (et attention car on compte aussi le caractère de fin de chaine 0xa).

En résumé, nous avons à esp+0x14 l'adresse de la clé entrée, et en esp+0x18 la somme des valeurs hexa de chacun des caractères.

En fin de boucle, on compare si la somme vaut 0x539 (ce qui fait 1337 en décimal, il y a du l33t dans ce chall). Vérifions si on prend 11 (0xa en hexa) caractères 'y' (0x79 en hexa) et un 'u' (0x75):
'0x79'*a+'0x75'+'0x0a' = 0x539
kevin@slack:~/chall/grehack$ ./wip
Ready to become 1337?
yyyyyyyyyyu
f41l

Le message d'erreur a changé, nous avons f41l, ce qui signifie que la première étape est donc passée.

La seconde étape fait 4 comparaisons:

Comparaisons très simples d'ailleurs.
On vérifie que le second caractère (eax+1) vaut 0x31 (1)
On vérifie que le quatrième caractère (eax+3) vaut 0x33 (3)
On vérifie que le quatrième caractère (eax+3) vaut 0x33 (3)
On vérifie que le huitième caractère (eax+7) vaut 0x37 (7)
Du 1337 encore. Si je modifie ma chaine par:
y1y3yyy7yyu, il va me manquer des points pour aboutir à 0x539, je complète donc avec d'autres caractères pour que la somme fasse 0x539 pour continuer à passer la première étape, comme par exemple: y1y3yyy7yyuHDD

kevin@slack:~/chall/grehack$ ./wip
Ready to become 1337?
y1y3yyy7yyuHDD
0xPh41L


Ok, on a bien le second message d'erreur, signe que la deuxième étape est passée.

La troisième étape démarre par la boucle nommée boucle 2 sur l'image vue d'avion:
Le programme va aller du côté de esp+0x14 (la clé) et faire deux XOR successifs, 13 puis 37 (oooooh, encore 1337). La clé va donc être XORée par 0x24.

La suite du programme est une longue suite de comparaison dont voici le début:
On voit que différents caractères du mot de passe sont comparés entre eux. Si on suit la chaîne complète, on observe que les caractères: 0,2,4,5,6,8,9,a,b,c,d sont identiques, et que le caractère en e-ième position vaut v (0x76). Si cela est vrai alors le message de succès est affiché:
Le dernier caractère est comparé à 'v', mais est XORé. 'v' XORé à 0x24 vaut 0x52 autrement dit 'R'.

 Si on résume le tout, on voit que le mot de passe doit répondre à ces caractéristiques:
.1.3...7......R+padding
avec tous les caractères '.' identiques, et que la somme en hexa de l'ensemble des chiffres vaut 0x539. Si je compte:
0x539 - 0x0a (retour chariot) - 0x31 - 0x33 - 0x37 - 0x52 = 0x442
J'ai besoin au minimum de 11 caractères et que le reste soit de l'ascii inscriptible. Avec une calculette hexa, je trouve une solution avec onze 'Y' et un 'o': Y1Y3YYY7YYYYYYRo
kevin@slack:~/grehack$ ./wip
Ready to become 1337?
Y1Y3YYY7YYYYYYRo
W3LL d0|\|3, y0u'r 50 L337 |\|0W...

Ok, chall done.

Et puisque je suis devenu un l33t et que le challenge permet plusieurs solutions, je propose sans trop de difficultés avec plein d'31337ness :
kevin@slack:~/grehack$ ./wip
Ready to become 1337?
31333337333333R^k3v1n
W3LL d0|\|3, y0u'r 50 L337 |\|0W...

EDIT 20/11/2013:  A la réflexion, je me rends compte qu'il y a une autre solution. Si on supprime le retour chariot de fin de chaine, alors on obtient une solution plus simple:

kevin@slack:~/grehack$ echo -n d1d3ddd7ddddddR | ./wip 
Ready to become 1337?
W3LL d0|\|3, y0u'r 50 L337 |\|0W...


PS: Je teste aussi un nouveau layout du blog, dites moi ce que vous en pensez, ça me paraît plus clair lorsque je copie colle du terminal et que je met des images. Si vous connaissez une CSS qui affiche correctement de l'hexa, je suis preneur aussi.

lundi 18 novembre 2013

Gre(at)Hack 2013

De retour de la Grehack 2013. En très bref: bonnes confs, bons repas, bon CTF, bonnes rencontres.

En peu plus long:

1/ La journée de conférence:
De manière générale très intéressantes. Juste une petite déception en fin de journée pour les rump car personne ne s'est proposé pour en faire.

Résumé des conférences, et des points qui m'ont marqués:
1/1/ Tain't not enough time to fuzz all the memory errors - Herbert Bos
Après un loooong rappel sur ce qu'est une corruption mémoire, l'orateur présente leur outil de fuzzing intelligent: Dowser. En toute fin de présentation, l'orateur présente un nouveau mode d'exploitation des binaires: le SROP, ou Signal Return Oriented Programming. Leur idée consiste à créer un faux Signal Frame sur la stack et de l'utiliser. Cette méthode semble très intéressante (adresses noyaux fixes, Turing complete ;) ), mais il n'a pas eu le temps de vraiment en parler.

1/2/ Specialization in the malware distribution ecosystem - Juan Caballero
L'orateur a travaillé sur les motivations du cybercrime, l'argent, ses mouvements et leur provenance. Les cybercriminels montent des business comme toute entreprise, en utilisant des plateformes cloud, des services clés en main, des taux de retour, des versions démos, etc.. On trouve du Pay-per-Install ou un tiers se charge d'installer un malware sur des machines, des Exploit-as-a-service ou un pirate vend clés en main un serveur d'infections, etc.. Le chercheur a monté des architectures d'analyse de ces infections pour en tirer des signatures de malware. Il finit avec un certain nombre de statistiques intéressantes. (Et au passage, j'ai rarement vu un orateur avec un débit de parole aussi rapide.)

1/3/ The many flavors of binary analysis - Halvar Flake
Halvar présente un certain nombre d'outils d'analyse de binaires avec leurs forces et leurs faiblesses. J'en retiens que l'analyse des patchs binaires des SP windows donne des 0-day car des correctifs ne sont pas toujours backportés: "SP Win8 => 0day win7". En reverse, il manque des outils pour bien modéliser les failles de Use After Free, de certaines boucles, et des flux de données des navigateurs modernes (JS, events, Jit, etc..). En résumé: "Reverse engineering is awesome!"

1/4/ Unraveling large scale geographical distribution of vulnerable DNS servers using asynchronous I/O mechanism - Ruo Ando, Yuuki Takano and Satoshi Uda
Les serveurs DNS sont une des chevilles de l'internet. Les chercheurs se sont posés deux questions: Existe t'il des serveurs DNS non mis à jour (vulnérables à au moins une attaque), et est-ce que les "bad guys" peuvent les trouver. La réponse à ces deux questions est malheureusement oui. Ils ont écrit un scanner asynchrone qui a crawler IPv4 en moins d'une trentaine d'heure, ce qui leur a permis de vérifier que des millions de DNS ne sont pas à jour, et que la méthode est suffisemment simple pour être utilisée par n'importe quel bad guy. Message personnel : patchez.

1/5/ Vulnerability Inheritance in Programmable Logic Controllers - Eireann Leverett and Reid Wightman
Aujourd'hui tout le monde a pris conscience des enjeux SCADA et de leurs vulnérabilités. Ces chercheurs se sont intéressés aux PLC Programmable Logic Controller qui sont des microcontrolleurs gérant des I/O. Ils ont un microkernel, tournent en root, possèdent un serveur web et utilisent des protos SCADA classiques (ModBus, etc..). Ils ont trouvé une faille dans un PLC, scannés IPv4 (ça devient la mode, avec masscan, unicorn, la conf précédente, etc...) et trouvés 600 PLC vulnérables. Il faut signaler un Award phénoménal à la pire vendor response lorsqu'ils ont remonté le bug, qui est un contournement de l'authent. Le vendeur dit que l'authent est censée fonctionner, qu'ils ne feront rien, et qu'il faut mettre des firewalls ou des VPNs devant le PLC.

1/6/ Amplification DDoS attacks with game servers - Alejandro Nolla
J'ai l'impression d'avoir déjà entendu ce talk toutefois très intéressant. Pour ceux qui ne connaissent pas le sujet, il faut savoir que les serveurs de jeux sont une cible de choix pour un DDoS: ils répondent beaucoup de données à une petite requête UDP. Un pirate peut espérer faire un x30 en débit en utilisant des serveurs de jeux. Ca marche, et les éditeurs semblent ne pas s'intéresser au problème donc on risque de voir ce genre de DDos encore longtemps.

1/7/ APT1 - Paul Rascagnères
Un remplacement au dernier moment d'une conférence. RootBSD nous présente son article APT1. Excellente présentation avec une vidéo de l'installation du réveil (sirène + gyrophare) pour le prévenir lors de la connexion des C&C à 1h du matin :)

1/8/ Pre-filtering Mobile Malware with Heuristic Techniques - Ludovic Apvrille and Axelle Apvrille
Cette conférence présente une architecture d'analyse automatique d'applis Androïd afin d'en détecter les malicieuses. Le but est d'obtenir aucun faux positif. Lorsqu'une appli malicieuse est détectée comme telle, l'analyse est terminée, et cela se fait assez vite. Le problème concerne les applis saines: à partir de quel niveau d'analyse est il possible de considérer que l'application n'est pas malveillante? http://perso.telecom-paristech.fr/~apvrille/alligator.html aide à la décision.

1/9/ Detecting Privacy Leaks in the RATP App: how we proceeded and what we found - Jagdish Achara, James-Douglas Lefruit, Vincent Roca and Claude Castelluccia
Pas grand chose à dire. L'appli RATP embarque une bibliothèque publicitaire qui leake beaucoup de données persos. On peut aussi décerner un award pour une lame response de la compagnie de pub qui confirme récupérer toute ces infos persos, mais qu'ils ne les exploitent absolument pas. (arf).

1/10/ I know your MAC Address: Targeted tracking of individual using Wi-Fi - Mathieu Cunche
Ce talk présente les fuites d'informations des smartphones. En effet, l'antenne wifi émet son @Mac en permanence et essaye de se connecter à des réseaux. Il devient possible de suivre des personnes, voire de les identifier.

1/11/ Statically Detecting Use After Free on Binary Code - Laurent Mounier, Marie-Laure Potet and Josselin Feist
Le matin même Halvar Flake indiquait la difficulté de détecter ce genre de failles. Cette équipe développe deux méthodes pour les détecter. Tout d'abord une analyse statique des motifs menant aux UaF, puis une étude d'exploitabilité est faite. (En anglais: exploitability, avoir le nom de son blog cité dans une conf, c'est vraiment la classe ;) ). La première partie ne s'intéresse qu'aux fonctions manipulant le heap, et cela a permis de retrouver certains CVE. Mais il disent qu'il leur reste du travail sur l'amélioration du heap model pour vérifier l'exploitabilité des UaF.

1/12/ Attacks using malicious devices : a way to protect yourself against physical access - Guillaume Jeanne and François Desplanques
Une excellente démo des capacités offensives des Teensy, ces microcontrolleurs qui peuvent prendre l'identité de n'importe quel périphérique USB. Après un petit raté à la première démo (effet oblige), on a pu voir comment ajouter un utilisateur via le teensy en mode clavier. Et on vu une seconde démo ou le teensy boosté par une flash lance un mode de communication entre l'OS et le teensy pour charger un payload selon l'OS sur lequel la clé est branché, en contournant l'antivirus. Joli.

2/ La nuit du CTF
Après un repas très geek (pizza/bière/coca), direction le CTF.
De bons challenges (un concert un peu moins bon), dans la droite veine de ceux de 2012. On a eu  du reverse, de la stégano, du misc, du réseau, du web et même un challenge "over 9000 points" (le devoir de math des étudiants :) )...

Mon équipe (5 personnes) a résolu 6 challenges, j'en ai fait deux. J'ai pu finir un challenge en premier donnant ainsi un bonus d'extra points substantiels.
On a fini 14e je crois, ce qui nous classe dans la première moitié du tableau, ce qui n'est pas si mal étant donné qu'il s'agit du premier exercice du genre que l'on fait. J'espérais un peu mieux, mais bah: on avait quitté lyon à 5h du matin, 24h plus tard après une journée dense, les réflexes ne sont plus aussi bon, en étant un peu plus frais je pense qu'on pouvait peut-être tomber un peu plus d'épreuves.

GreHack, l'année prochaine, si possible, j'y retourne \o/