Attacks
Vulnserver GTER exploitation: Hunting eggs

VP of Hacking
Updated
Jun 11, 2020
14 min
As we saw in the previous post, vulnserver is a VbD (Vulnerable-by-Design) application designed to help you sharpen the Windows exploitation skills.
Our previous post described the exploitation of TRUN command using a simple EIP overwrite technique, as we had virtually no constraints for our payload. However, exploiting the GTER command will not be as straightforward.
_____
⚠️ Warning: Do not run vulnserver.exe on a sensitive machine or a non-secure network. It will be a backdoor that may be used by others to break into your system.
_____
Enumerating Vulnserver
If you launch vulnserver.exe with no options, the default port used will be TCP/9999.

We can check the behavior of the GTER command by issuing the suggested syntax.

Ok, it’s fuzz time.
Fuzzing GTER
As we did before with the TRUN command, we discovered the syntax needed for the GTER command. And again, we’ll be using Spike to help us with our fuzzing.
As GTER uses a similar syntax to the TRUN command, we can reuse the Spike script created in our previous post and just change the command.
gter.spk.
Remember that the s_string command will send an immutable string to the fuzzed protocol, and s_string_variable tells Spike to use that string as a fuzz point.
Now we can send the fuzz attack to the victim machine:

Ugh! After a few iterations, vulnserver.exe crashed, and it seems that it happened when we sent 5060 bytes of data. Let’s check the offending payload on Wireshark:

We can now create a PoC (Proof-of-Concept) file with that information:
exploit.py.
This time, we’ll attach vulnserver.exe to Immunity Debugger.
Let’s run the initial exploit and see what happens:

Look at that! We replicated the crash!

Look at the state of the application at the moment of the crash. The first thing to notice is that the EIP register has the value 41414141, which means that we effectively overwrote it with our buffer of A. That’s good news. However, if you see in the stack window (bottom right), we only have 20 bytes after the ESP pointer, so if we do a JMP ESP, we will only have 20 bytes for working. That’s not enough space for anything complex.
However, if we look at the dump window (bottom left), we have a broader space (around 0x90 or 144 bytes) at the beginning of our buffer, which is again not enough for something like a reverse shell, so, we need to be creative here. Actually, we can fit a reverse shell in that space, but we need to carve it manually by reusing already loaded WinSock modules of vulnserver, but that technique is described in another post.
First things first:
We need to calculate the exact offset on which EIP gets overwritten. To do that, we will use pattern_create.rb from Metasploit to create a cyclic pattern.
Running pattern_create.rb.

We need now to update the exploit with that pattern:
exploit.py.
And we run the exploit again:

This time, EIP has the value 41396541. Let’s check the offset on our cyclic pattern:
Running pattern_offset.rb.
Great, that tells us that the EIP gets overwritten starting on the 147 byte of our buffer. Update the exploit to check the offset:
exploit.py.
Now run the exploit. If EIP gets the value 42424242, which are the four bytes of our B buffer, we got it right:

Whoohooo! Now we can start exploiting this.
Exploiting
If we check the state of the application after the crash, we can see that we can jump to ESP to gain control of the execution flow.
We can use mona.py plugin to find that instruction:
mona looking for JMP ESP.
This will tell mona to look for the instruction JMP ESP and will exclude DLL from the OS.

We will pick the JMP ESP instruction at 625011C7. Now we can proceed to update the exploit and replace the four B with that address:
exploit.py.
Let’s verify this:

Great!
But since everything can’t be so glorious, we landed on our C buffer, which contains 20 bytes. We need to move to the A buffer, which holds around 144 bytes to work.
Jump around
To get around this space constraint, we need to jump to our bigger buffer.
For jumping, we can use the unconditional jump instruction found in X86 architecture called JMP that will divert the execution flow to the desired address. We also need to know where to jump.
Now look at the next image, which is the resulting location after our JMP ESP execution:

As we can see, we are in the next instruction after the JMP ESP at the address 00CBF9C8 (this is a stack address, so it will change every time we run the application), and we see that we have only 20 bytes to work.
If we scroll up, we can see that the buffer of A starts at 00CBF931:

So we need to do a relative reverse jump. Using the debugger, we can easily calculate the offset:

As you can see, the resulting bytes are E9 64 FF FF FF. Let’s update our exploit with that jump:
exploit.py.
And check the result:

Great! We were able to jump to the start of our buffer. But what now? On 147 bytes, it’s hard to include a working reverse shell. However, there’s a trick we can use that will have to do with eggs.
Egghunter
An egghunter is a little shellcode (commonly around 32 bytes) that can be injected on our payload. It’s a special shellcode because its only mission is to search the entire process memory for the location of the desired code, and once it finds it, it will execute it.
But how will it know what to execute? Well, it will look for a tag that will be prepended to our shellcode, also called the egg, and once it finds that egg, it will execute any code that follows.
First, we need to create our egghunter shellcode:
Creating egghunter.
Note that the configured egg is w00t. However, to make the searching more effective, that egghunter was designed to look for a double instance of that egg, which means w00tw00t. This will guarantee that the executed code is the one we injected and will avoid false positives.
Let’s update our exploit:
exploit.py.
What will happen is the following:
Our buffer will be injected.
The
JMP ESPwill be executed.The reverse jump will be executed and land directly to our egghunter.
The egghunter will iterate through all the memory looking for the egg
w00tw00t.When the egghunter finds the egg, it will execute anything that follows, in our case, a bind shellcode.
So, the only thing that’s missing is our shellcode. We will create one that will bind a shell on port 4444:
Creating shellcode.
But where can we fit it? This shellcode is 355 bytes long, but we only have 140 bytes as much to work.
We have to think out of the box: Vulnserver is a server (really!), and it will surely multiplex connections. Well, we can create a different connection to send the shellcode over! That will store the shellcode on the process memory where our egghunter will be able to find it.
We can now finish our exploit. Remember to prepend the w00tw00t egg to the shellcode, or the egghunter won’t be able to find it!
exploit.py.
Now, let’s look the egghunter in action:

Awesome! We got our shell again!
You can download the final exploit here.
Conclusion
The egghunter technique is very useful when dealing with short space for sending complex payloads. However, you must be careful to inject the correct tag because it will start using all the available CPU for searching the egg on the entire system memory.
Get started with Fluid Attacks' PTaaS right now
Other posts
















