Support WebsiteBaker
Recent Posts31
Hilfe & Support (deutsch) / Re: Cross Site Scripting Vulnerability - Meldung über OpenBugBounty
« Last post by sternchen8875 on June 03, 2025, 01:56:07 PM »
Natürlich wird deine Meldung diskutiert und ich muß sagen, ich teile nicht unbedingt die Meinungen meiner Kollegen.
Open Bug Bounty ist keine Fake-Seite und die Researcher sind keine Abzock-Gängster - jede Meldung von denen hat eine gesunde Basis, das heißt: die Möglichkeiten, die bis dahin gefunden wurden, existieren wirklich.
Wie wird da gearbeitet?
Nehmen wir den Khan, der deinen 2. Report erstellt hat. Der macht an guten Tagen zwischen 200 und 1000 solcher Reports. Gestern waren es 1091 Reports zu fast ausschließlich de-Domains, darunter auch große, bekannte Seiten wie giga.de. Hat er keine Zeit oder keinen Bock, macht er auch mal nichts. Hat er einen Treffer, wird das im Portal gemeldet und gegengeprüft. Teil solcher Meldungen sind genaue Angaben, welche Webadresse, welche Form des Angriffes, welcher Exploit-Code. Mit diesen Angaben ist es in zwei Minuten nachgestellt, ob die Meldung korrekt ist. Und dann geht die Meldung an den Inhaber raus, also wie hier an dich.
Nun hat man je nach Wichtigkeit eine Zeitspanne, mal 2 Wochen, mal 3 Monate, um selbst zu suchen oder jemanden zu beauftragen, die Schwachstelle zu finden und zu korrigieren.
alternativ kann man auch den Researcher fragen, der dir gern seine Bankdaten mitteilt. Der gute Khan gibt in seinem Profil an, zwischen 200 und 1000 US$ zu erwarten.
Das mag viel sein, setzt man aber einen Insider ran, braucht der sicher ein paar Tage und kostet dann entsprechend. Glaubt man den Profilangaben, ist Google Großkunde und zahlt auch schon mal 7500 US$ pro Meldung
Nun denkt man sich vielleicht, zwischen 200 und 1000 Meldungen pro Tag x (im Durchschnitt) 250 US$ - da kommt etwas zusammen, ist aber nicht so. Bei den meisten Website-Betreibern landet es im Spam, ein weiterer Teil ignoriert es und ein noch weiterer Teil hofft, es selbst zu finden. Die "Coolen" warten einfach ab, wird schon nix passieren bis dahin. Am Ende melden sich zwei bis vier im Monat beim Khan und die Hälfte davon legt auf, wenn es ums Geld geht.
Je nachdem, in welche Stufe der Report eingeordnet ist, läuft dann der Zeitraum bis zur Veröffentlichung. In aller Regelmäßigkeit wird dann kontrolliert, ob die Schwachstelle schon behoben wurde. Falls ja, wird die Schwachstelle in den gängigen Portalen veröffentlicht analog zum o.g. Report, allerdings nicht auf die spezielle Webadresse bezogen, sondern auf das verwendete System, hier also WB. Diese Veröffentlichung erfolgt i.d.R 30 Tage nach Feststellung, das ein Patch erfolgt ist.
Ist kein Patch erfolgt, dann nach Ablauf der genannten Frist, aber anonymisiert.
Mich stören diese 30 Tage. Grobe Schätzungen gehen von über 200.000 Webseiten aus, die weltweit mit WB erstellt wurden und heute noch aktiv gepflegt werden. In Deutschland zählbar etwa 64.000. Ich habe im letzten Jahr über 100 Updates für User und Kunden gemacht, von denen die neueste Version eine WB 2.10.0 war, alles andere war älter.
Selbst, wenn diese Schätzungen viel zu hoch wären, kann man innerhalb von 30 Tagen niemals alle erreichen und schon garnicht Leute, die immernoch auf eine Version 2.8.x setzen.
Eine solche WB 2.8.1 läuft ja im Frontend immernoch in den meisten Fällen, vorallem, wenn man dort nur die üblichen Standard-Module Wysiwyg, Form und News verwendet.
ein paar Punkte aus deinem Post
Die Frage ist immer, was kann ich an solche Links https://meine-url.de/?id=2738 noch an Parametern mitgeben. Allerdings würde mir solch ein Link schon mal die Suche nach der richtigen page_id sparen
Mal ein Beispiel eines alten Exploids, den du auf jeder Erklärseite findest und das einmal erklärt, wie es funktioniert und dann, wie es verwendet wird
Du hast eine Liste, die mit TARGETS gefüllt wird. Das TARGET ist eine Website-Url und die Liste kann durchaus dynamisch sein. Heißt: der Reporter kommt auf meine Seite, liest dort alle externen Links aus, filtert diese auf Domains und trägt jede Domain als TARGET ein. Auf dieser Targetseite dann das Gleiche in grün, Links auslesen, Domains filtern, Targets übernehmen. Ist nix Verbotenes, macht Google jeden Tag, diverse Link-Checker-Tools auch.
Nun gibt es den wohl bekanntesten Exploit
Dann läuft ein Batchscript, das unser eingelesenes Target mit dem Script zusammenfügt
Wer nun versiert ist und z.b. solch Researcher, wird diverse andere Parameter haben, die er im Batchscript der Reihe nach durchtestet. Und dann kann man im WorstCase die komplette Datenbank auslesen oder auch nur die Zugangsdaten ändern.
Mehr ins Detail kann man hier garnicht gehen, vorallem, wenn man, wie ich, davon ausgeht, das die Bug Bounty-Meldung echt ist
Wenn ich dann sehe, das der gute Khan mal eben fast 1100 Seiten meldet, von denen mindestens 1050 eine de-Domain sind, dann scheint er ein DE-Fan zu sein, lebt hier oder sieht hier den Markt, z.b. weil es ihm vielleicht zu leicht gemacht wird.
WB ist eines der CMS mit sehr wenigen solcher Meldungen, die letzte große war in 2017 und betraf die Frontend-Registrierung. In einer weiteren Meldung aus ebenfalls 2017 ging es um den PHPMailer, der aber nahezu alle CMS betraf, weltweit.
Open Bug Bounty ist keine Fake-Seite und die Researcher sind keine Abzock-Gängster - jede Meldung von denen hat eine gesunde Basis, das heißt: die Möglichkeiten, die bis dahin gefunden wurden, existieren wirklich.
Wie wird da gearbeitet?
Nehmen wir den Khan, der deinen 2. Report erstellt hat. Der macht an guten Tagen zwischen 200 und 1000 solcher Reports. Gestern waren es 1091 Reports zu fast ausschließlich de-Domains, darunter auch große, bekannte Seiten wie giga.de. Hat er keine Zeit oder keinen Bock, macht er auch mal nichts. Hat er einen Treffer, wird das im Portal gemeldet und gegengeprüft. Teil solcher Meldungen sind genaue Angaben, welche Webadresse, welche Form des Angriffes, welcher Exploit-Code. Mit diesen Angaben ist es in zwei Minuten nachgestellt, ob die Meldung korrekt ist. Und dann geht die Meldung an den Inhaber raus, also wie hier an dich.
Nun hat man je nach Wichtigkeit eine Zeitspanne, mal 2 Wochen, mal 3 Monate, um selbst zu suchen oder jemanden zu beauftragen, die Schwachstelle zu finden und zu korrigieren.
alternativ kann man auch den Researcher fragen, der dir gern seine Bankdaten mitteilt. Der gute Khan gibt in seinem Profil an, zwischen 200 und 1000 US$ zu erwarten.
Das mag viel sein, setzt man aber einen Insider ran, braucht der sicher ein paar Tage und kostet dann entsprechend. Glaubt man den Profilangaben, ist Google Großkunde und zahlt auch schon mal 7500 US$ pro Meldung
Nun denkt man sich vielleicht, zwischen 200 und 1000 Meldungen pro Tag x (im Durchschnitt) 250 US$ - da kommt etwas zusammen, ist aber nicht so. Bei den meisten Website-Betreibern landet es im Spam, ein weiterer Teil ignoriert es und ein noch weiterer Teil hofft, es selbst zu finden. Die "Coolen" warten einfach ab, wird schon nix passieren bis dahin. Am Ende melden sich zwei bis vier im Monat beim Khan und die Hälfte davon legt auf, wenn es ums Geld geht.
Je nachdem, in welche Stufe der Report eingeordnet ist, läuft dann der Zeitraum bis zur Veröffentlichung. In aller Regelmäßigkeit wird dann kontrolliert, ob die Schwachstelle schon behoben wurde. Falls ja, wird die Schwachstelle in den gängigen Portalen veröffentlicht analog zum o.g. Report, allerdings nicht auf die spezielle Webadresse bezogen, sondern auf das verwendete System, hier also WB. Diese Veröffentlichung erfolgt i.d.R 30 Tage nach Feststellung, das ein Patch erfolgt ist.
Ist kein Patch erfolgt, dann nach Ablauf der genannten Frist, aber anonymisiert.
Mich stören diese 30 Tage. Grobe Schätzungen gehen von über 200.000 Webseiten aus, die weltweit mit WB erstellt wurden und heute noch aktiv gepflegt werden. In Deutschland zählbar etwa 64.000. Ich habe im letzten Jahr über 100 Updates für User und Kunden gemacht, von denen die neueste Version eine WB 2.10.0 war, alles andere war älter.
Selbst, wenn diese Schätzungen viel zu hoch wären, kann man innerhalb von 30 Tagen niemals alle erreichen und schon garnicht Leute, die immernoch auf eine Version 2.8.x setzen.
Eine solche WB 2.8.1 läuft ja im Frontend immernoch in den meisten Fällen, vorallem, wenn man dort nur die üblichen Standard-Module Wysiwyg, Form und News verwendet.
ein paar Punkte aus deinem Post
Quote
Meine Webseite ist bei Strato gehostet, wo (angeblich) auf Schadcode & Co. gescannt und geprüft wirdNicht angeblich, das wird in der Tat gemacht. Hier geht es darum, was an Code in den Dateien steht, die du auf den Server gebracht hast, und um Dateien, die sich von Croncheck zu Croncheck ändern. Es geht aber nicht um XSS oder Exploits. In jeden erdenklichen Dateityp kannst du heute Schadcode verstecken, egal, ob PDF, JPG oder XLS, in den ausführbaren Dateien sowieso
Quote
Der Zugang zum Backend ist mit htaccess abgesichertwürde wenig nützen, wenn es im Frontend einen Zugang gibt, der es möglich macht, Datenbank und/oder Zugänge auszulesen. Bei dir ist es schon mal vor Zugriffen geschützt, woanders wäre schon die Frage, ob jede Datei im Backend auch in die Prüfmechanismen der Seite eingebunden ist. Bei den WB-Core-Dateien für das Backend wird z.b. gecheckt, ob das Backend auch aktiv ist und ob du angemeldet bist.
Quote
Ziel des Codes ist es, dass man statt der komplizierten URL auch einfach die Seiten-ID an die Basis-URL hängen kander Code selbst ist nicht gefährlich und bietet kein offenes Tor. WB arbeitet ja generell nur über die Page-ID, egal, ob Front- oder Backend. Da Suchmaschinen und auch die Nutzer selbst aber lieber "sprechende Links" haben wollen, werden im Frontend über diese Page-ID dann z.b. der Link ersetzt und bei einem Link dann die dazugehörige Page-ID gesucht und über diese weitergearbeitet, z.b. welche Sectionen gibt es zu dieser Page-ID und welche Inhalte dann zu diesem Sections-Type mit dieser Page-ID.
Die Frage ist immer, was kann ich an solche Links https://meine-url.de/?id=2738 noch an Parametern mitgeben. Allerdings würde mir solch ein Link schon mal die Suche nach der richtigen page_id sparen
Mal ein Beispiel eines alten Exploids, den du auf jeder Erklärseite findest und das einmal erklärt, wie es funktioniert und dann, wie es verwendet wird
Du hast eine Liste, die mit TARGETS gefüllt wird. Das TARGET ist eine Website-Url und die Liste kann durchaus dynamisch sein. Heißt: der Reporter kommt auf meine Seite, liest dort alle externen Links aus, filtert diese auf Domains und trägt jede Domain als TARGET ein. Auf dieser Targetseite dann das Gleiche in grün, Links auslesen, Domains filtern, Targets übernehmen. Ist nix Verbotenes, macht Google jeden Tag, diverse Link-Checker-Tools auch.
Nun gibt es den wohl bekanntesten Exploit
Code: [Select]
<script>alert('XSS')</script>Der erstellt über JS ein kleines Alarm-Fenster, in dem nur XSS steht. Der Code selbst ist überhaupt nicht schädlich, das erscheinende JS-Popup würde aber zeigen, das hier solcher Art Zusatzparameter möglich sind.Dann läuft ein Batchscript, das unser eingelesenes Target mit dem Script zusammenfügt
Code: [Select]
http://{TARGET}?id=2738"><script>alert('XSS')</script>Erscheint nun ein JS-Popup mit XSS im Text, ist die Seite anfällig. Da gibt es unterschiedliche Programmierungen. Mit diesem Code im Beispiel würde man z.b. im Backend nicht weit kommen, bei dir eh nicht, weil das Backend über htaccess geschützt ist.Wer nun versiert ist und z.b. solch Researcher, wird diverse andere Parameter haben, die er im Batchscript der Reihe nach durchtestet. Und dann kann man im WorstCase die komplette Datenbank auslesen oder auch nur die Zugangsdaten ändern.
Mehr ins Detail kann man hier garnicht gehen, vorallem, wenn man, wie ich, davon ausgeht, das die Bug Bounty-Meldung echt ist
Wenn ich dann sehe, das der gute Khan mal eben fast 1100 Seiten meldet, von denen mindestens 1050 eine de-Domain sind, dann scheint er ein DE-Fan zu sein, lebt hier oder sieht hier den Markt, z.b. weil es ihm vielleicht zu leicht gemacht wird.
WB ist eines der CMS mit sehr wenigen solcher Meldungen, die letzte große war in 2017 und betraf die Frontend-Registrierung. In einer weiteren Meldung aus ebenfalls 2017 ging es um den PHPMailer, der aber nahezu alle CMS betraf, weltweit.
