Egghunting Sorcery

Posted on

 

This post is going to piggyback off my last post of “Stacks and Handlers and Python, oh my!“. So to follow along, please take the few seconds to head to that page, and definitely download the vulnerable software. If you do not have WinDBG, Immunity, or Mona…that page will have the downloads for them as well. As Always, I highly encourage you to pleeease follow along and participate in creating this exploit! You’ll also notice that I am using both WinDBG and Immunity. WinDBG is being used for the details in the pictures, and Immunity is being used for the simplicity in the video. I think doing it this way will help more! Just my opinion 🙂

 

Knowing thy Egghunter

Egghunting, what is this sorcery that you speak of??

Through out my journey of taking Offensive Security’s Cracking the Perimeter course, I learned about different types of egghunters. The one we will be using implements the NtDisplayString function. This particular egghunter is the smallest in size and from what I understand…more favorable. The other two egghunters vary in size and utilize different methods. For instance, there is a 37 byte egghunter that utilizes the IsBadReadPtr function, and the other is a 60 byte egghunter that utilizes the SEH function. They all have their pros and cons, which you can read more about here, a paper written by Skape. This was extremely helpful for me to understand and I hope you would download it and read it as well! I personally downloaded it and printed it out.

What does it exactly do though?

So these egghunters have “tags” which is what this small piece of code looks for in memory. These tags may be anything you want, and you may have seen them already in exploits if you have read through them such as KnFTP Overflow, or KiTTY Portable Overflow. These exploits used the common tag of “W00T”. After you fire your exploit and your tag is in memory, your egghunter will search in memory for your tag, w00t. Once it finds a double instance of your tag, it will then execute your payload and you can then bask. in the glory. of shell. Let’s go about showing you a different way…iRrFvz6 - Imgur

Egg: Hey what’s up man! You got w00t?

Address: No says I!

Egg: Ahh. Hey what’s up man! You got w00t?

Address: No says I!

Egg: Ahh. Hey what’s up man! You got w00t?

Address: Why yes, yes I do!

Egg: W00tW00t?!

Address: Yessir!!

Egg: Commence payload execution, sire…

The awesome thing about these egghunters is that it can help you get out of small spaces if the vulnerable software is forcing you to work with a small area. For example, lets say you only have 50 bytes to work with. You’re obviously not going to be able to fit some sort of meterpreter shell or regular shell. Those payloads alone can range from 93 bytes and up to 328+ bytes. Eeesh!! So that is when our handy egghunter will come into play to save the day 🙂

All this info may sound like a daunting task to complete, however, I can assure you that it is not that bad!

 

Reconstructing our Exploit

Earlier, I mentioned we were going to be working with the vulnerable software from my last post, which was Easy File Sharing Web Server. Lets pick a part the previous exploit so we can implement our egghunter and you can see it in action.

Sweet. That is now broken down. What we have to add now is our egghunter. The tag I chose is “hive”. I made a script that will give you your egghunter if you provide the tag you want that way you can just fire it up, receive it and move on with your day like nothing ever happened. You can find that here!

As a side note, if you have no idea what I am doing right now, it would probably be best if you head back to my last tutorial that way you can see how I came up with the values for the crash, the jmp, the P/P/R, and junk. Again, you can find that here 🙂

The next thing you’ll do is fire up your exploit and see the outcome. In the picture below, you are going to notice a few things:

  1. The access violation from our POC
  2. Viewing of the SEH chain  (!exchain)
  3. Placing a breakpoint on 100228ff  (bp 100228ff)
  4. Passing the exception which then leads us to our breakpoint  (gN)
  5. Stepping through the instructions to land in our egghunter  (t)
  6. Viewing our egghunter in our disassembly window

might be better 1

One thing to do is make sure that your egghunter is fully intact and hasn’t truncated.

What do you mean make sure it’s fully intact? And truncated?? It works! Don’t you see???

It may work and all, and LOOK correct…but having that mindset is going to throw everything for you off. If you just take a quick glance, it may look normal…but what if towards the middle of your egghunter, you have one character that truncated when being sent? How would that look? It can react differently depending on the application you are exploiting, but let’s say you have 74ef at address 042c6fc3. What if it expanded and shows as 74adf3? And everything after that looked normal? That would slip passed your analysis. Uh oh… Well right there gents, is when you will find out that “ef” would be a bad character. Then you will need to encode your egg to exclude that character! That was just one character. ONE character. One is all it takes to throw off your exploit! If that’s the case, you will more than likely spend hours on end trying to troubleshoot an issue because of just one character. I know because I have done it myself!

As a side note, you might want to consider getting a cushion for your desk and/or keyboard in the event you find yourself wanting to smash your head in

Next thing to do would be adding your tag into your exploit so it can lead to our payload! The first thing I did was append a “dummy” shellcode to our GET request. You can do it anywhere you want, but I wanted to choose this area just because I could. I also placed our tag BEFORE our payload that way when our egghunter finds it, our egghunter will then execute our payload! Your exploit should actually look somewhat similar to this now:

Now, our “E” is going to be our dummy shellcode. The reason being is to make sure that the size of any payload we specify will actually work and not be broken apart. At this stage, you are experimenting where you can place your payload. As far as the amount of bytes I placed, that was just a random number that I had came up with.

The awesome thing about this is adding to our GET request did not affect our crash whatsoever. If you wanted to go for a 1000 bytes, by all means! Go for it!!

As before, we fire up the exploit and test again to make sure it does indeed give us our dummy shellcode. Lets check it out…

Capture2

Awesome!! Look at that sweet, sweet space to insert any type of payload our little heart desires!

 

Let Exploitation…BEGIN!

Now that we have finally got everything working and good to go, we need to generate our shellcode!

Wait wait wait waaaait…in your last tutorial, you said you had to find bad characters? Are we skipping this step??

I am glad you asked! The awesome thing about this buffer space is that you don’t need to worry about them! Well, for the most part. You will still need to encode your payload to get rid of the nulls that MSFvenom will generate. Other than that, it is pretty simple! Using our egghunter pretty much got rid of the need of finding them and spending all that time doing repetitive tasks to finding the bad characters that will ruin your exploit. If you ask me, I’d say that’s a win!

As a side note, if you come across a bad character in the egghunter itself, do keep in mind you will need to encode that as well. For the most part, it’s not that big of a deal. But you may come into an exploit that will laugh at Veil, MSFvenom and any other encoder 😉 Isn’t that right fellow CTP-ers?? hehe

I used MSFvenom to generate a bind shell on port 54321. The total size came out to 375 bytes, which is well under the 800 bytes I appended to the buffer.

All that is left to do is switch that out with our dummy shellcode and voila! You will now have yet another…reliable exploit! 🙂

exploit

And there you have it, folks! I actually enjoyed creating this exploit more than other types of overflows. Implementing your own egghunter is much more fun and amazing to see how it works visually, rather than reading about it. One downside to utilizing them with your exploit is you will notice a 100% spike in your CPU usage for however long it takes to find your tag. But since…you know…you’re a nice guy…it shouldn’t matter, now should it?? 😉 It wasn’t that bad, was it??

This actually made it on Exploit-DB! Check it out: https://www.exploit-db.com/exploits/40178/

As always, here is my final POC for this exploit:

 

One thought on “Egghunting Sorcery

Leave a Reply

Your email address will not be published. Required fields are marked *