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 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 ESP
will 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