[HackerNotes Ep. 64] .NET Remoting, CDN Attack Surface, and Recon vs Main App

Exploiting .NET Remoting, Dom Purify Bypass, JS Deobfuscation, Delivering Impactful POCs, and Cloudflares CDN-CGI: Insights from Justin and Joel

Author

gr3pme
March 29, 2024

Hacker TLDR;

Exploiting .NET Remoting

Shubs (@infosec_au) tweeted out a blog Code-white dropped with some tasty research on exploiting HTTP-based .NET remoting.

In essence, it empowers you to invoke functions and unveil objects from your code on a separate server, enabling you to execute that code remotely.

If you're not yet acquainted with .NET remoting, think of it as .NET's counterpart to Java's RMI (Remote Method Invocation). The TLDR is to allow you to invoke functions and unveil objects from your code on a different server, enabling you to execute that code remotely.

You can register these objects to be triggered remotely and you can call them over a few different protocols. One of the protocols is HTTP, but to prevent attackers from being able to instantiate arbitrary objects on a host you need to pass an arbitrary string in the URL. The string gets created when the objects are created.

If you know this string, you can access that interface and get it to instantiate objects and run code. Now, historically this was fairly protected. But this is where the research comes in - there are new methods to leak this arbitrary string via HTTP. The full research can be found here: https://code-white.com/blog/leaking-objrefs-to-exploit-http-dotnet-remoting/

The exploit essentially takes advantage of an error stack trace that happens when an error is caused during the flow. The error inadvertently leaks the URL that you need to be able to hit .NET remoting via HTTP.

How it does this is by abusing a trusted object which you can overwrite via an HTTP request in a header. You can set the __RequestVerb header which will override the request method being processed on this trusted object.

This subsequently creates a mismatch during processing which causes an error which will dump the object reference URL.

DOM Purify Bug - Type Confusion

You don’t commonly hear about bugs in Dom Purify, but today is an exception. DOM purify was hit by a type of type confusion-esque bug, and if you’re a regular listener of the pod or reader of HackerNotes, you’ll probably be familiar with this type of bug. Let's jump in.

So, in DOM Purify you can pass in a string of HTML or you can pass in an actual object reference, such as Object.createElement. If you pass that object reference to DOMPurify sanitise, it will perform the same operation.

One of the interesting things here is when DOM Purify converts the input to element nodes, it also can convert and sanitize XML as well as HTML. What this researcher found, is essentially a confusion between HTML and XML contexts.

To achieve this confusion, it involves the use of specially crafted XML processing instructions. XML processing structures are essentially additional metadata you can pass to an XML document to instruct how it’s processed.

The payload to achieve such confusion, taken from the blog, is shown below: 

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "<http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd>"><svg id="slonser" xmlns="<http://www.w3.org/2000/svg>"><?xml-stylesheet > <img src=x onerror="alert('DOMPurify bypassed!!!')"> ?></svg>

I highly recommend checking out the full blog on this, it’s some quality research by Slonser. You can find the full writeup here: https://blog.slonser.info/posts/dompurify-node-type-confusion/

A fix has been implemented but it has since been bypassed. Keep an eye out for a few more bypasses by the community in the next few weeks.

CloudFlare /cdn-cgi/

If you’ve encountered a CloudFlare-protected target before you might have seen the /cdn-cgi/ endpoint kicking around. Cloudflare injects /cdn-cgi/ on every website to support functionality such as captchas, login endpoints and other things.

CloudFlares documentation states a few examples of the endpoint is used for:

There was a fair amount of research on the endpoint around 2017, including some cool CSP bypasses and some research from PortSwigger:

Sometimes, however, CDNs are reverse proxied on the same host - so say instead of having cdn.target.com, they will instead implement target.com/cdn and use the /cdn path to reverse proxy all traffic to the CDN instead.

In some cases, if you can upload to the CDN, you can access the uploaded file from the target, ie target.com/cdn/uploadedfile . The security implications of this can be massive, ranging from XSS and reverse proxy-based bugs such as secondary context path traversals and so on.

Unfortunately, Justin’s digging fell flat upon discovering a watertight CSP, so if you have any cool research relating to the /cdn-cgi endpoint, drop it in the Critical Thinking Discord channel!

Dealing With JS Obfuscation

XSSdoctor dropped some neat research on how to deobfuscate JS. A common JS obfuscation pattern is to implement a shift based on an arbitrary hex value, which is used to shift each array x times depending on the hex value.

The writeup covers exactly how this is done with code snips, and provides a means of reversing some of this obfuscation to make it more readable. Check it out here: https://medium.com/@jad2121/javascript-deobfuscation-the-easy-way-637d7e9b2952

You can also do this in mobile apps with Frida by hooking into the deobfuscate function, passing in values and checking what is returned. Alternatively, hooking the call to the function and replacing it for a wrapper to log all inputs and outputs will be as effective.

XSS Payload Obsufcation & Payload Impact

Renniepak dropped a tweet with a neat little tip on how to hide your payload:

history.pushState can be an alternative way to achieve the same as window.location , with a few advantages stated by the developer docs:

  • The new URL can be any URL in the same origin as the current URL. In contrast, setting [window.location](<https://developer.mozilla.org/en-US/docs/Web/API/Window/location>) keeps you at the same document only if you modify only the hash.

  • Changing the page's URL is optional. In contrast, setting window.location = "#foo"; only creates a new history entry if the current hash isn't #foo.

  • You can associate arbitrary data with your new history entry. With the hash-based approach, you need to encode all of the relevant data into a short string.

When crafting a POC, you can implement these sorts of attacker-like practices to demonstrate further demonstrate impact. Equally, If you model the entire attack path and make it context-specific to the target, targets are more likely to pay higher.

Using a more visual impact in a POC video or walkthrough can help easily demonstrate this to triagers, ultimately meaning less resistance and less back and forth with the program.

Speaking from experience, when I’ve taken time to create a POC video demonstrating exploitation alongside a good writeup, programs are more likely to award bonuses and pay.

Recon vs Main App

This one caused quite the debate on the pod. Naffy tweeted about keeping it simple when it comes to hacking:

The context seemed to be geared towards recon-based hunters - wider scopes, asset enumeration, and lots of content discovery.

Hunters at the top of their game in both recon and more of a main application approach all deliver impactful bugs, but different skill sets are required to do so. Equally, different styles bring different types of bugs.

Ultimately, regardless of what style of hunter you are, the underlying principles of keeping hacking simple across the board universally apply. How this could translate to more of an application-based approach:

  • Understanding the application context

  • Understanding business logic

  • Understanding directory structure (client-side and server-side)

  • What integrations are implemented?

  • What parameters, what content types are used, and what frameworks are used?

Regardless of how you hunt - the main takeaway from this one is to keep it simple and go deep.

As always, keep hacking!