Sicherheitsdiskussion SWM/SML

PHP Newsletter Software/Script und E-Mail-Marketing Software SuperWebMailer

Moderator: mirko

Benutzeravatar
mirko
Beiträge: 22903
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Beitrag von mirko »

Original von MP0-Crew:

Ja mit welchem Parameter? Ich habe versucht alles von extern abzufangen was nur geht aber natürlich kann man nicht alles unterbinden, sonst geht überhaupt kein Aufruf mehr.
Zum Beispiel MailingListId. Am besten, es wird generell für jeden Parameter, der in einen Query geschmissen wird, unter anderem mysql_real_escape_string() verwendet.
Alles von extern wird in einen Integer umgewandelt, damit sollte nichts passieren. Innerhalb des Bereichs, wird das dann ab der nächsten Version auch so gemacht, damit halt kein böser Mitarbeiter klauen gehen kann. mysql_real_escape_string() gibt es erst am PHP 4.3, deswegen habe ich das bisher auch nicht verwendet, es gibt halt noch PHP 4.1er Nutzer. Ich habe zumindest die \' \" selbst gequotet, um solche Angriffe auszuschließen.

Vom Prinzip her richtig, nur dann kann ein Normalmensch den Wert des Parameters M gar nicht mehr von Hand eingeben, das ist sehr ungünstig.
... dafür sollte im besten Falle das Backend da sein um sich einen passenden Link zu generieren. Den User aufzufordern manuell einen Parameter zu ändern, ist nicht wirklich Nutzerfreundlich. Aber das ist uns egal, solange man die Parameter nicht mit Schadecode austatten kann.
Ja aber für Wordpress, Joomla usw. muss man die Parameter manuell eingeben. Das beste wird sein noch einen eindeutigen Zusatzhash zu erfinden aber in der nächsten Version noch nicht.

Edit: wir haben mal den Threadttitel mal etwas weniger abschreckend benannt, da hier so gut reagiert wird.
Ohh habe ich gerade erst gesehen. :)
Benutzeravatar
mirko
Beiträge: 22903
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Beitrag von mirko »

Das mit Passwort wird jetzt auf jeden Fall geändert, dann muss halt der Nutzer erstmal mit einem kryptischen Passwort leben und kann es später immernoch auf einen freundlicheren Wert ändern.
Also, meine Passwörter sind immer kryptisch und es ist Jedem zu wünschen, dass er auch kryptische und keine \"freundliche\" Passwörter verwendet.
Nur einige können halt nichts aus einer E-Mail kopieren oder fehlerfrei abtippen, dann klingelt bei mir das Telefon, nur helfen kann ich in dem Fall auch nicht mehr.
PS: Nur diese Forensoftware ist ja grauslig. Stammt die noch irgendwie aus den 60ern?
Nee aus dem Jahr 2000 siehe rechts unten auf der Seite das Copyright. Eine andere gibt es aber erstmal nicht, da die Beiträge und Nutzer nicht so einfach übernommen werden können oder willst DU die alle abtippen. :biggrin:
MP0-Crew
Beiträge: 4
Registriert: 22.02.2011, 22:27

Beitrag von MP0-Crew »


Ja mit welchem Parameter? Ich habe versucht alles von extern abzufangen was nur geht aber natürlich kann man nicht alles unterbinden, sonst geht überhaupt kein Aufruf mehr.
Zum Beispiel MailingListId. Am besten, es wird generell für jeden Parameter, der in einen Query geschmissen wird, unter anderem mysql_real_escape_string() verwendet.
Vom Prinzip her richtig, nur dann kann ein Normalmensch den Wert des Parameters M gar nicht mehr von Hand eingeben, das ist sehr ungünstig.
... dafür sollte im besten Falle das Backend da sein um sich einen passenden Link zu generieren. Den User aufzufordern manuell einen Parameter zu ändern, ist nicht wirklich Nutzerfreundlich. Aber das ist uns egal, solange man die Parameter nicht mit Schadecode austatten kann.
Das mit Passwort wird jetzt auf jeden Fall geändert ...
Danke!

Edit: wir haben mal den Threadttitel mal etwas weniger abschreckend benannt, da hier so gut reagiert wird.

MP0
Zuletzt geändert von MP0-Crew am 26.02.2011, 01:04, insgesamt 1-mal geändert.
Benutzeravatar
Mkom
Beiträge: 41
Registriert: 17.02.2010, 15:50

Beitrag von Mkom »

Hallo Mirko,

ich finde es toll, wie souverän du hier mit der – offensichtlich teilweise berechtigten – massiven Kritik umgehst. Viele Andere hätten das stillschweigend gelöscht und unter den Tisch gekehrt.

Das zeigt mir wieder einmal mehr, dass der SWM und sein Entwickler ;) ein hervorragendes Produkt ist und bleibt und dass unser Kauf keine Fehlentscheidung war.
Das mit Passwort wird jetzt auf jeden Fall geändert, dann muss halt der Nutzer erstmal mit einem kryptischen Passwort leben und kann es später immernoch auf einen freundlicheren Wert ändern.
Also, meine Passwörter sind immer kryptisch und es ist Jedem zu wünschen, dass er auch kryptische und keine \"freundliche\" Passwörter verwendet.

Gruß
Alex

PS: Nur diese Forensoftware ist ja grauslig. Stammt die noch irgendwie aus den 60ern?
Benutzeravatar
mirko
Beiträge: 22903
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Beitrag von mirko »

Danke für die Rückmeldung vom Admin und danke, dass er unseren Thread nicht dicht gemacht hat. Das ist wirklich fair! Auch bitten wir wegen unseres Hacks im Demosystem um Verständnis und Entschuldigung.
Der Admin ist gleichzeitig der Entwickler, also warum sollte ich berechtigte Kritik löschen? Nur Spam wird gelöscht, das kommt aber nur selten vor.
Wir bekommen tatsächlich massig Spam und sind darüber nicht begeistert.
Ich auch nicht, an Spam mangelt es mir nicht. ;(
Leider ist die erwähnte Seite leider nicht die einzige, die mit dem SWM diesen Unfug anstellt (Daten sammeln, Spam verschicken, Daten verkaufen, etc). Zugegeben, uns sind genauso die Hände gebunden. Selbst mit unserer Analyse des Systems (die nur aufgrund der spammer so intensiv durchgeführt wurde ), blieb ein Erfolg aus, auf die Hintermänner zu stoßen. Aber die Datensätze sind wirklich enorm, mit denen da versucht wird Geld zu verdienen ...
Na an die Leute kommt man sowieso nicht ran. Das Problem ist halt ich kann nicht jeden Käufer prüfen, ob derjenige Spam versenden will oder nicht. Ich denke mal die meisten sind seriöse Versender, vielleicht 1% sind halt die schwarzen Schafe. Wenn ich aber selbst von jemanden Spam bekomme und ich sehen, dass es mit dem SWM versendet worden ist, dann bekommt er erstmal eine Abmahnung, weil er gegen die Lizenzbedingungen verstösst und am Ende die Lizenz gesperrt, so dass zumindest eine Neuinstallation nicht mehr möglich ist.
Wie gesagt, wir wollen niemandem Schaden zufügen, daher haben wir uns auch ausdrücklich nicht an anderen Systemen, wie z.B dem der \"Segelschule\" vergriffen. Auch haben wir mit unserem Thread keine Anleitung gegeben, wie man die Probleme im Detail ausnutzt.
Wir hoffen einfach nur, dass in zukünftigen Versionen in erster Linie mehr auf die Sicherheit während der Entwicklung geachtet wird, und zum anderen durch geeignete Strategien ein Missbrauch der Software versucht wird auszuschließen. Ein Backend sollte mit genausoviel Mühe programmiert werden, wie die öffentlichen Scripte.
Ich weiss das es intern nicht sicher ist, gibt es auch nächste Woche ein Update, damit es intern sicherer wird. Natürlich darf man nicht immer nur von bösen Mitarbeitern ausgehen, die Daten klauen wollen. Ich denke mal kaum einer weiss, wie man das überhaupt machen kann.
Ich sagte bereits, dass Blind-SQL-Injections ebenfalls in öffentlichen Scripten möglich sind. Das darf nicht sein! Ich kann durch fiese SQL-Querys die Server zum Schwitzen bringen oder eben durch eingeschleuste Tools an die Daten gelangen. Für 99€ in der kleinsten Version, kann man schon etwas Qualität erwarten, oder nicht?
Ja mit welchem Parameter? Ich habe versucht alles von extern abzufangen was nur geht aber natürlich kann man nicht alles unterbinden, sonst geht überhaupt kein Aufruf mehr.

Noch ein Tipp im Zusammenhang mit dem Spamfall von der Segelschule. Da man über die Passwort-Vergessen funktion leicht auf die hinterlegte Mail des Superadmins kommen kann, ist das natürlich auch sehr einladenend für Spammer.
Das kann man nicht, auch wenn man den Nutzernamen superadmin eingibt, dann schickt er die E-Mail mit dem Passwort an die hinterlegte E-Mail-Adresse, falls überhaupt eine E-Mail-Adresse hinterlegt ist. Die E-Mail kann keiner abfangen, außer derjenige hat insgesamt Zugriff auf den Server, dann kann man das sowieso komplett vergessen.
Die automatsierten Anmeldungen und die daraus resultierenden Anmeldemails sind häufig deshalb möglich, weil man durch willkürliches Raten des Parameters M in der defaltnewsletter.php häufig auf Mailinglisten stößt, die nicht mit einem Captcha gesichert sind. Hier sollte man mit einem guten Hash arbeiten, der die Manipulation der Parameter erkennt.
Vom Prinzip her richtig, nur dann kann ein Normalmensch den Wert des Parameters M gar nicht mehr von Hand eingeben, das ist sehr ungünstig.
Zum Passwortproblem: wieso generieren sie denn nicht einfach ein neues Passwort, nachdem der Nutzer dieses vergessen hat? Dann haben Sie ihr Klartextproblem gelöst.
Das mit Passwort wird jetzt auf jeden Fall geändert, dann muss halt der Nutzer erstmal mit einem kryptischen Passwort leben und kann es später immernoch auf einen freundlicheren Wert ändern.
MP0-Crew
Beiträge: 4
Registriert: 22.02.2011, 22:27

Beitrag von MP0-Crew »

Danke für die Rückmeldung vom Admin und danke, dass er unseren Thread nicht dicht gemacht hat. Das ist wirklich fair! Auch bitten wir wegen unseres Hacks im Demosystem um Verständnis und Entschuldigung.

Wir bekommen tatsächlich massig Spam und sind darüber nicht begeistert. Leider ist die erwähnte Seite leider nicht die einzige, die mit dem SWM diesen Unfug anstellt (Daten sammeln, Spam verschicken, Daten verkaufen, etc). Zugegeben, uns sind genauso die Hände gebunden. Selbst mit unserer Analyse des Systems (die nur aufgrund der spammer so intensiv durchgeführt wurde ), blieb ein Erfolg aus, auf die Hintermänner zu stoßen. Aber die Datensätze sind wirklich enorm, mit denen da versucht wird Geld zu verdienen ...

Wie gesagt, wir wollen niemandem Schaden zufügen, daher haben wir uns auch ausdrücklich nicht an anderen Systemen, wie z.B dem der \"Segelschule\" vergriffen. Auch haben wir mit unserem Thread keine Anleitung gegeben, wie man die Probleme im Detail ausnutzt.
Wir hoffen einfach nur, dass in zukünftigen Versionen in erster Linie mehr auf die Sicherheit während der Entwicklung geachtet wird, und zum anderen durch geeignete Strategien ein Missbrauch der Software versucht wird auszuschließen. Ein Backend sollte mit genausoviel Mühe programmiert werden, wie die öffentlichen Scripte.

Ich sagte bereits, dass Blind-SQL-Injections ebenfalls in öffentlichen Scripten möglich sind. Das darf nicht sein! Ich kann durch fiese SQL-Querys die Server zum Schwitzen bringen oder eben durch eingeschleuste Tools an die Daten gelangen. Für 99€ in der kleinsten Version, kann man schon etwas Qualität erwarten, oder nicht?

Edit:
Noch ein Tipp im Zusammenhang mit dem Spamfall von der Segelschule. Da man über die Passwort-Vergessen funktion leicht auf die hinterlegte Mail des Superadmins kommen kann, ist das natürlich auch sehr einladenend für Spammer.
Die automatsierten Anmeldungen und die daraus resultierenden Anmeldemails sind häufig deshalb möglich, weil man durch willkürliches Raten des Parameters M in der defaltnewsletter.php häufig auf Mailinglisten stößt, die nicht mit einem Captcha gesichert sind. Hier sollte man mit einem guten Hash arbeiten, der die Manipulation der Parameter erkennt.

Zum Passwortproblem: wieso generieren sie denn nicht einfach ein neues Passwort, nachdem der Nutzer dieses vergessen hat? Dann haben Sie ihr Klartextproblem gelöst.

MP0
Zuletzt geändert von MP0-Crew am 23.02.2011, 19:49, insgesamt 1-mal geändert.
segelschule
Beiträge: 3
Registriert: 23.02.2011, 02:23

Beitrag von segelschule »

Hallo,

unser Hoster stellt Ihnen gerne die Logfiles zur Verfügung, damit Sie entsprechend das Problem nachvollziehen können. Sie können ihn unter lakeserver.de kontaktieren.

Uns erreichen Sie unter http://www.segelschule-wasserburg.de/kontakt.html

Gruß vom Bodensee
--
Jörg
Benutzeravatar
mirko
Beiträge: 22903
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Beitrag von mirko »

Wie gehackt? Dazu müsste man wissen, was genau gemacht wurde. z.B. wird das Anmeldeformular durch Spambots ständig aufgerufen und E-Mail-Adressen eingetragen, dann schickt er jedesmal Anmelde-Mails raus und das könnten 1000te werden, wenn das ständig gemacht wird.
segelschule
Beiträge: 3
Registriert: 23.02.2011, 02:23

Beitrag von segelschule »

Also unser System wurde zumindest gehackt und der Hoster hat jetzt erstmal das System gesperrt. :-(
Benutzeravatar
mirko
Beiträge: 22903
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Beitrag von mirko »

Von außen kommt man an keine Daten ran. Hat man die Zugangsdaten, wie in dem öffentlichen Demo auf meiner Webseite, welches illegaler Weise vom MP0-Crew mit anonymisierten IP-Adressen mehrfach angegriffen worden ist, dann sind natürlich Manipulationen möglich. Die enthaltende Nutzerverwaltung ist auch keine Hochsicherheitsverwaltung, so ist es auch gar nicht gedacht. Und natürlich sind die unverschlüsselten Passworte ein Problem, das wird sich ab der nächsten Version ändern, auch wenn dann viele Probleme bekommen werden, Ihr vergessenes Passwort wiederzubekommen.


Der Nutzer MP0-Crew ist nur sehr schlecht gelaunt, weil er anscheinend Spam bekommen. Wer der Spam-Versender ist, weiß ich nicht, weil das Anhand der Domain, die von MP0-Crew als Hack vorübergehend in mein Demo eingebaut wurde, nicht erkennbar ist, sonst hätte ich denjenigen schon lange abgemahnt.

Und weil ich das noch lese, keine E-Mail wurde von MP0-Crew an meine E-Mail-Adresse gesendet. Die 0900er Nummer kann er gar nicht anrufen, weil er anscheinend im Ausland ist, denn seine Zugriffe erfolgen immer nur zu später Stunde.
segelschule
Beiträge: 3
Registriert: 23.02.2011, 02:23

Beitrag von segelschule »

Hallo,

unser System ist vergangene Woche anscheinend auch gehackt worden. Es wurde versucht an die eigene E-Mail eine Vielzahl von Mails zu schicken. Zum Glück waren noch keine Kundendaten hinterlegt.

Sehr ärgerlich, da wir das Skript wohl nun umsonst gekauft haben. Und dennoch keinen vernünftigen Newsletter Sender haben.
MP0-Crew
Beiträge: 4
Registriert: 22.02.2011, 22:27

Beitrag von MP0-Crew »

+++ Wichtig +++
Dieser Beitrag klärt über die mangelnden Sicherheitsvorkehrungen in der Software Superwebmailer (alle Versionen bis 3.40.0.00723), sowie SuperMailingList (alle Versionen bis 3.20.0.00420) auf.


Thema heute:
Die Sicherheit der Websoftware Superwebmailer und SuperMailingList :: H3ck3D by MP0


Einleitung
Da der Admin „Mirko“ auf unsere mehrfachen Warnungen auf den Demosystemen nicht reagiert hat, sowie unsere Mail unbeantwortet blieb, müssen wir unsere wichtige Ankündigung nun leider öffentlich machen. Dies ist natürlich besonders für Kunden ärgerlich, die wir durch unsere Aussagen verunsichern. Uns liegt aber sehr viel an der Websicherheit, weswegen uns leider keine anderen Möglichkeiten ergeben, als unser Statement hier öffentlich zu machen. Auch die 0900er Telefonnummer hat es uns nicht gerade leicht gemacht einen günstigen Kontakt herzustellen.

Wir hoffen im Sinne aller Kunden, dass dieses Statement nicht zensiert wird und der Admin diese wichtigen Informationen seinen Kunden nicht vorenthält.


Was wird nicht tun:

Bevor wir schildern worum es genau geht, soll klargestellt werden, dass es uns nicht darum geht anderen Nutzern, sowie dem Betreiber Schaden zuzuführen oder gar Daten zu stehlen oder zu missbrauchen. Außerdem verkaufen wir keine Exploits oder anderweitige Sicherheitslücken, um uns damit zu bereichern. Unsere Absicht ist es, auf Sicherheitsprobleme aufmerksam zu machen, um die genannten Vergehen, die leider einen Großteil der Intenetgrauzone bestimmen, zu verhindern.


Der Superwebmailer und sein Abkömmling SuperMailingList werden derzeit auf dutzenden Online-Systemen eingesetzt und aktiv genutzt. Da hinter den Newslettersystemen oft große Nutzerdatenbanken mit E-Mail-Adressen und meist auch den dazugehörigen personenbezogenen Daten, wie z.B Name und Adresse stecken, ist es besonders fatal, wenn es einem Angreifer möglich wäre durch geeignete Sicherheitslücken an diese sensiblen Daten zu gelangen.

In den allermeisten Fällen sind dann noch zusätzlich die Webserver nicht ausreichend geschützt, um eine vollständige Kompromitierung des Servers zu verhindern. Dies bringt natürlich weitere Datenprobleme für den Systeminhaber mit sich: unberechtigte Zugriffe auf weitere Datenbanken, Serverscripte, sensible Daten, usw.
Um das letztere Problem, der Serversicherheit soll es heute nicht gehen. Wir möchten aber auf gravierende Sicherheitsprobleme des Superwebmailers aufmerksam machen, damit der eben genannte Worst-Case nicht eintritt.


Die Sicherheitslücken (Anwender können diesen technischen Part überspringen und das FAZIT lesen)

Als Programmierer hat man die große Aufgabe einerseits den Kunden gerecht zu werden, die immer nach neuen Funktionen rufen oder Fehler behoben haben möchten. Andererseits aber muss man sich während der Entwicklung auch immer einer zweiten Gruppe widmen: den bösen Hackern. Der Programmcode muss immer so gestaltet sein, dass man dieser Gruppe grundsätzlich einen Riegel vor die Tür schiebt. Um viele Codekorrekturen durch Externe und Stresstests/Betatests durch experten sollte man daher nicht verzichten. Soweit die sehr allgemeine Theorie. Nun werden wir konkret.

Ein Sicherheitsbewusstsein seitens des Entwicklers ist an vielen Stellen in der Software nicht erkennbar. Es werden an fast in allen Scripten gravierende Anfängerfehler gemacht, die nicht zu entschuldigen sind! Dies hat als Resultat, dass viele Codeteile erhebliche Sicherheitsmängel aufweisen und es dem Hacker ermöglichen, auf sensible Daten zuzugreifen. Hierbei wurde aber nicht nur ein kleines Türchen offen gelassen, sondern ein komplettes Tor. Nebenbei stehen auch die Fenster offen, ach und der Keller auch ...

Wir möchten hier nicht alle Sicherheitslücken im Detail aufzählen, da würden wir morgen noch schreiben. Außerdem bezahlt uns keiner dafür. Doch einige grundlegende Dinge sollten wir festhalten, damit der Entwickler da schnell nachbessern kann:

1.
Variablenübergaben, die durch den Nutzer manipuliert werden könnten (GET/POST) müssen einerseits auf die Korrektheit der Variablentypen kontrolliert werden und andererseits auf Manipulation untersucht werden. Wenn das Script ein Integer erwartet, dann darf das Script nicht auch einen String akzeptieren. In der vorliegenden Software ist dies jedoch zulässig, zum Vorteil für den Angreifer.

2.
Datenbankqueries werden vom Admin zu Genüge eingesetzt. Mal abgesehen von der schlechten Datenbankmodellierung und der resultierenden Serverlast, wird hier ebenfalls wieder keine Kontrolle auf Manipulation der übergebenen Parameter durchgeführt. Einerseits findet wieder keine Typenkontrolle statt (siehe 1), anderseits werden auch keine unsicheren Zeichen maskiert.
Jeder Programmieranfänger hat schon mal etwas von SQL Injections gehört. Der Admin scheint dieses Wissen aber unser Ansicht nach in irgendeiner Schublade vergraben zu haben. So können wir ohne Probleme mit den Scripten der Software an die sensiblen Daten gelangen (E-Mail-Adressen, Passwörter, Scripte, etc.) und uns bei einem schlechten Server sogar den Vollzugriff verschaffen. Warum? Weil wir SQL-Code einschleusen können.
Beispiel:

So wird könnte aus einem harmlosen
SELECT *, DATE_FORMAT(`MessageDate`, \'%d.%m.%Y %H:%i\') AS MessageDateFormated FROM `localusermessages` WHERE id=5;

ein fieses ...

SELECT *, DATE_FORMAT(`MessageDate`, \'%d.%m.%Y %H:%i\') AS MessageDateFormated FROM `localusermessages` WHERE id=7 UNION SELECT 1,2,3,4,5,6,Password,8,9,10,11 FROM `users` WHERE id=1 /*

... Und schon haben wir das Superadmin-Passwort!
In diesem Zusammenhang erwähnenswert ist die sehr clevere Wahl des Administrator-Nutzernamens, der auf allen System derselbe ist. Weiter ist es sehr clever dem Nutzer fehlerhafte SQL-Querys auszugeben. Das macht eine SQLi zum Kinderspiel. Und leider können das heutzutage auch Kinder ...

Zugegeben, diese oben geschriebene Lücke ist nur ausnutzbar im passwortgeschützten Backend (die Datei spare ich mir jetzt zu nennen). Aber selbst ein \"Nutzer\" mit entsprechend wenig Rechten (z.B durchgeknallter Mitarbeiter) kann sich mal eben mit der gesamten Datenbank und ggf. mit dem Inhalt des Webservers aus dem Staub machen. Gut für Wikileaks (Datenhändler, etc), allgemein schlecht für die Firma.
Des Weiteren sind leider auch von öffentlichen Scripten derartige Zugriffe möglich (Teilweise durch Blind-SQL-Injection), die wir hier nicht veröffentlichen wollen.

3.
XSS-Attacken sind schon im Loginfeld möglich. Jeder Phisher freut sich über sowas!

4.
Verzeichnisrechte durch den Nutzer auf „Lesen Schreiben Ausführen, für Besitzer, alle Gruppe und sonstige“ setzen zu lassen, ist das absolut fahrlässigste was ein Admin verlangen kann. Perfekte Brutstätte für Rootkits und Malware.

5.
phpini.php: Serverinfos zum Nulltarif und so einfach zu bekommen. Darüber haben wir uns sehr gefreut. Macht die Anwendung von MySQL\'s INTO OUTFILE wieder zum Kinderspiel.

6.
Passwörter im Klartext in der Datenbank zu speichern ist ebenfalls sehr hilfreich für den Angreifer. Jeder Datenschützer wird sich außerdem sehr drüber freuen.

7,8,10,11 ....

Fazit:
Das Superwebmailerscript und die SuperMailingList sind ein reines Datenleck. Von Außen ist es jedem Angreifer möglich an die Daten zu gelangen. Im schlimmsten Falle kann durch die Sicherheitslücken der komplette Webserver gekapert werden. Wir raten daher allen Kunden von einer Verwendung und insbesonderen vorerst von einem Kauf ab!

Wir hoffen, dass wir trotz dieser offenen Art weiterhelfen konnten.

MP0
Antworten