Donc l'honneur est sauf! Je ne serai pas a l'origine de la nouvelle apocalypse numerique, comme le prophetisait certains, et je pourrai dormir paisiblement pendant que les jeunots pirateront des honeypots avec l'exploit Metasploit.
Quelques precisions/pensees sur le bug SMBv2:
- Malgre tout le buzz qui en a ete fait (y compris par Immunity), je trouve que le bug au final n'est que peu interessant, pour la simple raison qu'il n'est exploitable que sur plateformes x86.
- Si vous avez du x64, vous etes tranquille (pour le moment, mais ca ne devrait pas changer - sauf intervention divine), parceque les parametres de la fonction sont passes par registres et non par la pile, ce qui rend la technique de stack shifting inutilisable. Du 2008 x86 c'est super rare (3GB de memoire sur un serveur en 2009 c'est pas super utile), et du Vista x86, meme si c'est plus repandu, ca reste tout de meme rare (cf. pentests recents que j'ai pu mener).
- Comme d'habitude, pas grand monde n'a compris ce qui se passait, c'est pas nouveau, la securite informatique ce n'est pas un succes. Si vous avez des problemes de comprehension, evitez de l'ouvrir, vous passerez pour plus stupide que vous ne l'etes.
- Il est dommage de constater que l'exploitation d'un bug de nos jours est si problematique. Il aura fallu ~3 semaines a Stephen Fewer pour creer un exploit qui ne fonctionne pas souvent (a cause de l'adresse choisie dans le Bios/HAL), et ~1 mois a Piotr Bania pour arriver a quelque chose de fonctionnel grace, semble-t-il, a l'exploit publie precedemment. Beau boulot neanmoins des 2, puisque le resultat est la!
Thanks for the update on SMBv2. Could you discuss the strategies Immunity used to develop a successful and reliable exploit versus what other groups attempted?
ReplyDeleteThis comment has been removed by the author.
ReplyDelete@Matthew: There was no strategy used but a better understanding of the vulnerable code involved (or to be more specific: *after* the vulnerable code).
ReplyDeleteA good hint that somebody didn't try to understand the code is seeing a request with pack('>L', readable) * 25, while 90% of the dwords packed are not even dereferenced. It simply means that there was a lack of effort in tracing and identifying which variables/parts of the packet are indeed used and how.
Nowadays, exploitation is less and less a mater of overwriting a saved EIP on the stack, and only a few people make the constant effort of learning new tricks and improvising in unknown situations.
I liked writing this exploit because it required a different way of thinking, yet it only took a few hours to find this way and understand it, then a few more days to get through everything, exhaustively.
beaucoup appris
ReplyDelete