Aufdecken eines Gewirrs von Schwachstellen auf Websites

Nach meinem ersten Artikel auf codeby, der in die Top 3 der Woche aufgenommen wurde, war ich sehr motiviert, den nächsten zu schreiben. In der 11. Klasse ist die Freizeit für die Vorbereitung auf die Prüfung und die Olympiaden jedoch eingeschränkt. Deshalb schreibe ich die zweite erst nach ein paar Monaten, nachdem ich alle Olympiaden verlassen habe .

In dieser Veröffentlichung wird über einen interessanten Fall gesprochen, in dem eine auf einer Ressource gefundene Sicherheitsanfälligkeit dazu führte, dass sie auf mehreren anderen Websites gefunden wurde.

Anfang

Alles begann mit der Überprüfung der Website eines großen Herstellers geschmiedeter Produkte. Das persönliche Konto des Benutzers war nicht vorhanden und der Suchbereich für Sicherheitslücken war nicht zu umfangreich.

Beim Testen des Bestellformulars wurden eine Reihe von Schwachstellen darin entdeckt.
Erstens ist dies ein ziemlich standardmäßiges gespeichertes XSS in den Daten des Käufers, mit dem sich dieses Gewirr dehnte. XSS ist Standard, und das Fehlen einer "httponly" -Flagge in einem Cookie war eindeutig nicht Standard. Oft habe ich Cookies von verschiedenen Websites erhalten, aber nie eine Autorisierung erhalten, und ich begann zu bezweifeln, dass es in der Natur Websites gab, die nicht das "httponly" -Flag verwendeten, da deren Verwendung das Risiko von XSS-Angriffen erheblich verringert. Umso überraschender war es, eine solche Veranstaltung auf dem Gelände eines großen Unternehmens zu treffen. Aber wie sich herausstellte, war der Service, der dieses Versehen ermöglichte, viel größer als ich erwartet hatte. Aber dazu später mehr.

Ich habe die empfangenen Cookies ersetzt und mich im crm-Konto des Site-Systems angemeldet (ich konnte nicht widerstehen, zum ersten Mal hatte ich so viel Glück). Die Rechte waren nicht admin, aber sie reichten aus, um auf Statistiken zu Bestellungen zuzugreifen, einschließlich und Kundendaten.



Ich habe Screenshots gemacht, um das Vorhandensein einer Sicherheitsanfälligkeit zu beweisen, und einen Bericht gesendet. Mehr als eine Woche verging und ich wartete nicht mehr auf eine Antwort. Laut Statistik können Sie diese vergessen, wenn Sie nicht innerhalb von drei Tagen beantwortet werden. Aber nach 8 Tagen kam eine unerwartete Antwort. Und noch mehr, sie waren die ersten, die mich für die gefundene Sicherheitslücke bezahlt haben.



Als ich zum Testen des Bestellformulars zurückkehrte, fand ich dort auch eine iDOR-Sicherheitsanfälligkeit, mit der Sie den Bestellpreis ändern können, indem Sie die Parameter "json_order [0] [price]" und "json_order [0] [total]" in der POST-Anfrage domain.ru/shop.php bearbeiten . Das Ersetzen des Bestelllinks in derselben Anforderung im Feld json_order [0] [href] führte zu einer RFI.

Es wurde keine Antwort auf die Nachricht über neue Funde erhalten ...

Fortsetzung

An diesem Standort stellte sich heraus, dass das System nicht selbst geschrieben war, sondern von einem bekannten Dienst zur Zahlung bereitgestellt wurde. Nach ihrem Fehler mit dem Cookie war es logisch anzunehmen, dass es andere Schwachstellen geben würde.

Wenn das von mir über das Bestellformular gesendete Skript funktioniert hat, gab es keine Feldvalidierung sowohl auf der gewünschten Site als auch im crm-System. x2. Nachdem ich ein Testkonto erhalten hatte, suchte ich zunächst nach Feldern, die für xss anfällig sind.

Nach langen Fahrten durch das umfangreiche crm-System wurden mehr als ein Dutzend Felder mit unzureichender Validierung identifiziert. Irgendwo konnte man das Skript-Tag direkt einfügen, irgendwo musste man Inline-Skripte vom Typ "onmouseover = alert ()" verwenden. Außerdem war es an einigen Stellen möglich, ein Skript einzubetten, aber an einigen Stellen frage ich mich, von welcher Logik sie geleitet wurden, und fügte an einigen Stellen Filter hinzu, an anderen nicht? Unter dem Gesichtspunkt des logischen Zwecks der Felder sah ich kein Muster. An einigen Orten, an denen fast jeder nicht hingehen wird, hat alles gut funktioniert, aber sie haben sich beispielsweise nicht die Mühe gemacht, den Namen der Gegenpartei zu filtern.

Die meisten gefährdeten Felder konnten nicht extern beeinflusst werden. Sie könnten nur von Mitarbeitern verwendet werden, um ihre Rechte im System zu verbessern, was ebenfalls wichtig ist.

Mit xss war es vorbei, es war möglich, auf interessantere Dinge überzugehen.

Ich habe noch nie nach CSRF-Schwachstellen gesucht. Die von mir getesteten Websites gehörten nicht zu der Klasse, für die sie Phishing verwenden würden. Daher wollte ich mich oder die Eigentümer von Websites nicht mit Schwachstellen belästigen, die niemals gegen sie verwendet werden würden. Es war ein radikal anderer Fall. Dieses crm-System war beliebt, es wurde auch von großen Online-Shops verwendet, und es bestand die Möglichkeit, Kassen von Offline-Verkaufsstellen anzuschließen, was das Sicherheitsproblem noch wichtiger machte.

Überraschenderweise gab es keinen Schutz gegen CSRF. Es war möglich, Anfragen zu senden, Überprüfungen wurden nirgendwo durchgeführt.
- Kontoinformationen ändern? - bitte
- Namen und Preis der Ware ändern? - Keine Frage

Gleichzeitig enthielten Cookies etwas, das als "csrftoken" bezeichnet wurde.

Dann dachte ich immer noch, was bringt es, das csrf-Token in Cookies zu setzen? Beim Googeln habe ich herausgefunden, dass es eine recht bequeme Möglichkeit gibt, sich mit einem Token in Cookies vor CSRF zu schützen und es in einer Post-Anfrage zu duplizieren, in der Sie das Token nicht auf dem Server speichern müssen. Weitere Details hier .

In unserem Fall wurde jedoch nur die Hälfte der Arbeit erledigt, das Token wurde in Cookies abgelegt und es fehlte bei Anfragen an den Server. Darüber hinaus hat das vollständige Entfernen von Cookies nichts geändert. Warum wurde es hinzugefügt?

In Verbindung mit dem entdeckten csrf erhält unser xss, das zuvor von außen nicht zugänglich war, ein zweites Leben. Schließlich müssen wir nicht in unser Konto gelangen, um anfällige Felder zu bearbeiten.

Durch Ersetzen des MIME-Typs der Datei war es außerdem möglich, beliebige Dateien auf den Server hochzuladen. Aber der Server wurde korrekt konfiguriert und PHP-Skripte wurden dort nicht ausgeführt.

Weiter interessanter. Alle Daten zu Waren, die der Online-Shop entnommen hat, stammen von crm. Das heißt, Name, Beschreibung, Foto. Der Link zum Produktbild lautete "yyyy.domain.ru/file/get/id=xxx". Damit der Online-Shop Bilder aufnehmen kann, muss er über Leserechte für alle verfügen. 122.

Nachdem ich die Pfade überprüft hatte, auf denen andere, privatere Dateien gespeichert sind, sah ich dieselbe URL. Es scheint nicht überraschend, dass sie wahrscheinlich andere Zugriffsrechte haben. Nicht niedriger als 022 definitiv. Die Realität sah jedoch etwas anders aus, sie hatten auch freien Zugang für nicht autorisierte Benutzer.

- Haben Sie den Import von Bestelldaten in eine Exel-Datei angefordert? - Großartig, jetzt kann es jeder herunterladen.

Vielleicht sah es so aus wie "yt5bjFb54hb # HJ% $ p" und gab nicht der brutalen Gewalt nach? Auch nicht. Alle ID-Dateien hatten ein numerisches Format und lagen im Bereich von mehreren tausend. Schutz vor Brutus habe ich auch nicht bemerkt. Nachdem alle IDs von 1 bis 10000 Hindernissen gescannt wurden, trafen sie sich nicht. Noch mehrmals wiederholt, war niemand an solchen Aktivitäten interessiert.

Sie beantworteten meinen Bericht in 3 Tagen.

In Bezug auf das Fehlen einer Flagge sagte httponly, dass es fehlte "Anscheinend vor langer Zeit, seit die PHP-Version aktualisiert wurde." Am selben Tag eingeschaltet.

Laut xss sagten sie, dass jeder weiß, dass der Filter zu Beginn des Sommers ausgeschaltet war (zu diesem Zeitpunkt war es bereits August). Dies erklärt natürlich nicht, warum irgendwo gefiltert wurde, aber nicht irgendwo, aber tun wir so, als hätten wir dies nicht bemerkt Inkonsistenz. Sie versicherten auch, dass der Filter in ein paar Tagen gestartet wird. In der Tat stellte sich heraus, dass in ein paar Monaten. Aber hier verstehe ich sie perfekt: Ich hatte auch vor, mich in ein paar Tagen auf die Prüfungen vorzubereiten ...

Das Hochladen beliebiger Dateien auf den Server war für sie von geringer Bedeutung, da sie nicht auf dem Server ausgeführt werden, sodass Sie sich keine Sorgen machen müssen. Erst zum Zeitpunkt des Schreibens des Artikels hatte ich eine Idee, ob eine Site, die sich bereits auf einem anderen Hosting als crm befindet, versucht, ein Image des Produkts für die Storefront zu erstellen, aber ein PHP-Skript erhält. Wird es ausgeführt? Oder wird es aufgrund der Tatsache, dass es für das img-Tag vorgesehen ist, nur als Bild verarbeitet? Oder hängt es von den Servereinstellungen ab? Bitte antworten Sie sachkundigen Personen.

Die Reaktion auf den CSRF-Bericht erwies sich als recht interessant. Sie antworteten mit einer Frage: "Was halten Sie für ein Token zum Schutz vor CSRF-Angriffen?" Wirklich, wovon rede ich?



Sie sagten über den freien Zugriff auf Dateien, dass sie diesen Moment nicht berücksichtigt hätten. Sofort geschlossen.

Ich muss sagen, dass dies das einzige Mal war, dass ich wirklich eine Geldbelohnung erwartet habe. Die Seite ist groß, außer crm gibt es noch kein bezahltes Projekt. Beliebtes Online-Magazin. Aber er erhielt nur verbale Dankbarkeit.
Ich muss ihnen danken, ich wurde noch ruhiger in der Frage der Zahlung. Arbeit aus Dankbarkeit in irgendeiner Form wird letztendlich zu nichts führen. Sie werden sich an Lob und andere Ehrungen gewöhnen und sie werden aufhören, Befriedigung zu bringen. Und wenn Sie alles für sie getan haben, geht die Bedeutung von etwas verloren. Und Sie können nicht die Freude am Prozess Ihrer Tätigkeit verlieren, neue Probleme lösen und etwas Neues schaffen. Arbeiten Sie für die Arbeit, egal wie banal es klingt. Die Arbeit, bei der man nicht merkt, wie die Stunden vergehen, wie die Sonne es geschafft hat, nicht nur über den Horizont hinauszugehen, sondern dadurch wieder aufzusteigen.

'' '
Wir sind zufrieden mit kleinen, Glück ist nicht in großen Geld
"Tu was du liebst" - in unseren Kreisen geschätzt
'' '© Kolya Manyu - Jeden Tag

Ende

Im technischen Support der vorherigen Site wurde das Ticketempfangssystem UserEcho eines Drittanbieters verwendet. Ich habe es nicht versäumt, es zu überprüfen. In Träumen war es natürlich möglich, private Tickets zu lesen. Das ist mir natürlich nicht gelungen. Ich musste mich mit wenig zufrieden geben.



Beim Testen der API, die mit Tickets arbeitet, wurden zunächst keine Anomalien festgestellt, das Recht, nicht in die eines anderen zu schauen, es nicht zu abonnieren, war nicht möglich. Bei weiteren Untersuchungen der Website stellte sich jedoch heraus, dass die Entwickler einen kleinen Fehler gemacht hatten.
Im Profil finden Sie einen Abschnitt zum Verwalten Ihrer Tickets, in dem diejenigen aufgeführt sind, die Sie abonniert haben oder die Sie zuvor abonniert haben.



Wenn wir eine Anfrage zum Abbestellen des Tickets einer anderen Person senden, werden wir wie erwartet darüber informiert, dass wir keine Rechte an dieser Aktion haben. Gleichzeitig ist es in unserer Liste der Tickets enthalten, als eines derjenigen, für die wir zuvor abonniert wurden. So haben wir die Möglichkeit, den Namen und die URL des Formats "ticket_name_name_in_translate" herauszufinden. Dieser Schaden trug natürlich keinen. In sehr seltenen Fällen wird es möglich sein, aus dem Namen etwas Wichtiges und Wertvolles zu lernen. Aber es war besser, als überhaupt nichts zu haben.

Nach ein paar Wochen wurde der Fehler behoben.

Ich danke allen, die bis zum Ende gelesen haben!