Nachdem ein Kunde auf Bugs hingewiesen wurde, inkl. der Forderung nach einer globalen Lösung, kommt manchmal zügig die Rückmeldung, dass die Lücke geschlossen wurde. Eine globale Lösung, womit der ganze Server bzw. alle Seiten der Website gemeint sind, ist i.d.R. nicht im Handumdrehen erledigt. Wenn also “zu schnell” die Rückmeldung eintrifft, so gibt es meist einen der folgenden Gründe dafür:

• Die Website ist vom Umfang her überschaubar, womit die mögliche Angriffsfläche klein ist und eine Lösung relativ einfach und schnell erfolgen konnte.
• Der Kunde bzw. sein Webfuzzy hat den Proof of Concept nicht wirklich nachvollziehen können und wähnt sich in Sicherheit.
• Es wurde keine globale Lösung für das Problem integriert, sondern nur dafür gesorgt, dass mein PoC nicht mehr funktioniert.
• Bei der Behebung des Problems wurde einfach geschlampt.

---

Ich schreibe einem Kunden ein PoC, in dem die Session-ID mit “made_by_hacker” vorgegeben wird. Nach ein paar Tagen kommt die Rückmeldung “Lücke geschlossen”. Ich nehme mir mein PoC für die Nachprüfung zur Hand und er funktioniert noch immer!? Obwohl man die Session-ID während des Besuchs der Website in der Adresszeile des Browsers sehen kann, hat der Kunde gemeint die Lücke wäre geschlossen.

Der Kunde betreibt einen Shop mit einer asbach-Version von XT-Commerce, die nie ein Update erfahren hat. Da sag ich nur: Jahrelange Pflege – der Lücken!

---

Bei einem anderen Kunden ging es mal wieder um Cross-Site Scripting, wobei der PoC evtl. nicht auf den ersten Blick verstanden wurde.

Hier jeweils drei kleine Bilder pro Beispiel, um die Lücke leichter zu verstehen. Das erste Bild zeigt den Teil der in der Adresszeile des Browsers angezeigt wird, das zweite Bild den Teil aus der HackBar und das letzte Bild ist die Ausgabe im Browserfenster. (HackBar (addons.mozilla.org) ist ein Add-on für den Firefox.)

• Im ersten Beispiel wird nur <hr>xss<hr> injiziert – ohne Erfolg.
• Im zweiten Beispiel wird die Injektion modifizieren:
  aus < wird %3C und aus > %3E
  Auch dieser Versuch bleibt erfolglos
• Erst wenn das %-Zeichen selber noch durch %25 ersetzt wird, ist der PoC erfolgreich.

Auch hier kam relativ schnell die Rückmeldung, die Lücke sei geschlossen. Meiner Dokumentation der Nachprüfung habe ich nun weitere Screenshots und weiteren Beispielcode hinzugefügt. Mal schauen ob es diesmal verstanden und gefixt wird.

---

Noch einmal Cross-Site Scripting. Alle Bilder kommen aus dem Quellcode eines (!) Dokuments:

Und was meldet der Kunde? Er würde nun alle Eingaben zentral filtern lassen! Naja, also, äh, Cheffe… Der Webfuzzy hat dafür wohl einen Satz heiße Ohren bekommen. Schickt den Chef los die frohe Botschaft zu verkünden und dann solch ein Desaster. :O)

---

Bei dem nächsten Kunden gab es eine Lücke, die mich an die 90er erinnerte. Wenn man in das System eingeloggt war, reichte es aus in der Adresszeile des Browsers die Kunden-ID zu ändern, um in den Daten eines fremden Accounts zu stöbern und diese nach den eigenen Vorstellungen zu editieren. Hier gab der Kunde die Rückmeldung, dass nun jegliche Veränderung an der Kunden-ID mit einer Fehlermeldung und einem Rücksprung zur Startseite quittiert würde. Es wurde wohl geglaubt mit einer so einfachen Maßnahme das Problem beheben zu können.

Der Manipulation der Kunden-ID in der Adresszeile wurde wie beschrieben begegnet. Bei Änderungen an den Profildaten wird die Kunden-ID aber auch in einem Hidden-Feld übertragen. Das Script welches dann die Änderungen durchführen soll kümmert sich leider nicht darum, ob die Kunden-ID aus dem Formular, zu der Kunden-ID des Kunden gehört, der das Formular abgeschickt hat. Ein Angreifer kann zwar nicht in die fremden Daten reinschauen, aber nach wie vor kann er Änderungen vornehmen, er könnte z.B. alle 400.000 Kunden-Datensätze leeren…

Das perfide an den Lücken in dem System ist, auch wenn Vor- und Nachname unberechtigt geändert wurde, so wird der echte Kunde nach dem Login mit den ursprünglichen Daten für Vor- und Nachname begrüßt, er würde eine Manipulation also erst bei dem Aufruf seines eigenen Profils bemerken. Die Webfuzzies des Systems haben da mehrere Tabellen in der Datenbank, bei denen sie wohl selber nicht mehr so recht wissen wofür diese gebraucht werden. In der einen Tabelle stehen die Daten aus der Registrierung bzw. den Änderungen die der legitimen Besucher gemacht hat. In einer anderen Tabelle stehen die Daten, die ein anderer als der legitime Besucher editiert hat. Wofür soll so etwas gut sein? Backdoor?

---

Und bei dem letzten Beispiel war mein Grinsen für den Rest des Tages gesichert. Auch hier ging es um Cross-Site Scripting und SQL-Injection. Auch hier wurde vom Kunden die globale Filterung gemeldet. Das Global war nun wieder nicht so wirklich durchgreifend, weil es da wohl verschiedene Abteilungen gibt, die nicht so gerne miteinander arbeiten mögen. ;O) Aber das was mich dann zum Dauergrinsen brachte, war die Filterung von xss… ich meine… wirklich xss… diese drei Buchstaben! :O) xxx hat der Filter durchgelassen, ist ja auch wichtig für die zwischenmenschliche Kommunikation, aber xss – BÖSE!! – SOFORT FILTERN!! Der Junge an dem Filter hatte aber von onmouseover oder eval noch nie etwas gehört. “Gibbet net, filtern wir net!!” Wobei… Filter… Poren… Löcher… das passt wie Arsch auf Eimer. ;O)

---

So manchem Kunden gehe ich wahrscheinlich heftig auf die Nerven. Die kommen freudig mit “Lücke geschlossen!” und von mir gibt es fast immer ein “Njet, nachsitzen!”

Sorry, aber ich bin doch der Korinthenkacker, ich kann nicht anders, das ist meine Berufung. :O)

Es gibt auch Bugs, die kann man einfach nicht fixen…