Phrack 59
Le phrack 59 est sorti le 28 juillet 2002. Les articles en vo sont disponibles dans ce tarball.
Le phrack 59 est sorti le 28 juillet 2002. Les articles en vo sont disponibles dans ce tarball.
Sur les innombrables livres au sujet des systèmes d'exploitation, il n'y en a que deux ou trois (que je connaisse) qui traitent vraiment de la manière de créer un système d'exploitation complet. Ces livres se focalisent sur un matériel spécifique et les principales étapes (de construction) s'enterrent sous une montagne de détails étouffants.
Ce qui fut dit une fois ne peut etre renié. L'expiation des maux inspirant les pensées et les opinions des gens peut changer.
J'exploite de nouveau cette idée, mais en kernel hacking, pas en littérature. Particulierement dans ce domaine, de nombreuses idées devraient être abandonnées car inutiles. Ce qui ne signifie pas qu'elles ne permettent pas de résoudre des problèmes particuliers. Cela signifie simplement que les problèmes pouvant être résolus ne sont pas ceux que nous projetons de résoudre.
Y a-t-il encore quelque chose à dire sur les chaines de format après tout ce temps ? Sûrement, au moins on va essayer... Pour commencer, aller voir l'excellent papier de scut sur les chaines de format et lisez-le.
Ce texte traite de deux sujets. Le premier concerne les petits trucs qui pourraient aider à accélérer le brute force quand on exploite un bug avec des chaines de format, et le deuxième concerne l'exploitation des bugs de chaines de format basés sur le tas.
Attachez-vos ceintures, le voyage ne fait que commencer.
Le protocole Secure Shell (SSH) est considéré comme solide en soi mais son implémentation présente souvent des faiblesses. En particulier, l'interopérabilité entre SSH1 et SSH2, telle qu'elle est implémentée dans la majeure partie des clients SSH, souffre de certains points faibles décrits ci-dessous. De plus, le protocole SSH2 lui-même est suffisamment souple pour comporter des éléments qui intéresseront les attaquants.
Cet article a été traduit très gentillement par Thiébaud Weksteen.
Avant toute chose, je dois fixer des regles pour mon terrain de jeu. J'ai testé toutes ces techniques sous Linux 2.4.18 i386 avec une pile executable. Elles peuvent fonctionner sous toutes les versions linux, exceptées celles dont la pile n'est pas exécutable, à cause du concept de l'injection (dans la pile). En modifiant un peu ces techniques, il devrait être possible d'exploiter n'importe quel OS sur n'importe quelle architecture, du moment que l'appel système ptrace() est supporté.
Depuis que IBM a sorti Linux/390, on trouve de plus en plus de boxes de ce type. Voila une bonne raison pour un hacker de prêter une attention plus particulière à la facon dont peuvent etre exploites les services vulnerables dans un mainframe. Souvenez-vous, qui sont les proprietaires de mainframes? Les grands centres informatique, les assurances ou les gouvernements... ;) Dans cet article, je vais montrer comment ecrire du bad code (shellcode). Le bind-shellcode, a la fin, peut servir d'exemple. D'autres shellcodes et exploits utilisant des vulnerabilites connues peuvent être trouvés sur un des liens de la section Références.
Cet article est divise en deux parties:
Chaque composant d'un cryptosystème est critique pour sa sécurité. Une seule erreur dans l'un pourrait faire tomber tous les autres. Les nombres aléatoires cryptographiques sont souvent utilisés comme clefs, padding, graines et vecteurs d'initialisation. Utiliser un bon GNA pour chacun de ces composants est essentiel.