Sicherheitslücken in bekannten Mailern ermöglichen Passwortdiebstahl

Talion

...
ID: 33759
L
20 April 2006
794
75
Hallo,

vor mehr als einer Woche habe ich mehrere Sicherheitslücken in bestimmten Versionen des Jagusch-Script entdeckt, die es ermöglichen, Cross-Site-Scripting-Angriffe durchzuführen. Solche Angriffe lassen sich unter anderem dazu nutzen, Passwörter, Emailadressen, Session-Ids und zahlreiche andere persönliche Nutzerdaten auszulesen. Diese Angriffe habe ich gegen Test-Accounts erfolgreich durchgeführt, und sie sind mit vertretbarem Aufwand auch als echte Angriffe gegen fremde Accounts durchführbar.

Ich habe die Admins der betroffenen Seiten (zehn an der Zahl) angeschrieben. Einer hat den Fehler bislang behoben, allerdings ohne es für nötig zu halten sich mal für den Hinweis zu bedanken. Ein weiterer, dem 4 der betroffenen Seiten gehören, hat sich für den Hinweis bedankt, die Fehler aber noch nicht behoben. (Dort liegt das Problem aber etwas anders als in den anderen Fällen, denn der Angriff an sich ist nicht erfolgreich, aber hat viele Datenbank-Fehlermeldungen zur Folge. Es ist anzunehmen, dass die Nutzereingaben dort nicht ausreichend geprüft werden, so dass sich vermutlich SQL Injections durchführen lassen. Auch diese Art von Angriff bietet einem weitreichende Möglichkeiten, oftmals sogar noch bessere als bei XSS (=Cross-Sitescripting); ich habe jedoch mangels Zeit nicht überprüft, ob sich solche Angriffe dort durchführen lassen.)

Bleiben also 5 Seiten, auf denen der Fehler nach einer Woche weder behoben ist, noch eine Reaktion kam. (Eine Antwort mit dem Inhalt "Ich habe keine Zeit den Fehler zu beheben, werde mich aber sobald wie möglich darum kümmern" hätte ich zwar für unverantwortlich gehalten, aber wenigstens noch verstanden.)

Aus diesem Grund stelle ich hier nun einen Demo-Angriff vor. Dabei nutze ich eine der weniger kritischen Sicherheitslücken aus, um auf den betroffenen Seiten beliebigen HTML-, Javascript- oder sonstigen clientseitigen Code auszuführen. Konkret wird hier nur den Text "XSS works" oder bei aktiviertem Javascript der Text "XSS with javascript works even better. Hier könnte IHR Text stehen. Oder IHR Passwort gestohlen, IHRE Emailadresse ausgelesen, IHR Account gelöscht werden." eingebunden, doch wenn das geht, würden auch alle anderen Inhalte funktionieren, wie meine Tests ja auch bestätigt haben.


Wer Javascript deaktiviert hat, ist vor vielen XSS-Angriffen geschützt, denn dann kann zwar beliebiger zusätzlicher Text angezeigt werden, aber es können persönlichen Daten ausgelesen und an den Angreiferserver gesendet werden. (Mal ein Beispiel wo "nur" Text eingebunden wurde: Bundeskanzlerin Merkel tritt zurück auf www.bundesregierung.de)
Wer eine aktuelle Version der Firefox-Erweiterung noscript verwendet, ist vor vielen XSS-Angriffen geschützt, da diese automatisch erkannt werden.


Auf folgenden Seiten könnt ihr die Demo-Angriffe ansehen:

https://www.reading4money.de/
https://bannisdukatenportal.de/
https://www.beatmails.de/
https://klicks-ohne-en.de/
https://www.dragongeiz.de/


Den Nutzern dieser Mailer möchte ich folgende Empfehlungen geben:
- In den AGB der betroffenen Mailer gibt es (hoffentlich) einen Absatz zum Datenschutz. Solange der Angriff funktioniert, ist keine Datensicherheit mehr gewährleistet. Möglicherweise wäre also eine Kündigung aus wichtigem Grund bzw. Nichterfüllung der vertraglichen Pflichten erfolgreich.
- Unabhängig davon würde ich zur Abmeldung raten
- Wer das dort verwendete Passwort auch auf anderen Seiten verwendet, sollte es dringend überall ändern



Mit freundlichen Grüßen,
Hannes
 
oh oh


zeig mir doch mal bitte wie es geht das Passwort somit auszulesen. Ich habe mal einen Programmierer gefragt, seine Antwort dazu.

https://www.ewock.de/~flexo/GEFAHRGEFAHR.html

fl**** ?(16:55):
ALLE schrott-kiddie-php-seiten sind angreifbar mit XSS
die sache ist
der aufwand von XSS ist sehr hoch
schwer damit was anzurichten
fl****?(16:56):
weil du den user dazu bringen musst bestimmte links zu klicken nachdem sie sich eingeloggt haben
und das ist nicht mehr soviel anders wie
"log dich mal bitte ein, änder dein passwort auf "gehackt!""
 
Zuletzt bearbeitet:
Vergiß es und lass es nach hier Panik zu machen.

Ich habe auch 2 sehr gute Progger, die sich super mit SQL und PHP und speziell in Jagusch auskennen.

Nicht nur, das mein Script bei beiden Mailern das Gleiche ist und zu 80 % nicht mehr original jagusch ist, nein es ist auch mehrfach überprüft worden und es hat keiner derartíge Sicherheitslücken darin gefunden, und wenn, dann sind die lange geschlossen worden.

Und wenn es nur über Umwege geht und das ein User erst einen bestimmten gebauten Link klicken muß, dann ist der User absolut selbver schuld, wenn er Dieses tut.

Also, lass die Panikmache, das tut keinem gut, auch wenn du dich für besonders Allwissend hältst.
 
An alle, die glauben XSS ist nichts schlimmes, sollten sich mal https://de.wikipedia.org/wiki/XSS durchlesen.

Ja hättest du es mal gemacht, dann wüßtest du auch was es ist

Beim Cross-Site Scripting wird Schadcode auf Seiten des Clients ausgeführt, etwa dem Webbrowser oder E-Mail-Programm. Dazu schiebt der Angreifer dem Opfer ein von ihm präpariertes HTML-Dokument unter, das beispielsweise per E-Mail verschickt wird. Oder der Angreifer lässt dem Opfer einen Hyperlink zukommen, der auf eine vom Angreifer präparierte Webseite weist oder selbst den Schadcode enthält. Häufig werden dazu auch URL-Spoofing-Techniken und andere Kodierungsverfahren eingesetzt, um den Link unauffällig oder vertrauenswürdig erscheinen zu lassen.

Welche Bank ändert Ihr System weil unbedarfte Bankkunden auf Phishingmails rein fallen? Keine, nicht eine einzigste. Sicher ist es gefährlich, aber es ist eben nur so gefährlich, wie du selber. Klickst du als User nur die Links auf der Webseite passiert dir nichts, ebenso bei der Bank. Klicks du einen anderen Link wie eben diese hier im Forum ist es klar.

Genau das selbe wie wenn ich sage ändere mal dein Passwort auf 12345.

Ihr könnt mir aber gern das Gegenteil beweisen. mein Account bei Beatmails ist ewin12000 der erste der hier mir das Passwort postet bekommt 50 Euro von mir überwiesen, Bedingung Passwort per XSS ausgelesen.
 
Zuletzt bearbeitet:
Trotzdem versteh ich nicht, warum man die Sicherheitslücke nicht fixt, wenn sie zu beheben geht?
 
Also bitte! Egal wie groß die Gefahr ist, gehören Sicherheitslücken gefixt sobald man sie kennt! Sicherlich ist das Risiko nicht so groß, darum kann man sich beim fixen etwas Zeit lassen. Die Lücken aber nicht zu beseitigen empfinde ich als unprofessionell und fahrlässig!

Warum die Webbis auf die Email nicht reagieren kann ich nicht nachvollziehen. Gut ich weiß jetzt nicht wie Talion die Webbis angeschrieben hat. Also ich würde mich Bedanken wenn man bei mir Sicherheitslücken aufdeckt. Dann brauche ich die nicht zu suchen ;)

DadyCool
 
Also bitte! Egal wie groß die Gefahr ist, gehören Sicherheitslücken gefixt sobald man sie kennt! Sicherlich ist das Risiko nicht so groß, darum kann man sich beim fixen etwas Zeit lassen. Die Lücken aber nicht zu beseitigen empfinde ich als unprofessionell und fahrlässig!

Warum die Webbis auf die Email nicht reagieren kann ich nicht nachvollziehen. Gut ich weiß jetzt nicht wie Talion die Webbis angeschrieben hat. Also ich würde mich Bedanken wenn man bei mir Sicherheitslücken aufdeckt. Dann brauche ich die nicht zu suchen ;)

DadyCool

Eine Sicherheitslücke kann man aber auch nur dann finden wenn man scheiße bauen will, oder meinste er durchsucht Mailer nach den Lüken um den Webbis zu helfen ? Sonst nichts zu tuhn der junge Samarita ?
 
Eine Sicherheitslücke kann man aber auch nur dann finden wenn man scheiße bauen will, oder meinste er durchsucht Mailer nach den Lüken um den Webbis zu helfen ? Sonst nichts zu tuhn der junge Samarita ?

Du monierst jetzt also im Ernst, dass ein User, der vllt. auf deiner Seite eine Sicherheitslücke gefunden hat, diese aber nicht ausgenutzt hat, sondern lieber dir bescheid gegeben hat?
 
Du monierst jetzt also im Ernst, dass ein User, der vllt. auf deiner Seite eine Sicherheitslücke gefunden hat, diese aber nicht ausgenutzt hat, sondern lieber dir bescheid gegeben hat?

Mir hat keiner Bescheid gegeben, hab aber auch andere Dinge im Netz von daher Betrifft es mich ja nicht so wirklich.

Aber mal im Ernst man findet die doch nicht durch Zufall :roll:


Edit:
Z.B. beim MT Script ist es auch möglich, muss noch jemand einen Thread für aufmachen
 
Na ja, muss nur jemand einen Link per Paidbanner auf eine beliebige Seite mit dem Anhang buchen und schon kann der Cookieinhalt per JavaScript "verschickt" werden. Weiterleitung kann ja einfach per JavaScript passieren.

Kann man auch alles schön versteckt per IFrame machen.

Ein Herz für Javascript und Nicht-No-Script-User.

EDIT: komisch, jetzt wird auf einmal was gemacht :ugly: die ersten 3 URLs sind schon mal entscriptet
 
Zuletzt bearbeitet:
ALLE schrott-kiddie-php-seiten sind angreifbar mit XSS
die sache ist
der aufwand von XSS ist sehr hoch
schwer damit was anzurichten
Das finde ich schonmal hervorhebenswert. Paidmailer haben etwas mit Geld zu tun, unter anderem vertraut man ihnen Kontodaten etc. an. Vielleicht sollte da bei den Nutzern ein Bewusstsein dafür entstehen, ob sie ihre Daten Seiten anvertrauen wollen, die sich in die selbe Kategorie wie Schrott-Kiddiie-PHP-Seiten stellen und Sicherheitslücken mit Begründungen wie "Und ich habe keine Lust 40k Zeilen PHP Code durchzugucken, um Sicherheitslücken zu schliessen, die sich nur unter bestimmten seltenen Bedingungen ausnutzen lassen" wissend in Kauf nehmen.
Richtig, der Aufwand ist relativ hoch, aber durchführbar.
Dass XSS und SQL Injections unterschiedliche Angriffe sind, ist mir bewusst; bitte zeige mir die Stelle an der ich etwas gegenteiliges behauptet habe.


Und wenn es nur über Umwege geht und das ein User erst einen bestimmten gebauten Link klicken muß, dann ist der User absolut selbver schuld, wenn er Dieses tut.
Der User muss den Link nicht klicken, sondern es reicht völlig wenn er in einem Besuchertauschprogramm oder sonstigen derartigen Geschichten auftaucht. Sicher gehört ein gewisser Zufall dazu, wenn er zum selben Zeitpunkt eingeloggt ist, aber dieser Zufall wird definitiv auftauchen, somit ist der Angriff nutzbar. Dass es der gefährlichste denkbare Angriff wäre, habe ich nicht behauptet, aber dass man sich deswegen nicht dagegen schützen muss, ist blanker Unsinn.

Ich halte meine User weder für Naiv noch für Blöd.
Viele erfolgreiche Angriffe sind nicht raffiniert. Viele User sind naiv und oder blöd, nicht aus Mangel an Intelligenz, sondern aus Mangel an Fachwissen auf diesem Gebiet. Es versteht sich für seriös auftretende Seiten von selbst, dem User so viel Sicherheit wie möglich zu bieten. Klar sind z.b. Phishing-Opfer selbst schuld, aber ist das ein Grund, deswegen Tür und Tor dafür offen zu lassen?


Trotzdem versteh ich nicht, warum man die Sicherheitslücke nicht fixt, wenn sie zu beheben geht?
:yes:


Eine Sicherheitslücke kann man aber auch nur dann finden wenn man scheiße bauen will, oder meinste er durchsucht Mailer nach den Lüken um den Webbis zu helfen ? Sonst nichts zu tuhn der junge Samarita ?
Meinst du ich hätte die Seiten sonst angeschrieben? Zum einen beschäftige ich mich mit dem Thema im Studium, zum anderen muss man nur mal versehentlich ein " oder > im Usernamen eingeben um zu sehen, dass die Variablen ungeprüft ausgegeben werden.


einen POST erzeugen um das Kennwort zu ändern
Nein, eben nicht. GET reicht bereits aus, und zwar ohne das Passwort zu kennen. Übrigens: wenn man im Passwort ein Apostroph hat, kann man sich nicht mehr einloggen, und auch die Passwort vergessen Funktion hilft nicht weiter. Auch da würd sich eine sachgemäße Behandlung von Variablen anbieten, statt sich auf magic_quotes und co. zu verlassen.


Jagusch ist Schrott. Wer Wert auf Sicherheit legt, der sollte es neu schreiben lassen. Aber zu versuchen jede Sicherheitslücke darin zu schliessen ist einfach nicht wirtschaftlich.
Das lohnt sich ebenfalls hervorzuheben. Ein Seitenbetreiber der ein solches Script verwendet, verdient keinerlei Vertrauen.


Z.B. beim MT Script ist es auch möglich, muss noch jemand einen Thread für aufmachen
Es ist auch bei tausend anderen Scripten möglich, aber irgendwo muss man den Anfang machen. Auf Privatseiten mag sowas ja harmlos sein, aber bei geschäftlichen Seiten hört der Spaß auf, da muss jede noch so harmlose Sicherheitslücke behoben werden, insbesondere wenn es so leicht zu erledigen ist wie hier.



Das Passwort kann man übrigens auslesen, weil es hier im Klartext angezeigt wird: mitgliederbereich.php?page=IhreDaten
<tr>
<td><font face='Verdana,Helvetica,Geneva,Swiss,SunSans-Regular'>Kennwort:</font></td>
<td></td><td><input type='password' name='newkennwort' value='PASSWORT HIER' size='40'></td></tr>



Zum Account löschen muss einem lediglich folgender Link untergeschoben werden (Iframe, Paidlink, Besuchertausch, ...)
https://www.reading4money.de/mitgliederbereich.php?page=MitgliedschaftbeendenOK
(GET reicht, keine weitere Nachfrage!)





EDIT: komisch, jetzt wird auf einmal was gemacht :ugly: die ersten 3 URLs sind schon mal entscriptet

Seltsam, dabei ist das doch alles völlig unbedenklich...
 
Zuletzt bearbeitet:
Seltsam, dabei ist das doch alles völlig unbedenklich...

Ganz einfach, weil Ihr sonst keine ruhe gebt :p

Die Passwörter werden soweit ich weiß nicht im Klartext angezeigt und der Zufall das einer eingeloggt per Cookie ist und den Link per Mailtausch aufruft und daraus einen Nutzen ziehen kann ist faktisch bei 0. Bankdaten hmm ok ich geh an die Tankstelle und suche die Quittungen aus dem Papierkorb von Leuten die mit ec bezahlt haben, hab ich die auch, anfangen kann ich damit nichts und im Account bei einem Jaguschscript stehen die nunmal nicht. Name und Anschrift kann man auslesen? weiß ich nicht aber ich schlag das Telbuch auf und hab die auch. Hmm fakt ist du schiebst jemanden einen manipulierten Link unter und was ist das, auch wenn du es gut meinst es ist strafbar hmm selbst der Versuch ist strafbar;)
 
Postet mir bitte eure Anschrift wo ich dann die Rechnung dafür hin schicken kann.

Da sich hier ja alle "Paid4grössen" versammelt und ihr Fachwissen kund tun könnt ihr ja gleich den Hut rum gehen lassen.
 
Ganz einfach, weil Ihr sonst keine ruhe gebt :p
Damit ist das Hauptziel ja bereits erreicht, auch wenns vermutlich schnell wieder in Vergessenheit geraten wird.

Die Passwörter werden soweit ich weiß nicht im Klartext angezeigt
Doch, habs gerad extra nochmal ausprobiert. Und es ist kein Geheimnis, dass ein Großteil der Leute das selbe Passwort auch auf allen anderen Seiten verwendet.


Hmm fakt ist du schiebst jemanden einen manipulierten Link unter und was ist das, auch wenn du es gut meinst es ist strafbar hmm selbst der Versuch ist strafbar;)
Es ist strafbar, sobald ich es bei anderen versuche, aber nicht bei meinen eigenen Accounts. Und wer das bei anderen Accounts versucht, ist sich vermutlich bewusst, dass er eine strafbare Handlung begeht.



Den Paid-Nutzern würde ich übrigens empfehlen darauf zu achten, wer von den Seitenbetreibern hier lediglich unsachliche Kommentare von sich gibt, und wer sich hingegen mit dem Problem ernsthaft auseinandersetzt.
Natürlich ist XSS ein relativ schwacher, da aufwändiger Angriff, aber nichtsdestotrotz keiner den man als unpraktikabel unter den Tisch fallen lassen kann. Als Panikmache würde ich meinen Aufruf nicht bezeichnen, sondern nur als Beispiel dafür, wie sorglos manche Betreiber eben mit Sicherheitsproblemen umgehen.


Gute Nacht allerseits ;)
 
Zuletzt bearbeitet:
So, ich sage jetzt mal die Dinge die vermutlich einige denken aber niemand sagen will.

Seltsam, dabei ist das doch alles völlig unbedenklich...

Ich gehe mal davon aus, dass du den Jagusch Code nicht kennst? Das sind keine Fälle wo der Author "was vergessen" hat - weitgehend *nirgendwo* wird *irgendwas* escaped. Dein "Bugreport" hat mir nicht viel neues gesagt, als er an mich weitergeleitet wurde...

Weder HTML noch SQL wird escaped. Aber es gibt ja magic quotes. SQL Injections haben wir glaube ich keine, weil die (dank magic quotes) ja relativ einfach zu finden sind (grep mysql_query *.php | less...). Aber was HTML angeht...

Ausserdem konnte der Author nicht wirklich coden und hat lieber 11 verschachtelte for-Schleifen geschrieben um die Refvergütung zu berechnen anstatt eine rekursive Funktion in PHP, besser in der Datenbank, oder besser gleich ein Nested Set zu benutzen. Hier, guck:

https://212.112.227.4/~flexo/old.txt

Und, ja, das tut exakt was gleiche wie:

https://212.112.227.4/~flexo/new.txt

Von solchem Code reden wir hier.

Er ist voll von Bugs, Sicherheitslücken, grausamen Performanceproblemen, etc.

Benutzt wird er, weil er billig ist, und die Gewinnspanne in Paid4 ja nicht sonderlich groß ist.

Es würde sich für einen Betreiber einfach nicht rentieren jede Sicherheitslücke zu fixen von der er erfährt. Denn letztendlich:

Wie bereits in einem anderen Post erwähnt - mit den Daten die man im Mailer findet kann man nicht sonderlich viel anfangen. Wieso sollte jemand das Risiko einer Anzeige auf sich nehmen, für ein paar Bankverbindungen?

Technisch hast du recht. Natürlich ist es eine Sicherheitslücke, und es wäre schön sie zu fixen. Nur wer soll dafür aufkommen? Du denkst du nicht, dass jemand derartigen Code für lau wartet?

Realistisch betrachtet ist die Wahrscheinlichkeit, dass jemand mit genug technischem Verständnis sich findet, der dann auch noch die Motivation hat es umzusetzen eher gering - und selbst wenn es passiert ist die Schadenseingrenzung hinterher noch relativ einfach.

Felix Nawothnig
 
Zuletzt bearbeitet:
Kommerziellen Code öffentlich zu zeigen dürfte recht teuer werden. Sogar der Ver... ach nee, steht ja direkt da. :ugly:

EDIT: ich sag auch niemanden, dass es ewock war :ugly:
 
Zuletzt bearbeitet: