Cross Site Scripting Vulnerability - Meldung über OpenBugBounty

[VSG]

Hallo zusammen,

ich habe heute Morgen eine E-Mail bekommen von OpenBugBounty.org. Nach dem darin enthaltenen Link existiert auf meiner Seite eine Cross Site Scripting Vulnerability.

Meine WebsiteBaker-Version ist 2.13.6 r237 mit den Modulen, die im Anhang aufgelistet sind. Ich wüßte nicht, dass es diesbezüglich aktuellere Versionen gibt. Insofern vermute ich, dass die Schwachstelle auch andere WB-Installationen (und vermutlich auch ganz andere CMS-Installationen) betrifft.

Selbstverständlich gibt es keine näheren Infos zu der Schwachstelle, die mir der Finder sicher gegen Bezahlung mitteilen wird. Nur betreibe ich keine kommerzielle Seite. Alles ist privat in den letzten 20 Jahren aufgebaut, selbst bezahlt, ohne Werbung. Einen Bug-Hunter zu bezahlen ist da leider nicht auch noch drin.

Hat einer eine Idee, wie man da am besten weiter vorgeht, bzw. gibt es Tools, mit denen man eine Internetseite auf Schwachstellen testen kann?
Wie gesagt, ich denke, dass die nicht nur meine Installation betrifft und wenn ich mir die Aktivität des Bug-Hunters ansehe, hat er in den letzten Tagen buchstäblich hunderte Seiten mit einer solchen Schwachstelle gemeldet. Vermutlich wurde nur nach einem bestimmten Code gesucht und jede Seite geflaggt, die den verwendet.

Alternativ kann ich nur die Zeit bis August verstreichen lassen und dann, sobald die Schwachstelle publik gemacht wird, mich nochmal melden. Ganz wohl ist mir dabei aber nicht.

Danke im Voraus für Eure Unterstützung!
Viele Grüße

VSG

[hgs]

Danke für den Hinweis.

[sternchen8875]

Grundsätzlich muß man hier mit Antworten vorsichtig sein, weil jede Art der Antwort als Garantie gedeutet wird und man wähnt sich dann in einer Sicherheit, die vielleicht nicht vorhanden ist oder man lebt in einer Angst, die vielleicht nicht nötig ist.
Der Mailabsender selbst, also die Webseite "OpenBugBounty" ist vom Grundsatz her nicht böse. Es dient als allgemeine Ansprechstelle für Sicherheitsmeldunge n, die dann gecheckt werden, bevor sie an den Betroffenen weiter gegeben werden. Es gab also Zeiten, da konnte man sich sicher sein, das eine Mail von dort auch nix Gutes bedeutet.
Wo Licht ist, ist aber auch Schatten. Über die Jahre hat "man" festgestellt, das es ausreichend ist, einfach eine Masse an Meldungen zum selben Problem zu senden, um dort die Benachrichtigungen an den Webseitenbetreiber auszulösen, um dann später Details gegen Geld zu verraten. Und so mancher hat dann bezahlt, um zu erfahren, das die Jquery-Dateien etwas zu alt sind. Alt heißt aber nicht unbedingt gefährlich.

Spreche ich nun von WB, dann ist nur das unveränderte Original-Paket mit seinen mitgelieferten Modulen captcha_control, ckeditor, code, droplets, form, jsadmin, menu_link, news, output_filter, show_menu2, WBLingual, wrapper und wysiwyg gemeint. Hier gibt es diverse sog. "Ethical Hackers", die das Paket als solches durchchecken und im Falle eines Falles dann auch WB informieren. Desweiteren gibt es ähnliche Portale wie OpenBugBounty.org, wo wir dann auch Einsicht im Detail über die Meldungen im Detail haben und so eventuelle Sicherheitslücken schließen können, auch kurzfristig, bevor das public wird. Leider hab ich meinen Account dazu ausgerechnet heute gesperrt, weil ich mich beim Passwort mehrfach vertippt hatte. Nun muß ich auf den Support warten 

Was dort getestet wird, ist immernur ein einzelnes Projekt, im Rahmen der WB-Tests eben das Grundpaket mit den mitgelieferten Addons und den vom System zur Verfügung gestellten Möglichkeiten, z.b. mit und ohne Captcha, mit und ohne ASP usw. Da es aber über 1000 Addons für WB und seine Forks gibt, ist es nahezu unmöglich, diese auch in einem Projekt zu testen. Die meisten dieser Tests beschränken sich dann eh "nur" auf das Frontend. Ich erinnere mich aber auch an ein paar Tests im WB-Backend in Zeiten von WB 2.8.2, wo Eingabeformulare im Backend getestet wurden, Seiten, auf denen ein Backend-Zugang nötig ist

XSS ist i.d.R. die Eingabe von Code, meist JS-Code, der es dann ermöglicht, weitere Aktionen durchzuführen. Im WorstCase lassen sich so Datenbanken oder Zugänge auslesen, Inhalte verändern oder auch Webseiten umleiten. Erste und "beste" Möglichkeit bieten dabei die Adressleiste des Browsers und/oder Eingabefelder, wo der Benutzer aktiv werden kann z.B. für Kommentare, Kontaktformulare u.ä.. Eine andere Möglichkeiten sind Daten, die per GET übertragen werden, z.B. Content mit mehreren Seiten, eine Bildergalerie mit 5 Unterseiten oder News, die auf mehrere Seiten aufgeteilt werden.
Die WB-eigenen Module (Bestandteile des WB-Paketes) sind in dieser Richtung abgesichert und lassen die Ausführung solcher Codes nicht zu. Ob das aber auch von den anderen Modulen so abgesichert ist, läßt sich nicht sagen, dafür sind die Möglichkeiten einfach zu komplex.

Jetzt zu antworten, du mußt dir keine Sorgen machen, wäre sicher nicht zielführend. Andererseits sind uns da auch Grenzen gesetzt.
Mein Ansatz als Endbenutzer wäre halt, die auf diversen Blogs und Webseiten erklärten Methoden mal anzutesten mit Vorrang auf das Frontend. Es gibt auch diverse Portale, wo solch XSS-Tests gegen einen Account oder Newsletter möglich sind. Wichtig wäre halt, das du im Fall eines "Treffers" auch schnell reagierst. Das, was man in einem solchen Test an Code eingibt und ggf bis in die Datenbank gelangt, muß da direkt wieder raus, z.b. Code in Eingabefeldern von Kontaktformularen u.ä.
Und dann muß solche Code-Eingabe auch unterbunden werden. Übermittelt man z.b. die Seitenzahl der nächsten Unterseite einer Bildergalerie, muß geprüft werden, ob dieser Wert auch eine Zahl ist. Man könnte auch den Zahlenbereich vorgeben, wenn bekannt. Bei Auswahlfeldern kann man die Auswahl-Optionen vorgeben und prüfen, ob das übermittelte Zeugs auch Teil davon ist. Und Texteingaben sollte man filtern. WB macht das über die Funktion $admin->StripCodeFromText($value). Kann man es nicht selbst reparieren, dann besser diese Unterseite deaktivieren, z.b. durch die Einstellung Sichtbarkeit == keine
Und so läßt sich alles an Usereingaben prüfen. Was davon bei deiner Webseite zutrifft, mußt du wissen, starten würde ich mit Modulen, die nicht zum WB-Paket gehören

[crnogorac081]

I dont see any modules affrcted. Listing all modules points its just mass mail.

[VSG]

Danke allerseits für die Antworten.

Gestern habe ich eine neue Bug Bounty-Meldung erhalten, die wieder XSS betrifft, aber von einem anderen "Security Researcher".

@sternchen8875:
Ich hatte im Vorfeld schon nach Tests für XSS-Schwachstellen gesucht, aber nur eine frei zugängliche Seite gefunden. Das dortige Ergebnis vermag ich aber auch nicht einzuordnen.
Das ist auch mein Grundproblem: Ich bin kein Programmierer, mir fehlt schlicht das Wissen und Verständnis. Gerade deshalb bin ich ja sehr dankbar für so einfach zu bedienende Software wie WebsiteBaker.

Darum wird mir tatsächlich nichts anderes bleiben, als Ende August abzuwarten und dann die gefundene Schwachstelle hier bekanntzugeben, in der Hoffnung, dass jemand helfen kann.
Meine Webseite ist bei Strato gehostet, wo (angeblich) auf Schadcode & Co. gescannt und geprüft wird. Der Zugang zum Backend ist mit htaccess abgesichert und bis auf die genannten Module ist nichts installiert und meines Erachtens das einzig veraltete ist AnyNews. Ob das ausschlaggebend ist, kann ich nicht sagen.

Danke nochmals für die Hilfe.
Viele Grüße

VSG

PS: Eine Änderung gibt es noch, die ich bislang ganz vergessen hatte. Vor vielen, vielen Jahren hatte ich entweder über Ruud oder Dietmar folgenden Code bekommen, der in der index.php nach "$starttime = array_sum(explode(" ", microtime()));" eingefügt wird:

Code: [Select]

if(isset($_GET['id'])) {
// sanitize 'id' and move it into page_id
if( ($page_id = intval($_GET['id'])) < 1) {
// if page_id less then 1 (illegal page id's)
// delete it and set to default website request
unset($_GET['id']);
unset($page_id);
}
}

Ziel des Codes ist es, dass man statt der komplizierten URL auch einfach die Seiten-ID an die Basis-URL hängen kann, z.B. https://meine-url.de/?id=2738
Kann das eine Schwachstelle darstellen? Denn klar, kann ich ans Ende der gültigen Seiten-ID alle möglichen Zeichenfolgen hängen – die Seite wird dennoch richtig aufgerufen, aber die URL ist damit nicht mehr richtig.

[sternchen8875]

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

Meine Webseite ist bei Strato gehostet, wo (angeblich) auf Schadcode & Co. gescannt und geprüft wird

Nicht 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

Der Zugang zum Backend ist mit htaccess abgesichert

wü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.

Ziel des Codes ist es, dass man statt der komplizierten URL auch einfach die Seiten-ID an die Basis-URL hängen kan

der 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.

[sternchen8875]

Und da haben wir es schon.... passend zum Thema

Google entfernt kritische Schwachstelle in Chrome