Jump to content
Kev

OSCE Exam Practice - Part I (Lab Setup)

Recommended Posts

OBLIGATORY INTRO

 

Howdy! This is the first post in a multi-part series detailing steps taken, and exploits written, as part of my OSCE exam preparation. I intend to use these practice sessions to refine my exploit development process while sharing any knowledge gained.

 

I originally wanted to take this course a few years ago, but could never quite lock it in. Recently, I was fortunate enough to have work fund the course. Since then, I’ve been spending my free time listening to Muts’ dulcet tones and working through the modules. I wrapped up the official course material yesterday and plan to work through some additional work recommended by some OSCE graduates.

 

What makes the timing awesome for me is that I just finished up CSC 748 - Software Exploitation for my graduate course work. The course dealt with Windows x86 exploitation, fuzzing, and shellcoding. Sound familiar? It dove into some topics that OSCE doesn’t cover such as using ROP to bypass DEP. I’m incredibly happy to have been able to do both of them one right after the other. I’ll be including some of the shellcoding tricks I learned from the course in this series at some point.

 

EXPLOIT DEVELOPMENT ENVIRONMENT

This post will cover setting up a lab environment. While this may not be the most interesting topic, we’ll cover some setup tips that may be helpful.

 

Don’t worry, we won’t go step by step through setting up all these things unless it’s warranted.

 

OPERATING SYSTEM

For these practice sessions, we’ll attempt to stick reasonably close to an OSCE environment by using a 32bit Windows 7 VM. Unfortunately, Microsoft has taken down the IE/Edge Virtual Machine images from their site. You can only get the Windows 10 images nowadays. Fear not! If you find yourself in need of an older version, they’re archived and can still be downloaded at the link below.

 

 

SCRIPTING LANGUAGE

We’ll be writing all proof of concepts using Python 3. Python 2 still gets a lot of use in PoCs for exploits and exploit-centric tooling, however, I strongly prefer 3 as a language overall and will stick to it throughout these posts.

 

The latest version of Python (3.8.2 at the time of this writing) can be found here.

 

HEX EDITOR

There are times we’ll need a hex editor. I prefer 010 when working on windows.

 

NASMSHELL

Part of creating shellcode is janking™ around with the instructions to find what works in the smallest amount of space without known bad characters. nasmshell makes it incredibly easy to check which opcodes are generated by which instructions. Of note, nasmshell requires python2.

 

FUZZER

For network fuzzing, we’ll be using boofuzz. It’s a fork of and the successor to the venerable Sulley fuzzing framework. Sulley has been the preeminent open source fuzzer for some time, but has fallen out of maintenance. Installation consists of a simple pip command.

pip install boofuzz --user

AUTOMATIC CRASH DETECTION & PROCESS RESTART

This part is totally optional. Boofuzz offers a utility called process_monitor.py that detects crashes and restarts the target binary automatically. It requires a few additional libraries to run and must run on the target machine itself. As we’ll be doing all coding and fuzzing from the same windows environment, this is fine.

 

The install steps are located here. I won’t copy and paste them here, however I will note something that I was forced to do during installation. All of the libraries for process_monitor.py are installed into my Python2.7 environment. Whereas boofuzz is installed into my Python3.8 environment. This is because pydasm requires Python2.7. The end result is that we’ll be scripting fuzzers in Python3, and executing process_monitor.py with Python2.

 

Also, there is a note on the install page:

Quote

Building pydasm on Windows requires the Visual C++ Compiler for Python 2.7

 

I didn’t need to do anything to satisfy this requirement, as my flare-vm install script pulled it down for me.

 

DEBUGGER

The topic of which debugger to use seems to be pretty contentious in the OSCE forums/chats. We’ll be using WinDbg. The reason is that I spent 4 months using it for college and have come to like it.

 

FLARE-VM

To install WinDbg (and some other tools), I used the Flare-VM install script. Flare-VM will take a Windows 7-10 machine and install a plethora of RE tools. I modified the flare’s profile.json for a relatively light-weight installer.

 

And if you’re feeling lazy, here’s my profile.json.

 {
    "env": {
        "TOOL_LIST_DIR": "%ProgramData%\\Microsoft\\Windows\\Start Menu\\Programs\\FLARE",
        "TOOL_LIST_SHORTCUT": "%UserProfile%\\Desktop\\FLARE.lnk",
        "RAW_TOOLS_DIR": "%SystemDrive%\\Tools",
        "TEMPLATE_DIR": "flarevm.installer.flare"
    },
    "packages": [
        {"name": "dotnetfx"},
        {"name": "powershell"},
        {"name": "vcbuildtools.fireeye"},
        {"name": "vcpython27"},
        {
            "name": "python2.x86.nopath.flare",
            "x64Only": true,
            "args": "--package-parameters \'/InstallDir:C:\\Python27.x86\'"
        },
        {"name": "libraries.python2.fireeye"},
        {"name": "libraries.python3.fireeye"},

        {"name": "windbg.flare"},
        {"name": "windbg.kenstheme.flare"},
        {"name": "windbg.ollydumpex.flare"},
        {"name": "windbg.pykd.flare"},

        {"name": "ghidra.fireeye"},
        {"name": "vbdecompiler.flare"},
        {"name": "010editor.flare"},
        {"name": "resourcehacker.flare"},
        {"name": "processdump.fireeye"},
        {"name": "7zip.flare"},
        {"name": "putty"},
        {"name": "wget"},
        {"name": "processhacker.flare"},
        {"name": "sysinternals.flare"},
        {"name": "ncat.flare"},
        {"name": "shellcode_launcher.flare"},
        {"name": "xorsearch.flare"},
        {"name": "xorstrings.flare"},
        {"name": "lordpe.flare"},
        {"name": "googlechrome.flare"},
        {"name": "nasm.fireeye"}
    ]
}

 

MONA.PY

Even after using Flare-VM’s installer, we’re still missing a key tool, mona.py. Mona.py is an incredible tool; it’s bonkers how many facets of exploit dev on windows are made easier with mona.

 

To get mona up and running with WinDbg, we’ll just need to follow these steps.

 

We can confirm everything works by opening up WinDbg, attaching to some benign process, and running the following commands:

.load pykd.pyd
══════════════

Processing initial command '.load pykd.pyd'
!py mona
════════

[+] Command used:
!py C:\Program Files\Windows Kits\10\Debuggers\x86\mona.py
     'mona' - Exploit Development Swiss Army Knife - WinDBG (32bit)
     Plugin version : 2.0 r605
     Python version : 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500 32 bit (Intel)]
     PyKD version 0.3.2.2
     Written by Corelan - https://www.corelan.be
     Project page : https://github.com/corelan/mona
    |------------------------------------------------------------------|
    |        _ __ ___    ___   _ __    __ _     _ __   _   _           |
    |       | '_ ` _ \  / _ \ | '_ \  / _` |   | '_ \ | | | |          |
    |       | | | | | || (_) || | | || (_| | _ | |_) || |_| |          |
    |       |_| |_| |_| \___/ |_| |_| \__,_|(_)| .__/  \__, |          |
    |                                          |_|     |___/           |
    |                                                                  |
    |------------------------------------------------------------------|

SQLITE BROWSER

We’ll need a way to look at boofuzz’s results. They’re stored in a database, and the provided web interface leaves something to be desired. As we’ll be working on windows, we’ll need to grab a sqlite database browser. One can be found here.

 

WINDBG - QUALITY OF LIFE TWEAKS

We’re going to be spending a ton of time in the debugger, so it should be a debugger that sparks joy!

 

Typing .load pykd.pyd isn’t terribly hard, but doing it every time you restart your debugger can be irksome. We can automatically load the file with a pretty simple trick.

  • right-click on the windbg icon in the toolbar (assuming flare-vm put it there for you)
  • right-click on the windbg (x86) menu item
  • select properties

 

windbg-properties.png

 

Once we’re in the properties menu, perform the following

  • click on the Shortcut tab
  • add the following command-line option to the Target field: -c ".load pykd.pyd"

 

windbg-properties-2.png

Quote

This solution was something like the 7th comment to an unaccepted solution on stack overflow. I’m happy to think that my SO sleuthery will save others time and effort.

 

SANE LOGGING LOCATION

Without any configuration, mona.py stores command results beside the debugger’s exe. The exe is stored six levels deep under Program Files and isn’t exactly accessible. The command below will get the logging location squared away for us.

!py mona config -set workingfolder c:\monalogs\%p_%i

The %p will get populated with the debuggee’s name and the %i will be replaced by the debuggee’s pid. Ex. C:\monalogs\TFTPServerSP_1300

 

 

PERSONALIZED WORKSPACE W/ SCRATCHPAD

You can personalize WinDbg quite a bit. There are a few themes shipped with WinDbg, and some others can be found with google, though it’s not obvious how to work with them. WinDbg will read Workspace settings from the registry or a .wew file. If you’re loading a .reg file, you can simply double-click the file and it will load. However, we’ll be creating our own .wew file.

 

CREATE THE LAYOUT

We’ll take a look at my setup, which is pretty much default, with a slight modification. I like having WinDbg’s scratchpad open. It’s a convenient place for simple notes (usually addresses/offsets). It’s not open in the default configuration, so let’s fix that.

  • Open WinDbg
  • Press alt+8 to open the scratchpad
  • Position it wherever you like

 

My setup looks like this, with the scratchpad positioned to the right of the assembly window.

 

windbg-layout.png

 

ASSOCIATE THE SCRATCHPAD

If the scratchpad isn’t associated to a file on disk, the information disappears when the debugger exits. Fortunately, making the scratchpad persistent is easy.

 

First, right-click the scratchpad’s top bar and select Associate with file.... After that, simply pick a location (I store mine in C:\monalogs)

 

scratch-assoc.png

 

SAVE THE WORKSPACE

With a new layout created, we need to save it to disk. There are four different options to save a workspace… We want to use the Save Workspace to File... option. Store it wherever you like.

save-workspace.png

 

AUTOLOAD THE WORKSPACE

With the scratchpad setup and the workspace file saved somewhere, we need to configure windbg to load the workspace on startup. The premise is the same as what we used to autoload pykd. We just need to add the following command-line option to the Target field in WinDbg’s properties.

-WF "C:\Users\vagrant\Desktop\with_scratchpad.WEW"

windbg-properties-3.png

 

FURTHER CONFIGURATION

In case you want to go further, you could use some of the themes listed below as a starting point and tweak until you’re content.

 

OBLIGATORY OUTRO

The next post in this series will cover exploiting VulnServer’s TRUN command. Check it out here.

 

Source epi052.gitlab.io

  • Thanks 1
  • Upvote 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...