Saturday, June 9, 2012

Try Harder :)

So its now been 1 week since I first started this course and I must say its starting to kick me in the ass in some places. A prime example of this was today.While I obviously can't release all the details of the challenge, the specific challenge that I was struggling with was the extra mile challenge from chapter 6 of the lab. 

The second one was actually very hard to do. First off, the exploit must end in "}" for the exploit to be triggered, making it rather interesting to find out where to located your shellcode and how it would fit into the provided space. Second off, as noted in one of the fourms, you had to use a DLL from the application itself and not from the OS to get the POP POP RET to work for the SEH. This caused much frustration and confusion for me...though in actually it was pretty obvious that I should have done that as its standard to check application DLLs first, then OS DLLs as this makes the exploit more reliable (the application DLLs load in the same place across OS versions, where as many OS DLLs do.)

The third challenge was getting all of the bad characters sorted out. To do this I used generatecodes.pl and sent this as the payload, then manually checked the results. This allowed me to find that an extra character was also causing problems in addition to the standard ones I had already filtered out, and thus made the application execute the standard SEH handler as per normal.

The fourth and hardest challenged that faced me though was the limited space available for the shellcode. While I can't tell you what I did to go about it, I can say that Corelan's tutorials definitely helped here, and I was able to craft some shellcode that ultimately resulted in a bind shell on port 4444, created via a fairly standard msfpayload encoded to remove all the bad characters.

The main thing I want to point out here is that all of this was possible because when one faces the wall, you really do have to try harder. What I found works best is working at it in chunks. I worked till I felt like I was about to give up, tried a thing or two more, and, wait for the magic...., took a break. Yep. A break really does help, and it lets you calm down and think things through more. This last exploit took me literally a day to create (from 12 am to about 10 pm) on and off so it was a lot of work but the breaks helped to make things clearer.

Well thats all I have for now. :)

-tekwizz123

Wednesday, June 6, 2012

4 Days In

Yep thats all it took. 4 days in and i broke my machine somehow..... busy backing it up atm, so I thought it would be a good time to give an overview of my thoughts on this course.

So far its been an amazing course. I know im going to be reflecting the thoughts of others here but even if I don't pass, the amount of info and the clarity of its presentation is simply top notch for the most part (a few videos went a bit fast for me, but so far its only been 1-2)

Futhermore the extra mile challenges are, well, actually quite a challenge. So far i have done all of them except for the DNS extra mile challenge, which i skipped because i was too tired to do it then...will have to come back to that one.

As for the actual exploiting part, i managed to get a few boxes on the first day, followed by 1-2 a day on Monday and Tuesday. From there its kinda stopped, and i know have about 6 boxes so far. The total number of boxes in the lab is about 45 or so, so i still have a long way to go.

One of the most interesting things about this course though is that although they don't tell you how to exploit any of the machines, they do give you some help by walking you though how to do different enumeration techniques in the videos, and then ask you to perform these on the labs. This makes for a very enjoyable experience as you get to learn how Mutts would go about doing it, and then your given the opportunity to recreate that in the lab, both learning the skills and gaining knowledge that you will need for later pentests.

Now one of the many things that is asked when taking this course is how much programming language that you need. From my personal experience, walking into this course I had known some programming from my exploit development and Grey Hat Python book, but i had no experience in Bash whatsoever. Personally speaking, I do think you need a bit of programming knowledge to understand some sections reguarding Python if you don't want to get caught up and have to look everything up, but then again you could enter this course without any experience in it; it just might hinder your progress a little bit.

As for the bash side, if you don't know it don't worry. So long as you know how to move around and do basic things in Linux, you will be fine. Honestly I didn't know how the cut command worked at all, and Muts provided one of the best examples of it, and know I love it. /being lame comment Bash has sort of become my new best friend in a way /end lame comment

Overall, very very good course. Unfortunetly I can't say much more as im only beginning module 6 + I don't want to spoil the course for you guys who might be considering taking it.


Now im going to go fix this dang pc...........raaaaaagh.....i think i might also have some cookies with that ;)

-tekwizz123 (*munch*)

Friday, June 1, 2012

The Day Before....

Okay so its the day before PWB starts and im super bored so I thought I would give ya all an update.

Anyway, today I'm officially graduating from school :) Ceromony starts at 2pm and as I write this right now its 10:30 am, though I was up at 8 am after by bro busted into my room to find a calculator for his SAT test (yep today is one of those days)

This also means that im going to spend the good part of an hour waiting for my diploma, since i go last as my last name starts with a "W"......yaaay....big woop.

Futhermore that also means my family can't see me either......


Anyway enough about me, and onto my thoughts about PWB. Yesterday I asked around to find what would be the best way to prepare on my last day before the exam and some people have recommended that you do some boot2roots. (A great list can be found on g0tmi1k's website. Search google for "vulnerable by design" and you should find it)

So naturally I downloaded some, specifically all of the Kioptrix ones. So far as of this morning I have managed to get through the first three, though I had to ask for help on one of them (the second level) because the exploit on exploit-db is out of date, and thus won't work, and on another one.

Specifially that second one was an interesting lesson. This is something you may want to keep in mind when pentesting:

  • Don't upload php files to a server via wget without renaming them to .php.txt first.

Why? Well, if you don't rename the file, wget will automatically interpret that file for you on the server. Which is not good if all that results in is a shell on your own server rather than on the remote host hehe.

Yeah other than that i'm working on r00ting Kioptrix Level 4 atm, but it seems like one of the files is missing from the archive.....odd, but i'll figure it out soon.

Also have downloaded a few wordlists from g0tmi1k's site in case I need them for bruteforcing and went ahead and printed out his privledge escalation guide that will help me when I get stuck on getting r00t on the linux hosts.

That's pretty much all i have to say for now....lets see what tomorrow brings.

Friday, May 25, 2012

PWB

Okay just wanted to give a heads up to those who are interested.

Its finally offical. As of next Sunday, I am starting PWB from OffSec. What will follow over the next couple of weeks after this will be a weekly or semi-weekly (depending on how busy I am) journal of my current thoughts and opinions on the course. Please note I might take a while to post the entries as I don't want to leak course details that would ruin the fun for others.

Hope to see ya all soon,

tekwizz123

Monday, May 7, 2012

Set Up Your Windows XP for Fuzzing

A little guide I found that you will need to follow before you can do the fuzzing tutorial which will post later (its in video fourm so I need to find a place that accepts .ogv files hehe. Not too many places that do that though so might have to convert it)

Here you go:

https://github.com/OpenRCE/sulley/wiki/Windows-Installation

If you need a Windows XP box, you get one from following the steps mentioned in Offensive Security's Metasploit Unleashed course here:

http://www.offensive-security.com/metasploit-unleashed/Windows_XP_SP2_Setup

or just go torrent some random edition. Your choice. I don't care but you pay for what you get.


The tutorial should be up shortly :D

Wednesday, April 11, 2012

Upcoming Plans and Other Stuff....

So yeah sorry for the delay guys been busy getting stuff done for school (I do have a life outside of this you know :P )

Anyway as of yesterday I have been getting back to more security stuff and i'm happy to let you know that in a few weeks or so I'll be making a post on how to make your own fuzzer in Python and will be taking you step by step through the entire process. Expect this to take a little while as its going to take bit of time to try and explain everything and get it all down on paper.

Expect lots of programming, some internal windows fuction calls and other stuff that generally will make an average mind spin XD Hehe im just playing with ya. So long as you have strong grasp of some programming language, you should be fine. 

In the meantime, here is a video of the finished fuzzer running in action by downloading the video from here (apparently SWF files aren't supported by youtube or many popular video sites.... :(  :

http://www.filedropper.com/firstpythonfuzzerinaction

Sunday, April 1, 2012

PyCommands Tutorial

Hey guys so I have been playing around a lot with the Grey Hat Python book and just been walking through the book chapter by chapter so I thought I might share some of the stuff that I have learned so that a) it stays in my mind and b) you guys can also learn more.

Without futher ado, lets start!


Enter Immunity Debugger
Okay before I start I would like to provide a very brief intro into what I'm about to cover for those of you who might not know what PyCommands are.

Essentially PyCommands are commands (or more specifically, Python scripts) that you can run from within Immunity Debugger that allow you to essentially control various parts of the debugger while it is running. This essentially means that Immunity Debugger is what is known as a "scriptable debugger", and if you don't know what that means, please use your good friend Google who will kindly tell you a much better answer than I can provide here :)

Getting Started


Okay first off we are going to need to get Immunity Debugger, which can be downloaded from here:

http://debugger.immunityinc.com/register.html

Please note that the registration info is not needed. In fact you can just click next and continue on.

Next, take a look at the API help guide. While its not much it will help you to make future programs so go ahead and take a look though what functions Immunity Debugger provides for you. It might not make sense right now, but it will give you an idea of the power that is involved.

Access it by doing the following:

1. Open up Immunity Debugger
2. Go to Help, then select "Select API help file"
3. Go to the Documentation file under the Immunity Debugger installation file
4. Select IMMLIB.HLP

Also you can take a look at the online documentation located at http://debugger.immunityinc.com/Documentation/ (this address is new, some old books may reference a different address but this is the one that works atm)


Running A PyCommand

To run a command, make sure that it is in you PyCommands folder in Immunity Debugger and then find that white box at the bottom and enter:

        !(name of the script goes here) (arg1) (futher arguments)

And then once done, check the Log window (if you don't know where that is, then just go to View and then select Log)

Also please note that all of the scripts that we will be viewing/writing today are based on Python 2.x, not Python 3.x. Make sure you remember that as there are slight differences between the two, and thus this might affect your results. Just saying...feel free to use 3.x if you REALLY want to (hehe).


Basic Structure of A PyCommand Script
Okay what follows is what you need at a minimal outline to create PyCommand script:

*enter code mode*

#!/usr/bin/env python

from immlib import *

def main(args):
          # Instantiate a immlib.Debugger instance of the current debugger process that is running right now.
          imm = Debugger()

       *Any commands would go here at this point. Sorry about formatting as Blogger is a bi**h with code ;)*

         # This command is not required, its only so that the command returns input to the user so that they      know that the script is done (this is displayed below the white box where you enter the commands)
       
        return "[*] PyCommand Executed!"


* End code mode*


A Couple of Simple Commands + Bits of Information



  • imm.log("String goes here %d" % a number in this case, *if you want, instead of the code displaying 0xBADF00D, it will display the memory address you place here (note that the decimal value you place here will be converted into a hex value*)
    • This writes the given message to Immunity Debuggers logs (which can be viewed via View-> Logs). If an address is specified, then that is used in place of the address 0xBADF00D.
  • imm.updateLog()
    • Normally when a script runs, the log will only be updated after the script has finished running. If you want the logs to update at a certain spot instead of waiting till the end, then place this after your calls to imm.log() to have Immunity's logs update themselves right then and there. Useful if you doing CPU intensive processes and you want to notify the user of what's going on, however note that this will cause the process to take a bit longer to run than if you didn't use the updateLog() call.
  • imm.createTable('Name', ['name of column one', 'name of column two', 'and so on'])
    • Creates a table with the name (in this case Name) and then adds the columns with their given names to the table
  • table.add(0 , ["column one's value", "column two's value", "etc"])
    • Pretty self explanatory, 0 is just the number (starting from 0) of the table
  • imm.assemble(*insert your variable here*)
    • Transforms you variable into assembly code.
  • imm.search(*insert variable here*)
    • Searches all of the memory in the current process for your selected variable (which must be in assembly code mind you) and returns a list of addresses where it found that variable in memory.
  • imm.readMemory(address, size)
    • Read size bytes from the address located in address and return them.
  • imm.writeMemory(address, buf)
    • Write the assembly buffer buf into the address located at address
  • imm.ps()
    • List all the running processes and return (according to the docs) a "list of tuples with process information (pid, name, path, services, tcp list, udp list)"
  • imm.searchCommands(cmd)
    • Search in all loaded executables for a given command (the command must be given as a string) with newlines represented by "\n" (minus quotes)
  • imm.getRegs()
    • Returns a Dictionary of all of the x86 registers
  • imm.setRegs(reg, value)
    • Sets the register represented by the string reg to the DWORD value value.
  • imm.getPEB()
    • Get the PEB of the current process.
  • imm.getPEBaddress():
    • Returns the DWORD address of the current process's PEB.
  • imm.getAddress(expression)
    • Gets the address of expression (which is a string)
    • Ex: imm.getAddress("kernel32.Process32FirstW") -> returns the address of Process32FirstW which is used to iterate though available processes currently running on the system in case your interested ;)
Okay that should be enough for you to get most scripts done. If you need to write to a file at any time, the process is the same as you would do in a normal python script.

Some Example Scripts From Grey Hat Python

Again I claim no credit for these. They are all the work of Justin Setiz and all credit goes to him for creating these except for one which I will mention shortly.

badchar,py


*BEGIN CODE SEGMENT*

from immlib import *

def main(args):

    imm = Debugger()

    bad_char_found = False

    # First argument is the address to begin our search
    address = int(args[0],16)

    # Shellcode to verify
    shellcode = "<INSERT SHELLCODE HERE>"
    shellcode_length = len(shellcode)

    debug_shellcode = imm.readMemory( address, shellcode_length )
    debug_shellcode = debug_shellcode.encode("HEX") # We need to encode the debug_shellcode from assembly into hex format so that we can compare it to
                                                    # the shellcode we inserted just above here.

    imm.log("***************************************")

    imm.log("Address: 0x%08x" % address)
    imm.log("Shellcode Length: %d" % shellcode_length)


    #Begin a byte by byte comparison of the two shellcode buffers
    count = 0
    while count < shellcode_length:
        if debug_shellcode[count] != shellcode[count]:

            imm.log("Bad Char Detected at offset %d" % count)
            bad_char_found = True
            break

        count += 1

    if bad_char_found:
        imm.log("[*****]")
        imm.log("Bad char found %s" % debug_shellcode[count])
        imm.log("Expected to find: %s" % shellcode[count])
        imm.log("[*****]")

    else:
        imm.log("[*****]")
        imm.log("No bad characters found :) Your good to go!")
        imm.log("[*****]")        

    return "[*] !badchar finished, check Log window."

*END CODE SEGMENT*

Defeat IsDebuggerPresent (for use against malware)

This is the only piece of code that is mine. The creator of this technique was Damian Gomez of Immunity.

*BEGIN CODE SEGMENT*

from immlib import *

def main(args):
    imm = Debugger()


    # This is the initial test to see what it was before:

    result = imm.readMemory( imm.getPEBAddress() + 0x2, 1 )

    # At PEB + 0x2 in a process is the BeingDebugged variable which is what
    # the function IsBeingDebugged returns. If we set this to 0 then
    # IsBeingDebugged is tricked into thinking that the process is not being
    # debugged because hey, thats what the process is reporting right?
    # And thats one of many ways to get around anti-debugging techniques.

    result = result.encode("HEX")

    imm.log("Before the change: %s" % result)


    #Make the change

    imm.writeMemory( imm.getPEBAddress() + 0x2, "\x00" )


    # And print the new results

    result = imm.readMemory( imm.getPEBAddress() + 0x2, 1 )

    result = result.encode("HEX")

    imm.log("Result after change: %s" % result)

    return "!defeatDebuggerPresent is done."


*END CODE SEGMENT*


findantidep.py

Included by default in Immunity Debugger. This is a GUI program that takes you through the process of disabling DEP on a specific process you are debugging and then returning execution to the area of code your  shellcode is in. I will let you figure out how to use this because your probably smart enough to figure it out yourself if you have a need to use it (and space. may make separate tutorial on it as its an entire tutorial in itself to be honest)

End

Thats all fokes. Hopefully you can continue to use the examples given above in combination with the API guide to create some awesome scripts. And if you create something really awsome, let me know and if its good i'll post it up on here along with your name :)

And im out mates

-tekwizz123