Comment les vulnérabilités de sécurité client sont-elles généralement détectées?

Question

Je veux dire dans les systèmes d'exploitation ou leurs applications. La seule façon que je peux penser est d'examiner les binaires pour l'utilisation de fonctions dangereuses comme strcpy(), et ensuite essayer de les exploiter. Cependant, avec des améliorations du compilateur comme le commutateur Visual Studio/GS, cette possibilité devrait surtout appartenir au passé. Ou est-ce que je me trompe?

De quelles autres façons les gens utilisent-ils pour trouver des vulnérabilités? Il suffit de charger votre cible dans un débogueur, puis envoyer des commentaires inattendus et voir ce qui se passe? Cela semble être un processus long et fastidieux.

Quelqu'un peut-il recommander de bons livres ou sites Web sur ce sujet?

Merci d'avance.

Answer 1

Deux problèmes majeurs sont liés à la "sécurité côté client".

Le client le plus couramment exploité aujourd'hui est le navigateur sous la forme de "Drive By Downloads". Le plus souvent, les failles de corruption de la mémoire sont à blâmer. Les objets com ActiveX ont été un chemin commun sur les systèmes Windows et AxMan est un bon fuzzer ActiveX.

En termes de systèmes de protection de la mémoire, le/GS est un canari et ce n'est pas la fin de tout pour arrêter les débordements de tampon. Il vise uniquement à protéger les débordements basés sur les piles qui tentent d'écraser l'adresse de retour et de contrôler l'EIP. Les zones NX et les canaris sont une bonne chose, mais ASLR peut être bien meilleur pour stopper les exploits de corruption de mémoire et toutes les implémentations d'ASLR ne sont pas sécurisées de la même manière. Même avec ces trois systèmes, vous allez toujours être piraté. IE 8 fonctionnant sur Windows 7 avait tout cela et c'était l'un des premiers à être piraté au pwn2own et voici how they did it. Cela impliquait d'enchaîner une vulnérabilité de dépassement de mémoire et une vulnérabilité de pointage variable. Le problème avec la "sécurité côté client" est CWE-602: Client-Side Enforcement of Server-Side Security sont créés lorsque le côté serveur fait confiance au client avec des ressources secrètes (comme des mots de passe) ou pour envoyer un rapport sur des informations sensibles telles que le Players Score dans un jeu flash.

La meilleure façon de rechercher les problèmes côté client consiste à regarder le trafic. WireShark est le meilleur pour les protocoles client/serveur non-navigateur. Cependant, TamperData est de loin le meilleur outil que vous pouvez utiliser pour les plates-formes basées sur un navigateur tels que Flash et JavaScript. Chaque cas va être différent, contrairement aux débordements de tampon où il est facile de voir le processus plantage, les problèmes de confiance côté client sont tous sur le contexte et il faut un humain qualifié pour regarder le trafic réseau pour comprendre le problème. Parfois, des programmeurs idiots codent en dur un mot de passe dans leur application. C'est trivial de décompiler l'application pour obtenir les données. La décompilation Flash est très propre et vous obtiendrez même des noms de variables et des commentaires de code complets. Une autre option consiste à utiliser un débogueur comme OllyDBG pour essayer de trouver les données en mémoire. IDA-Pro est le meilleur décompilateur pour les applications C/C++.

Answer 2

Writing Secure Code, 2nd edition, comprend un peu sur la modélisation des menaces et les tests, et bien plus encore.