1. Blog
  2. pentesting
  3. Pentesting Stories: Can I get a Quote?

Pentesting Stories: Can I get a Quote?

 

Blog by: Paul van der Haas, Security Specialist, SecureLink Netherlands

Als vernünftiger Pentester hat man eine Standard-Checkliste um Privilege Escalations auf die Spur zu kommen. Es gibt zu dem Thema zahllose Seiten. Fuzzy Security ist beispielsweise eine davon.

Ein Punkt, den man praktisch immer auf dieser Liste findet, ist eine einfache Suche nach Service-Pfaden, die nicht korrekt in Anführungszeichen gesetzt wurden. Besonders Dienste, die ein Leerzeichen im BinaryPathName enthalten, bieten einen einfachen Ansatzpunkt für die unerlaubte Ausweitung von Rechten. Ein simples Beispiel:

C:\Program Files(x86)\tool\tool.exe

Haben Sie das unschuldige kleine Leerzeichen zwischen ‘Program’ und ‘Files’ bemerkt? Außerdem steht der Pfad nicht in entsprechenden Anführungszeichen (“”). Wenn der Service Control Manager (SCM) den Dienst startet, behandelt er den Pfad-Wert zunächst als Kommando und versucht ihn auszuführen. Anführungszeichen würden Windows verraten, welcher Teil der tatsächliche Pfad der ausführbaren Datei ist, und welcher Teil zusätzliche Kommandozeilen-Parameter enthält (wenn vorhanden).

Pfade ohne Anführungszeichen

In Abwesenheit von Anführungszeichen betrachtet Windows ein Space als Trennzeichen. Zuerst wird also der Pfad C:\Program geparst und automatisch nach einer ausführbaren Datei dieses Namens gesucht, etwa C:\Program.com, C:\Program.exe, C:\Program.bat oder dergleichen. Die Ambivalenz durch die fehlenden Anführungszeichen verursacht also, dass anstatt der im Pfad gemeinten Datei ein völlig anderes Programm mit entsprechendem Namen direkt ausgeführt kann, wenn sie existiert.

Um das auszunutzen, muss eine Datei (z.B. mit dem Namen “Program.exe”) unter C:\ erstellt werden. Der Zugriff auf C:\ ist für gewöhnlich eingeschränkt, was meistens bedeutet, man muss bereits Admin-Rechte haben. Eine weitere Option wäre es aber auch, sich physischen Zugang zum System zu verschaffen. Vorausgesetzt es ist keine Festplattenverschlüsselung eingerichtet, kann man in solchen Fällen z.B. den Rechner unter Umgehung von Windows mit einem alternativen Betriebssystem wie der Linuxdistribution Kali direkt von einem USB-Stick aus starten und eine Datei auf C:\ platzieren.

Ist man bereits Administrator gibt es natürlich weit bessere Optionen um sich ‘NT AUTHORITY\SYSTEM’-Rechte zu verschaffen. Und physischen Zugang zu einem System ohne Festplattenverschlüsselung zu bekommen ist in der Regel ein größeres Problem als sich ‘NT AUTHORITY\SYSTEM’-Rechte zu erschleichen.

Willkommen in der Wirklichkeit

Vor Kurzem haben meine Kollegen und ich eine Workstation untersucht und uns dabei durch die oben erwähnte Checkliste gearbeitet. Überraschenderweise fanden wir tatsächlich zwei Dienste mit Pfaden, bei denen die Anführungszeichen fehlten. Da wir physischen Zugang zu dem System hatten und keine Festplattenverschlüsselung aktiv war, konnten wir dieses Eingangstor nutzen, um uns ‘NT AUTHORITY\SYSTEM’-Rechte zu holen.

Während der Reproduktion dieser Schwachstelle in meiner lokalen virtuellen Windows 10 Instanz (vollständige Installation) wurde das folgende Resultat zurückgeliefert:

microsoft-vulnerability-pentest

Bedeutet das etwa, dass es Windows 10 Features gibt, deren Dienstpfade nicht in Anführungszeichen stehen?

Oh ja, genau das bedeutet es!

Natürlich habe ich sofort einen Report an das Microsoft Security Response Center (MSRC) geschrieben. Es folgt ein Auszug aus dem Report.

Beschreibung:

Die ‘Wms’ und ‘WmsRepair’ Dienste werden lokal ausgeführt und enthalten Dienstpfade ohne Anführungszeichen. Dies kann für eine Privilege Escalation missbraucht werden. Durch die Platzierung einer Datei “Program.exe” unter C:\ kann beliebiger Code mit SYSTEM-Rechten ausgeführt werden.

Um die Schwachstelle auszunutzen benötigt der Angreifer entweder lokale Administratorrechte oder physischen Zugang zum System.

Es folgt ein Proof-Of-Concept für einen der verwundbaren Dienste:

Dienst ‘WmsRepair’ (beachten Sie, dass der Dienst als SYSTEM ausgeführt wird und automatisch startet):

microsoft-vulnerability-pentest

Schritte zum Exploit:

  1. Eine beliebeige Code Payload erstellen und als ‘Program.exe’ speichern
    msfvenom -p windows/x64/exec cmd=’cmd.exe /c net user Elevation Elevate2019! /add && net localgroup Administrators Elevation /add’ -f exe > Program.exe
  2. Payload (Program.exe) in ‘C:\’ speichern (als lokaler Admin)

microsoft-vulnerability-pentest

3) Den Dienst ‘Windows MultiPoint Server’ (Wms) starten

microsoft-vulnerability-pentest

Erwartetes Resultat:

Program.exe sollte nicht gestartet werden.

Beobachtetes Resultat:

Der Dienst startet Program.exe als ‘SYSTEM’. Die payload wird ausgeführt und ein neuer lokaler Administrator erblickt das Licht der Welt:

microsoft-vulnerability-pentest

Empfehlung:

Es wird dringend nahegelegt, Dienste automatisiert auf fehlende Ausführungspfade zu überprüfen. Fügen sie Anführungszeichen am Anfang und Ende eines Pfades ein.

Ist das echt Spannend?

Eine neue “Schwachstelle” zu finden ist immer aufregend! Sie haben allerdings möglicherweise bemerkt, dass diesmal das Wort Schwachstelle in Anführungszeichen steht. Die Entdeckung wurde an Microsoft weitergeleitet. Doch deren Antwort war die folgende:

Danke für Ihren Report. Unser Team konnte das Verhalten bestätigen, allerdings unterschreitet dieser Vorgang unsere Schwelle für die Behebung in einem Sicherheitsupdate. Stattdessen werden wir uns diesem Problem möglicherweise in einer künftigen Version von Windows widmen, daher schließen wir diesen Fall.

Der Exploit setzt voraus, dass der Angreifer Administratorrechte hat, was die Wahrscheinlichkeit einer erfolgreichen Attacke reduziert. Es gibt schon seit Jahren einen Blogartikel in dem detailliert erklärt wird, warum wir Probleme mit Dienstpfaden nicht priorisieren: https://blogs.msdn.microsoft.com/aaron_margosis/2014/11/14/it-rather-involved-being-on-the-other-side-of-this-airtight-hatchway-unquoted-service-paths/

Das Problem wird also als geringfügiges Risiko eingeschätzt. Sollten wir demnach aufhören, darauf überhaupt zu testen? Ganz entschieden: Nein! Immerhin lässt dieses Problem auf einen eklatanten Mangel an Qualitätskontrolle und sicherem Programmdesign schließen und damit auch auf weitere, möglicherweise einfachere, Pfade der illegitimen Rechteausweitung.

Prinzipiell stimmt natürlich, dass dieses Problem nicht unbedingt eine hochrisiko-Bewertung verdient. Wie einer meiner Kollegen meinte (ich weiß, so sollte man das eigentlich nicht formulieren): Bei denen brennt der Hut wohl an anderen Stellen.

Weitere spannende Pentesting-Stories und zusätzlich interessante Einblicke in die Angriffslage finden Sie im Annual Security Report den Sie hier kostenlos herunterladen können!

Share