[HackerNotes Ep.80] Pwn2Own VS H1 Live Hacking Event (feat SinSinology)

Hacker TLDR;

• Competing in Pwn2Own & LHE Comparison: Pwn2Own competitions are intense hacking events focused on remote code execution (RCE) with huge payouts. Participants provide detailed whitepapers along with their exploits, along with chances to win 1st place and the ‘Master of Pwn’ title. Detailed comparisons on LHEs and Pwn2Own events are below.

• SinSinology’s research - Whatsup Gold RCE: A stellar writeup from Sina detailing how he abused .NET’s WFC, an alternative to .NET remoting, to achieve RCE in WhatsUp Gold. Unauthenticated. Tips and tricks for handling and reviewing WFC are included.

  • Original research here: https://summoning.team/blog/progress-whatsup-gold-rce-cve-2024-4885/

• Sina’s Approach + Methodology: Tips on how to deoptimise DLLs, debuggers to use, pros of a debugger and a whole lot more that are too long to summarise here!

• PWN20WN / IOT Debugging: We’ve got a bunch of knowledge and techniques on access methods for gaining a shell on IOT devices including:

  • Hardware Techniques

  • JTAG, UART ports

  • Physically Connect to the Device (if available)

  • Remove MMC/Storage Device

  • Fault Injection/Glitching

  • Blackbox Techniques

  • Firmware Analysis

• Tips for Security Research: Competing at an elite level of security research takes a lot - a quick TL;DR of some tips detailed to get to that level below:

  • Get the reps in, you can’t avoid this part

  • More failure == closer to success

  • Avoid education procrastination

  • Start hacking and bug bounty for the sake of learning how to hack and hunt, not for financials

  • Recreating other people’s bugs and work, attempting to locate the initial signals of a bug and recreate the flow and POCs can be very useful when learning

  • If you can get your hands on source code, DO IT

This episode is sponsored by ThreatLocker. Check out their eBook "The IT Professional's Blueprint for Compliance" here!

SinSinology - Web Hacker To Pwn2Own

Sina Kheirkhah, known as @SinSinology, is a full-time vulnerability researcher with a background as a developer. His journey into hacking began when one of his sites was hacked and defaced, and after reaching out to the hacker, he received a detailed explanation of the vulnerabilities, sparking his interest in the dark side (pwning).

Soma dedicated significant time throughout his journey to understanding the fundamentals, focusing on both web-based vulnerabilities and low-level concepts like Assembly and debugging. His blog showcases the calibre of his research; check it out here: SinSinology’s Blog.

Sina is also a big competitor in Pwn2Own. If you aren’t familiar with Pwn2Own, it has an interesting origin story. Pwn2Own originated at CanSecWest offering the challenge to demonstrate that RCE could be achieved in Mac OS X. Since this time, Pwn2Own has evolved into an elite hacking space where ZDI (Zero Day Initiative) organises the event and pays out big money to researchers, with over $1M being paid out on most events.

Competing in Pwn2Own

Pwn2Own competitions are intense and challenging, often marked by unexpected obstacles. One of the most significant challenges is the possibility of OTA updates being pushed to devices just before or during the competition.

These updates can nullify entire exploit chains by breaking them with no new features or bugs. Participants are required to provide not only the exploit but also a detailed whitepaper to the ZDI researchers and the vendor, explaining the exploit in depth.

ZDI purchases both the bug and the associated research, making complex bugs more valuable due to the extensive research involved. The competition has also evolved over the years, shifting from solo researchers to company-backed teams.

Some companies even employ full-time security researchers, each specializing in different areas such as hardware/PCB, shell access, and fuzzing. This team approach adds additional complexity for solo researchers to compete and win against seasoned, well-resourced teams.

Pwn2Own vs. LHEs

There are a few differences between your standard bug bounty LHE and a Pwn2Own competition. These events have distinct objectives and characteristics, including:

Communication

Pwn2Own maintains a strict communication protocol with no vendor communications before the event and no direct communications during the competition; all interactions occur via ZDI. In contrast, LHE competitions foster more collaboration with a pre-kickoff call that includes a scope discussion, the establishment of a Slack channel, and ongoing communications.

Preparation Time

Pwn2Own allows participants 2-3 months of research time before the competition officially kicks off, providing ample time for thorough exploit development.

Registration and Travel

Participants in Pwn2Own can register up to one week before the competition, with the option for remote registration. In some cases, Pwn2Own sponsors travel for in-person attendance, especially for those who have achieved a full win. In LHE competitions, travel sponsorship is provided if participants receive a first-hand invite.

Winning Criteria

In Pwn2Own, a win is defined by a successful on-stage exploit with no duplication, referred to as a full win. The top performer in the competition earns the prestigious title "Master of Pwn." This title is awarded to only one individual or team who wins the entire competition.

Achieving "Master of Pwn" instantly grants platinum status on their ZDI account, significantly increasing the payout for each bug they sell to ZDI outside of the competition. For instance, with platinum status, selling a bug to ZDI results in a double payout.

In contrast, LHEs have a leaderboard and some awards such as ‘MVP’ for most valuable hacker. You also have a 1st-3rd place ranking as well as some other awards such as show and tell for the event.

Payouts

Pwn2Own primarily focuses on payouts for remote code execution (RCE) vulnerabilities, while LHEs offer payouts for the entire spectrum of web application vulnerabilities. In Pwn2Own, if a target has been listed by ZDI, there is a payout for the first successful exploit. If a second researcher crafts a unique bug, they receive 50% of the original payout. If another researcher submits a duplicate exploit, they receive 50% of the payout for the second unique bug.

Each successful exploit in Pwn2Own awards participants with both money and "Master of Pwn" points. The participant with the most points wins additional money. More complex exploit chains are rewarded more, encouraging in-depth and sophisticated research.

LHes however payout on just about all aspects of web vulnerabilities and award a certain number of points based on the severity of the bug.

Steps for pwn2own

Now, with a competition like this, how do you prep for it? Inspired by Alex Plaskett, the steps for preparing for a Pwn2Own competition are as follows:

1. Background Research: Begin by searching for prior vulnerabilities, previous write-ups, and reverse engineering efforts related to the target product. Building on prior research is often more effective than starting from scratch.

2. Device Setup: Acquire the target device, gain a shell, and establish a way to debug it in a lab environment.

3. Attack Surface Mapping: Identify available attack surfaces and determine what can be exploited.

4. Bug Hunting: Conduct static analysis, code review, and fuzzing to find bugs. This may require creating custom tools specific to the target.

5. Exploit Development: Develop the proof of concept (POC) exploit. Ensure the POC is as efficient, reliable, and portable as possible. If an update is pushed before the event, and your exploit relies on specific memory address locations, it’s crucial to ensure you can easily re-point your exploit. This adaptability could be the difference between successfully pwning or not.

Some interesting unique quirks I noticed here too - It is encouraged to make your exploit as complex as possible, unlike a typical bug bounty. This complexity reduces the likelihood of encountering a full duplicate and increases the chances that only a partial duplicate will occur if another team uses a portion of your exploit chain first.

After all, ZDI is buying your research as well as your exploit, so it kind of makes sense to reward the complexity component of an exploit.

These steps were inspired by Alex Plaskett here: https://www.youtube.com/watch?v=uBu9B0tNObs

SinSinology’s research - Whatsup Gold RCE

We dropped the link to his blog earlier but some of his research is seriously good.

In his post, Sina explores WFC, a versatile alternative to .NET remoting that supports different bindings such as HTTP and TCP. WCF facilitates RPC-based methods using protocols like XML or TCP, offering a more modern approach for remote procedure calls. When auditing WCF, several key components need attention:

1. Address: This is the endpoint, such as /api, where the service is accessible.

2. Binding: This specifies the protocol, either HTTP or TCP, that the service will use.

3. Contract: This represents the methods or code you want to invoke. To exploit these contracts, you need to find or write the interface for them. Contracts define the available methods for invocation.

To locate these components, you might not always find a configuration file; sometimes, the information is embedded directly in the code. Therefore, decompiling the application to search for WCF setup and registration is crucial. Specifically, searching for the term "binding" can help identify the necessary sources.

Using WCF’s ‘GetFileWithoutZip’ primitive, Sina found a means of writing arbitrary files. The entire POC involved crafting a malicious payload that could manipulate file paths allowing for RCE from an unauthenticated perspective!

Spending time reviewing sources, and not just sinks, when auditing a codebase is always beneficial. Regardless of whether an exploit is found, it enhances your understanding of the application's logic and flow, providing a good return on investment if you plan on researching the codebase for a while.

Check out the full research for this one here: https://summoning.team/blog/progress-whatsup-gold-rce-cve-2024-4885/

SinSinology’s Approach & Methodology

Now looking at some of Sina’s prior research, the impact is mega. Some of Sina’s specialities and focuses are around deserialization, path traversal, race conditions, injections and logic bugs. Equally, there’s a big focus on .NET based research, and detailed a rough .NET methodology for us on the pod:

.NET Methodology

1. Acquire Software or Source Code: Obtain the target software or its source code to begin the analysis.

2. Install the Software: Set up the software in a controlled environment to understand its functionality and interactions.

3. Map Out the Attack Surface: Identify potential points of entry and vulnerabilities. This is done by:

4. Decompile .NET: Use decompilers to convert the executable & DLL back into a human-readable form.

Now, decompiling can be a bit of a headache. Some recommended decompilers and tips if you find yourself going down this route:

• Decompilers: dnSpy, dnSpyex, Ilspy, Visual Studio, and .peak are essential for this task.

• Try Multiple Decompilers: Some decompilers might not work due to optimizations, so using several tools can help mitigate this issue.

• Debugging: If when you’ve decompiled breakpoints fail to set, it indicates the DLL has been optimized. To address this, adjustments need to be made to the DLL attributes, allowing the debugger to read the values correctly. More on this shortly.

Deoptimsie DLL/Images

If you can’t hit a breakpoint after decompling, the image may be optimized. To deoptimize an image:

1. Create an .ini File: Place a .ini file next to the DLL or image file.

2. Add Configuration: In the .ini file, include a setting to allow optimization.

3. Restart the Process: Restart the application or process. The next time it runs, the image will no longer be optimized and should work correctly with debugging tools.

4. Modify .NET Attributes: Adjust any .NET attributes that might be preventing the debugger from accessing the necessary values.

By following these steps, you can effectively deoptimize the DLL and ensure proper functionality during debugging. Some good additional resources for debugging with dnSpy and understanding the DLL optimisations that are applied:

• dnSpy: https://github.com/malware-dev/MDK-SE/wiki/Advanced-debugging-with-dnSpy

• DLL Optimisations: https://learn.microsoft.com/en-us/visualstudio/debugger/jit-optimization-and-debugging?view=vs-2022

Why use a debugger?

It can seem quite long-winded, and a pain to set up a debugger. You might be thinking - why not just read the source and build out requests that way? If you’ve done source code review before, you’ll know there are quite a few benefits to debugging source.

If for example, you’re trying to follow the flow of an HTTP request in a complex enterprise-based app, you’re going to have a bunch of noise in between the HTTP request source and the HTTP request sink - middlewares, filters, intercepters, auth checks, the list goes on. This could also be hundreds of lines of code.

Using a debugger, you can see the HTTP request at every step in the process which can massively save you time troubleshooting. Equally, you can examine the call stack to check if a variable has been overwritten, function calls and just about everything you need to see to debug.

Being able to do that saves a tonne of time - you can peak into the call stack and dynamically overwrite variables, and bypass checks if you need to easily test and rewrite parts of your request or POC.

PWN20WN / IOT Debugging

If you thought .NET debugging sounded hard, setting up debugging on devices used in Pwn2Own and IOT, in general, seems even more long-winded! First of all, you need to get a shell on the device as a means of initial access.

Access methods can be categorized as hardware-based, black box testing, and firmware analysis. Here's an overview of each method:

1. Hardware Techniques

1.1 JTAG, UART ports

• JTAG:

  • JTAG (Joint Test Action Group) is a common hardware interface for debugging and programming embedded systems.

  • Use a JTAG debugger to connect to the JTAG interface on the target device.

  • Common tools: OpenOCD, Segger J-Link, Bus Pirate.

• Steps:

  1. Identify the JTAG pins on the target device.

  2. Connect the JTAG debugger to these pins.

  3. Use debugging software to interact with the device, inspect memory, and potentially get a shell.

• UART:

  • UART (Universal Asynchronous Receiver-Transmitter) is a serial communication protocol used in many embedded systems.

  • Use a USB-to-UART converter to connect to the UART interface.

  • Common tools: PuTTY, minicom, screen.

• Steps:

  1. Identify the UART pins (TX, RX, GND) on the target device.

  2. Connect the USB-to-UART converter to these pins.

  3. Open a terminal program on your computer and connect to the serial port.

  4. Interact with the device, which might provide a shell or debugging interface.

1.2 Physically Connect to the Device (if available)

• This involves physically opening the device to access internal components and interfaces.

• Steps:

  1. Disassemble device.

  2. Locate the relevant interfaces (e.g., JTAG, UART, SPI).

  3. Use the appropriate tools to connect and interact with these interfaces.

1.3 Remove MMC/Storage Device

• This involves removing the storage device (e.g., SD card, eMMC) to read its contents.

• Tools: Card reader, eMMC adapter.

• Steps:

  1. Remove the storage device from the target device.

  2. Connect it to a computer using a card reader or eMMC adapter.

  3. Use disk imaging tools (e.g., dd) to create an image of the storage.

  4. Analyze the image using tools like Binwalk, strings, and hexdump.

1.4 Fault Injection/Glitching

• Fault injection involves intentionally causing errors in the system to bypass security mechanisms.

• Glitching involves introducing brief disturbances in power or clock signals.

• Steps:

  1. Identify critical moments in the device's operation (e.g., boot process).

  2. Use fault injection/glitching tools to introduce errors at these moments.

  3. Monitor the device for changes in behaviour that might allow access.

2. Blackbox Techniques

• Blackbox testing involves interacting with the device solely through its external interfaces (e.g., network, USB) without internal knowledge.

• Steps:

  1. Service Identification: Identify open ports and services in use.

  2. Fuzzing: Start fuzzing the service to identify vulnerabilities.

  3. Exploit: Using the prior output from the fuzzing, try and shell the device.

3. Firmware Analysis

• This involves analyzing the firmware of the device to find vulnerabilities or hidden interfaces.

• Tools: Binwalk, Ghidra, IDA Pro.

• Steps:

  1. Obtain Firmware: Download from the vendor's website or extract from the device.

  2. Extract Firmware: Use Binwalk to extract the firmware contents.

  3. Analyze File System: Explore the extracted files, and look for interesting files (e.g., configuration files, binaries).

  4. Reverse Engineering: Use Ghidra or IDA Pro to analyze binaries for vulnerabilities or backdoors.

  5. Modify and Reflash: Modify the firmware and reflash it to the device, if possible, to gain access.

When it comes to getting a shell using one of the above techniques, Sina will exhaust the first 10 hours via hardware and firmware techniques. If this doesn’t work, he goes black box and tries to exhaust the black box techniques.

With a shell on the target, you’ll be able to dive in and start to understand what’s available in terms of attack surface on the target, Remember, with pwn2own, the ultimate goal is RCE without user interaction.

This should probably steer research time to more impactful areas of the attack surface such as file writes, file reads, deserialisations and so on.

Fuzzing

When it comes to fuzzing these types of devices, it’s almost an art in itself. You probably won’t be able to fuzz one of these devices like you would a standard web app service, so you have to take some extra steps.

If you want to fuzz a specific area of an attack surface - ie a specific component - you’ll likely need to virtualise this in an environment which mimics and can run the component. Some virtualisation recommendations for this are:

• AFL+Qemu ← recommendation,libafl, unicorn engine, qiling

Quite long-winded, right? A quick TL;DR of the process to start fuzzing some of these more obscure IOT devices:

Get a shell → Investigating the attack surface → Use emulation software/virtualisation software to get the right environment for part of the attack surface → start fuzzing

Tips for Security Research

To get to the level of a Pwn2Own competitor, you need a serious amount of skill and commitment. The guys did a great job of summarising some tips to get to that level, and perform your own security research:

• Get the reps in, you can’t avoid this part

• More failure == closer to success

• Avoid education procrastination. There will always be things to read and things to learn, if you get caught in this trap you’ll constantly be reading instead of getting the reps in on actual hacking

• Start hacking and bug bounty for the sake of learning how to hack and hunt. Don’t start it for the financial aspect as it can very quickly demotivate newcomers and skew why you started hacking in the first place.

• Recreating other people’s bugs and work, attempting to locate the initial signals of a bug and recreate the flow can be very useful

• TL;DR: If you can get your hands on source code, DO IT

There’s no doubt Sina is seriously talented at what he does. He’s also offering training on .NET based vectors based on his years of research and Pwn2Own experience. If you want to be trained by him check it out here https://summoning.team/

As always, keep hacking!