Myne-us

Question: How does loader know ASLR is enabled for a binary?

2012-01-23T21:52:00.000-08:00

Most people know that ASLR randomizes the base address of the binary when loaded, but how does the loader know that a binary is ASLR capable? This is a fairly easy question to answer but from what I can tell is rarely documented as a detection method and the subject of this post.

In the PEHeader->IMAGE_OPTIONAL_HEADER there is a flag called DLLCharacteristics that defines many features for the executable on load, 1 of them being ASLR. If you look here IMAGE_OPTIONAL_HEADER structure sand croll down about mid way you will see the values it defines. If you look you will also notice this defines if DEP is enabled as well.

I created a little ruby script to give you access to these values over your whole file system, directories, or a file. There are many tools like cff explorer you can use to view these per a file but this one will give you the ability to crawl a file system to find multiple files with ASLR disabled, DEP disabled and more.

git dllcharacteristics

enjoy

QnA -> What is FS

2012-01-19T21:14:00.000-08:00

First off
1. I promise I will get the video out for Derbycon heap. I just got bored of doing editing so it is just sitting there raw right now.
2. I plan on updating and redoing the Journy into exploitation post to have some updated information and more content eventually.

Ok now the reason for this post, because I am so bad at posting or finishing posts on this blog and I have people asking for content I am going to attempt a new strategy. To help get information back out so people can learn and also help people along way I am going to start posting questions I get and the answers to them.
I am going to avoid posting questions on really easy topics and will usually link someone to a place to read on those topics but for topics that are either poorly documented or hard I will try to cover them. One of the major advantages for myself is if I don't know the answer it will give me something to do research on as well.

Topics i will cover.
Reverse Engineering:
Exploitation:
Security in general:

Preview question.

Q: What is FS?

I wrote a challenge some time back on Securabit podcast I am a part of as a fun exercise. The question came from someone trying to reverse this challenge.
The anti-debugging technique was accessing the PEB offset +68 to detect if the debugger is attached. This is set to 70 when a debugger is attached. To find the base address of PEB I accessed FS[30] and stored that in a register.
Ok I skimmed over some items there like why is it set to 70 and what is the PEB but that is not the question. The question is what is FS.?

FS is a segment register that was added with the release of protected x86 32bit operating systems. Typically, in win32, FS points to the base of the Thread Information Block of the current active thread in PEs.

To break this down even more when you commends such as


mov EBX, DWORD PTR DS[EAX]

the DWORD pointer is saying start with base address of DS (another segment register) and add the value EAX to this and store that in EBX. so when I accessed


mov EAX, DWORD PTR FS[30]

I was saying take the value in FS and add 30 to that and return what is there. This address stores the Base of the PEB.

Few other notes on FS:
FS[0] stores the pointer to the first SEH in the link list. This is usually called when an exception occurs in code.

FS points to the current active thread. This means a single application with multiple threads will have multiple pointers to different Thread Blocks.

Challenge
Source for Challenge

When fuzzers miss (REVISED), Derbycon talk.

2011-02-05T00:13:00.000-08:00

This post has been revised to reflect my talk at Derbycon on when fuzzers miss. I expanded on the explanations, added 2 more examples, code, slides and videos of each demo.

Each demo source and executable is in a zip below the corresponding video.

Link to derbycon talk

Fuzzing

Expansion fuzzing, this is the most common form of fuzzing. This is where you take a buffer and push characters inside of it slowly expanding the number of characters you push. This is to find overflows in improper bounds checking in it's simplest form.

Expansion fuzzing example:


 #!/bin/python
 from socket import *
 import sys

 if len(sys.argv) < 2:
  print "Usage: app.py ip port"

 ip = sys.argv[1]
 port = sys.argv[2]

 s = socket(AF_INET, SOCK_STREAM)
 s.connect((ip, int(port)))
 s.settimeout(2)

 for i in range(30000):
  try:
   s.send("A" * i)
   data = s.recv(1024)
   if data.chomp != "":
    print data
  except:
   pass
 s.close

Smarter:
Some fuzzers are a little more intelligent about how they handle the fuzzing process. They will take into account int wraps, special characters used in the protocol among many other things. These are fuzzers such as listed below as a small example
Spike, sully, ....

Brute force fuzzing:
Brute force is a time/accuracy trade off fuzzing. This is a technique where you try to push every variation of every character into a buffer possibly finding parsing issues or read issues. The below example is raw brute force buzzing and can take forever, it is suggested to be smart about input and not try to run this raw against a target unless you have a ton of processing power and time.

Brute force fuzzing example:


 import sys, time
 from socket import *

 class bruteforce:
  def __init__(self, ip, port):
   self.ipaddr = ip
   self.port = port

  def fuzz(self, val):
   try:
    s = socket(AF_INET, SOCK_STREAM)
    s.connect((self.ipaddr,int(self.port)))
    # Timeout for any hanging sockets
    s.settimeout(1) 
    s.send(val)
   except:
    # When fail print the characters 
    # failed to screen in hex format
    print "failed on value: "+val.encode('hex') 
   s.close
   return 0

  def run(self):
   size = 2**100000
   i = 0
   # have to use while because the size 
   # is too large to be handled in a for loop
   while i < size: 
    # convert int to hex
    val = hex(i).replace('0x', "") 
    if len(val)%2:
     # align the hex to make sure 
     # it is set to decode
     val = "0" + val 
    # decode the hex to a character
    data = val.decode('hex')
    
    self.fuzz(data)
    i += 1
    # setup timing for app so you don't 
    # flood it and fail on packets
    time.sleep(.01)     
   return 0


 if len(sys.argv) < 2:
  print "usage: brute_fuzz.py ip port"
  exit()

 # !!Warning before running this!!
 # if this prints the characters to the
 # screen it will lock up whatever prints the characters!
 # Operating systems do not like beep 
 # codes and this will flood it with beepcodes and stall

 fz = bruteforce(sys.argv[1], sys.argv[2])
 fz.run()

Listed Commands:
listing out commands that might be common exploit techniques specific for a protocol and running those quickly against a target.

This is my thought process in exploitation.
Reading:
I can not stress how important this is! Reading the application documentation, protocol RFC, and any files that get accessed by the application.
Discovery / vuln to exploit
this is a phase most of what this talk is based on so will not go over this at this point.
Technique:
this is where you get to where your shellcode is located once you have a POC running and offsets figured out.
Shellcode:
writing custom shellcode or using existing shellcode
Cleanup:
important process that can easily be skipped. review your exploit and make sure there are no bugs and see if there is anyplace you can reduce code.

This is a very simple exploit as an example to show where the vuln is located. The bottom left is the source code, the top left is the function for int overflowme() and on the right is the stack frame for overflowme(). this is what the stack looks like at point when EIP points to the call to gets.

In this slide we see the progression of the vulnerability. This shows when EIP is pointing to RETN and ready for the exploit to kick off. The conect of vulnerability vs the time the exploit kicks off is one of the keys behind this talk and is something throughout the slides I kept a theme to color all the vulnerable places in pink and the places where the exploit kicks off in red.

Time for the demos!
In each of these demos you will see bubbles the represent a function and arrows that show the order of calls and returns. if an arrow is pointing down it is a call to another function and if it is pointing up it returns back to that function. Keep an eye on the text colors as well pink = vulnerable place , red = where the exploit kicks off and what we want. Also keep in mind when something is pushed on the stack it will push up the function chain overwriting the stack frame from the higher function not the lower functions.

This is a post I made some time back that I merged into this post.

In this example we see that a char variable is set in StartProgram with a buffer size of 25. inside this function it calls get_login and prompts for a username and password. The vulnerability is in the username where it attempts to fill a 25 byte buffer with a 50 character input. This is a classic buffer overflow where EIP will be overwritten with whatever is pushed in the buffer. The trick to why a fuzzer will miss this is RETN is where the vulnerability is but it always stays in 1 function lower then where we work in unless we successfully log in.

demo1.zip

By finishing out the application and tearing down each stack frame we where now able to trigger our exploit.

Watch the stack when inputting data into a buffer, you should always follow the data you input in a buffer.

Threads can be really troublesome in exploit development. The only thread that really matters is the main thread that the application is running in. Any other thread can be destroyed at any period in time and no effect the application. This key problem will leave us with a vulnerability hanging out there without triggering the place the exploit kicks off.

We will also look at stacks and variables to show that when you overflow a buffer you are not just overwriting RETN address but also the data from other local vars below it and how this can cause issues.

In this example we have a single thread that opens off of startApp then calls authenticate to get the username and password. I have "main thread" shown next to the branching thread just to represent the fact that there are 2 threads running at that point. The vulnerability is in the password field allows 200 byte character set to be pushed into a 20 byte buffer and the exploit kicks off when this function returns. The key here is looking at verifyAuth and seeing when auth fails it just kills that thread and opens a new one with startApp(). To get this exploit to kick off we need to be able to successfully log in to break down the function block for veryfyAuth -> authenticate.

In the video I will also show examples where authenticate fails to auth because we stomp on the username on the stack causing the auth process to fail. This is another key that will cause you sometimes to hit the incorrect path to let an exploit trigger by just pushing As into the buffer without knowing what that buffer holds.

Demo2 Part1

Demo2 Part2

This can be tricky to find but taking the normal logic of following the data should allow you to see the overflow happen. From this point it is just looking at where the thread is terminated and trying to find a way to get it to start returning higher up the stack frames.

Also as shown in the video the location that the buffers get filled cause the overflow to stomp on a local variable before it. Paying attention to what buffer is for what can sometimes be challenging when following process. Setting a memory or hardware breakpoint on access to stack frames can sometimes help find this but most time this is just going to be manual work of watching where the buffers are located. One key thing to note here is the fact that if this where a pointer pushed onto the stack and not a variable you not may have control over execution in the future, so watch those local variables and overwrite to see if they may be used in a future path.

In this example we will start a look into the heap and something fairly obvious but often used exit(). The heap can often be a great place to show many examples of where fuzzers just fail at finding the exploitable areas. Most of the protections on the heap do not target the allocation but the free calls to the chunks. Just like RETN this has to do with watching for the place where the exploit kicks off and not watching the vulnerable call. Heap can have a lot of examples and location where the exploit kicks off so this makes things more difficult, in a use after free example we have to look for the use then an allocation in the future, in a double free we need to make sure we are looking for that second free and taking the correct path to make sure we are getting to it just to name a few.

In this example we will look at crashing an application using a standard heap overflow and a free to cause a crash when validating the free list. This application is a simple echo program, all it does is echo out anything you send it. After the first echo it will ask if you would like to keep echoing output, if Y then it will allocate the initial echo to heap using heapalloc and then continue to echo out in a while 1 loop anything you put in. the trick here to access free is to get out of the echo loop free the heapalloc and exit the application. To access free you need to type quit() which is not told to you. I put the hidden quit in because reversing and finding pathing such as this sometimes can help you get back where you need to be.

[video] !!!!Video is in the process of being edited will have it up soon.!!!!
demo3.zip

heap is more difficult in every way then stack overflows including finding flaws so some practice and thinking on where the exploit kicks off with practice will help find heap exploits

These are only a few examples of limitless possible reasons why buffers may have an overflow and not trigger the exception. The main thing to take form this is the thought process.

Here are some things I use to find exploits such as this.
- when pushing data into an application pay attention to functions and understanding how this would look like in C. If you want to find the exploitable area and not just the vuln follow the data.
-break/log RETN, Watch the call stack/ pathing/ stack frame. Also if program is threaded make sure to check all stack frames and not just the current thread's stackframe.
-break/log Free/alloc, When watching for heap exploit break on what controls the heap structure and dump the heap chunks
-all references to, find anything that references the data you pushed in to see if it is used someplace later in a strcat, strcpy or anything of this type
-diffing, if the program is already patched don't take the time finding the exploit when they give it to you in a diff
-all intermodule calls, use all call function calls to find where you may want to look and pull out specific stack frames looking for user controlled data
-tracing, this can take a ton of time but tracing application paths and finding areas you are not hitting looking for data to be accessed can help.
-Work!, this is not all easy so it is going to take some thinking and some of your own ideas.

if you have any questions or comments please post below, hit me up on twitter or irc

FOAM file fuzzer

2010-08-23T19:37:00.000-07:00

FOAM is a general purpose file fuzzer I wrote in order to find offset values quickly. It is written in python so you will need http://www.python.org/ on your system.

The script can be downloaded at https://sites.google.com/site/myneuslayout/tools

From 0x90 to 0x4c454554, a journey into exploitation.

2010-08-03T23:33:00.002-07:00

I put some time in and compiled a list in a course type layout to help people in process of learning exploit development. I hope my research will help others spend more time learning and less time searching.

First off I want to thank the corelan guys for the help they have provided me so far in the process.

layout: I will be posting in a hierarchical structure, each hierarchy structure should be fully understood before moving on to the next section. I will also post sets of Parallel learning topics that you can use to study in line with other topics to help prevent monotony. These Parallel areas will have a start and end mark which shows when they should be complete in perspective to the overall learning

desktop background Link to Backgrounds

Other Posts like this one:
Because of quality of these posts I wanted to put them at the top. I could not figure out where to put them in the list because they cover so much.
past-present-future of windows exploitation
smashing the stack in 2010
IT-Sec-catalog

Part 1: Programming

complete this section before getting to the book "Hacking Art of exploitation"

Learn Python the hard way

Wikibooks Python

http://docs.python.org/

onlinecomputerbooks.com

Grey hat python

Wikibooks Ruby

LittleBookOfRuby

Ruby Programmers Guide

onlinecomputerbooks.com

O'Reilly Learning Perl

onlinecomputerbooks.com

Cprogramming.com

http://www.java2s.com/Tutorial/C/CatalogC.htm

http://beej.us/guide/bgc/

onlinecomputerbooks.com

Skullsecurity: Assembly

Windows Assembly Programming Tutorial

http://en.wikibooks.org/wiki/X86_Assembly

The Art of Assembly

Assembly primer for hackers

PC Assembly Language

http://en.wikibooks.org/wiki/Windows_Programming

http://www.relisoft.com/win32/index.htm

Windows Internals 5

Windows Internals 4

http://en.wikibooks.org/wiki/X86_disassembly

The Art of Disassembly

Part 2: Getting started

Smash the stack for fun and profit (Phrack 49)

C function call conventions and the stack

Anatomy of a program in memory

Function Calls, Part 1 (the Basics)

IA-32 Architecture

Code Audit from cryptocity.net

Parallel learning #1 finished:

Hacking art of exploitation [Chapter 1&2]

Corelan T1

Corelan T2

complete this section before end of part 2

Kspice blog

Nullthreat's blog

A demo exploit

tenouk.com: Buffer overflow intro

The Tao of Windows Buffer Overflow

nsfsecurity on BOF

Hacker center: BOF

Buffer overflow Primer

Shellcoder's Handbook Ch1&2

Hacking art of exploitation [Chapter 3]

Corelan T3A

Corelan T3B

SEH Based Exploits and the development process

SEH overwrite simplified

Parallel learning #2 finished:

Part 3:Tools of the trade

Corelan: Immunity debugger cheatsheet

Part 4: Network and Metasploit

Beej.us network programming

Hacking art of exploitation [Chapter 4]

Socket Programming in ruby

Security Tube: Metasploit Megaprimer

Metasploit.com

Metasploit Unleashed

Metasploit Louisville Class

Metasploitable (a target)

Corelan T4

intern0t: developing my first exploit

DHAtEnclaveForensics: Exploit Creation in Metasploit

Wikibooks Metasploit/Writing Windows Exploit

Part 5: Shellcode

Corelan T9

projectShellcode: Shellcode Tutorial

Shellcoder's Handbook Ch3

Hacking art of exploitation [Chapter 5]

Writing small shellcode

Shell-storm Shellcode database

Advanced shellcode

Part 6: Engineering in Reverse

Understanding Code

Reverse Engineering the World

Reversing for Newbies

Room362.com reversing blog post

Ethicalhacker.net intro to reverse engineering

acm.uiuc.edu Intro to Reverse Engineering software

Reversing: secrets of reverse engineering

Reverse Engineering from cryptocity.net

CrackZ's Reverse Engineering Page

Reverse engineering techniques

CBM_1_2_2006_Goppit_PE_Format_Reverse_Engineer_View

HistoryofPackingTechnology

Windows PE Header

OpenRCE Articles

Crackmes.de

Part 7: Getting a little deeper into BOF

Exploit-db

Buffer overflow protection

The evolution of Microsoft's Mitigations

Purdue.edu: Canary Bit

Preventing the exploitation of SEH Overwrites with SEHOP

Bypassing SEHOP

Wikipedia Executable space protextion

Wikipedia DEP

Bypassing Hardware based DEP

Wikipedia ASLR

Symantec ASLR in Vista

Defeating the Stack Based Buffer Overflow Prevention

Corelan T6

Return to libc

microsoft protections video

Exploitation from cryptocity.net

Corelan T7

Corelan T8

Corelan T10

Virtual Worlds - Real Exploits

Gera's Insecure Programming

Smash the stack wargaming network

Part 8: Heap overflow

Heap Overflows for Humans-101

rm -rf / on heap overflow

w00w00 on heap overflow

Shellcoder's Handbook Ch4&5

h-online A heap of Risk

Defcon 15 remedial Heap Overflows

heap overflow: ancient art of unlink seduction

Memory corruptions part II -- heap

Read the rest of Shellcoder's Handbook

Part 9: Exploit listing sites

National Vulnerability Database

Common Weakness Enumberation

Part 10: To come

If anyone has any good links to add post a comment and I will try to add them or send me the link and I will review and add it.

If anyone finds any bad or false information in any of these tutorials please let me know. I do not want people reading this getting bad information.

packetwars event

2010-07-09T22:09:00.000-07:00

Packetwars is a hacker challenge competition that is put together for people to test their skills against some known vulnerable real world targets. When attending this event I got to go against a few of these setups and see what they had to offer. With a variety of different vulnerabilities available I found it to be not only fun but valuable. If you feel you are up to the challenge attend Daycon IV on Oct 22nd and 23rd.

Site: www.packetwars.com
Conference: http://www.day-con.org/127.0.0.1.html

////When you submit your form include my name (myne-us) to save 50% on admission till the end of July.\\\\

Myne-us

Free to learn

2010-06-19T21:41:00.000-07:00

Places to go online to learn for free. This is a small list but I tried to just keep it to some of the good ones.

Courses
http://www.offensive-security.com/metasploit-unleashed/
http://www.youtube.com/user/StanfordUniversity
http://www.youtube.com/user/MIT
http://www.corelan.be:8800/
http://pentest.cryptocity.net/

books
http://freecomputerbooks.com/compscHardwareBooks.html
http://www.scribd.com/

Other
http://www.shell-storm.org/papers/index.php?lg=english
http://www.securitytube.net/
http://www.theacademypro.com/index.php
http://www.hackerscenter.com/index.php?/Video/General/

Enjoy!
Myne-us

practice makes perfect

2010-05-13T09:39:00.001-07:00

This is a list of sites and images where you can practice your skills. Enjoy!

http://de-ice.net/hackerpedia/index.php/De-ICE.net_PenTest_Disks

http://netwars.info/

http://www.dvwa.co.uk/

http://www.damnvulnerablelinux.org/

http://hackerdemia.com/

http://www.badstore.net/

http://www.mavensecurity.com/web_security_dojo/

http://www.fatetek.net/training.shtml

http://www.net-force.nl/challenges/

http://www.enigmagroup.org

http://listbrain.awardspace.biz

http://haxme.org/missions/

http://www.hackquest.de/index.php

http://www.hackthissite.org/

http://challenges.ihtb.org/

http://www.dareyourmind.net/menu.php

http://www.intruded.net/wargames.html

http://www.hellboundhackers.org/

http://www.bright-shadows.net/

http://www.irongeek.com/i.php?page=security/deliberately-insecure-web-applications-for-learning-web-app-security

http://www.makeuseof.com/tag/top-5-websites-to-learn-how-to-hack-like-a-pro/

http://www.try2hack.nl/

http://www.astalavista.com/index.php?app=hackingchallenge

http://www.trythis0ne.com/?page=home

http://www.hackertest.net/

http://hax.tor.hu/warmup1/

http://www.caesum.com/game/

http://crackmes.de/

http://www.hack4u.org/index.php?choices=1&code=level0

http://community.core-sdi.com/~gera/InsecureProgramming/

http://testasp.acunetix.com/Templatize.asp?item=html/about.html

http://test.acunetix.com/disclaimer.php

http://ha.ckers.org/challenge/

http://ha.ckers.org/challenge2/

http://community.core-sdi.com/~gera/InsecureProgramming/LinkedBy.html

http://www.overthewire.org/wargames/

http://www.smashthestack.org/

http://www.wechall.net/index.php

http://hackme.ntobjectives.com/

http://wocares.com/xsstester.php

http://www.osix.net/

http://projecteuler.net/index.php?section=problems

http://uva.onlinejudge.org/index.php?option=com_onlinejudge&Itemid=8&category=3

http://www.rootcontest.com/

http://www.cyber-wars.com/

http://roothack.org/

http://www.mod-x.co.uk/main.php

http://www.introversion.co.uk/uplink/about.html

http://whitewolfsecurity.typepad.com/

https://www.vte.cert.org/vteweb/RequestAccess/GetAccess.aspx

http://lost-chall.org/

http://hax.tor.hu/peek/

http://www.hacker.org/

http://thisislegal.com/

http://www.happyhacker.org/wargame/index.shtml

http://neworder.box.sk/link.php

http://www.webantix.net/hacking/war-games-current-and-past-hacking-simulators-and-challanges/

http://www.lifedork.net/wargames-online-hackers-training.html

http://www.room362.com/blog/2009/5/29/getting-your-fill-of-security.html

http://hack.thebackupbox.net/cgi-bin/pageview.cgi?page=wargames

http://ace.delos.com/usacogate

http://zero.webappsecurity.com/banklogin.asp?serviceName=FreebankCaastAccess&templateName=prod_sel.forte&source=Freebank&AD_REFERRING_URL=http://www.Freebank.com

(if anyone had anything to add to these let me know and I will update the list.)

SSH tunnel pivot

2010-05-11T19:16:00.000-07:00

Hello everyone. Have some new videos posted about ssh tunneling and pivots.
Let me know what you think and if have any suggestions.

part 1

Part 2

Part3

Link to De-ICE
http://de-ice.net/hackerpedia/index.php/De-ICE.net_PenTest_Disks

core commands
SSH -L localport:targetip:targetport username@pivotmachine
ncat 127.0.0.1 localport
nmap -sV -p[localport] 127.0.0.1

thanks
Myne-us

Welcome

2010-02-10T19:53:00.001-08:00

Hello

I'm Myne-us