Autoblog d'Exploitability

Ce site n'est pas le site officiel exploitability.blogspot.com.
C'est un blog automatisé qui réplique les articles de exploitability.blogspot.com

Street fighter -- Assassin's Fist

2014-07-31T17:52:00.001+02:00 - (source)
De manière générale, l'adaptation d'un jeu vidéo en film donne très rarement des bons résultats.
Mais ce n'est pas toujours vrai.

Je viens de découvrir la web série "Street Fighter - Assassin's Fist" sur Machinima, et je ne peux que conseiller à tous les fans de Street Fighter 2 de la regarder. Cette série est constituée de 12 épisodes + deux trailers. L'histoire raconte l'entraînement de Ken et Ryu sur la voie de l'art martial Ansatsuken, initiés par leur maître Gouken. Le film fait des sauts dans le passé expliquant l'origine de l'ansatsuken et la rivalité entre Gouken et Akuma.

D'après les commentaires lus sur internet il s'agit d'une série faite par deux fans du jeu et cela se ressent. Cette websérie présente Ken, Ryu, Gouken et Akuma de manière tout à fait crédible.

Le scénario se tient, les combats parviennent à être crédible tout en conservant le visuel et les mouvements du jeu vidéo. Le caractère de Ryu e Ken correspondent également à l'idée que l'on se fait d'eux: Ryu, tout en réserve et Ken beaucoup plus extraverti.
Il y a eu un gros travail sur la bande son, ou l'on retrouve plusieurs morceaux du jeu vidéo retravaillés, et détourné comme la musique de Ryu jouée à la flûte. A ce sujet, le nombre de détails tirés du jeu sont innombrables et participent beaucoup à l'immersion dans l'esprit du jeu vidéo.

Cette websérie est un must see pour tout joueur de street fighter, et j'espère que la saison 2 viendra bientôt avec la même qualité.


L'ensemble des vidéos sur le site d'Assassins Fist.

SSTIC 2014

2014-06-03T14:26:00.001+02:00 - (source)
Tout droit sorti de l'imprimante



L'antivirus est mort (air connu)

2014-05-12T13:29:00.003+02:00 - (source)

On a vu cette info beaucoup reprise sur les réseaux sociaux ces derniers temps: pour Bryan Dye, vice-président chez Symantec, l'antivirus est mort et condamné à l'échec. C'est une position étrange pour une société qui édite justement un antivirus. Si on regarde l'article initial, on se rend compte que sa position est effectivement plus nuancée.

1/ L'antivirus est un échec [(c) newsoft]
Dye dit que l'antivirus est un échec commercialement parlant. Symantec va décider de ne plus investir dans cette technologie  "We don't think of antivirus as a moneymaker in any way.".
Le calcul ici est simple: les "bad guys" savent contourner un antivirus. Les antivirus et les virus ont joués à la souris pendant longtemps (vitesse et fréquence de mise à jour, analyse comportementale, ajout d'options de firewalling, sandbox, etc..) mais à la fin, le virus gagne toujours. Selon Dye, il semble donc plus pertinent de passer à autre chose que de continuer cette course à la technologie dans laquelle ils sont perdant.

2/ Mais l'antivirus reste incontournable.
Malgré ses défauts, l'antivirus bloque tout de même 45% des menaces (toujours selon le même article).
Même si ce pourcentage reste sujet à caution (comment sont qualifiées et comptées ces menaces? Voir un article de S.Bortzmeyer intéressant à ce sujet), l'antivirus reste bon dans son domaine: bloquer un certain "bruit de fond" de menaces informatiques. Dye souhaite don le cantonner à ce rôle et proposer une nouvelle forme de défense.

3/ Ne plus essayer de protéger, mais de minimiser les impacts
Dès lors qu'il est majoritairement admis que des attaquants motivés savent contourner les antivirus, et que ces mêmes antivirus ne pourront jamais l'empêcher, il faut trouver une ligne de défense supplémentaire.
Au lieu de prévenir une infection, le but est désormais de la détecter fiablement le plus vite possible, peu importe que l'infection initiale ait réussie ou non.
Et bien évidemment, Dye indique que Symantec va lancer une nouvelle offre de sécurisation des données et des réseaux qui va faire du comportemental: combo classique sonde réseau (et probablement agents sur les postes et points clés).

4/ Etes vous les 20%
L'analyse faite sur les antivirus par Mr Dye peut être portée de la même manière sur les firewalls: ils savent bloquer une petite catégorie d'attaque, mais un attaquant motivé va toujours le contourner. Faut il pour autant le supprimer? Bien évidemment non. Un antivirus et un firewall vont bloquer 80% des attaques. Le problème, dont j'ai déjà parlé ici, concerne ces fameux 20% restants.

80% des attaques bloquées par les outils traditionnels (antivirus, firewall, lecture de logs), qui sont des defaçages de site web, des vols de numéros de CB, du spam, etc.. Les 20% restants, ce sont du vol de propriété intellectuelle, obtenir des informations confidentielles, endommager des infrastructures du monde physique, décrédibiliser une entreprise, voler du code source ou des certificats de chiffrements etc. et ce sont ces 20% qui posent problème.

Fin 2012, les options consistaient en l'analyse des 10 ou 12 failles vraiment problématique, l'offensif ou l'augmentation du coût de l'attaque. Si on les prend dans l'ordre:


Ces méthodes restent encore une fois dans la défense; est-ce vraiment le bon (ou l'unique) moyen de se prémunir des attaques?

5/ un nouveau paradigme: vous êtes compromis.
La stratégie qui consiste à empêcher un attaquant d'entrer et corrompre un réseau va donc le mur.

Il semble plus sage aujourd'hui de considérer que l'état de compromission est l'état standard d'un réseau et de ses données et qu'il faille faire avec.

Nous commençons aujourd'hui à observer une voie médiane qui consiste non plus à empêcher ces attaques de survenir, mais à les détecter et les analyser afin d'en comprendre l'origine, l'ampleur et le but[1]. Les protections vont dans ce sens. Dans le même ordre d'idée certaines sociétés ne proposent plus de pentest mais des analyses de compromissions.

L'état est donc le suivant, qui n'est pas à l'avantage de la défense:



---
[1] Je ne peux m'empêcher de penser à un cours d'histoire que j'avais eu plus jeune concernant les menaces terroristes: a une époque, les gouvernements cherchaient surtout à empêcher les groupes terroristes de se former. Puis ils ont ensuite cherché à les contrôler afin de mieux connaître ces groupes, ces personnes et ces réseaux. Quelle est la méthode la plus efficace?

400 Gigabits par seconde, c'est beaucoup pour un DDOS?

2014-02-28T13:35:00.000+01:00 - (source)
Il y a un peu moins d'un an, je titrais un article de blog "300 Gigabits par seconde, c'est beaucoup pour un DDOS"? Il y a de cela deux semaines, CloudFlare donnait de nouveaux chiffres alarmant, citant une attaque à 400Gbit/s.

Cette info m'a inspiré deux réflexions. La première concerne  le messager: on sait que cloudflare vend de la protection antiDDos, ils sont donc les plus intéressés de citer des DDos de grande ampleur en raison de la publicité que cela leur fait. Les chiffres ont en effet été repris par un certain nombre de sites d'infos techniques avec des liens vers cloudflare. Vu les moyens mis en oeuvre pour l'attaque contre SpamHaus pour atteindre 300GBit/s, ce chiffre de 400 avait une odeur de suspicion. La seconde réflexion concerne les motivations de la personne effectuant ce DDos qui ne sont jamais données, non plus que la cible. Nous aurions une personne (ou un groupe de personnes) capable de lancer le DDos le plus puissant du monde, sans raison, ni motivations, ni cible. Ce qui semble étrange. J'ai donc laissé de côté un peu cette info, pensant être en face d'un "coup" marketing plus que technique.

Puis des informations techniques sont tombées, extrêmement intéressantes.

Tout d'abord, sur la méthode employée. Comme attendu, les attaquants ont utilisés de l'amplification. Au lieu d'attaquer le serveur, on requête un serveur tiers avec l'IP source de la victime, et on s'arrange pour que la réponse de ce serveur tiers soit plus grosse que la requête. Double effet: on masque la véritable IP de l'attaquant, et on gagne en puissance de feu^W débit. Il y a 6 mois, on entendait beaucoup parler d'amplification par les serveurs de jeux (par exemple à la GreHack). Un nouvel amplificateur particulièrement puissant a été trouvé: le NTP. Un bon article de Bortzmeyer explique cette attaque. Je me demande si des gens ont scanné Internet à la recherche de "chargen", ça pourrait être très pratique. [EDIT : effectivement : Cf https://isc.sans.edu/diary/A+Chargen-based+DDoS%3F+Chargen+is+still+a+thing%3F/15647]

Ensuite, des chiffres équivalents ont été donnés par d'autre fournisseurs de service comme OVH, ce qui tend à prouver la réalité de ces chiffres élevés.

Enfin, un document interne de CloudFlare donne beaucoup d'informations sur l'attaque (contrairement à leur premier communiqué). L'amplification NTP permet de faire un x200 en débit (!!!). L'autre information percutante, c'est celle-ci "Remarkably, it is possible that the attacker used only a single server running on a network that allowed source IP address spoofing to initiate the requests." En x200, il suffit de deux cartes réseaux à 1Gbit/s pour atteindre 400GBit/s... CloudFlare compare ensuite l'attaque au DDos qui a eu lieu contre spamhaus (qui avait sollicité de gros moyens) avec celle-ci. Il a suffit à l'attaquant 7 fois moins de machines amplificatrics pour un résultat 33% supérieur. Finalement, l'attaque à 400Gbit/s est relativement plus simple que celle contre SpamHaus, permettant d'imaginer ce DDos comme un test grandeur nature.

Pour terminer, il semblerait que le prochain amplificateur soit trouvé avec  snmp. Les premiers calculs indiquent une amplification maximale de 650! S'il se réalise, le prochain DDos dépassera le Terabit/s. Comme disent les anglais: "wait and see".

Bluetouff et gogleuh

2014-02-10T15:14:00.003+01:00 - (source)
Vous n'avez pas pu le rater, Bluetouff est désormais un cybercriminel.

Résumé des faits : Bluetouff cherche à l'aide de Google diverses données. Il tombe sur le site web de l'Anses qui contient des documents très intéressants. Il en télécharge plusieurs, et commente certains d'entre eux sur le site de reflets. L'Anses s'émeut du fait de trouver ses documents et décide de mener une enquête.
Bluetouff se voit donc face à la justice, et tout geek un minimum versé dans la technique ne voit pas d'autre issue dans ce procès que la relaxe puisque Bluetouff n'a rien fait d'autre que de télécharger des documents accessibles publiquement.

Le jugement en appel, décidé par le parquet uniquement (l'Anses n'a pas voulu poursuivre la procédure) montre le contraire puisque Bluetouff est condamné. On a pu voir fleurir un bon nombre de commentaires mi amusé, mi ecoeuré sur le thème: la justice n'y connait rien, et utiliser gogleuh n'a rien de répréhensible. Le jugement est pourtant très clair et n'a rien à voir avec Google.

Le jugement, public, est disponible : Arrêt Bluetouff. Il se lit très bien (6 pages). Les juges vont devoir qualifier en droit les actes qu'on leur a soumis. Le procès va donc chercher à éclaircir trois points, pour juger de ces trois infractions:
1/ Bluetouff s'est introduit de manière frauduleuse dans le site de l'Anses
2/ Bluetouff s'est maintenu frauduleusement dans le site de l'Anses
3/ Bluetouff a volé des données sur le site de l'Anses

Et là, les juges vont faire du juridique et non pas de la technique. Sur le premier point, ils indiquent que Bluetouff n'est pas poursuivi car rien ne vient prouver l'intention frauduleuse d'accéder à ces données, puisque même l'Anses le reconnaît. Point besoin d'être expert sécu pour comprendre que si le plaignant indique n'avoir rien fait pour protéger ses données, la bonne foi du visiteur passant par là peut être acquise. Sur le second point, c'est là que tout se joue. Les juges indiquent noir sur blanc que le prévenu "a constaté la présence de contrôles d'accès" et qu'il le reconnaît. Point besoin de technique non plus pour lui mettre le dos le "maintien frauduleux". Dans l'esprit des juges, il savait que c'était protégé, il est resté, donc maintien frauduleux; c'est simple. Sur le vol, les juges indiquent que Bluetouff a copié, dupliqué et partagé ces fichiers sans plus d'explications. Les juges indiquent vol de fichiers inaccessibles au public, mais le point 1 montre qu'en tout état de cause ces fichiers étaient accessibles au public (de manière involontaire, certes). C'est un point léger dans leur argumentaire.

Que peut on en conclure? Le raisonnement des juges est assez clair et le point central repose sur cet "aveu" de Bluetouff disant qu'il est resté après avoir su qu'il s'agissait de documents protégés. Si vous vous faites arrêter un jour (et je ne le souhaite à personne), faites attention à ce que vous dites...


Pour la suite, il y a le point de vue du principal intéressé sur son blog, et un pourvoi en cassation qui est en cours. Je ne suis malheureusement pas très optimiste sur le pourvoi en cassation :-( l'histoire nous le dira.

Haka est sorti: TCP/IP security is not boring anymore!

2014-01-23T11:25:00.002+01:00 - (source)
Il y a trois ans, je publiais un article intitulé "TCP/IP security is boring" dans lequel j'indiquais que la sécurité TCP/IP était devenue ennuyeuse.
La sécurité remonte sur les couches hautes, et les firewalls sont finalement limités dans leur usage: on coche une case pour appliquer une politique de sécurité sans jamais pouvoir sortir du carcan initial prévu par l'outil.

Mais le projet HAKA voit le jour, et je vais en faire un peu sa pub [1].

Je fais partie de l'équipe qui développe le projet HAKA, et avec HAKA la sécurité réseau ne sera plus jamais ennuyeuse. Haka est un langage orienté sécurité et réseau permettant d'accéder à n'importe quel champ protocolaire d'une communication et d'interagir avec celle-ci de manière simple (modification, suppression, création de paquet) sans avoir à se poser des questions compliquées sur la gestion bas niveau (gestion de la mémoire, dissection de protocole, ordonnancement des paquets, etc..). Ceci donne des possibilités illimitées quant à l'application de règles de sécurité et d'analyse des flux réseaux.

Un site web a été ouvert, ainsi qu'un github car HAKA est open-source. Get it, commit, play with it, fork it ou tout autre mot en 'it' :) Une version précompilée pour debian (32 ou 64bits) est disponible afin de pouvoir le tester facilement. Haka peut être lancé sur du trafic live pour l'analyser (le logger, bloquer, modifier, etc..) ou bien sur des pcap. La version 0.1 permet d'accéder à n'importe quel champ IP, TCP et HTTP.

Pour montrer la facilité d'usage de HAKA, des tutoriels montrent comment utiliser Haka. Après l'inévitable Hello World, sont présentés la manière de faire du filtrage sur n'importe quel champ IP/TCP/HTTP puis une méthode originale pour bloquer les navigateurs webs qui ne sont pas à jour en les forçant à être redirigés sur les sites d'update. Puis un module de statistiques est écrit sur une manière de browser des pcaps. Ensuite un exemple de détection de SQL injections est écrit: en une centaine de lignes de code, il devient possible de détecter et bloquer (ou modifier, ou ce que vous voulez en fait) des SQLi sur flux sans utiliser de proxy applicatifs ou autre outil lourd, avec des possibilités d'extensions simples. Pour finir, un exemple de groupe de règles est expliqué.

Pour donner un avant goût, voici un exemple de règle haka:
Pour les exemples, un seul endroit: le site web.

Haka a beaucoup d'autres fonctions qui en font un langage facile à utiliser:
debugger, analyse interactive, API C/Lua pour l'étendre, etc... La version 0.1 permet d'utiliser les règles de sécurité, les versions suivantes vont donner la possibilité de définir une grammaire et une machine à état pour définir soi-même des règles de dissection protocolaire.

Haka, c'est bon, mangez-en :-)
---
[1] Ce blog reste un blog personnel, le site officiel et la communication officielle autour de Haka se fait sur son site web et sur github.

NSA Catalog : petit papa Snowden

2013-12-29T21:40:00.001+01:00 - (source)
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.


Grehack 2013 writeup - 1337

2013-11-19T23:13:00.001+01:00 - (source)
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.

Gre(at)Hack 2013

2013-11-18T13:41:00.000+01:00 - (source)
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/

RIP.

2013-11-11T14:43:00.004+01:00 - (source)
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.

Powered by VroumVroumBlog 0.1.32 - RSS Feed
Download config articles