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/

lundi 11 novembre 2013

RIP.

J'apprends via twitter et par mail que Cedric "Sid" Blancher vient de nous quitter, victime d'un accident de parachute.

C'est un grand nom de la sécurité informatique qui nous quitte Je n'ai jamais eu la chance de croiser IRL, j'ai souvent échangé par mail et il était toujours disponible et de bons conseils.

RIP.

mercredi 6 novembre 2013

Alors, badbios, übermalware ou fake?


Après une petite semaine à entendre parler de badbios un peu partout, je pense qu'un point d'étape est nécessaire. Il est rare qu'un virus (ou supposé tel) fasse autant le buzz, même des journaux grands publics évoquent le sujet . Il est d'ailleurs intéressant de remarquer qu'une information a écrasé toutes les autres: la fameuse communication over-the-air de ce malware.
Mais ce virus semblait plein d'autres promesses. Listons les:

  • Infection des BIOS des machines:
    Rootwyrm a livré une analyse intéressante titrée "badbios analysis is wrong". Je crois qu'elle a été très mal comprise par la majorité des gens qui la cite comme preuve d'inexistence de badbios. Il est seulement fait mention qu'écrire un virus de BIOS qui touche toutes les cartes mères est très difficile, qu'un checksum protège les BIOS et que des fonctionnalités de badbios sont inatteignables depuis le BIOS. badbios peut résider ailleurs que dans le BIOS, un checksum se contourne et la difficulté d'écrire un BIOS n'est pas un problème pour un attaquant motivé. Il est à noter que rootwyrm a écrit un second article "the-pc-bios-is-insecure-as-hell" "Really, the problem is that the hardware and the OS have jointly weakened security around the BIOS to the point where this is even possible. We’ve gone from keeping a highly sensitive component which by necessity and capability has few security features, and turned it into a gaping vulnerability which is only protected by ‘there is no free space’ and ‘there’s over 60,000 different targets.’ If you solve for the latter by narrowing targets – say ‘only IBM System x 3650M3′ or ‘only MacBook Air 2012′? Then you introduce the potential for working around the former."
    Dragos Ruiu a fourni des samples de ces BIOS. Ils ont été analysés et rien d'étrange n'en est sorti.
  • Infection des clés USB:
    Ce sujet n'a pas vraiment été repris, ni étudié. Le site flashboot.ru a été cité plusieurs fois comme indiquant comment reflasher le firmware des clés USB. Cette piste semble prometteuse, il n'y a que très peu de contrôleurs différents et une attaque semble possible. Dragos indique avoir des clés à donner pour analyse lors de sa prochaine conférence. A suivre, donc.
  • Autre vecteur d'infection:
    Inconnu, seul un tweet de Dragos en parle: "only 2 unusual infection vectors IDed, USB and one other, waiting on patches before discussion" 
  • Infection du lecteur CD:
    Pas grand chose de neuf. Dragos en a parlé un moment.
  • Hyperviseur malicieux:
    Aucune nouvelle si ce n'est un tweet de Dragos.
  • Fontes suspicieuses sous windows:
    Dragos a fourni un sample (kit.tgz). Ce sample a été analysé, et une fois de plus tout semble normal:  + le deuxième commentaire de ce post G+  "the font files you published all look well formed to me." (Tavis Ormandy)
  • Communication Over-the-air:
    Le sujet qui passionne les foules. Pour y répondre clairement, oui, c'est faisable. Deux sites donnent des méthodes: http://fileperms.org/badbios-high-frequency-malware-communication-test/ et http://holmes.meklu.org/static/highfreq/ . Je reproduis parfaitement avec deux portables les spectrogrammes de holmes.meklu.org. Et 20KHz, c'est parfaitement inaudible à l'oreille. Je ne donne pas d'autres liens, mais dès qu'on cherche un peu google on trouve pleins d'expérimentations et PoC dans ce domaine. Donc oui, imaginer qu'un malware communique par voie des aires en ultrasons, c'est possible.
  • Communication avec un SDR en réutilisant la carte son:
    Un autre sujet qui fait rêver: on emploie les composants d'une carte son afin de les utiliser pour créer une antenne (émission et réception). C'est malheureusement impossible. Donc la voie ultrason est à conserver.
  • Dumps de procmon:
    Tavis a analysé ces logs procmon (voir le post G+), et rien d'anormal n'en ressort: "I can see you were working on some documents, browsing facebook, installing some sysinternals tools and so on - nothing suspicious."
  • Dump des disques:
    Dragos a soupçonné ses disques de vouloir lui masquer des données. Il indique qu'utiliser dd ne renvoie pas les mêmes informations selon l'offset de départ et la taille de blocs demandée. Il a posté une centaine de Mo de dumps qui ont été analysés par plusieurs personnes: rien de probant en résultat; quelques petites anomalies, mais "(...)so the drive is probably failing.". Et Dragos a annoncé sur twitter que les dump sont aujourd'hui parfaits, sans erreur (il soupçonne le malware de s'être effacé). [Pour ceux que ça intéresse, faire des "strings" sur ces dump renvoie différents codes. >:) ]

badbios secoue relativement fort la communauté infosec mais jusqu'à maintenant rien n'en sort de probant; Tavis a eu un commentaire assez direct au sujet de Dragos Ruiu: "My guess is it's just a combination of stress and healthy paranoia causing you to connect unrelated events". Toutes ces analyses mises bout à bout semblent donc indiquer que cet über malware n'existerait pas. Ceux qui pensent que c'est impossible seront confortés dans leur opinion, ceux qui imaginent que nous sommes en face du malware le plus évolué du monde vont continuer à trouver des preuves de son existence (les dumps sont comme par hasard corrompus alors qu'on sait que le malware modifie les firmwares de disque, le malware s'est auto effacé pour empêcher toute analyse, etc..).
Pour ceux qui s'en souviennent, anonymous avait piraté HBGary en 2011. Un des documents leaké présentait un rootkit qui a des similitudes troublantes avec le descriptif de badbios, notamment la communication par ultrason.

Le problème de cette histoire, c'est qu'elle est suffisamment crédible pour qu'on y accorde de l'attention. Elle est aussi tellement énorme que le premier réflexe est de la nier complètement. Que l'histoire soit vraie ou fausse, je crois qu'on va voir du dév de réseau basé sur les ultrasons de manière moins confidentielle :) et les attaques matérielles et forensics vont sans doute faire un pas en avant