Des vulnérabilités ou des exploits logiciels surprenants ?

Question

Quelles sont les vulnérabilités ou les exploits logiciels les plus étranges/sophistiqués/surprenants/profondément cachés que vous ayez jamais vus ? Des endroits dans le code où vous pensiez qu'il n'y avait aucun danger caché, mais où vous aviez tort ?

(Pour clarifier : tout le monde connaît les injections SQL, les XSS ou les débordements de mémoire tampon - des bogues qui résultent souvent d'un codage négligé. Mais des choses comme le cheval de Troie caché de Ken Thompson (Reflections on Trusting Trust : http://cm.bell-labs.com/who/ken/trust.html ), vulnérabilité récente de déréférencement NULL dans le noyau Linux ( http://isc.sans.org/diary.html?storyid=6820 ), ou une attaque complexe sur le RNG par déni de service ( http://news.ycombinator.com/item?id=639976 ) m'ont beaucoup perturbé.]

Mise à jour : Merci à tous pour les réponses, elles étaient excellentes. J'ai eu un choix difficile. En fin de compte, j'ai décidé d'attribuer la prime à l'attaque par canal latéral et surveillance de l'alimentation. Néanmoins, toutes vos réponses combinées montrent que je dois en apprendre davantage sur la sécurité, car c'est un sujet vraiment profond :).

Answer 1

Mon préféré et le plus impressionnant que j'ai vu jusqu'à présent est une classe de techniques de cryptographie connue sous le nom de Attaques par canal latéral .

Un type d'attaque par canal latéral utilise la surveillance de l'alimentation. Des clés de chiffrement ont été récupérées sur des cartes à puce en analysant soigneusement la quantité d'énergie consommée par l'alimentation électrique. Les processeurs qui y sont intégrés utilisent différentes quantités d'énergie pour traiter différents jeux d'instructions. En utilisant ce petit bout d'information, il est possible de récupérer des données protégées, de manière totalement passive.

Answer 2

Tout le monde connaît les injections SQL, mais l'un des exploits les plus surprenants dont j'ai entendu parler récemment consistait à insérer des injections SQL dans des codes à barres. Les testeurs doivent vérifier que TOUTES les entrées ne contiennent pas de SQL malveillant. Un attaquant pourrait se présenter à un événement et faire planter le système d'inscription, modifier les prix dans les magasins, etc. Je pense que le piratage des codes à barres en général m'a surpris. Il n'y a pas d'effet de surprise, mais il s'agit d'un élément supplémentaire dont il faut être conscient.

EDIT : Je viens d'avoir une discussion où l'idée de mettre l'injection SQL sur une bande de carte magnétique a été évoquée. Je suppose que l'on peut en mettre une n'importe où, donc tester toutes les entrées, en particulier celles des utilisateurs et de ces types de dispositifs de stockage de données.

Answer 3

Je pense qu'une vulnérabilité relativement récente de Linux correspond à votre description de l'exploitation d'un code qui semble sûr (bien qu'un peu mal structuré).

C'était spécifiquement le morceau de code dans le noyau Linux :

struct sock *sk = tun->sk;  // initialize sk with tun->sk
…
if (!tun)
    return POLLERR;  // if tun is NULL return error

En raison d'une optimisation de GCC, l'instruction if et le corps sont supprimés (ce qui est raisonnable pour le code userland, mais pas tellement pour le code du noyau). Grâce à une certaine ingéniosité, une personne a été en mesure de construire un exploit à partir de cela.

Un résumé :

http://isc.sans.org/diary.html?storyid=6820

Un exploit posté :

http://lists.grok.org.uk/pipermail/full-disclosure/2009-July/069714.html

EDIT : Voici un résumé beaucoup plus approfondi de la façon dont ce code a été exploité. C'est une lecture courte, mais une très bonne explication des mécanismes utilisés pour l'exploitation.

http://lwn.net/SubscriberLink/342330/f66e8ace8a572bcb/

Answer 4

Un exploit classique a été le piratage de Ken Thompson, qui lui a donné un accès privilégié à tous les systèmes Unix de la planète.

À l'époque où Bell Labs était le seul fournisseur d'Unix, ils ont distribué le code source afin que chaque installation puisse construire et personnaliser son propre système d'exploitation. Cette source incluait la commande de connexion d'Unix. Ken a modifié le compilateur C pour qu'il reconnaisse s'il compilait la commande d'ouverture de session, et si c'était le cas, il a ajouté une vérification initiale du mot de passe. Ce mot de passe était son propre mot magique et donnait l'accès Root.

Bien sûr, toute personne lisant le source du compilateur C le verrait et le supprimerait. Ken a donc modifié à nouveau le compilateur C pour que, s'il compilait un compilateur C, il remette le hack de connexion.

Voici maintenant la partie la plus hallucinante : Ken a compilé le compilateur C avec son compilateur piraté, puis a supprimé toute trace de son piratage, en l'effaçant des sources, des sauvegardes, du contrôle de la source, tout. Il n'existait que dans le binaire compilé qui faisait partie de la distribution Unix.

Tous ceux qui ont eu cet Unix des Bell Labs ont eu un login piraté et un compilateur C. S'ils regardaient les sources, ils étaient en sécurité. S'ils reconstruisaient l'OS, le compilateur piraté piratait le compilateur reconstruit, qui réinsérait le piratage dans la commande de connexion.

La leçon que j'en tire est que la sécurité ne peut être garantie par aucune analyse statique (inspection du code source, du système d'exploitation, des applications).

Ken l'a révélé dans un article de l'ACM intitulé Réflexions sur la confiance .

Answer 5

Il y a quelques années, j'ai jeté un coup d'oeil à un programme (sur l'Acorn Archimedes) qui était protégé par un système complexe de cryptage (juste pour voir comment c'était fait et en tirer des leçons). C'était très bien fait, avec le code de décryptage lui-même utilisé comme une partie de la clé de décryptage, de sorte que toute tentative d'y toucher briserait le décryptage et vous laisserait donc avec des déchets en mémoire.

Après deux jours à essayer de comprendre comment cela se passait et comment on pouvait le contourner, un ami m'a rendu visite. À l'aide d'un outil du système d'exploitation (un clic et un glissement pour maximiser l'allocation de mémoire de la RMA), il a limité la RAM disponible pour le processus à exécuter à une taille légèrement supérieure à celle du fichier .exe. Puis il l'a exécuté. Immédiatement après s'être décrypté, il a essayé d'allouer de la mémoire, a échoué et s'est écrasé. Il a ensuite sauvé le programme décrypté de la mémoire. Durée totale du crack : environ 2 minutes, en utilisant uniquement un déplacement de la souris et une commande de sauvegarde en ligne de commande.

J'en ai tiré la leçon qu'il ne vaut pas la peine de consacrer trop de temps et d'efforts à la protection de votre logiciel - si quelqu'un veut le craquer, il le fera, et probablement par un moyen simple qui ne vous est jamais venu à l'esprit.

(Avertissement : nous avions tous deux acheté des copies légales de ce programme et n'avons jamais utilisé le code piraté de quelque manière que ce soit. Ce n'était vraiment qu'un exercice de programmation intellectuelle)