Die schlimmste Sicherheitslücke, die Sie je gesehen haben?

Question

Was ist die schlimmste Sicherheitslücke, die Sie je gesehen haben? Es ist wahrscheinlich eine gute Idee, die Details zu begrenzen, um die Schuldigen zu schützen.

Hier ein kleiner Einblick in die Frage was zu tun ist, wenn man eine Sicherheitslücke findet, und eine andere mit einigen nützlichen Antworten, wenn ein Unternehmen (scheinbar) nicht antwortet.

Answer 1

Aus der Anfangszeit der Online-Shops:

Sie erhalten einen Rabatt von 90 %, indem Sie .1 in das Mengenfeld des Warenkorbs eingeben. Die Software berechnete die Gesamtkosten korrekt als .1 * Kosten, und der Mitarbeiter, der die Bestellung verpackte, überging einfach das ungerade "." vor der zu verpackenden Menge :)

Answer 2

Die am wenigsten verzeihliche Sicherheitslücke, und leider eine sehr häufige und leicht zu findende noch dazu, ist Google-Hacking . Ein typisches Beispiel:

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

Es ist erstaunlich, wie viele Seiten im Internet, insbesondere Regierungsseiten, eine SQL-Abfrage über den Query-String übergeben. Das ist die schlimmste Form der SQL-Injektion, und es ist gar nicht so schwer, anfällige Seiten zu finden.

Mit geringfügigen Anpassungen war ich in der Lage, ungeschützte Installationen von phpMyAdmin, ungeschützte Installationen von MySQL, Abfragezeichenfolgen mit Benutzernamen und Kennwörtern usw. zu finden.

Answer 3

Social Engineering:

<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.

Von bash.org

Answer 4

Eine wahre Geschichte aus meiner Anfangszeit bei Microsoft.

Sie kennen die Angst erst, wenn Sie aufwachen und die Schlagzeile auf ZDNet.com an diesem Morgen lautet: " Schlimmste Sicherheitslücke im Internet Explorer aller Zeiten wurde in "Blah" entdeckt ", wobei 'Blah' ein Code ist, den Sie sechs Monate zuvor selbst geschrieben haben.

Als ich zur Arbeit kam, überprüfte ich sofort die Änderungsprotokolle und entdeckte, dass jemand aus einem anderen Team - jemand, dem wir vertrauten, um Änderungen am Produkt vorzunehmen - meinen Code ausgecheckt, eine Reihe von Einstellungen der Sicherheitsregistrierungsschlüssel ohne triftigen Grund geändert, ihn wieder eingecheckt und nie eine Codeüberprüfung durchgeführt oder jemanden darüber informiert hatte. Bis heute habe ich keine Ahnung, was er sich dabei gedacht hat; kurz darauf verließ er das Unternehmen. (Aus eigenem Antrieb.)

(UPDATE: Ein paar Antworten auf die in den Kommentaren aufgeworfenen Fragen:

Zunächst möchte ich darauf hinweisen, dass ich die wohlwollende Position vertrete, dass die Änderungen an den Sicherheitsschlüsseln unbeabsichtigt waren und auf Unachtsamkeit oder Unkenntnis und nicht auf Böswilligkeit beruhten. Ich habe keine Beweise für das eine oder das andere und glaube, dass es klug ist, Fehler der menschlichen Fehlbarkeit zuzuschreiben.

Zweitens sind unsere Abfertigungssysteme heute viel, viel leistungsfähiger als noch vor zwölf Jahren. So ist es heute beispielsweise nicht mehr möglich, Code einzuchecken, ohne dass das Checkin-System die Änderungsliste per E-Mail an interessierte Parteien sendet. Insbesondere bei Änderungen, die erst spät im Entwicklungszyklus vorgenommen werden, gibt es eine Menge "Prozesse", die sicherstellen, dass die richtigen Änderungen vorgenommen werden, um die Stabilität und Sicherheit des Produkts zu gewährleisten).

Der Fehler bestand darin, dass ein Objekt, dessen Verwendung im Internet Explorer NICHT sicher war, versehentlich als "sicher für die Skripterstellung" freigegeben worden war. Das Objekt war in der Lage, Binärdateien - in der Tat Bibliotheken vom Typ OLE Automation - an beliebige Speicherorte zu schreiben. Dies bedeutete, dass ein Angreifer eine Typbibliothek erstellen konnte, die bestimmte Zeichenfolgen von schädlichem Code enthielt, sie in einem Pfad speichern konnte, der ein bekannter ausführbarer Speicherort war, ihr die Erweiterung von etwas geben konnte, das die Ausführung eines Skripts bewirken würde, und hoffen konnte, dass der Benutzer den Code irgendwie versehentlich ausführen würde. Mir ist kein erfolgreicher "realer" Angriff bekannt, der diese Schwachstelle ausnutzte, aber es war möglich, einen funktionierenden Exploit zu erstellen.

Wir haben dafür verdammt schnell einen Patch veröffentlicht, das kann ich Ihnen sagen.

Ich habe viele weitere Sicherheitslücken in JScript verursacht und anschließend behoben, aber keine von ihnen hat auch nur annähernd so viel Aufmerksamkeit erregt wie diese eine.

Answer 5

Ich hoffe, Sie können erkennen, was hier falsch ist. (Schrecklich falsch, in der Tat):

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);
}

Der letzte Empfänger war der glücklichste ;)