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.