Trou de sécurité pire vous ' ai vu ?

Question

Quel est le pire trou de sécurité que vous avez jamais vu? C'est probablement une bonne idée de garder les détails limitée pour protéger les coupables.

Pour ce que ça vaut, voici une question à propos de quoi faire si vous trouvez un trou de sécurité, et un autre avec quelques réponses utiles si une compagnie n'a pas (semble) répondre.

Answer 1

Depuis les débuts de magasins en ligne :

Obtenir une réduction de 90 % en entrant.1 dans le champ quantité du panier. Le logiciel correctement calculé le coût comme.1 * coût et l’homme d’emballage de l’ordre tout simplement occulté l’impair «. » devant la quantité d’emballer  :)

Answer 2

Le moins pardonnable trou de sécurité, et malheureusement très commun et facile à trouver, est Google hacking. Affaire au point:

http://www.google.com/search?q=inurl%3Aselect+inurl%3A%2520+inurl%3Afrom+inurl%3Awhere

Il est incroyable de voir comment beaucoup de pages sur Internet, les sites du gouvernement en particulier, passer une requête SQL par le biais de la chaîne de requête. C'est la pire forme de l'injection SQL, et il ne prend aucun effort pour trouver des sites vulnérables.

Avec des modifications mineures, j'ai été en mesure de trouver sans protection des installations de phpMyAdmin, sans protection des installations de MySQL, les chaînes de requête contenant les noms d'utilisateur et mots de passe, etc.

Answer 3

Ingénierie sociale:

 <Cthon98> hey, if you type in your pw, it will show as stars
<Cthon98> ********* see!
<AzureDiamond> hunter2
<AzureDiamond> doesnt look like stars to me
<Cthon98> <AzureDiamond> *******
<Cthon98> thats what I see
<AzureDiamond> oh, really?
<Cthon98> Absolutely
<AzureDiamond> you can go hunter2 my hunter2-ing hunter2
<AzureDiamond> haha, does that look funny to you?
<Cthon98> lol, yes. See, when YOU type hunter2, it shows to us as *******
<AzureDiamond> thats neat, I didnt know IRC did that
<Cthon98> yep, no matter how many times you type hunter2, it will show to us as *******
<AzureDiamond> awesome!
<AzureDiamond> wait, how do you know my pw?
<Cthon98> er, I just copy pasted YOUR ******'s and it appears to YOU as hunter2 cause its your pw
<AzureDiamond> oh, ok.
 

De bash.org

Answer 4

Histoire vraie de mes premiers jours à Microsoft.

Vous n'avez pas connu la peur jusqu'à ce que le jour vous réveiller et de voir le titre sur ZDNet.com le matin est "le Pire de Sécurité d'Internet Explorer Trou n'A Jamais Été Découvert Dans 'Blah'" où 'Blah' est le code que vous avez écrit vous-même six mois auparavant.

Immédiatement après se rendre au travail, j'ai vérifié les journaux des modifications et a découvert que quelqu'un d'une autre équipe, une personne que nous avons fait confiance à apporter des modifications au produit -- a vérifié mon code, changé un tas de sécurité paramètres de clé de registre pour aucune bonne raison, vérifié à nouveau, et n'a jamais eu un examen du code ou dit à personne à ce sujet. À ce jour, je n'ai aucune idée ce qui sur terre il pensait qu'il était en train de faire; il a quitté l'entreprise peu de temps après. (De son propre chef.)

(Mise à JOUR: quelques réponses aux questions soulevées dans les commentaires:

Tout d'abord, notez que je choisis de prendre la position de bienfaisance que la clé de sécurité, les modifications étaient intentionnelles et non fondée sur la négligence ou de l'ignorance, plutôt que de malice. Je n'ai aucune preuve, d'une façon ou l'autre, et nous croyons qu'il est sage d'attribuer les erreurs de l'homme est faillible.

Deuxièmement, notre checkin systèmes sont beaucoup, beaucoup plus forte aujourd'hui qu'ils ne l'étaient il y a douze ans. Par exemple, il n'est maintenant plus possible de vérifier dans le code sans le système d'archivage envoyant un courriel à la modification de la liste des parties intéressées. En particulier, les changements effectués en fin de navire cycle ont beaucoup de "processus" qui garantit que le droit des modifications sont apportées pour assurer la stabilité et la sécurité du produit.)

De toute façon, le problème a été qu'un objet qui n'était PAS sûr pour être utilisé à partir d'Internet Explorer a été libérée accidentellement en étant marqué "sûrs pour l'écriture de scripts". L'objet a été capable d'écrire des fichiers binaires -- OLE Automation de bibliothèques de types, en fait -- arbitraire emplacements de disque. Cela signifie qu'un attaquant pourrait créer un type de bibliothèque qui contenait certaines chaînes de hostile code, enregistrez-le dans un chemin qui a été connu de l'exécutable de l'emplacement, de lui donner l'extension de quelque chose qui serait la cause d'un script à exécuter, et espère que d'une certaine façon, l'utilisateur accidentellement exécuter le code. Je ne sais pas du succès de tout le "monde réel" des attaques qui ont utilisé cette vulnérabilité, mais il était possible de fabriquer un travail d'exploiter avec elle.

Nous avons expédié un patch sacrément vite pour que l'on, permettez-moi de vous le dire.

Je l'ai provoqué et a ensuite fixé beaucoup plus de trous de sécurité dans JScript, mais aucun d'eux n'a réussi à approcher de la publicité que l'on fait.

Answer 5

J'espère que vous pourrez voir ce qui ne va pas ici. (Terriblement faux, en fait):

 String emailBody = "";

for (int i = 0; i < subscribers.Count; i++)
{
    emailBody += "Hello " + subscribers[i].FirstName + ",";
    emailBody += "this is a reminder with your account information: \n\n:";
    emailBody += "Your username: " + subscribers[i].Username + "\n";
    emailBody += "Your password: " + subscribers[i].Password + "\n";
    emailBody += "Have a great day!";

    emailDispatcher.Send(subscribers[i].EmailAddress, emailBody);
}
 

Le dernier destinataire était le plus heureux;)